Nell’ultima versione di Discourse, l’uso di file .hbs nei temi e nei plugin è deprecato. Il supporto per questo formato di file verrà rimosso dopo la prossima versione ESR.
I template Handlebars dovrebbero essere sostituiti con il formato .gjs più moderno, che fornisce un’esperienza di sviluppo notevolmente migliore e consentirà grandi miglioramenti delle prestazioni nelle future versioni di Discourse.
Per i casi semplici, condividi il tuo codice con https://ask.discourse.com/ e chiedi di riscriverlo nel formato .gjs.
Per i casi più complessi, gli aggiornamenti possono essere automatizzati utilizzando questo codemod:
È molto probabile che abbandoneremo il supporto in 2026.8.0-latest. Ma è possibile che sia più tardi, a seconda dei dati reali e del feedback della comunità.
Grazie! Si spera che la maggior parte delle persone se ne sia già occupata, dato che sono stati deprecati con un banner amministrativo per quasi un anno. Non si sa mai, ho aggiunto questa nota:
Per quanto mi riguarda, ho provato per il mio piccolo plugin personale e ci sono riuscito con l’aiuto di ask Discourse che ha unito i miei file hbs e js in un unico file gjs.
Consiglio vivamente l’uso di ask Discourse per risolvere questo problema a chi, come me, ha difficoltà di sviluppo
Non ho idea di cosa sia un file .gjs, né ho tempo di studiarli e riscrivere più plugin. È ridicolo.
A cosa serve avere un’API per i plugin se è fragile come quella di Discourse? Mantenere i plugin per questo software di forum è stato solo un problema dopo l’altro.
Se non hai il budget o le risorse per gestire le personalizzazioni, ti consiglio vivamente di semplificare la tua configurazione.
A mio avviso, è il prezzo (ragionevole) da pagare per rimanere su una piattaforma all’avanguardia ad alta velocità che continua a innovare, migliorare le prestazioni, distribuire frequenti patch di sicurezza e stare al passo con gli standard in evoluzione.
Il team di Discourse sembra impegnarsi molto per garantire che i messaggi di avviso di deprecazione arrivino con largo anticipo rispetto alla rimozione delle funzionalità.
Preferiresti rimanere bloccato su una piattaforma insicura con meno funzionalità?
Pensa al valore che ottieni dal core ben mantenuto che puoi scaricare gratuitamente.
Ma con l’aiuto di ask.discourse.com, ha letto il mio codice e ha convertito il mio file hbs e js in .gjs, quindi non esitate se il primo metodo non funziona.
Credo che questa domanda sia già stata risposta qui:
Inoltre,
Tieni presente che capisco la tua frustrazione: tutti coloro che hanno sviluppato plugin, temi o componenti qui si trovano ad affrontare deprecazioni e aggiornamenti obbligatori.
Non intendo più lavorare su nessuno dei miei plugin per Discourse. Non ne vale semplicemente la pena.
Visto che altre persone ne stanno utilizzando due di questi, qual è la procedura per eliminarli senza creare problemi agli altri?
Ne ho abbastanza del fatto che si rompano, di solito per motivi completamente assurdi, ogni pochi mesi, e della quantità di tempo e sforzo necessari solo per mantenere funzionante il mio forum.
Non voglio essere “all’avanguardia”. Voglio semplicemente un forum web funzionante e stabile.
Dire “non aggiornare” non è un’opzione, dato che abbiamo bisogno di aggiornamenti di sicurezza. È assurdo che qualcuno abbia suggerito proprio questo l’ultima volta che mi sono lamentato.
Il team di Discourse deve davvero preoccuparsi di più della compatibilità e del non rompere forum e codice esistenti. Sembra che non ci pensino nemmeno. Introducono cambiamenti che rompono la compatibilità solo per mettere un po’ d’ordine dalla loro parte. Questo non è il modo in cui si gestisce una piattaforma e un’API utilizzate da altre persone, e non voglio avere più nulla a che fare con questo.
Se desideri procedere in questa direzione, ti consiglio di aggiungere una nota al README e al topic Meta, segnalandolo come #rotto e poi archiviarlo su GitHub. In questo modo, rimane ancora disponibile per essere forklato da altri (assumendo che la licenza sia sufficientemente permissiva).
Ci preoccupiamo assolutamente della compatibilità e del mantenimento del corretto funzionamento delle cose. Ecco perché abbiamo lunghi periodi di deprecazione con percorsi di aggiornamento completamente automatizzati.
Cerchiamo sempre di trovare un equilibrio tra personalizzazione e stabilità: i temi e i plugin di Discourse sono così potenti proprio perché diamo loro accesso diretto alle API sottostanti del browser/framework. Questo enorme potere comporta una certa responsabilità nel tenersi aggiornati rispetto ai cambiamenti sottostanti.
Infatti: tenersi aggiornati è importante. Negli ultimi mesi abbiamo investito molto nel nostro processo di rilascio per rendere le cose molto migliori per gli utenti ESR (precedentemente ‘stable’). Maggiori dettagli qui. Dovrai ancora aggiornare, ma c’è molta più flessibilità riguardo ai tempi e all’urgenza.
Per quanto riguarda questa specifica deprecazione, la soluzione è completamente automatizzata. Se puoi farci sapere i nomi dei plugin, saremo felici di eseguire il codemod per te e creare una PR. L’abbiamo fatto per tutti i 600+ temi/plugin che manteniamo, quindi a questo punto è un meccanismo ben oliato.
Capisco che non sia facile, se si torna dopo qualche mese e si scopre che molto è cambiato. Tenersi aggiornati sulle modifiche potrebbe non essere semplice, ma a mio avviso è il prezzo da pagare per un software di forum all’avanguardia con un’API estesa.
Allora perché continuate a apportare cambiamenti dettati dal desiderio di ripulire piccole quantità di spazzatura dal vostro lato, a scapito della compatibilità?
Quella spazzatura obsoleta fa parte del prezzo da pagare per mantenere una piattaforma o un’API. Non causa problemi reali. Ma voi insistete nel cambiarla/rimuoverla, costringendo altri a svolgere lavoro aggiuntivo e a effettuare test in conseguenza di ciò.
Gli ESR durano solo 9 mesi, il che difficilmente può essere considerato supporto esteso.
Inoltre, utilizzarli significa dover gestire tutti i cambiamenti che rompono la compatibilità tutti insieme, con un elenco molto più ampio di commit da cercare se si sta cercando di capire perché si è verificato un problema.
L’ESR così com’è oggi peggiorerà questo problema, non lo migliorerà.
L’unica soluzione è preoccuparsi davvero dell’API e mantenerla. Effettuare cambiamenti che rompono la compatibilità solo come ultima risorsa, non per piccole pulizie “nice to have”. E non buttare via un intero framework che le persone stanno utilizzando solo perché vi va di usarne un altro, o per qualsiasi altra ragione.
La procedura qui è avere la produzione su ESR e lo staging sulle release mensili o su quelle con test superati.
Se aggiorni lo staging ogni giorno/settimana/mese – puoi anche automatizzare questo processo – sarai in grado di aggiornare in modo iterativo i tuoi plugin e temi, mantenendoli in uno stato funzionante.
Il fatto che tu mantenga la produzione su ESR ti offre un margine minimo di tre mesi per risolvere i problemi.
Sembra che tu non riesca a comprendere il concetto secondo cui un’API pubblicata non dovrebbe essere un bersaglio in continuo movimento.
Immagina se Microsoft obbligasse tutti gli sviluppatori di Windows a modificare il proprio codice ogni sei mesi. È impensabile. Puoi prendere un codice scritto per Windows 95 30 anni fa e compilarlo ed eseguirlo su una macchina moderna oggi senza apportare alcuna modifica.
Non puoi affermare di preoccuparti della compatibilità quando il codice scritto secondo le tue specifiche smette di funzionare a causa esclusivamente delle decisioni che hai preso.
