В ближайшие несколько недель мы перенесем ряд популярных плагинов Discourse в основной репозиторий. Это означает, что Discourse будет поставляться с большим количеством плагинов по умолчанию, и нам станет проще поддерживать их все в актуальном состоянии и с тестами.
Все эти плагины по умолчанию останутся отключенными, поэтому для существующих сообществ никаких видимых изменений не произойдет. Если вы используете управляемый хостинг, такой как discourse.org, вам ничего делать не нужно.
Самохостинговые сообщества
Если вы размещаете Discourse самостоятельно и уже используете один из этих плагинов, перед следующим пересборкой вам будет предложено удалить соответствующую строку из вашего файла app.yml.
Окружение разработки
Если у вас уже установлен один из этих плагинов локально, а затем вы обновите ядро Discourse до последней версии, произойдет одно из двух.
Если вы используете символические ссылки для плагинов, то при выполнении git pull возникнет ошибка. Чтобы решить проблему, удалите символическую ссылку, а затем снова выполните git pull.
Если вы клонируете плагины напрямую, то git pull для ядра завершится успешно, но у вас появятся неожиданные «незафиксированные изменения», вызванные вложенными репозиториями Git. Лучший способ действий — удалить затронутую директорию, а затем восстановить её из ветки main. Например:
Спасибо. Несмотря на мои скромные знания в области разработки и программирования, я всё же хочу задать вам вопрос. Могут ли эти плагины, которые изначально являются компонентами, предназначенными для добавления к базовой установке, со временем утратить свой статус плагинов и стать неотъемлемой частью базовой установки, перестав называться плагинами?
Да, возможно. В частности, плагины аутентификации (например, apple-auth) с большой вероятностью в конечном итоге будут интегрированы в ядро, как и другие встроенные методы аутентификации (например, Google, Facebook и т. д.).
Интересный ход, который по умолчанию ещё больше активизирует дискуссию и облегчает новые установки.
Вопрос по поводу:
вам будет предложено удалить соответствующую строку из файла app.yml перед следующей пересборкой.
Будет ли также отображаться подсказка или предупреждающее сообщение до/в момент нажатия кнопки обновления на странице обновлений в панели администратора?
Если я правильно помню по своему опыту, сначала вы сможете обновить только Docker. После обновления Docker в интерфейсе обновления вам будет показано сообщение, объясняющее, что обновление необходимо выполнить через командную строку, и как это сделать.
Затем при обновлении в командной строке вы увидите подсказку (HINT) для каждого плагина, который нужно удалить из app.yml, как объясняется в первом сообщении выше.
Это хорошее обновление, но действительно ли это было необходимо? Выдавать ошибку сборки — это, на мой взгляд, немного сурово. Предупреждение в интерфейсе или автоматическое обновление (или просто полное игнорирование таких случаев) было бы куда приятнее, чем приставлять пистолет к виску и говорить: «Уберите это немедленно»!
На прошлой неделе это застало меня врасплох, когда я пытался обновить через командную строку, и обновление не удалось (плагин reactions).
Сегодня утром это снова застало меня врасплох, когда обновление через командную строку снова не удалось (плагин data explorer).
Я был бы очень рад получить предупреждение в командной строке до начала процесса обновления, который неизбежно завершится неудачей.
Уже дважды за две недели мои обновления не удавались, и это означало, что мой Discourse был недоступен всё время, пока я отлаживал проблему, редактировал конфигурацию, пробовал снова и так далее — всё это в состоянии лёгкой паники, потому что всё было сломано.
Мне интересно, вы получили этот список плагинов из установок Discourse в реальных условиях? Он совпадает почти на 50% с моей собственной основной установкой!
Интересно, не приведёт ли включение всех этих плагинов в ядро к раздуванию форумов? То есть, вероятно, найдутся администраторы, которые не хотят видеть некоторые плагины на своём форуме (например, Discourse AI), но у них не будет выбора — они будут вынуждены их установить. Конечно, их можно отключить, но меня волнует, не замедлят ли дополнительные файлы и прочее работу форумов?
На стороне клиента Discourse не предоставляет никаких JavaScript-ресурсов для отключённых плагинов, поэтому здесь никакого влияния не будет.
На стороне сервера для корректно реализованных плагинов (все представленные именно таковы) кастомизации от плагинов игнорируются, когда они отключены. Так что технически может быть небольшая нагрузка на проверку состояния включено/выключено, но она должна быть ничтожной.
Плагины, которые мы здесь объединяем, — это те, что работают на каждом экземпляре Discourse на нашем хостинге discourse.org. Поэтому они все очень хорошо протестированы в масштабе.
Есть ли причина, по которой вы делаете всё это сразу незадолго до выпуска? Для переводчиков, занимающихся этим в свободное время, 3000 дополнительных строк за две недели — это много. И даже в языках, где плагины уже были переведены, все 3000 текстов нужно вычитать заново. Периодически по 300 строк, вероятно, было бы удобнее, чем по 1500 каждую неделю.
Для самохостинговых сообществ, которые уже используют один или несколько из этих плагинов, потеряют ли плагины свои конфигурационные данные при удалении из app.yml и интеграции в ядро?
У меня плагин AI настроен именно так, как мне нужно; было бы полезно знать заранее, если мне потребуется перенастроить его (или хотя бы записать параметры конфигурации, чтобы затем добавить их обратно).
Мы стараемся сделать процесс максимально плавным для переводчиков, используя память переводов в Crowdin, чтобы переводы не приходилось переделывать с нуля. Но всё же, я согласен, их нужно проверить.
Интересно, можно ли здесь автоматизировать что-то ещё? Например, возможно, мы могли бы «автоматически одобрять» строки из этих плагинов, не требуя проверки
