У нас есть сайт на WordPress, где мы используем Discourse для входа и комментирования в WordPress.
Всё работало нормально, пока мы не перенесли WordPress (который всегда работал на отдельном сервере) на новый IP-адрес и другой сервер.
С тех пор в классическом редакторе появились статьи с настройками, показанными на изображении ниже, для которых ссылка на Discourse не создаётся даже после автоматической публикации.
Мне всегда приходится вручную открывать конкретную статью, просто сохранять её, и тогда ссылка на Discourse создаётся, и всё работает как надо.
Есть ли какие-то идеи, где искать причину проблемы?
Кто-нибудь подсказывает, где может быть проблема?
Единственное упоминание об ошибке, которое я нашел в логе, — это сообщение ниже, но мне не удалось найти ничего по этой записи.
Ошибка вебхука, которую вы видите сразу после этого, указывает на проблему с вебхуком, но это не обязательно свидетельствует о проблеме с самой публикацией.
Если вы сможете запустить новый тест, воспроизведя проблему, и посмотрите на созданные логи publish, это даст нам представление о проблеме, которую вы описали.
Также, не могли бы вы уточнить, что вы имеете в виду под «перевести статью»?
Я всегда должен вручную заходить в конкретную статью и просто переводить её
Я подозреваю, что ваша установка Discourse могла закэшировать запись DNS и использует IP-адрес вашей старой установки WP. Самый быстрый способ проверить это — перезапустить контейнер и посмотреть, исчезнет ли проблема.
Скорее всего, в логе отображается запись о состоянии, когда я сохранял статью вручную. Извините, это опечатка: должно было быть «сохранить вручную». Я тоже подумал о DNS и сразу после переноса WordPress на новый сервер выполнил команду «./launcher rebuild app», но, возможно, с точки зрения DNS это было слишком рано. Попробую ещё раз.
Извините, просто уточню: вы имеете в виду, что лог не связан с проблемой автоматической публикации, о которой вы сообщили? Если нет, не могли бы вы предоставить лог события автоматической публикации?
Мне очень трудно понять по журналу, связаны ли конкретные строки с проблемой или нет. Я внес несколько изменений, касающихся DNS, и посмотрим, поможет ли это, когда следующая статья выйдет в 10 часов.
Итак, текущая проблема заключается в том, что когда статья в WordPress должна автоматически опубликоваться в определённое время, ссылка на сообщество Discourse не создаётся. Однако если я впоследствии вручную отредактирую проблемную статью и просто сохраню её без каких-либо изменений, ссылка на сообщество Discourse будет создана.
В следующий раз, когда выйдет статья, найдите логи с меткой publish.INFO или publish.ERROR с похожей временной меткой и поделитесь здесь тем, что обнаружите.
Хорошо, ваша проблема — это старая проблема автоматической публикации запланированных сообщений.
Наиболее вероятная причина в том, что один из других плагинов на вашем сайте также подключается к вашей системе планирования, вызывая проблемы, с которыми другие сталкивались ранее. Судя по вашему списку плагинов, вероятным кандидатом является:
WordPress Editorial Calendar - 3.8.5
Попробуйте отключить его и посмотрите, сохранится ли проблема.
Как именно вы вызываете задачу cron? Обратите внимание, что при вызове wp cron на запрос влияют любые глобальные параметры wp: Config – WP-CLI – WordPress.org. Возможно, что-то в вашем конфигурационном файле wp влияет на то, как обрабатывается задача.
Эта команда запустит все запланированные задачи cron WordPress:
wp cron event run --due-now
Если вы вызываете только wp cron event run publish_future_post, возможно, события, необходимые для плагина WP Discourse для публикации поста, не срабатывают. Я думаю, это эквивалентно тому, как WordPress обрабатывает запланированные публикации внутри:
wp cron event run publish_future_post future_to_publish publish_post transition_post_status
Я не тестировал это. Я настраиваю новый компьютер и пока не установил на него сайт WordPress. Я сделаю это скоро.
