Discourse の最新バージョンでは、テーマやプラグインで .hbs ファイルを使用することは非推奨になりました。このファイル形式のサポートは、次の ESR リリース後に削除されます。
Handlebars テンプレートは、よりモダンな .gjs 形式に置き換える必要があります。これにより、開発体験が大幅に向上し、将来の Discourse のバージョンで大きなパフォーマンス向上が可能になります。
簡単なケースについては、コードを https://ask.discourse.com/ で共有し、.gjs 形式に書き直すように依頼してください。
より複雑なケースについては、こちらの codemod を使用して更新を自動化できます。
2026.7ではまだhbsファイルがサポートされ、2027.1がサポートされなくなる最初のESRリリースである、と正しく理解していますか？
はい、その通りです。
おそらく、サポートは 2026.8.0-latest で終了するでしょう。ただし、実際のデータやコミュニティのフィードバックによっては、それ以降になる可能性もあります。
たった今これを見つけましたが、更新が必要そうですね。
ありがとうございます！ほとんどの人はすでにそれらの対応を済ませているはずですが、管理者のバナーで約1年間非推奨とされていました。念のため、この注意書きを追加しました。
私の方では、個人用の小さなプラグインを試したところ、ask Discourseの助けを借りて、hbsファイルとjsファイルをgjsファイルに統合することに成功しました🤣
私のように開発に苦労している人は、この問題を解決するためにask Discourseを使うことを強くお勧めします。
それは素晴らしいです！OPにもask.discourse.comに関する注記を追加しました。ファイルが数個しかない場合は、非常にうまく機能しますよ 
.gjs ファイルが何なのか、またそれを学んで複数のプラグインを書き直す時間もないというのが私の状況です。これはありえません。
Discourse のような脆弱なプラグイン API を持つことに一体何の意味があるのでしょうか？このフォーラムソフトウェアのプラグインを維持することは、トラブルの連続でした。
全くおかしな話ではありません。
カスタマイズの管理に予算やリソースが足りない場合は、設定を簡素化することを強くお勧めします。
これは、イノベーションを続け、パフォーマンスを向上させ、頻繁なセキュリティパッチを適用し、進化する標準に対応する最先端の高速プラットフォームに留まるための（妥当な）対価だと個人的には思います。
Discourse チームは、機能の喪失に先立って十分な時間前に非推奨警告メッセージが表示されるよう、多大な努力を払っているようです。
セキュリティが脆弱で機能が少ないプラットフォームに留まることを選びますか？
無料でダウンロードできる、よくメンテナンスされたコアから得られる価値について考えてみてください。
.gjs ファイルが何なのかを知る必要さえありません: Automatically updating themes and plugins to .gjs file format
私の小さなプラグインではうまくいきませんでした。
でも、ask.discourse.com の助けを借りて、コードを読んでもらい、hbs ファイルと js ファイルを .gjs に変換してもらいました。最初の手法がうまくいかない場合は、ためらわずに試してみてください。
これについては、こちらでも回答されています：
また、
ご不満はお察しします。プラグイン、テーマ、またはコンポーネントを開発された方であれば、誰もが非推奨化や必須アップデートに直面しています。
他にも不満を表明されている方がいます：
私は Discourse プラグインの追加作業は行いません。もはやその価値がないからです。
他の人が私のプラグインの 2 つを使用していることを考えると、他の人に問題を引き起こさずにそれらを削除する手順はどのようなものでしょうか？
数ヶ月ごとに、まったく意味のない理由でプラグインが機能しなくなることにうんざりしています。また、自分のフォーラムを稼働させるために必要な時間と労力も多すぎます。
私は「最先端」にいたいわけではありません。単に、動作し、安定した Web フォーラムが欲しいだけです。
「更新しない」という選択肢もありません。セキュリティ更新が必要だからです。前回私が不満を述べた際、誰かがそのように提案したことはばかげています。
Discourse チームは、互換性をより重視し、既存のフォーラムやコードを壊さないようにするべきです。彼らはそのことについてほとんど考えていないように見えます。彼らは、自分側の整理を少し整えるために、互換性を破壊する変更を加えています。これは、他の人が利用しているプラットフォームや API を管理する方法ではありません。私はこれ以上、その一部になりたくありません。
そのような状況で申し訳ございません。
もしこの方針で進めたい場合は、README およびメタトピックに注意を追加し、broken とマークしてから、GitHub リポジトリをアーカイブすることをお勧めします。そうすれば、ライセンスが十分に寛容であれば、他の人がフォークできるようになります。
私たちは確かに互換性と機能の維持を重視しています。そのため、完全に自動化されたアップグレードパスを備えた長い非推奨期間を設けています。
私たちは常にカスタマイズ性と安定性のバランスを取るよう努めています。Discourse のテーマやプラグインがこれほど強力なのは、それらが基盤となるブラウザやフレームワークの API に直接アクセスできるからです。この莫大なパワーには、基盤となる変更に対応し続けるという一定の責任が伴います。
その通りです。最新の状態を維持することは重要です。過去数ヶ月間、ESR（以前は「安定版」）ユーザーのためにリリースパイプラインに大幅な投資を行い、改善を図ってきました。詳細は こちら をご覧ください。更新は必要ですが、タイミングと緊急性についてはより柔軟性が生まれています。
今回の特定の非推奨については、解決策は完全に自動化されています。プラグイン名をお知らせいただければ、コード変換を実行し、PR を作成することも喜んでお手伝いいたします。私たちは現在管理している600以上のテーマやプラグインに対してすべてこの作業を行っており、すでに非常にスムーズなプロセスとなっています。
この投稿で、私は unmaintained タグ、または end-of-life タグの追加を提案しました。
数ヶ月後に戻ってきた際に多くの変更があることに気づくのは簡単ではないことは理解しています。変更に対応し続けるのは大変かもしれませんが、私見では、広範な API を備えた最先端のフォーラムソフトウェアを利用する上で、払うべき代償です。
それなら、なぜ自らの側での些細な「不純物」の整理を優先し、互換性を犠牲にして変更を繰り返すのでしょうか？
そのようなレガシーな不純物は、プラットフォームや API を維持する上で必要なコストの一部です。実際には大きな問題を引き起こすことはありません。しかし、あなたはそれを無理に変更・削除し、結果として他者に追加の作業やテストを強いています。
ESR のサポート期間はわずか 9 ヶ月であり、これは「拡張サポート」とは言い難いものです。
また、ESR を使用すれば、すべての破壊的変更が一度に発生することになり、問題の原因を特定するために検索しなければならないコミットリストも膨大になります。
現状の ESR は、この問題を悪化させるだけで、改善にはなりません。
唯一の解決策は、API を真に重視し、維持することです。破壊的変更は最終手段としてのみ行い、「あったらいいな」程度の整理のために実施すべきではありません。また、自分が別のフレームワークを使いたいという理由や、その他諸々の理由で、人々が利用しているフレームワーク全体を廃止するようなことはやめてください。
ここで推奨されるプロセスは、本番環境を ESR で、ステージング環境を月次リリースまたはテスト通過版で運用することです。
ステージング環境を毎日・毎週・毎月更新すれば（自動化も可能です）、プラグインやテーマを反復的に更新し、常に動作する状態に保つことができます。
本番環境を ESR に維持することで、問題を修正するための最低 3 ヶ月の猶予が得られます。
公開された API が常に変化する標的であってはならないという概念が、どうやらご理解いただけないようです。
もしマイクロソフトが、Windows 開発者に 6 ヶ月ごとにコードをすべて書き換えさせるようなことをしたらどうでしょうか。考えられません。30 年前に Windows 95 向けに書かれたコードであっても、現在では全く変更を加えずに最新のマシンでコンパイルし、実行することができます。
ご自身で定めた仕様に基づいて書かれたコードが、ご自身の判断によって完全に動作しなくなる状況において、互換性を重視しているなどとは主張できません。
Windows はそのスタック全体を制御しますが、Discourse はライブエコシステム上にプラットフォームを構築しています。Ember だけでも、メジャーバージョン間で後方互換性を繰り返し破ってきました。そして、それはフロントエンドエコシステムにおいてむしろ例外ではなく、むしろ一般的なことなのです。
私には、ここで適切なモデルは Windows ではなく、他の API プラットフォームが採用しているもの、つまり明確なバージョン管理、廃止のお知らせ、そして合理的な移行期間であることが非常に明確に思われます。