# Включение более популярных плагинов в ядро Discourse
**URL:** https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574
**Category:** Announcements
**Created:** [10.Июль.2025 10:15:25 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574 "2025-07-10T10:15:25Z")
**Posts on this page:** 20
**Page:** 4
### Author:  [@kgrier](https://meta.discourse.org/u/kgrier)
#### Post date: [28.Июль.2025 18:12:56 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/80 "2025-07-28T18:12:56Z")
Поскольку я рано столкнулся с проблемой «сбой плагина при пересборке» при самостоятельном хостинге Discourse, я понимаю желание включить в ядро проверенные версии. И потенциально предложить более широкий набор функций.
Ориентированная на клиентов организация могла бы провести опрос по направлению развития основных плагинов или, по крайней мере, по срокам. Возможно, я что-то упустил. Как поставщик ИТ-инструментов для моих клиентов (то есть конечных пользователей), пытающихся с помощью ИТ решать реальные задачи, я видел, как многие продукты из-за чрезмерной сложности обновлений в итоге заменялись другими. Теперь самохостеры будут удалять («rm -fr») плагины, которые им не нужны. Я это понимаю и, возможно, тоже присоединюсь к этому клубу. По моему опыту, дополнительный код увеличивает сложность интеграции, риск ошибок конфигурации и поверхность атаки. Но рано или поздно удаление того, что разработчик приложения предполагает как существующее, тоже что-то сломает.
Мне гораздо больше понравилось бы, если бы усилия джедаев Discourse были направлены на создание надежного, поддерживаемого, скриптового метода для включения облачного хранения изображений с интеграцией CDN. Интеграция SMTP-рассылки по сравнению с этим тривиальна, и она ломалась из-за изменений в MailGun и других сервисах, что причиняло неудобства самохостинговым сайтам.
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [28.Июль.2025 18:54:17 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/81 "2025-07-28T18:54:17Z")
> [@kgrier](#):
>
> Теперь у самохостеров будет возможность удалять ненужные плагины командой «rm -fr»… Но рано или поздно удаление чего-то, что разработчик приложения предполагает необходимым, приведёт к поломке.
Действительно, я настоятельно не рекомендую использовать `rm -rf` для этих плагинов. Как вы и заметили, существуют риски, связанные с неожиданными взаимозависимостями в будущем. Кроме того, вы создадите различия в основном git-репозитории, что почти наверняка приведёт к сбоям при обновлении интерфейса через docker\_manager.
Конечно, оставлять эти плагины в их стандартном состоянии «отключено» полностью поддерживается, и это гарантирует, что они не окажут никакого ощутимого влияния на производительность.
---
### Author:  [@elmuerte](https://meta.discourse.org/u/elmuerte)
#### Post date: [28.Июль.2025 19:29:25 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/82 "2025-07-28T19:29:25Z")
Нам нужен способ исключить плагины из поиска, даже если они находятся в директории плагинов. Это не решает проблему реальных межзависимостей, но позволяет сократить зависимости миграций базы данных для неиспользуемых зависимостей (например, pgvector для ИИ).
---
### Author:  [@pacharanero](https://meta.discourse.org/u/pacharanero)
#### Post date: [29.Июль.2025 10:59:35 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/83 "2025-07-29T10:59:35Z")
Для тех, кто разворачивает сервис самостоятельно, или для тех, кто, как я, предоставляет хостинг-услуги клиентам, вот простая команда `grep`, которая покажет, есть ли какие-либо из новых встроенных плагинов уже в вашем файле `containers/app.yml`:
```bash
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 перед повторной сборкой.
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [29.Июль.2025 11:57:49 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/84 "2025-07-29T11:57:49Z")
@pacharanero Спасибо за сборку!
Может быть, стоит изменить это так, чтобы оно ссылалось на `containers.*.yml`, чтобы помочь тем, кто выполнил стандартную установку с двумя контейнерами, но работает только в веб-режиме? Ведь вам действительно не нужны они в определениях ваших контейнеров. ☺
@david, не могли бы вы добавить это в первое сообщение и поддерживать его после интеграции cakeday?
---
### Author:  [@pacharanero](https://meta.discourse.org/u/pacharanero)
#### Post date: [29.Июль.2025 12:12:28 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/85 "2025-07-29T12:12:28Z")
> [@mcdanlj](#):
>
> @pacharanero Спасибо за сборку!
Благодаря 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
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [29.Июль.2025 14:36:56 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/86 "2025-07-29T14:36:56Z")
> [@elmuerte](#):
>
> Нам нужен способ исключить плагины из поиска, даже если они находятся в директории плагинов.
На первый взгляд это кажется разумной идеей, которую стоит рассмотреть в будущем — иметь более декларативный способ определения того, какие плагины загружаются при запуске, даже если их исходный код всё ещё находится на диске.
Тем не менее, я не знаю, насколько это реализуемо и какие усилия потребуются для реализации.
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [29.Июль.2025 14:59:26 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/87 "2025-07-29T14:59:26Z")
Это, безусловно, возможно. Однако это добавляет сложности — ещё один элемент, который нужно поддерживать и обслуживать. К тому же это было бы полезно только в однопользовательских средах (то есть не в средах общего хостинга, где разные пользователи хотят использовать разные плагины).
В любом случае, я считаю, что было бы более полезно потратить время на улучшение UX и производительности «отключённых» плагинов (мы уже начали это делать после этого крупного слияния с ядром).
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [29.Июль.2025 15:01:57 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/88 "2025-07-29T15:01:57Z")
Также я не пробовал удалять плагины, так как считаю, что это может поставить под угрозу мои отчёты об ошибках в мета-форуме, аналогично тому, как это происходит даже при попытке установки на общем хостинге.
---
### Author:  [@MichaIng](https://meta.discourse.org/u/MichaIng)
#### Post date: [29.Июль.2025 22:26:49 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/89 "2025-07-29T22:26:49Z")
Ох, это было тяжелое обновление. Выявление проблемы в хаосе лога пересборки изначально не такая уж простая задача. Нашел её, дважды упустил необходимость удалить другой плагин из нашей конфигурации, поэтому только с третьей попытки пересборка успешно прошла этот этап. Было бы **действительно** полезно заранее проверить и предупредить, что конфигурацию нужно скорректировать. Утилита `discourse-doctor` проверяет наличие плагинов в конфигурации (слишком просто, но можно взять за основу), так что это может послужить отправной точкой. Вероятно, сейчас уже слишком поздно, три недели спустя, и что поделать…
Но это было не всё: мы также столкнулись с ошибками `db:migrate`. Повторили попытку дважды, затем запустили `discourse-doctor`, который также выполнил пересборку, и, странно, всё прошло успешно. Я изучил его код: перед пересборкой он абсолютно ничего не делает (никаких изменений), а вызывает пересборку точно так же, как и мы. Получается, что `db:migrate` сработал с третьей попытки по какой-то причине? Я прочитал в теме, что большое количество добавленных плагинов вносит зависимости, которые могут конфликтовать или быть старше тех, что использовались ранее. К счастью, нам не пришлось вручную удалять плагины, корректировать зависимости или менять базу данных, как это потребовалось другим. Ожидается ли каким-то образом, что многократный запуск `db:migrate` в итоге приведёт к успеху? Осталось только надеяться, что ничего не сломано…
Я полностью поддерживаю [это](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/35?u=michaing) мнение по данному вопросу. Не стоит внезапно добавлять сразу целый ворох плагинов. Если какая-то функция считается очень полезной для всех (стартовых) инстансов, обсуждайте её индивидуально, по одной. Возможно, тогда будет лучше просто внедрить её нативно в Discourse (с переключателем в настройках), вместо того чтобы оставлять в виде плагина, привлекая его разработчиков. Сейчас мы также рассматриваем возможность добавления шага удаления в нашу конфигурацию и думаем, что делать с плагинами, которые теперь включены по умолчанию. Это подразумевает изменения в нашем инстансе Discourse, которые мы не планировали, и у меня, честно говоря, сейчас нет времени тестировать и обдумывать это после полуночи по местному времени, особенно учитывая хаос с обновлением и необходимость исследований для исправления…
Хотя в связи с этим возник вопрос: не были ли некоторые функции превращены в плагины? Я вижу плагин narrative bot, который я не помню из прошлых версий. В его описании сказано «вводит сотрудников», поэтому сначала я подумал, что это дополнение к discobot только для сотрудников (модераторов, администраторов и т. д.). Но судя по его настройкам, это всё тот же discobot, верно? Все ли эти плагины, которые теперь отображаются как включённые, хотя не были явно установлены через конфигурацию, — это функции, которые уже присутствовали ранее?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [29.Июль.2025 23:08:37 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/90 "2025-07-29T23:08:37Z")
> [@MichaIng](#):
>
> Я вижу плагин narrative bot, которого я не помню из предыдущих версий.
Он был установлен ранее, мы просто скрыли его в интерфейсе вместе с остальными встроенными плагинами. Наш интерфейс был улучшен, чтобы корректно отображать всё, что существует. (У нас было несколько упущений, включая Chat, который был скрыт через CSS)
* * *
Я уже заметил рост скорости работы внутренней команды разработки за очень короткое время, пока это действует. Это приводит к созданию более стабильного продукта, и я очень этому рад.
Планов откатываться назад нет. Вам нужно адаптироваться к новому миру.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [29.Июль.2025 23:47:28 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/91 "2025-07-29T23:47:28Z")
3 сообщения были перенесены в новую тему: [Помогите отладить неудачные миграции](https://meta.discourse.org/t/help-me-debug-failed-migrations/376496)
---
### Author:  [@SkyeDragon](https://meta.discourse.org/u/SkyeDragon)
#### Post date: [04.Август.2025 06:02:04 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/93 "2025-08-04T06:02:04Z")
> [@Ethsim2](#):
>
> Также я не пробовал удалять плагины, потому что считаю, что это поставит под угрозу мои отчеты об ошибках в Meta, как и сама попытка установки на Shared Hosting.
По моему мнению, если что-то ломается из-за того, что плагин не установлен, то это само по себе **является** ошибкой. Ядро не должно зависеть от плагинов. Сами плагины должны четко указывать свои требования на своих соответствующих страницах.
Но да, это сделает версию для самостоятельного хостинга еще менее стабильной в будущем, так как именно пользователи самостоятельного хостинга будут сталкиваться с этими проблемами. С учетом этого и [разветвленной темы](https://meta.discourse.org/t/discourse-does-not-ship-an-lts-release/376086/2), у меня нет впечатления, что стабильность для пользователей самостоятельного хостинга является высоким приоритетом для команды.
---
### Author:  [@gerhard](https://meta.discourse.org/u/gerhard)
#### Post date: [04.Август.2025 09:02:54 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/94 "2025-08-04T09:02:54Z")
> [@Moin](#):
>
> Я думаю, что трудно понять, какие тексты были вычитаны, а какие — нет.
Мы заранее об этом не подумали, поэтому некоторые подтверждения могли потеряться. Но нам удалось перенести значительную часть из проектов плагинов на Crowdin в основную часть. В следующий раз мы сделаем лучше, так как теперь у нас есть инструменты для переноса подтверждений между проектами.
> [@Moin](#):
>
> Я на мгновение подумал, проверяли ли вы заранее, есть ли открытые комментарии, которые теперь отсутствуют, так как были добавлены только тексты, а не все данные из Crowdin.
Нет, мы не проверяли заранее, но я проверил после. Ни в одном из плагинов на Crowdin не было неотвеченных комментариев. У нас есть внутренний инструмент, который хранит все комментарии, опубликованные в наших плагинах на Crowdin. Мы могли бы даже использовать его для повторной публикации отсутствующих комментариев на Crowdin, например, когда Crowdin удаляет комментарии из-за обновления исходной строки. Просто это не было приоритетом для реализации.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [05.Август.2025 06:58:43 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/96 "2025-08-05T06:58:43Z")
Было бы действительно здорово добавить здесь ещё одну опцию:
«Включённые плагины»
Это позволило бы избежать первоначального огромного списка в разделе «Установленные плагины».
Также для этого можно:
- Разрешить добавлять пользовательские ссылки в разделе плагинов (возможно)
- Настроить этот выпадающий список так, чтобы он реагировал на параметр фильтра маршрута:
то есть:
`https://example.com/admin/plugins?filter=enabled`
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [08.Август.2025 04:28:01 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/98 "2025-08-08T04:28:01Z")
> [@elmuerte](#):
>
> Нам нужен способ исключить плагины из поиска, даже если они находятся в директории плагинов
Согласен. Возможно, стоит добавить опцию для перечисления включённых основных установленных плагинов. Вместо простого показа всех плагинов. Дополнительные возможности фильтрации, безусловно, лучше.
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [08.Август.2025 04:41:37 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/99 "2025-08-08T04:41:37Z")
> [@SkyeDragon](#):
>
> По-моему, если что-то ломается из-за того, что плагин не установлен, то это само по себе **является** ошибкой. Ядро не должно зависеть от плагинов. Сами плагины должны явно указывать свои требования на своих страницах.
Я согласен с этим мнением. На мой взгляд, настоящая проблема заключается в том, что они всё ещё классифицируются как плагины.
После объединения их следует переместить в раздел с брендингом, например, «Функции ядра», поскольку плагины воспринимаются как опциональные компоненты, которые можно установить, а не как часть основной программы. Поэтому, на мой взгляд, называть их плагинами некорректно, если не предполагается возможность их удаления.
Аналогично TC, которые были объединены с ядром, например, «личные пузыри», не перечисляются в разделе «Компоненты тем». Правда, в данном конкретном случае нельзя отключить тот самый TC. Если бы вы хотели вернуться к предыдущему состоянию, вам пришлось бы создать TC для отмены изменений 😉
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [08.Август.2025 04:47:00 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/100 "2025-08-08T04:47:00Z")
> [@merefield](#):
>
> Включённые плагины
>
> Это позволило бы избежать начального огромного списка в разделе «Установленные плагины».
Однозначно согласен с необходимостью дополнительных опций фильтрации. Было бы хорошо добавить также фильтр для отключённых плагинов.
Однако, после более тщательного обдумывания и чтения других постов, если плагины будут объединены с ядром, их, пожалуй, больше не стоит называть плагинами и не следует отображать в разделе «Плагины». Возможно, лучше использовать название вроде **Основные функции** или **Опциональные функции** , поскольку их больше не предполагается возможность удалить.
---
### Author:  [@SkyeDragon](https://meta.discourse.org/u/SkyeDragon)
#### Post date: [08.Август.2025 05:09:13 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/101 "2025-08-08T05:09:13Z")
> [@Heliosurge](#):
>
> После объединения его следует переместить в раздел с фирменным названием, например «Основные функции», поскольку плагины воспринимаются как необязательные компоненты, которые можно установить, а не как часть основной программы. Поэтому, на мой взгляд, называть их плагинами некорректно, если не предполагается их удаление.
Нет никаких причин, по которым правильно спроектированное программное обеспечение для форумов должно _ **требовать** _ наличия рекламного кода для работы.
Если Discourse решит внедрить анти-функции, это лишь заставит людей либо форкнуть Discourse, либо мигрировать на другую платформу. Те из нас, кто не любит крупный технологический бизнес и рекламу, относятся к этому крайне негативно. Discourse не сможет навязать нам это, как бы сильно они ни пытались. (Ubuntu пыталась сделать то же самое, и теперь мой репозиторий с наибольшим количеством звёзд — это проект, удаляющий рекламу ;))
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [08.Август.2025 06:46:46 UTC](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574/102 "2025-08-08T06:46:46Z")
> [@SkyeDragon](#):
>
> Нет никаких причин, по которым правильно спроектированное программное обеспечение для форумов должно _ **требовать** _ наличия рекламного кода для работы.
Не совсем понял. Если под «рекламным кодом» вы имеете в виду плагины, которые были объединены с основным продуктом, а не остались в качестве опциональных дополнений или установок, то, если оглянуться назад, можно найти множество примеров, когда такой «рекламный код» был встроен в ядро.
Я понимаю позицию команды DeV: многие их плагины могли изначально создаваться как отдельные расширения для более гибкого тестирования перед интеграцией в основную программу.
Я согласен, что, как и в любом программном обеспечении, часто встречаются функции, которые пользователи могут не использовать, предпочитая их отключать, и это приводит к поиску способов их полного удаления.
Хотя я признаю, что существует множество недавно объединённых плагинов, которые, скорее всего, не понадобятся мне. Однако наличие простой функции отключения и фильтрации таких элементов — это хорошо для всех.
Я понимаю, что, как заявляет команда, цель состоит в том, чтобы упростить работу с дополнениями для тех, кто использует самохостинг.
Теперь, на мой взгляд, интерфейс администратора должен быть более настраиваемым, как это было раньше. Это также может помочь пользователям, migrating с других платформ, за счёт возможности загрузить административный интерфейс с похожим макетом, аналогичный той платформе, с которой они переходят. Подобно тому, как Linux позволяет это делать, имитируя некоторые другие операционные системы. Но это уже другая тема. 😉
Я понимаю опасения, что Discourse может начать превращаться в раздутый софт. Reactors продемонстрировали, насколько более лёгким мог быть Windows NT.
[Previous page](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574.md?page=3)
[Next page](https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574.md?page=5)