В последней версии Discourse использование файлов .hbs в темах и плагинах устарело. Поддержка этого формата файлов будет удалена после следующего релиза ESR.
Шаблоны Handlebars следует заменить на более современный формат .gjs, который обеспечивает гораздо лучший опыт разработки и позволит значительно повысить производительность в будущих версиях Discourse.
Для простых случаев поделитесь своим кодом на https://ask.discourse.com/ и попросите переписать его в формате .gjs.
Для более сложных случаев обновление можно автоматизировать с помощью этого кодомода:
It’s most likely that we will drop support in 2026.8.0-latest. But it’s possible it could be later, depending on real-world data and community feedback.
Спасибо! Надеюсь, большинство людей уже позаботились об этом, так как эти функции были объявлены устаревшими с помощью баннера для администраторов почти год назад. На всякий случай я добавил эту заметку:
Что касается меня, я попробовал для своего маленького личного плагина и добился успеха с помощью ask Discourse, который объединил мои файлы hbs и js в один файл gjs.
Настоятельно рекомендую использовать ask Discourse для решения этой проблемы тем, кто, как и я, сталкивается с трудностями в разработке
Я понятия не имею, что такое файл .gjs, и у меня нет времени разбираться в этом и переписывать множество плагинов. Это абсурд.
В чём смысл наличия API для плагинов, если он настолько хрупок, как в Discourse? Поддержка плагинов для этого программного обеспечения форума приносила одни лишь проблемы.
Если у вас нет бюджета или ресурсов для управления кастомизациями, я бы настоятельно рекомендовал упростить вашу конфигурацию.
По моему мнению, это (разумная) цена за то, что вы остаетесь на передовой высокопроизводительной платформе, которая постоянно инноварует, улучшает производительность, выпускает частые обновления безопасности и соответствует развивающимся стандартам.
Команда Discourse, похоже, прилагает много усилий, чтобы обеспечить заблаговременные предупреждения об устаревании функций задолго до их отключения.
Неужели вы предпочли бы застрять на небезопасной платформе с меньшим количеством функций?
Подумайте о ценности, которую вы получаете от хорошо поддерживаемого ядра, которое можно скачать бесплатно?
У меня это не сработало для моего маленького плагина.
Но с помощью ask.discourse.com он прочитал мой код и конвертировал мой файл hbs и js в .gjs, так что не стоит сомневаться, если первый метод не работает
Обратите внимание: я понимаю ваше разочарование. Все, кто разрабатывает плагины, темы или компоненты, сталкиваются с устареванием и обязательными обновлениями.
Я больше не буду работать над своими плагинами для Discourse. Это просто не стоит того.
Учитывая, что другие люди используют два из них, каков процесс их удаления, чтобы не создать проблем другим?
Я устал от того, что они ломаются каждые несколько месяцев, обычно по совершенно абсурдным причинам, а также от затраченного времени и усилий, необходимых лишь для того, чтобы мой форум продолжал работать.
Я не хочу быть «на острие прогресса». Мне просто нужен рабочий и стабильный веб-форум.
Вариант «не обновляться» тоже не подходит, так как нам нужны обновления безопасности. Абсурдно, что в прошлый раз, когда я жаловался, кто-то предложил именно это.
Команде Discourse действительно нужно больше заботиться о совместимости и не ломать существующие форумы и код. Они, похоже, даже не задумываются об этом. Они вносят разрушающие изменения лишь для того, чтобы немного упорядочить что-то на своей стороне. Так не управляется платформа и API, которыми пользуются другие люди, и я больше не хочу иметь с этим ничего общего.
Если вы всё же хотите пойти по этому пути, я рекомендую добавить примечание в README и тему Meta, пометить её как broken, а затем архивировать репозиторий GitHub. Таким образом, он всё ещё будет доступен для форка (при условии, что лицензия достаточно разрешительная).
Мы определённо заботимся о совместимости и о том, чтобы всё работало. Именно поэтому у нас есть длительные периоды устаревания с полностью автоматизированными путями обновления.
Мы всегда стараемся найти баланс между настраиваемостью и стабильностью — темы и плагины Discourse настолько мощные потому что мы даём им прямой доступ к базовым API браузера/фреймворка. Эта огромная сила несёт с собой определённую ответственность за своевременное обновление в соответствии с изменениями в базовых системах.
Действительно — своевременное обновление важно. За последние несколько месяцев мы значительно вложились в наш процесс выпуска версий, чтобы сделать его намного лучше для пользователей ESR (ранее «стабильные»). Подробнее здесь. Вам всё ещё нужно обновляться, но теперь есть гораздо больше гибкости в сроках и срочности.
Что касается конкретного устаревания, решение полностью автоматизировано. Если вы сообщите нам названия плагинов, мы с радостью запустим для вас кодмод и создадим PR. Мы уже сделали это для всех 600+ тем и плагинов, которые поддерживаем, так что сейчас это отлаженный механизм.
Я понимаю, что если кто-то возвращается через несколько месяцев, ему может быть сложно обнаружить, что многое изменилось. Следить за изменениями может быть непросто, но, на мой взгляд, это цена, которую нужно платить за передовое программное обеспечение для форумов с обширным API.
Тогда почему вы продолжаете вносить изменения, продиктованные желанием убрать мелкие «остатки» с вашей стороны, в ущерб совместимости?
Этот устаревший «мусор» — часть цены за поддержание платформы или API. Он не создаёт реальных проблем. Но вы настаиваете на его изменении или удалении, заставляя других людей выполнять дополнительную работу и тестирование.
Версии ESR существуют всего 9 месяцев, что hardly можно назвать расширенной поддержкой.
К тому же их использование означает, что вам придётся столкнуться со всеми разрывающими изменениями одновременно, а список коммитов, которые нужно просмотреть, чтобы понять причину проблемы, станет намного больше.
ESR в её нынешнем виде лишь усугубит эту проблему, а не улучшит её.
Единственное решение — действительно заботиться об API и поддерживать его. Вносить разрывающие изменения только в крайнем случае, а не ради «приятных мелочей» вроде уборки. И не выбрасывать целый фреймворк, который используют люди, просто потому, что вам захотелось использовать другой, или по любой другой причине.
Здесь процесс выглядит так: на продакшене используются ESR-версии, а на стейджинге — ежемесячные релизы или версии с пометкой «тесты пройдены».
Если вы обновляете стейджинг ежедневно, еженедельно или ежемесячно (это даже можно автоматизировать), вы сможете поэтапно обновлять свои плагины и темы, поддерживая их в рабочем состоянии.
Тот факт, что на продакшене используются ESR-версии, даёт вам минимум три месяца на исправление проблем.
Кажется, вы не можете понять, что опубликованный API не должен быть постоянно меняющейся целью.
Представьте, если бы Microsoft заставляла всех разработчиков Windows менять свой код каждые шесть месяцев. Это немыслимо. Вы можете взять код, написанный для Windows 95 30 лет назад, и скомпилировать и запустить его на современной машине сегодня без каких-либо изменений.
Вы не можете заявлять о заботе о совместимости, когда код, написанный по вашим спецификациям, перестанет работать исключительно из-за решений, принятых вами.
