Включение более популярных плагинов в ядро Discourse

Новости и события Объявления
80

Поскольку я рано столкнулся с проблемой «сбой плагина при пересборке» при самостоятельном хостинге Discourse, я понимаю желание включить в ядро проверенные версии. И потенциально предложить более широкий набор функций.

Ориентированная на клиентов организация могла бы провести опрос по направлению развития основных плагинов или, по крайней мере, по срокам. Возможно, я что-то упустил. Как поставщик ИТ-инструментов для моих клиентов (то есть конечных пользователей), пытающихся с помощью ИТ решать реальные задачи, я видел, как многие продукты из-за чрезмерной сложности обновлений в итоге заменялись другими. Теперь самохостеры будут удалять («rm -fr») плагины, которые им не нужны. Я это понимаю и, возможно, тоже присоединюсь к этому клубу. По моему опыту, дополнительный код увеличивает сложность интеграции, риск ошибок конфигурации и поверхность атаки. Но рано или поздно удаление того, что разработчик приложения предполагает как существующее, тоже что-то сломает.

Мне гораздо больше понравилось бы, если бы усилия джедаев Discourse были направлены на создание надежного, поддерживаемого, скриптового метода для включения облачного хранения изображений с интеграцией CDN. Интеграция SMTP-рассылки по сравнению с этим тривиальна, и она ломалась из-за изменений в MailGun и других сервисах, что причиняло неудобства самохостинговым сайтам.

81

Действительно, я настоятельно не рекомендую использовать rm -rf для этих плагинов. Как вы и заметили, существуют риски, связанные с неожиданными взаимозависимостями в будущем. Кроме того, вы создадите различия в основном git-репозитории, что почти наверняка приведёт к сбоям при обновлении интерфейса через docker_manager.

Конечно, оставлять эти плагины в их стандартном состоянии «отключено» полностью поддерживается, и это гарантирует, что они не окажут никакого ощутимого влияния на производительность.

8 лайков
82

Нам нужен способ исключить плагины из поиска, даже если они находятся в директории плагинов. Это не решает проблему реальных межзависимостей, но позволяет сократить зависимости миграций базы данных для неиспользуемых зависимостей (например, pgvector для ИИ).

2 лайка
83

Для тех, кто разворачивает сервис самостоятельно, или для тех, кто, как я, предоставляет хостинг-услуги клиентам, вот простая команда grep, которая покажет, есть ли какие-либо из новых встроенных плагинов уже в вашем файле containers/app.yml:

grep -E 'git clone .*(discourse-(adplugin|affiliate|ai|apple-auth|assign|calendar|chat-integration|data-explorer|gamification|github|graphviz|hcaptcha|login-with-amazon|lti|math|microsoft-auth|oauth2-basic|openid-connect|patreon|policy|post-voting|reactions|rss-polling|solved|subscriptions|templates|topic-voting|user-notes|zendesk-plugin|cakeday))' containers/app.yml

Команду нужно запускать от имени root из директории /var/discourse. Она выведет строки, которые необходимо вручную удалить из раздела плагинов в файле app.yml перед повторной сборкой.

9 лайков
84

@pacharanero Спасибо за сборку!

Может быть, стоит изменить это так, чтобы оно ссылалось на containers.*.yml, чтобы помочь тем, кто выполнил стандартную установку с двумя контейнерами, но работает только в веб-режиме? Ведь вам действительно не нужны они в определениях ваших контейнеров. :smiling_face:

@david, не могли бы вы добавить это в первое сообщение и поддерживать его после интеграции cakeday?

2 лайка
85

Благодаря ChatGPT, который с первого раза составил это в точности правильно, используя следующий запрос:

Пожалуйста, соберите URL-адреса GitHub для каждого из плагинов, упомянутых в этом посте
https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574#p-1810533-affected-plugins-3

Составьте из них список и создайте unix-команду, которая покажет, упоминается ли какой-либо из этих плагинов уже в команде ‘git clone’ в файле app.yml контейнеров Discourse

3 лайка
86

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

