In der neuesten Version von Discourse ist die Verwendung von .hbs-Dateien in Themes und Plugins veraltet. Die Unterstützung für dieses Dateiformat wird nach der nächsten ESR-Version entfernt.
Handlebars-Vorlagen sollten durch das modernere .gjs-Format ersetzt werden, das eine wesentlich bessere Entwicklungserfahrung bietet und große Leistungsverbesserungen in zukünftigen Versionen von Discourse ermöglichen wird.
In einfachen Fällen teilen Sie Ihren Code unter https://ask.discourse.com/ und bitten Sie darum, ihn im .gjs-Format neu zu schreiben.
In komplexeren Fällen können Updates mithilfe dieses Codemods automatisiert werden:
Höchstwahrscheinlich werden wir die Unterstützung in 2026.8.0-latest einstellen. Es ist jedoch möglich, dass dies später erfolgt, abhängig von realen Daten und dem Feedback der Community.
Danke! Hoffentlich haben die meisten Leute das bereits erledigt, da sie seit fast einem Jahr mit einem Admin-Banner als veraltet gekennzeichnet sind. Nur für den Fall habe ich diese Notiz hinzugefügt:
Ich persönlich habe es für mein kleines persönliches Plugin versucht und es mithilfe von Ask Discourse geschafft, das meine HBS- und JS-Dateien zu einer GJS-Datei zusammengefügt hat.
Ich empfehle dringend die Verwendung von Ask Discourse, um dieses Problem für diejenigen zu lösen, die wie ich Entwicklungsschwierigkeiten haben
Das ist großartig! Ich habe auch einen Hinweis auf ask.discourse.com im OP hinzugefügt. Wenn du nur wenige Dateien hast, kann das sehr gut funktionieren
Ich habe keine Ahnung, was eine .gjs-Datei ist, und auch keine Zeit, mich damit auseinanderzusetzen und mehrere Plugins neu zu schreiben. Das ist lächerlich.
Was soll der Sinn einer Plugin-API sein, wenn sie so fragil ist wie die in Discourse? Die Wartung von Plugins für diese Forum-Software war bisher nur Ärger.
Wenn Sie weder das Budget noch die Kapazitäten haben, um Anpassungen zu verwalten, würde ich Ihnen raten, Ihr Setup zu vereinfachen.
Meiner Meinung nach ist dies der (angemessene) Preis, den Sie dafür zahlen, auf einer hochmodernen, schnelllebigen Plattform zu bleiben, die kontinuierlich innoviert, die Leistung verbessert, häufige Sicherheitsupdates bereitstellt und mit sich wandelnden Standards Schritt hält.
Das Discourse-Team scheint große Anstrengungen zu unternehmen, um sicherzustellen, dass Verwarnungsmeldungen bei bevorstehenden Funktionsänderungen weit im Voraus ausgegeben werden.
Wären Sie lieber auf einer unsicheren Plattform mit weniger Funktionen festgefahren?
Denken Sie an den Wert, den Sie aus dem gut gepflegten Kern erhalten, den Sie kostenlos herunterladen können?
Das hat bei meinem kleinen Plugin nicht funktioniert.
Aber mit Hilfe von ask.discourse.com hat jemand meinen Code gelesen und meine .hbs- und .js-Dateien in .gjs umgewandelt. Zögert also nicht, falls die erste Methode nicht funktioniert.
Beachte, dass ich deine Frustration verstehe: Alle, die hier Plugins, Themes oder Komponenten entwickelt haben, sehen sich mit Veraltetheit und obligatorischen Updates konfrontiert.
Ich werde keine weiteren Arbeiten an meinen Discourse-Plugins mehr durchführen. Es lohnt sich einfach nicht.
Da andere Personen zwei dieser Plugins nutzen, wie ist der Prozess, um sie zu löschen, ohne anderen Probleme zu bereiten?
Ich habe es satt, dass sie alle paar Monate kaputtgehen, meist aus völlig unsinnigen Gründen, und wie viel Zeit und Aufwand es erfordert, nur mein Forum funktionsfähig zu halten.
Wenn Sie diesen Weg einschlagen möchten, empfehle ich, eine Notiz im README und im Meta-Thema hinzuzufügen, es mit broken zu markieren und dann das GitHub-Repository zu archivieren. Auf diese Weise ist es immer noch für andere verfügbar, um es zu forken (vorausgesetzt, die Lizenz ist ausreichend permissiv).
Wir kümmern uns absolut um Kompatibilität und darum, dass alles funktioniert. Deshalb haben wir diese langen Abschaffungszeiträume mit vollständig automatisierten Upgrade-Pfaden.
Wir versuchen stets, die Balance zwischen Anpassbarkeit und Stabilität zu finden – Discourse-Themes und -Plugins sind so leistungsstark, weil wir ihnen direkten Zugriff auf die zugrunde liegenden Browser-/Framework-APIs gewähren. Diese enorme Macht geht mit einer gewissen Verantwortung einher, sich über zugrunde liegende Änderungen auf dem Laufenden zu halten.
Ich verstehe, dass es nicht einfach ist, wenn man nach einigen Monaten zurückkehrt und feststellt, dass sich viel geändert hat. Mit den Änderungen Schritt zu halten mag nicht einfach sein, aber meiner Meinung nach ist es ein Preis, den man für eine hochmoderne Forumsoftware mit einer umfangreichen API zahlen muss.
Dann warum nehmen Sie ständig Änderungen vor, die darauf abzielen, kleinere Reste von Altlasten auf Ihrer Seite aufzuräumen, auf Kosten der Kompatibilität?
Diese veralteten Reste sind Teil des Preises für die Pflege einer Plattform oder API. Sie verursachen keine echten Probleme. Aber Sie bestehen darauf, sie zu ändern oder zu entfernen, wodurch andere Menschen zusätzliche Arbeit und Tests leisten müssen.
ESR-Versionen halten nur 9 Monate, was kaum als erweiterte Unterstützung gelten kann.
Und ihre Nutzung bedeutet lediglich, dass Sie sich auf einmal mit allen brechenden Änderungen auseinandersetzen müssen, wobei die Liste der Commits, nach denen Sie suchen müssen, um herauszufinden, warum ein Problem aufgetreten ist, viel länger wird.
ESR, wie es heute besteht, wird dieses Problem verschlimmern, nicht verbessern.
Die einzige Lösung besteht darin, sich tatsächlich um die API zu kümmern und sie zu pflegen. Brechende Änderungen sollten nur als letztes Mittel erfolgen, nicht für „nice-to-have“-kleine Aufräumarbeiten. Und werfen Sie nicht ein gesamtes Framework, das Menschen nutzen, einfach weg, nur weil Sie Lust auf ein anderes haben oder aus welchem Grund auch immer.
Der hier vorgesehene Prozess besteht darin, die Produktion auf ESR und die Staging-Umgebung auf den monatlichen Releases oder auf „tests-passed“ zu betreiben.
Wenn Sie Staging täglich/wöchentlich/monatlich aktualisieren – das können Sie sogar automatisieren –, können Sie Ihre Plugins und Themes schrittweise aktualisieren und in einem funktionierenden Zustand halten.
Die Tatsache, dass Sie die Produktion auf ESR belassen, gibt Ihnen mindestens drei Monate Spielraum, um Dinge zu beheben.
Sie scheinen nicht zu begreifen, dass eine veröffentlichte API kein ständiges Ziel sein sollte.
Stellen Sie sich vor, Microsoft würde alle Windows-Entwickler alle 6 Monate dazu zwingen, ihren Code zu ändern. Das ist undenkbar. Code, der vor 30 Jahren für Windows 95 geschrieben wurde, kann heute noch ohne jegliche Änderungen auf einer modernen Maschine kompiliert und ausgeführt werden.
Sie können nicht behaupten, Kompatibilität zu priorisieren, wenn Code, der zu Ihren Spezifikationen geschrieben wurde, allein aufgrund Ihrer Entscheidungen nicht mehr funktioniert.
