Dopo l’aggiornamento a 3.1.1 da 2.8.x tutti i miei vecchi template che utilizzano %{base_url}%{url} per includere un link a un argomento ora vengono evidenziati come non validi, l’interfaccia utente dice La seguente chiave di interpolazione non è valida: base_url
Ma in realtà è valido, perché se lo rimuovo e lascio solo %{url}, il link è interrotto (include solo il percorso, senza il dominio) e se lo includo, il link è valido e completo.
Questa potrebbe essere una modifica rispetto alle versioni precedenti di Discourse, ma non credo sia un bug. Trovare le chiavi di interpolazione consentite per i modelli di posta elettronica è sempre stato complicato. Ora abbiamo un argomento che spiega quali chiavi possono essere utilizzate: Interpolation Keys for Customizing Text and System Email Templates. Le chiavi consentite sono elencate qui: discourse/app/models/translation_override.rb at main · discourse/discourse · GitHub.
{base_url} non è in quell’elenco.
Dato che conosci già l’URL di base del tuo sito, non sono sicuro che la chiave sia necessaria. Invece di %{base_url}%{url}, usa semplicemente l’URL del tuo sito. Ad esempio https://forum.example.com%{url}
Ma funziona, cioè %{base_url} viene espanso correttamente, quindi non è valido (è solo l’interfaccia grafica che si lamenta). Inoltre, non si può creare un link completamente funzionante senza di esso (a meno che non si codifichi l’intera base_url, il che è un no no).
Lo scopo dei segnaposto in generale è creare software robusto, che include evitare di codificare le cose. Se cambio il nome di dominio, il nome host o il percorso della mia installazione di Discourse (qualsiasi elemento di base_url) allora dovrei modificare tutti i template in cui l’ho codificato. Questa è una cattiva pratica di codifica.
Dato che so che lo sviluppo di Discourse altrimenti segue pratiche di codifica molto sane e robuste, posso solo presumere che sia stata una svista/un bug (1) rimuovere base_url durante la convalida del template ma (2) interpretarlo comunque se presente, e (3) non offrire un’alternativa per costruire un URL completamente funzionante senza ricorrere a cattive pratiche di codifica…
Inoltre, questa sarebbe una grande modifica incompatibile con le versioni precedenti per la quale non vedo alcun beneficio reale, ma causa molto lavoro manuale per gli utenti… motivo in più per presumere che si tratti di un bug/una svista.
(Ho anche visto altri bug introdotti nella versione 3.x relativi ai template di testo, quindi ancora più motivo per presumere che sia stata una svista)
Quando testo questo, non riesco a salvare %{base_url}, quindi non viene utilizzato.
Forse è una svista. Concordo sul fatto che potrebbe interrompere i modelli di email esistenti da siti precedenti. Sposterò questo nella categoria Bug e darò al team la possibilità di decidere cosa farne.
Come ho detto inizialmente, sto parlando di modelli personalizzati esistenti etichettati erroneamente come non validi dopo l’aggiornamento a 3.x, ovvero modelli che sono stati modificati sotto 2.x e esistono ancora dopo l’aggiornamento contenenti %{base_url}. La rimozione di quel segnaposto rende impossibile creare URL completi senza ricorrere alla codifica manuale degli URL. Non rimuoverlo rende ovvio che viene ancora espanso correttamente sotto 3.1.1. Ho riletto il primo post e non lo trovo poco chiaro.
Probabilmente potresti testarlo tu stesso modificando direttamente il database (o possibilmente anche in una console Rails se il codice non esegue la stessa validazione).
Alla fine l’ho capito. Non lo testerò io stesso, ma sono sicuro che tu abbia ragione.
Questo sembra proprio un bug. Forse quello che dovrebbe succedere è che %{url} dovrebbe includere il nome host. In un modello endo un URL senza quel nome host è piuttosto inutile (a meno che non ci sia un modo HTML per cambiare la base relativa a livello globale?)
Il team è a una conferenza questa settimana, quindi ci vorrà un po’ prima che possano esprimersi su questo.
Non penserei che sia una buona pratica, perché non c’è modo di fare riferimento alla root del sito web. %{base_url} gioca un ruolo importante per una ragione, per consentire la creazione di URL. In generale, i sistemi di templating per gli URL offrono 3 segnaposto: base, percorso, url_completo, con quest’ultimo offerto solo per comodità (è la concatenazione dei primi due).
@pfaffman Questo non è ancora stato risolto nemmeno nella versione 3.2.1. Non è cambiato nulla dalla mia segnalazione iniziale. Potrebbe essere dato priorità per la risoluzione, per favore? In breve, praticamente OGNI template dovrebbe consentire %{base_url} dato che %{url} include solo il percorso dopo l’url di base.
Come minimo, non impedire all’utente di utilizzarlo (nonostante non sia presente nell’elenco delle chiavi disponibili).
Ehi @nordize, nessuno di quelli che hanno risposto qui ha il potere di correggere i bug.
Bene, cosa suggerirebbe in quel caso? Non so chi contattare o se si possa fare qualcos’altro per attirare l’attenzione delle persone pertinenti.
Per tenerti aggiornato, un ingegnere è stato assegnato per esaminare la questione. 
Qualcuno può aiutarmi con il nome dell’oggetto rails o con il comando rails console per forzare %{base_url} in un template che so per certo che lo accetta e lo espande (è solo l’interfaccia grafica che dice che non è valido)?
Ciao, @nordize!
Potresti fornire maggiori informazioni, come uno screenshot e la chiave del template che stai cercando di aggiornare. Non ho problemi a usare base_url sulla mia istanza, ma il problema potrebbe essere correlato a un particolare template.
Puoi vedere qui un esempio in cui dovrebbe esistere: Help with Rails console to edit text template
Ce ne sono molti altri (la maggior parte dei modelli di email, ad esempio).
Ogni singolo modello di email (se non ogni modello di testo!) dovrebbe consentire %{base_url} poiché quella è la radice del sito web a cui si dovrebbe essere in grado di fare riferimento da qualsiasi punto. Non capisco la decisione di rimuoverlo selettivamente da alcuni modelli… a meno che non sia stato in qualche modo un errore di valutazione.
Grazie. Ci darò un’occhiata.
Sono quasi certo che non sia intenzionale.