Подключение WP Discourse к локальному экземпляру Discourse с конкретной версией

Я только что попробовал установить этот плагин на WordPress 6.7.2 с php-fpm-8.3.17-1.fc41.x86_64, но он не работает. При нажатии кнопки «Сохранить параметры» в логе появляется следующая ошибка:

[2025-02-21 17:15:13] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"От Discourse получен некорректный ответ","http_code":"","http_body":""} 

В файле /var/log/php-fpm/www-error.log есть соответствующие ошибки:

[21-Feb-2025 17:14:42 UTC] PHP Warning:  Undefined array key "url" in /wordpress/wp-content/plugins/wp-discourse/lib/discourse.php on line 301

Я вижу, что та же ошибка сообщается в «дымовом тесте» по адресу https://plugintests.com/plugins/wporg/wp-discourse/latest.

Редактирование: Забудьте об ошибке неопределённого URL. Похоже, это была просто начальная ошибка, возникшая до заполнения веб-формы. Однако ошибка wpdc_response_error по-прежнему повторяется каждый раз при нажатии кнопки «Сохранить параметры».

Редактирование 2: С стороны Discourse я вижу ошибку 403 Forbidden, но мне неясно, почему соединение с моего сайта WordPress блокируется. Я могу успешно использовать тот же API-ключ с помощью curl.

Completed 403 Forbidden in 33ms (Views: 0.3ms | ActiveRecord: 15.1ms (2 queries, 0 cached) | GC: 2.2ms)

Я запускаю Discourse 3.5.0.beta1-dev в режиме разработки.

Редактирование 3: Я обнаружил, что в этой версии Discourse существуют специальные разрешения WordPress для API-ключа. Использование «Granular» вместо «Global» и установка флагов в разделе WordPress устранило ошибки 403 Forbidden. Однако я по-прежнему получаю пустые/некорректные ответы, отправляемые на WordPress.

Delivering messages [] to client d9fbb33f11ed404bbc361c459802c87d for user 1 (chunked)

Похоже, мне нужно использовать более старую версию Discourse с плагином для WordPress. Какая последняя версия совместима с ним?

Привет, @Gregory_Bartholomew, давайте попробуем разобраться в вашей проблеме.

Это работает с последней версией Discourse.

Когда вы говорите, что запускаете Discourse «в режиме разработки», вы имеете в виду, что запускаете его локально? Если нет, то в какой среде вы его запускаете?

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

Спасибо. Я сейчас пытаюсь переустановить Discourse. Для тестирования я выбрал версию 3.3.0.

Я пытаюсь установить Discourse локально, а не использовать Docker-контейнер, из-за ошибки в ZFS, которая мешает успешной сборке контейнера на файловых системах ZFS (проблема pnpm 7024). При локальной установке я могу обойти эту ошибку, добавив package-import-method=hardlink в .npmrc перед запуском pnpm install.

Я имел в виду, что у меня было установлено RAILS_ENV=development. Сейчас я попробую снова с RAILS_ENV=production.

Также я пытаюсь переработать руководство, на которое я ссылался выше, чтобы оно работало на Fedora Linux.

Редактирование: С версией 3.3.0 у меня не очень получается.

$ pnpm install
 WARN  Поле "workspaces" в package.json не поддерживается pnpm. Вместо этого создайте файл "pnpm-workspace.yaml".
 ERR_PNPM_INVALID_SELECTOR  Не удалось разобрать селектор "**/unset-value"

Попробую снова с версией 3.4.0 и посмотрю, как всё пойдёт. :confused:

Что ж, я переустановил Discourse в версии 3.4.0:

Однако мне не удалось запустить его в режиме production. Не совсем понимаю, почему. Просто появилось сообщение «Oops …», и в логах было не так много информации. Думаю, проблема могла быть связана с какими-то настройками прокси, но я не уверен.

В любом случае, я вернул переменную RAILS_ENV в значение «development», и система запустилась. Тем не менее, при попытке подключения из WordPress я всё ещё получаю ту же ошибку:

