Проблема с постоянными ссылками в многосайтовом режиме

Содержание

Вопрос или проблема
Ответ или решение
Решение проблемы
Заключение

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

У меня есть мультисайт WP на AWS с сервером на базе nginx. Также активирована автомасштабируемость. По какой-то причине, и только для некоторых страниц (в основном для пользовательских типов записей), после каждого развертывания данные этих CPT будут выдавать 404 ошибки.

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

Теперь, поскольку мы разворачиваем сайт с помощью codedeploy, я добавил скрипт wpcli, который сделает это за меня.

exec("~/bin/wp site list --json --field=url", $siteOuput, $return);

$siteList = json_decode($siteOuput[0], true);

foreach($siteList as $siteUrl) {
    exec("~/bin/wp rewrite flush --url=$siteUrl", $permalinkOutput, $return);
}

Это, казалось, работает (у нас есть журналы, в которых говорится, что сброс постоянных ссылок был успешным для сайтов). Однако, похоже, это не так. Когда я перехожу к CPT, он выдает 404 ошибку, и мне нужно вручную перейти в настройки и пересохранить постоянные ссылки.

Правила переопределения установлены в базе данных, поэтому это крайне запутывающе. Кроме того, сброс постоянных ссылок из wpcli явно не работает, так есть ли здесь разница между контекстом веба и cli?

Я пытался инициировать вызов к маршруту rest, который имел логику для сброса постоянных ссылок, но это тоже не сработало (снова здесь я подозревал, что это не сработает из контекста REST API).

У кого-нибудь есть идеи, в чем может быть проблема и как это исправить? Основная проблема в том, что когда происходит событие автомасштабирования, постоянные ссылки ломаются :S

Итак, проблема заключалась в пользовательском маршруте rest, который имел вызов к flush_rewrite_rules(), который (насколько я вижу) сбрасывал постоянные ссылки на значения по умолчанию и нарушал структуру постоянных ссылок.

Как только мы удалили все вызовы к пользовательскому маршруту, 404 ошибок больше не возникало.

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

Проблема с перmalink на вашем мультсайтовом WordPress, которая проявляется в виде 404 ошибок после развертывания, связана с тем, как выполняется сброс правил перmalink. Ваша текущая реализация через скрипт WP-CLI не дает ожидаемого результата. Давайте рассмотрим, как вы можете решить эту проблему более эффективно.

Решение проблемы

Проблема с настройками REST API и flush_rewrite_rules():
Как вы уже заметили, вызов flush_rewrite_rules() в вашем пользовательском маршруте REST API приводит к сбросу четко установленных правил перmalink на значения по умолчанию. Это может произойти, если вы не передаете корректные параметры для вашего пользовательского типа записи или если пользовательские правила не зарегистрированы должным образом.

Убедитесь, что вы вызываете flush_rewrite_rules() только после того, как вы зарегистрировали свои пользовательские типы записей и таксономии. Избегайте вызова этого метода до регистрации всех необходимых компонентов.
Настройка правильного порядка выполнения:
Проверьте порядок, в котором выполняется ваш скрипт WP-CLI. Возможно, он выполняется до или после регистрации пользовательских типов записей. Убедитесь, что все необходимые функции, связанные с вашим пользовательским типом записи, выполняются до сброса правил. Это можно проверить, переместив вызовы в нужное место или используя add_action с соответствующими хуками, такими как init или after_switch_theme.
Операции в веб и CLI контекстах:
Действительно, в некоторых случаях выполнение кода в CLI и веб-контексте может привести к различиям в поведении, особенно если вы используете глобальные переменные или значения параметров, специфичных для сессий. Убедитесь, что при выполнении WP-CLI вы используете правильный контекст и пытаетесь избежать блокировок вызовов, если это не обязательно.

Замените код для сброса перmalink:
Вместо использования скрипта для сброса перmalink через WP-CLI, попробуйте добавить дополнительные условия для автоматической установки корректной структуры после каждого развертывания:

add_action('init', function() {
   // Проверяем, если это не админ и не AJAX запрос
   if (!is_admin() && !defined('DOING_AJAX')) {
       // Проверяем, если это запрос к вашему кастомному типу записи
       if (get_post_type() === 'ваш_кстомный_тип') {
           flush_rewrite_rules();
       }
   }
});

Настройки Autoscaling:
Вам также необходимо убедиться, что все ваши серверы масштабируются и правильно обрабатывают кэширование. Закругляйте любые кэшированные объекты после развертывания для обеспечения согласованности.

Заключение

Попробуйте убрать вызовы к вашему пользовательскому маршруту REST API, которые вы используете для сброса правил перmalink. Убедитесь, что все пользовательские типы записей и таксономии зарегистрированы до их вызова. Вместе с тем, не забудьте проверить конфигурацию вашего Autoscaling на предмет возможных кэшей, которые могут мешать корректной работы сайта.

Если после применения этих изменений проблема сохраняется, рекомендуется провести отладку ошибок через логи и внимательно следить за изменениями в базе данных, особенно в таблице wp_options, где прописаны правила перmalink.