Тем не менее, я не знаю, насколько это реализуемо и какие усилия потребуются для реализации.

3 лайка
87

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

В любом случае, я считаю, что было бы более полезно потратить время на улучшение UX и производительности «отключённых» плагинов (мы уже начали это делать после этого крупного слияния с ядром).

10 лайков
88

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

2 лайка
89

Ох, это было тяжелое обновление. Выявление проблемы в хаосе лога пересборки изначально не такая уж простая задача. Нашел её, дважды упустил необходимость удалить другой плагин из нашей конфигурации, поэтому только с третьей попытки пересборка успешно прошла этот этап. Было бы действительно полезно заранее проверить и предупредить, что конфигурацию нужно скорректировать. Утилита discourse-doctor проверяет наличие плагинов в конфигурации (слишком просто, но можно взять за основу), так что это может послужить отправной точкой. Вероятно, сейчас уже слишком поздно, три недели спустя, и что поделать…

Но это было не всё: мы также столкнулись с ошибками db:migrate. Повторили попытку дважды, затем запустили discourse-doctor, который также выполнил пересборку, и, странно, всё прошло успешно. Я изучил его код: перед пересборкой он абсолютно ничего не делает (никаких изменений), а вызывает пересборку точно так же, как и мы. Получается, что db:migrate сработал с третьей попытки по какой-то причине? Я прочитал в теме, что большое количество добавленных плагинов вносит зависимости, которые могут конфликтовать или быть старше тех, что использовались ранее. К счастью, нам не пришлось вручную удалять плагины, корректировать зависимости или менять базу данных, как это потребовалось другим. Ожидается ли каким-то образом, что многократный запуск db:migrate в итоге приведёт к успеху? Осталось только надеяться, что ничего не сломано…

Я полностью поддерживаю это мнение по данному вопросу. Не стоит внезапно добавлять сразу целый ворох плагинов. Если какая-то функция считается очень полезной для всех (стартовых) инстансов, обсуждайте её индивидуально, по одной. Возможно, тогда будет лучше просто внедрить её нативно в Discourse (с переключателем в настройках), вместо того чтобы оставлять в виде плагина, привлекая его разработчиков. Сейчас мы также рассматриваем возможность добавления шага удаления в нашу конфигурацию и думаем, что делать с плагинами, которые теперь включены по умолчанию. Это подразумевает изменения в нашем инстансе Discourse, которые мы не планировали, и у меня, честно говоря, сейчас нет времени тестировать и обдумывать это после полуночи по местному времени, особенно учитывая хаос с обновлением и необходимость исследований для исправления…

Хотя в связи с этим возник вопрос: не были ли некоторые функции превращены в плагины? Я вижу плагин narrative bot, который я не помню из прошлых версий. В его описании сказано «вводит сотрудников», поэтому сначала я подумал, что это дополнение к discobot только для сотрудников (модераторов, администраторов и т. д.). Но судя по его настройкам, это всё тот же discobot, верно? Все ли эти плагины, которые теперь отображаются как включённые, хотя не были явно установлены через конфигурацию, — это функции, которые уже присутствовали ранее?

2 лайка
90

Он был установлен ранее, мы просто скрыли его в интерфейсе вместе с остальными встроенными плагинами. Наш интерфейс был улучшен, чтобы корректно отображать всё, что существует. (У нас было несколько упущений, включая Chat, который был скрыт через CSS)

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

Планов откатываться назад нет. Вам нужно адаптироваться к новому миру.

5 лайков
Help me debug failed migrations PushFixTopicEmbedAuthorsJob
91

3 сообщения были перенесены в новую тему: Помогите отладить неудачные миграции

93

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

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

2 лайка
94

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

image
image1161×1236 202 KB

Нет, мы не проверяли заранее, но я проверил после. Ни в одном из плагинов на Crowdin не было неотвеченных комментариев. У нас есть внутренний инструмент, который хранит все комментарии, опубликованные в наших плагинах на Crowdin. Мы могли бы даже использовать его для повторной публикации отсутствующих комментариев на Crowdin, например, когда Crowdin удаляет комментарии из-за обновления исходной строки. Просто это не было приоритетом для реализации.