[2025-02-21 22:11:06] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"An invalid response was returned from Discourse","http_code":"","http_body":""} 

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

GET "/site.json" for 000.123.456.789 at 2025-02-21 16:11:05 -0600
10:11 pm
Processing by SiteController#site as JSON
10:11 pm
ApiKey Load (9.0ms) SELECT "api_keys".* FROM "api_keys" WHERE (revoked_at IS NULL) AND "api_keys"."key_hash" = '3f27a89fedae42123b9ad596fae6c06d36748f53bd241213941083af49cf5e46' ORDER BY "api_keys"
10:11 pm
ApiKeyScope Load (10.6ms) SELECT "api_key_scopes".* FROM "api_key_scopes" WHERE "api_key_scopes"."api_key_id" = 1
10:11 pm
User Load (8.1ms) SELECT "users"."id", "users"."username", "users"."created_at", "users"."updated_at", "users"."name", "users"."last_posted_at", "users"."active", "users"."username_lower", "users".
10:11 pm
UserOption Load (6.1ms) SELECT "user_options"."user_id", "user_options"."mailing_list_mode", "user_options"."email_digests", "user_options"."external_links_in_new_tab", "user_options"."enable_quoti
10:11 pm
Group Load (8.6ms) SELECT "groups"."id", "groups"."name", "groups"."flair_icon", "groups"."flair_upload_id", "groups"."flair_bg_color", "groups"."flair_color" FROM "groups" ORDER BY groups.name ASC
10:11 pm
(7.0ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."read_restricted" = FALSE
10:11 pm
(10.7ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."read_restricted" = TRUE
10:11 pm
Topic Count (4.1ms) SELECT COUNT(*) FROM (SELECT 1 AS one FROM "topics" WHERE "topics"."deleted_at" IS NULL LIMIT 16) subquery_for_count
10:11 pm
(6.1ms) SELECT "users"."id" FROM "users" INNER JOIN "user_auth_tokens" ON "user_auth_tokens"."user_id" = "users"."id" WHERE "users"."admin" = TRUE AND (users.id > 0) ORDER BY user_auth_tokens.crea
10:11 pm
(8.5ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."topic_featured_link_allowed" = TRUE
10:11 pm
ColorScheme Load (6.8ms) SELECT "color_schemes".* FROM "color_schemes" WHERE (color_schemes.id NOT IN (SELECT color_scheme_id FROM theme_color_schemes)) AND "color_schemes"."id" = 1 LIMIT 1
10:11 pm
ColorSchemeColor Load (7.8ms) SELECT "color_scheme_colors".* FROM "color_scheme_colors" WHERE "color_scheme_colors"."color_scheme_id" = 1 ORDER BY id ASC
10:11 pm
(6.0ms) SELECT "group_users"."group_id" FROM "group_users" WHERE "group_users"."user_id" = -1
10:11 pm
(8.0ms) SELECT "category_users"."category_id", "category_users"."notification_level" FROM "category_users" WHERE "category_users"."user_id" = -1
10:11 pm
UserField Load (9.5ms) SELECT "user_fields"."id", "user_fields"."name", "user_fields"."created_at", "user_fields"."updated_at", "user_fields"."editable", "user_fields"."description", "user_fields".
10:11 pm
Completed 200 OK in 256ms (Views: 0.3ms | ActiveRecord: 116.4ms (15 queries, 0 cached) | GC: 94.6ms)

Думаю, я сделаю перерыв в этом вопросе на некоторое время, но если у вас есть какие-то идеи, что может быть не так, буду признателен за подсказки. :slightly_smiling_face:

Я перенёс эту беседу в отдельную тему, так как проблемы, с которыми вы столкнулись, могут запутать других пользователей, использующих стандартные настройки.

Итак, подытожим:

  1. Вы запускаете Discourse на локальной машине.
  2. Вы используете конкретные версии. В данный момент у вас установлена версия 3.4.0.
  3. Вы пытаетесь подключить ваш локальный экземпляр к удалённому экземпляру WordPress.

Верно ли это? Также, пожалуйста, уточните следующее:

  1. Как вы подключаетесь к удалённому экземпляру WordPress со своей локальной машины? Используете ли вы ngrok?
  2. Почему вы используете конкретные версии Discourse вместо последней версии?
  3. Какова ваша общая цель в данном случае?

Да.

Да.

Мой тестовый экземпляр WordPress также работает локально.

Нет, всё работает локально. У меня запущены два экземпляра httpd, слушающие разные IP-адреса (один для WordPress, другой для Discourse). Экземпляр WordPress работает непосредственно на моей хост-системе, а экземпляр Discourse — в контейнере systemd-nspawn. И хост-система, и контейнер работают под управлением Fedora Linux 41.

Сначала я попробовал запустить Docker-версию, но она не собиралась на моей тестовой машине. Изучив сообщение об ошибке, я нашёл открытый отчёт об ошибке, в котором указывалось, что проблема связана с файловой системой ZFS. Я не знаю, как изменить образ Docker, чтобы применить обходное решение, поэтому нашёл инструкцию по клонированию исходного репозитория и сборке Discourse с её использованием.

Сначала я собрал последнюю версию (3.5.0.beta1-dev), но поведение казалось отличным от того, что показано в вашем видео. В логах Discourse при попытке WordPress подключиться с помощью ключа API (когда разрешения были установлены в значение “Global”) я видел ошибку 403 Forbidden. Изменение разрешений на “Granular” и установка всех флагов для WordPress позволяло запросам продвигаться дальше, но WordPress получал пустые/некорректные ответы. Затем я заметил на https://blog.discourse.org/, что последней рекомендуемой версией является 3.4, и пришёл к выводу, что некоторые проблемы, с которыми я столкнулся, могли быть связаны с тем, что я пытался запустить предрелизную версию. Я попробовал git checkout v3.3.0, думая, что она будет достаточно старой для полной совместимости с плагином WordPress, который я тестирую, но она не собиралась на моей системе, поэтому я переключился на версию 3.4.0, и она, похоже, работает (хотя и в режиме “development”).

На самом деле я просто хочу поэкспериментировать с плагином WordPress Discourse и разобраться в его работе. Мне вообще не важен сам Discourse. Мне просто нужно что-то для тестирования. Когда я разберусь, как всё работает, я, возможно, попробую установить плагин на продакшн-сайт (fedoramagazine.org) и перенаправить комментарии на продакшн-экземпляр Discourse по адресу discussion.fedoraproject.org.

Это самое печальное, что я когда-либо читал на этом форуме! :lolsob:

Проблема, скорее всего, связана с вашей локальной настройкой и сетью. Она не вызвана версией Discourse или различием между глобальными и точечными ключами. Мне будет сложно отладить проблемы межсоединения вашего локального приложения, особенно учитывая разнообразие способов и сред, в которых можно запускать WordPress и Discourse локально. Вот несколько советов, которые помогут вам.

  1. Всегда используйте последнюю версию Discourse, WordPress и плагина WP Discourse.
  2. Используйте порт 3000 вместо порта 4200 в URL локального Discourse в настройках WP Discourse.
  3. Убедитесь, что созданный вами ключ может использоваться именем администратора, которое вы установили как имя пользователя для публикации.

Ниже показано, как выглядит моя локальная настройка, где мой локальный WordPress и Discourse подключены друг к другу. Для запуска WordPress локально я использую MAMP Pro.


Сработало!!!

Спасибо за совет о прямом подключении к порту 3000. Похоже, именно это и сыграло решающую роль.

Одно замечание (по крайней мере, в моей локальной конфигурации): мне также потребовалось установить ALLOW_EMBER_CLI_PROXY_BYPASS=1 перед запуском ember-cli.