Я заметил, что люди часто сначала включают безопасный режим, когда что-то ломается и используются сторонние модификации. Это логично: вы не знаете, откуда исходит проблема.
Однако безопасный режим отключает только JavaScript. Если проблема в серверном коде, типичное немедленное решение — раскомментировать все плагины в файле app.yml. Это допустимо, но требует пересборки и считается довольно «техническим» действием. Для нетехнического пользователя комментирование элементов в app.yml — не то, к чему стоит относиться легкомысленно.
Я размышляю о целесообразности PR, который добавит отключение плагинов на стороне сервера в безопасном режиме. Я представляю это примерно так в контроллере safe-mode:
find_opts = {
include_official: params["only_official"] != 'true',
include_unofficial: params["no_plugins"] == "true"
}
Discourse.find_plugins(find_opts).each do |plugin|
if plugin.enabled_site_setting.present?
SiteSetting.set(plugin.enabled_site_setting, false)
end
end
Да, тот же эффект можно достичь, если пользователь зайдёт в настройки своего сайта и отключит плагины вручную, однако я замечал, что пользователи редко действительно так делают.
Текущий безопасный режим действует только для текущей страницы и отключается при открытии новой вкладки или обновлении. Поэтому он полностью безопасен для тестирования.
Ваше предложение меняет его смысл на постоянное переключение настройки, что влияет на весь сайт. Это означает, что доступ к ней также должен быть ограничен администраторами.
Я понимаю ваше предложение, но это значительное изменение в поведении.
Я думаю, что ключевой момент заключается в том, что нетехнические администраторы сайтов ищут решение, чтобы восстановить работоспособность своего сайта при сбоях. «Безопасный режим» часто воспринимается как такое решение (правильно или нет). Возможно, одним из способов реализации этого было бы введение дополнительных элементов управления безопасным режимом для администраторов.
Можно добавить большую кнопку на маршруте /admin/plugins для автоматического отключения всех плагинов аналогичным образом, однако я сомневаюсь, будет ли это иметь тот же эффект. Возможно, будет.
Меня также привлекает эта идея, поскольку её вполне можно реализовать в рамках текущей архитектуры плагинов Discourse.
Обычно проблемы с плагинами возникают из-за несовместимых изменений в ядре; часто приложение даже не запускается, если включить проблемный плагин или при загрузке.
Функция полного отключения всех плагинов должна каким-то образом перезапускать приложение, чтобы работать корректно.
Я бы поддержал изменение плагина для управления Docker, которое позволяло бы легко отключать/включать плагины, перемещая их в папку плагинов и обратно, с последующей перезагрузкой приложения — это ускорило бы отладку.
Однако я отмечаю, что значительное количество ошибок возникает из-за кода, обернутого в API серверного плагина, что, как мне кажется, должно обрабатываться этим механизмом.
В настоящее время «безопасный режим» (или нечто подобное) не является полным решением проблем с сбоями. Добавление автоматического отключения плагинов сделало бы это решение немного лучше, сократив количество случаев, когда требуется полная перезагрузка или изменение конфигурации, и лучше отражая то, как это воспринимают нетехнические администраторы сайтов.
Полагаю, я ищу постепенные и относительно простые шаги. Возможно, изменение менеджера Docker с технической точки зрения столь же прямолинейно.
Да, если когда-нибудь это станет возможным, было бы очень хорошо иметь в настройках администратора один булевый параметр «отключить все плагины», который работал бы без пересборки контейнеров. Однако, не будучи разработчиком Discourse (имея лишь год опыта разработки приложений на node.js и vuejs), мои инстинкты подсказывают, что это непростое изменение и потребует значительных архитектурных доработок.
В нашем устаревшем форуме на стеке LAMP была эта функция, и мы не раз использовали этот булевый параметр для быстрого выявления ошибок, связанных с плагинами. Однако архитектура программного обеспечения настолько отличается, что сравнивать их даже бессмысленно.
Лично я уверен, что команда Discourse придумает решение. Многие пользователи зависят от плагинов, и со временем проблем будет становиться всё больше.
Для меня важным фактором является то, что эта функция предназначена исключительно для тех, кто размещает Discourse самостоятельно. Я не хочу включать в ядро режим безопасной работы для плагинов — это точно не то, что мы будем использовать, так как координация перезапуска через 5 кластеров — сложная задача.
Docker manager — подходящий инструмент для этого. Он уже поддерживает перезапуск приложения, что необходимо для реализации вашего предложения, и может выполнить все требуемые действия без изменений в ядре Discourse.