Думаю, они предлагают следующее: если плагин, который уже был включён в ядро, будет указан в app.yaml, он просто будет проигнорирован. При этом должно появиться уведомление о том, что указание в app.yaml избыточно, и владелец может его удалить.
Меня тоже немного раздражает, что пока в моём app.yaml есть какие-либо плагины, я всегда рискую получить неудачное обновление. Поэтому каждый раз при обновлении мне приходится перепроверять, не был ли один из моих плагинов добавлен в ядро.
Почему бы не создать скрипт, который сделает это за системного администратора?
Я сам организую плагины по командам или авторам, чтобы немного облегчить себе жизнь и знать, какие плагины являются официальными и так далее. Но если идея состоит в том, чтобы сделать Discourse более удобным для пользователя, это должно быть реализовано на стороне команды.
Это не так уж сильно отличается от того, как вы консультируете людей, когда у пользователя происходит сбой обновления из-за неудачного обновления Postreq (или чего-то подобного).
С плагинами именно здесь концепция установщика Procourse была отличной идеей для упрощения установки и удаления плагинов без необходимости использования командной строки.
Конечно, я понимаю, что, возможно, ей требовалась некоторая доработка на случай, если что-то пойдёт не так. Но это можно было бы легко реализовать с помощью файла журнала или простого механизма отката при необходимости через командную строку. Я признаю, что это могло бы сделать решение более привлекательным для самостоятельного хостинга по сравнению с платным планом. Однако для платного плана существует достаточно преимуществ, чтобы всё же выбрать его.
Такой менеджер плагинов также можно создать или форкнуть, чтобы позволить планам с хостингом устанавливать плагины в рамках своего тарифного уровня, так как некоторые плагины могут не требоваться в конкретном плане.
Действительно, я давно пропустил сообщение о том, что чат включён в состав, и попытался его установить. Мне кажется, тег для плагина не был обновлён. Конечно, сайт упал, так как он не принял попытку установки плагина, хотя теоретически можно было просто проигнорировать эту запись, выполнив полную пересборку, и сообщить, что её можно удалить, поскольку она излишняя.
Отлично, обратная связь получена! 
Думаю, мы можем закрыть эту тему — я поставлю таймер, чтобы у коллег была возможность ответить, если они захотят.
Добавят ли whos-online в ядро?
В свете недавней инициативы по включению большего числа официальных плагинов в ядро, я хотел бы узнать, рассматривается ли плагин «Кто онлайн» для включения.
Я заметил, что он доступен на официальных тарифах хостинга (учитывается в квоте плагинов), поэтому мне интересно, не свидетельствует ли это о движении к более широкому внедрению.
Полностью понимаю, что из-за ограничений производительности или несовпадения с философией проекта он может оставаться отключенным по умолчанию, если явно не указано иное в app.yml.
Спасибо!
В настоящее время мы не планируем переносить какие-либо другие плагины в ядро. Cakeday был последним, и его пришлось внедрять отдельно от основной партии из-за некоторых сложностей, связанных с тем, как он ранее включался по умолчанию.
Полностью понимаю ваше разочарование процессом — он, безусловно, не такой плавный, как мне бы хотелось. Для контекста: фундаментальная проблема заключается в том, что файлы app.yml не являются файлами конфигурации Discourse. Это конфигурация pups, а строки установки плагинов — это просто команды оболочки (shell commands).
Внедрение специфичной для Discourse логики в pups и заставить его игнорировать определённые команды оболочки — это не вариант. Этот инструмент используется не только для Discourse. Кроме того, я подозреваю, что многие будут недовольны, если мы изменим команды оболочки, выполняемые во время загрузки, без их ведома.
Поэтому мы остановились на самом чистом решении, которое смогли найти с помощью имеющихся инструментов: принудительная пересборка через CLI, а затем отображение сообщения с просьбой удалить затронутую строку из вашей конфигурации.
Интересный пост, Дэвид!
Я заметил кое-что в первом сообщении темы о плагине Who’s Online:
Внимательно подумайте перед установкой этого плагина
Мне кажется, что здесь лучше было бы написать «включение» вместо «установка», если это технически верно.
Текущая формулировка может создать впечатление, что наличие дополнительных встроенных плагинов является философской или производительностной проблемой, тогда как речь идет лишь о том, включены они или нет. Поскольку новый базовый плагин, который ранее не был включен, после пересборки по умолчанию отключен, риск заключается не в том, что он установлен вместе с ядром, а в том, что его включают.
Это не обязательно верно: установленный, но отключенный плагин действительно может вызывать проблемы с производительностью. Например, см. Disabled plugins still causing performance impact
Теперь эта конкретная проблема (в основном) решена для встроенных плагинов, но в случае с другими плагинами такое всё ещё может происходить время от времени.
Плагин discourse-categories-suppressed добавляет простой опциональный интерфейс для скрытия выбранных категорий из ленты «Последние». Он интегрируется через одно выпадающее меню в:
Администрирование → Настройки → Категории
«Скрытые из ленты «Последние» категории»
Это кажется очень естественной настройкой ядра — особенно учитывая, что:
• Плагин официальный и активно поддерживается
• Он остаётся отключённым по умолчанию, если администратор не включит его вручную
• Многие сообщества (включая моё) используют «Последние» как основное представление при входе и хотят более тонкого контроля над тем, что там отображается
Подумает ли команда о включении этого плагина в комплект (по-прежнему отключённого по умолчанию), чтобы администраторы могли использовать этот переключатель без необходимости устанавливать что-либо дополнительно?
Спасибо за рассмотрение — это, кажется, небольшая настройка интерфейса, которая была бы полезна многим сайтам, если бы она была доступна сразу «из коробки».
Эта тема была автоматически закрыта через 2 дня. Новые ответы больше не допускаются.
Не уверен, что это задумано, но хотел сообщить:
Мы используем устаревшую стабильную версию 3.5.4 и применяли плагин cakeday. Однако пересборки (той же версии Discourse) перестали работать, поскольку cakeday был объединён с ядром. Поэтому я отключил плагин в файле yml и… ну, он исчез. Теперь сборка снова работает, но у нас больше нет дней рождения (cake days), так как в интерфейсе администратора нет никаких признаков того, что эта функция установлена.
Думаю, это связано с тем, что мы используем устаревшую стабильную версию, но такой результат при пересборке той же версии Discourse стал для нас неожиданностью.
Плагин cakeday не включён в сборку 3.5.4, поэтому вы больше не видите его.
Вы уверены, что именно это стало причиной сбоя? Если вы видели сообщение вроде:
СОВЕТ: Плагин ‘$plugin’ теперь включён в состав Discourse и не должен указываться в конфигурации контейнера
то, боюсь, такое предупреждение будет появляться при любой неудачной пересборке, если плагин cakeday указан в конфигурационном файле. Это был наиболее эффективный способ предупредить пользователей о проблеме, но он может сбить с толку тех, кто использует старые версии ядра.
Так что, если вам нужен плагин cakeday, думаю, вы сможете снова добавить его в файл app.yml и выполнить пересборку. Скорее всего, сбой был вызван чем-то другим, и вы уже это исправили.
Кстати: настоятельно рекомендую обновиться до поддерживаемой версии. Версия 3.5 больше не получает обновлений безопасности и может быть уязвима для атак.
Cloning into 'docker_manager'...
I, [2026-03-09T15:05:49.126710 #1] INFO -- : > cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git
fatal: destination path 'discourse-cakeday' already exists and is not an empty directory.
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git failed with return #<Process::Status: pid 146 exit 128>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in `spawn'
exec failed with the params {"cd"=>"$home/plugins", "cmd"=>["git clone https://github.com/discourse/docker_manager.git", "git clone https://github.com/discourse/discourse-cakeday.git", "git clone https://github.com/discourse/discourse-whos-online.git", "git clone -b no-regional-flags https://github.com/mentalstring/discourse-nationalflags.git", "git clone https://github.com/discourse/discourse-yearly-review.git", "git clone https://0fa273b19b56a1a58c41484d49a01d99f1b5b8d2@github.com/mentalstring/custom-username-validator", "git clone https://github.com/discourse/discourse-saved-searches"]}
bootstrap failed with exit code 128
---
HINT: The plugin 'discourse-cakeday' is now bundled with Discourse and should not be included in your container configuration.
Remove the line 'git clone https://github.com/discourse/discourse-cakeday' from your containers/web_only.yml file, then try again.
For more information, see https://meta.discourse.org/t/373574
---
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
Повторное добавление плагина в app.yml вызывает ошибку, показанную выше. Его немедленное удаление снова позволяет сборке завершиться успешно. Похоже, что проблема только в этом плагине.
Я понимаю, что мы используем устаревшую версию, и её обновление запланировано в дорожной карте. Просто хотел отметить, что, хотя мы не меняли версию, которую используем (3.5.4), ранее сборка с плагином проходила успешно, а теперь — нет. При этом у нас, похоже, нет способа вернуть функциональность плагина (ни через сам плагин, ни через ядро).
Интересно! Не знаю, связано ли это с тем, что наш Docker-образ теперь включает плагин discourse-cakeday, а после «отката» ядра до версии 3.5 остаётся пустая директория.
Если добавить rm -rf discourse-cakeday перед строкой git clone https://.../discourse-cakeday, это должно устранить проблему. В результате конфигурация будет выглядеть примерно так:
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- rm -rf discourse-cakeday
- git clone https://github.com/discourse/discourse-cakeday
Да, это сработало. Всё снова работает — спасибо!
Извините за небольшое отклонение от темы, но я не думаю, что есть более подходящий раздел, и это как-то связано с предыдущей проблемой.
После моего предыдущего сообщения, похоже, в discourse/docker_manager были внесены дальнейшие изменения, которые ломают сборки более старых версий. После пересборки сегодня весь административный раздел Discourse перестал работать с ошибками вроде этой:
loader.js:247 Uncaught (in promise) Error: Could not find module `discourse/admin/models/admin-plugin` imported from `discourse/plugins/docker_manager/discourse/models/repo`
Мне удалось исправить сборку, добавив в файл yml следующее:
- git clone https://github.com/discourse/docker_manager.git && cd docker_manager && git reset --hard 314bbd78c200860c76bb62ced65b40e7cde5aa02 && cd ..
Не уверен, какой именно коммит вызвал проблему, но этого хватило, чтобы всё снова заработало.
Я знаю, знаю, мне нужно обновиться (я имею это в виду). Но, вероятно, есть и другие люди, как мы, которые по тем или иным причинам вынуждены дольше оставаться на старых версиях, и когда старые сборки ломаются без изменения версии, это немного неожиданно.
В любом случае, мы уже нашли обходной путь до момента обновления, так что просто делюсь этим на случай, если это окажется полезным для других в аналогичной ситуации.
Какую версию ядра Discourse вы используете? Всё ещё 3.5?
Да, 3.5.4. Надеюсь, скоро обновлюсь.