6 лайков
96

Было бы действительно здорово добавить здесь ещё одну опцию:

image
image406×223 4.8 KB

«Включённые плагины»

Это позволило бы избежать первоначального огромного списка в разделе «Установленные плагины».

Также для этого можно:

  • Разрешить добавлять пользовательские ссылки в разделе плагинов (возможно)
  • Настроить этот выпадающий список так, чтобы он реагировал на параметр фильтра маршрута:

image
image396×179 1.17 KB

то есть:

https://example.com/admin/plugins?filter=enabled

12 лайков
98

Согласен. Возможно, стоит добавить опцию для перечисления включённых основных установленных плагинов. Вместо простого показа всех плагинов. Дополнительные возможности фильтрации, безусловно, лучше.

1 лайк
99

Я согласен с этим мнением. На мой взгляд, настоящая проблема заключается в том, что они всё ещё классифицируются как плагины.

После объединения их следует переместить в раздел с брендингом, например, «Функции ядра», поскольку плагины воспринимаются как опциональные компоненты, которые можно установить, а не как часть основной программы. Поэтому, на мой взгляд, называть их плагинами некорректно, если не предполагается возможность их удаления.

Аналогично TC, которые были объединены с ядром, например, «личные пузыри», не перечисляются в разделе «Компоненты тем». Правда, в данном конкретном случае нельзя отключить тот самый TC. Если бы вы хотели вернуться к предыдущему состоянию, вам пришлось бы создать TC для отмены изменений :wink:

100

Однозначно согласен с необходимостью дополнительных опций фильтрации. Было бы хорошо добавить также фильтр для отключённых плагинов.

Однако, после более тщательного обдумывания и чтения других постов, если плагины будут объединены с ядром, их, пожалуй, больше не стоит называть плагинами и не следует отображать в разделе «Плагины». Возможно, лучше использовать название вроде Основные функции или Опциональные функции, поскольку их больше не предполагается возможность удалить.

1 лайк
101

Нет никаких причин, по которым правильно спроектированное программное обеспечение для форумов должно требовать наличия рекламного кода для работы.

Если Discourse решит внедрить анти-функции, это лишь заставит людей либо форкнуть Discourse, либо мигрировать на другую платформу. Те из нас, кто не любит крупный технологический бизнес и рекламу, относятся к этому крайне негативно. Discourse не сможет навязать нам это, как бы сильно они ни пытались. (Ubuntu пыталась сделать то же самое, и теперь мой репозиторий с наибольшим количеством звёзд — это проект, удаляющий рекламу ;))

102

Не совсем понял. Если под «рекламным кодом» вы имеете в виду плагины, которые были объединены с основным продуктом, а не остались в качестве опциональных дополнений или установок, то, если оглянуться назад, можно найти множество примеров, когда такой «рекламный код» был встроен в ядро.

Я понимаю позицию команды DeV: многие их плагины могли изначально создаваться как отдельные расширения для более гибкого тестирования перед интеграцией в основную программу.

Я согласен, что, как и в любом программном обеспечении, часто встречаются функции, которые пользователи могут не использовать, предпочитая их отключать, и это приводит к поиску способов их полного удаления.

Хотя я признаю, что существует множество недавно объединённых плагинов, которые, скорее всего, не понадобятся мне. Однако наличие простой функции отключения и фильтрации таких элементов — это хорошо для всех.

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

Теперь, на мой взгляд, интерфейс администратора должен быть более настраиваемым, как это было раньше. Это также может помочь пользователям, migrating с других платформ, за счёт возможности загрузить административный интерфейс с похожим макетом, аналогичный той платформе, с которой они переходят. Подобно тому, как Linux позволяет это делать, имитируя некоторые другие операционные системы. Но это уже другая тема. :wink:

Я понимаю опасения, что Discourse может начать превращаться в раздутый софт. Reactors продемонстрировали, насколько более лёгким мог быть Windows NT.