Программное изменение слага через functions.php, но возвращает 404

Вопрос или проблема

Я хотел изменить слаг определенного типа записи (в данном случае, статья) на значение из его пользовательского поля.

Я зашел в functions.php и вставил этот код.

function na_remove_slug( $post_link, $post, $leavename ) {

if ( 'article' != $post->post_type || 'publish' != $post->post_status ) {
    return $post_link;
} 

# получаем значение пользовательского поля, которое будет слагом
$post_name = get_field('filter_category', $post->ID)->post_name; 
# заменяем "article" значением пользовательского поля
$post_link = str_replace( "https://wordpress.stackexchange.com/" . $post->post_type . "https://wordpress.stackexchange.com/", "/$post_name/", $post_link ); 
    return $post_link;
}
add_filter( 'post_type_link', 'na_remove_slug', 10, 3 );

Когда я запрашиваю пользовательские типы записей, кажется, что их слаг был изменен, например:
www.example.com/article/some-title на www.example.com/design/some-title

Где design — это значение моего пользовательского поля.

Но когда я в конце концов посещаю www.example.com/design/some-title, я получаю 404. Но если я посещаю www.example.com/article/some-title, он возвращает правильную веб-страницу.

Я понимаю, что мой код только изменяет то, как ссылка отображается, но как я могу правильно показать свою одиночную запись, используя слаг, который я изменил?

Если вам нужно больше разъяснений, не стесняйтесь комментировать.

Вы можете попробовать этот плагин, я думаю, это сработает для вас. Вы можете напрямую изменить URL на своей странице, нажав на URL на любое, что хотите.

Надеюсь, это будет полезно.

Ответ или решение

Вопрос, который вы подняли, касается настройки «постоянных ссылок» (URL) в WordPress, конкретно изменения слага (slug) пользовательского типа записи «article» в значение, хранящееся в пользовательском поле. Проблема заключается в том, что, хотя слаг визуально изменяется в ссылке, фактическая страница по этому адресу возвращает ошибку 404. Давайте рассмотрим, как можно решить эту проблему, и что необходимо сделать для корректного отображения страницы.

1. Понимание механизма работы слагов

Слаг — это часть URL, которая позволяет уникально идентифицировать запись. В вашем коде вы изменяете визуальное представление ссылки на пост, однако WordPress по умолчанию ищет записи по оригинальному слагу, который сопоставлен с типом записи «article». Сслыка на новую версию (например, www.example.com/design/some-title) не может быть обработана должным образом, если WordPress не знает, что эта запись также существует под новым слагом.

2. Модификация вашего кода

Для успешного изменения слага поста и предотвращения возникновения ошибки 404, необходимо создать дополнительную логику обработки. Приведем пример более полной функции, которая учитывает эти изменения:

function na_remove_slug($post_link, $post, $leavename) {
    if ('article' != $post->post_type || 'publish' != $post->post_status) {
        return $post_link;
    }

    $post_slug = get_field('filter_category', $post->ID); // Получаем значение кастомного поля
    if ($post_slug) {
        $post_link = str_replace('/article/', '/' . $post_slug . '/', $post_link); // Заменяем слаг
    }

    return $post_link;
}
add_filter('post_type_link', 'na_remove_slug', 10, 3);

3. Обновление правил перезаписи

После изменения слага потребуется обновить правила перезаписи (rewrite rules). Это позволит WordPress правильно сопоставлять URL. Для этого добавьте следующий код в ваш файл functions.php.

function na_rewrite_rules() {
    add_rewrite_rule(
        '^([^/]+)/([^/]+)/?$',
        'index.php?article=$matches[2]',
        'top'
    );
}
add_action('init', 'na_rewrite_rules');

4. Сброс правил перезаписи

После добавления этой функции вам потребуется сбросить правила перезаписи. Это можно сделать через панель управления WordPress, просто зайдя в Настройки > Постоянные ссылки и сохранив изменения (даже не внося в них никаких изменений).

5. Проверка и тестирование

После внесения всех изменений обязательно протестируйте новые URL, чтобы подтвердить, что они ведут к соответствующим записям. Перейдите по новому слагу (например, www.example.com/design/some-title), и убедитесь, что страница загрузилась успешно без ошибки 404.

6. Заключение

Это решение должно помочь вам корректно перенаправлять и отображать записи с измененными слагами. Однако желательно также учесть возможность разработки комбинации плагина для более простого управления слагами, если функционал потребуется расширить. Удачи в вашем проекте! Если возникнут дополнительные вопросы, не стесняйтесь обращаться за разъяснениями.

Оцените материал
Добавить комментарий

Капча загружается...