Последний коммит в плагин WP-Discourse приводит к тому, что все пользовательские посты (созданные через плагин EventON) приписываются пользователю system, несмотря на то, что пользователь существует как в Discourse, так и в WordPress.
Если откатиться к версии 2.3.7, всё работает как ожидалось, но обновление до версии 2.3.8 вызывает эту ошибку.
Мы получаем следующее сообщение об ошибке по электронной почте:
Причина сбоя:
От Discourse был получен код ответа 400.
Отсутствует параметр или его значение пустое: post
Возможно, вы имели в виду? post
post[raw]
controller
title
Думаю, эта информация поможет выявить вероятную причину проблемы.
[2022-02-21 08:07:11] publish.INFO: create_post.post_success {"wp_title":"[Please Ignore] Test Event","wp_author_id":"3958","wp_post_id":126070,"discourse_post_id":""}
[2022-02-21 08:07:11] publish.INFO: create_post.body_valid {"wp_title":"[Please Ignore] Test Event","wp_author_id":"3958","wp_post_id":126070,"discourse_post_id":""}
В версии 2.3.7 пост был правильно связан с моей учётной записью как в WordPress, так и в Discourse.
v2.3.8:
[2022-02-21 08:10:15] publish.INFO: create_post.post_success {"wp_title":"[Please Ignore] Another test event","wp_author_id":"3958","wp_post_id":126071,"discourse_post_id":""}
[2022-02-21 08:10:15] publish.INFO: create_post.body_valid {"wp_title":"[Please Ignore] Another test event","wp_author_id":"3958","wp_post_id":126071,"discourse_post_id":""}
В версии 2.3.8 пост был связан с моей учётной записью в WordPress и с системной учётной записью в Discourse.
Можете ли вы подтвердить для меня несколько моментов:
Ваши пользовательские типы записей (например, события) успешно публикуются в Discourse.
Вы ранее не сталкивались с ошибкой 400.
Какие типы пользователей (чьи имена пользователей Discourse предполагается использовать) публикуют сообщения (например, являются ли они администраторами или нет).
Какой тип API-ключа вы используете для подключения WordPress к Discourse.
Да, посты публикуются успешно, но с версией v2.3.8 указывается неверный пользователь (система).
Нет, мы не видели ошибок 400 ни в одной из предыдущих версий плагина wp-discourse.
Эти пользователи — незарегистрированные администраторы в WordPress, и до сих пор всё работало у нас. Все пользователи были правильно связаны в Discourse.
Извините за беспокойство. Моя проблема, похоже, была решена в WordPress 5.9.1 и WP Discourse 2.3.9.
Однако, похоже, что теперь Discourse выполняет дополнительную работу при каждой публикации поста, и право собственности после публикации переносится с системного пользователя на публикующего?
Привет @orenwolf, мне жаль слышать, что у вас всё ещё есть проблема. Не могли бы вы подтвердить, что пользователи, которые должны публиковать от своего имени, имеют поле «Discourse Username» в своём профиле WordPress?
В целом, ребята, спасибо за ваше терпение. В ходе моих собственных тестов на различных сайтах (а также в собственных модульных тестах плагина) функция «Discourse Username» теперь работает как ожидалось в версии 2.3.9. Если у вас всё ещё возникают проблемы, пожалуйста, подтвердите, что вы используете последнюю версию плагина и что пользователь, который должен быть автором публикации, имеет поле «Discourse Username».
Возможно, вы задаётесь вопросом, почему эта проблема вообще возникла. Я думаю, будет полезно дать немного контекста (что также ответит на ваш вопрос, @itsbhanusharma). Ранее эта функция работала так: она использовала разных пользователей в заголовке Api-Username (см. здесь). Считалось, что это необходимо, потому что соответствующий endpoint в Discourse не поддерживает установку создателя публикации, отличного от пользователя, выполняющего API-запрос.
Следствием этого было то, что эта функция работала только при наличии API-ключа «Все пользователи» с областью действия «Глобально». Я просто отмечу, что в течение некоторого времени стандартные инструкции по созданию API-ключа для плагина WP Discourse были следующими:
Если вы ещё не создали API-ключ, нажмите «Новый API-ключ», установите уровень пользователя в «Один пользователь», выберите пользователя — учётную запись администратора, отметьте «Глобальный ключ» и нажмите «Сохранить». Скопируйте и вставьте API-ключ сюда.
Следование этим инструкциям означало, что эта (недокументированная) функция не работала, что вызывало проблемы на различных сайтах.
Кроме того, по соображениям безопасности я постепенно вносил изменения в плагин, чтобы можно было использовать гораздо более специфичные API-ключи. Это потребует изменений в самом Discourse, и (когда они будут объединены) позволит администраторам плагина создать новый, гораздо более ограниченный API-ключ. Я сделаю объявление об этом, когда наступит время.
Да, @itsbhanusharma, теперь эта функция работает путём выполнения второго запроса для изменения владельца публикации после её создания (если указано поле «Discourse Username»). На данный момент это единственный корректный способ произвольно установить владельца публикации через API Discourse (без необходимости использования Api-Username и глобального ключа «Все пользователи», как описано выше). Учитывая характер этой операции, это не должно вызывать проблем с производительностью.
Это не проблема производительности, а скорее неудобство объяснять менее опытным пользователям, что иконка карандаша в верхней части их сообщения — это нормально, и так и останется.
Потребуется время, но в конце концов мы к этому привыкнем.
Немного отталкивает то, что сообщения помечаются как отредактированные, но это приемлемо, пока всё работает.
Однако проблема в том, что уведомления некорректны. В них указывается, что новое сообщение создано пользователем «Система».
На данный момент это больше похоже на временное решение, а не на полноценное исправление. Определённо, это большой шаг назад — не иметь возможности автоматически публиковать сообщения от имени правильного пользователя. Не совсем понятно, что именно привело к этой поломке изначально.
Коротко: я постепенно меняю способ, которым плагин обрабатывает все свои запросы к Discourse, по разным причинам, особенно в части тестирования и безопасности. Полный контекст и обоснование этих изменений слишком обширны, чтобы подробно останавливаться на них здесь. Я понимаю, что в контексте этой конкретной функции может казаться, что «если что-то не сломано, не чини», однако здесь есть более широкий контекст.
Эти изменения происходят уже некоторое время (месяцы), но сейчас они вышли на поверхность, потому что я допустил ошибку в выпуске 2.3.8. Поэтому я включил изменение, которое должно было быть в том выпуске, в 2.3.9.
Тем не менее, @jtbayly@itsbhanusharma, я услышал вашу обратную связь по поводу иного подхода к этой конкретной функции. Понимаю, что это может казаться хаком. Это не так. Тем не менее, учитывая вашу обратную связь, я верну существующий способ работы в плагин за настройкой, которую вы сможете использовать по желанию (это будет доступно в версии 2.4.0). Я сообщу дополнительно, когда это будет объединено в течение следующих нескольких дней.
Я надеюсь полностью убрать этот подход, когда решу проблемы, которые вы оба подняли, скорее всего, с помощью дальнейших изменений в discourse/discourse. Как уже упоминалось, в течение следующего месяца я сделаю более крупное объявление об изменениях в том, как плагин обрабатывает ключи API (в зависимости от того, когда изменения будут объединены в discourse/discourse), которое затронет и аспекты этого вопроса.
Когда я это сказал, я хотел признать, что не уверен, есть ли вообще какой-то другой путь вперёд. Это не должно было звучать как комментарий «зачем ты это сломал!».
Я очень благодарен за вашу работу по поддержанию совместимости плагина WP с обновлённым ядром Discourse. И я очень рад, что (вероятно) грядут изменения в ядре, которые позволят улучшить ситуацию в этой области.
