Abbiamo creato un plugin che ridefinisce l’outlet del plugin post-event-builder: ogni evento creato sulla nostra istanza richiede la compilazione dei campi personalizzati, e il nostro modulo completa i valori proposti con dati da una fonte esterna.
Utilizziamo solo versioni ESR di Discourse, quindi tutto funzionava correttamente su 2026.1.x, e ora sto procedendo all’aggiornamento a 2026.7.x, scoprendo così il nuovo modulo e quello avanzato.
Poiché i nostri utenti devono compilare tutti i campi personalizzati, vorremmo utilizzare il modulo “avanzato” al posto di quello compatto, senza l’opzione per cambiare modulo.
Inizialmente ho pensato a un’impostazione di sito per utilizzare il modulo avanzato in modo predefinito (disabilitando la possibilità di passare a quello compatto, dato che tutto è già presente nel modulo avanzato), oppure a due impostazioni (utilizzare il modulo avanzato in modo predefinito, impedire il cambio di modulo). Un plugin outlet per sostituire il modulo compatto potrebbe essere utile, purché includa il passaggio al modulo avanzato in modo da poterlo rimuovere.
Il nuovo comportamento ci sta bloccando seriamente nel processo di aggiornamento e non possiamo restare sulla vecchia versione 2026.1.x, ormai non più mantenuta.
Qual sarebbe l’approccio migliore? Come posso contribuire?
Se creo una PR con un nuovo plugin outlet, c’è la possibilità che venga accettata e backportata alla prossima versione 2026.7.x, o dovremmo trovare un altro modo per risolvere questo problema bloccante?
Ho aggiunto un nuovo outlet di plugin per sovrascrivere il form “compact” predefinito, ma non sono davvero soddisfatto della modifica.
Il pulsante per accedere al form “advanced” non può essere sovrascritto tramite l’outlet e l’“anteprima modificabile” nell’editor continua a utilizzare la “modalità compact”, che potrebbe non adattarsi al form sovrascritto (almeno, non nel nostro caso).
Inizio a pensare che una soluzione più pulita sarebbe aggiungere un’opzione nell’area di amministrazione del plugin per scegliere il comportamento del form. Vedo almeno 2 opzioni:
default_editor: scegli “compact” (predefinito) o “advanced”
allow_editor_switch: nasconderà i pulsanti per cambiare editor
Sto ancora approfondendo le implicazioni, ma apprezzo qualsiasi feedback sull’idea generale
In tal caso, nel componente PostEventBuilder, creerei un value transformer per initialScreen, un getter che legge this.args.model.initialScreen e poi sovrascrive il valore tramite il value transformer. In questo modo, initialScreen sarebbe sempre impostato a advanced tramite il value transformer.
Sarò lieto di recensire una PR per il core da parte tua per il value transformer; suppongo che tu abbia già un tema personalizzato a cui agganciare questa funzionalità.
Non posso allegare screenshot, quindi proverò a descrivere il comportamento attuale e ciò che voglio ottenere
Utilizzando l’editor Markdown:
se l’anteprima è abilitata, il modulo evento viene mostrato nell’anteprima (non racchiuso in post-event-builder), con un pulsante in alto a destra nell’anteprima per passare alla modalità avanzata
se l’anteprima è disabilitata, il modulo evento appare in una finestra modale, racchiuso in post-event-builder (il caso d’uso che hai menzionato) con un pulsante nel piè di pagina della finestra modale per passare alla modalità avanzata
Utilizzando l’editor di testo formattato, il modulo evento è incorporato nel modulo del post; sembra essere lo stesso blocco usato nell’anteprima.
Quello che mi serve è avere un solo editor, il nostro.
Poiché il plugin è incluso nel core, sono consapevole che qualsiasi modifica avrà un impatto su tutti gli utenti del plugin, quindi le modifiche dovrebbero essere minime
Non mi sento ancora abbastanza a mio agio con EmberJS da capire come tutto sia collegato, quindi ogni modifica richiede tempo e spesso ottengo un risultato solo per rendermi conto che forse esiste un altro modo più pulito di fare le cose.
Forse l’ultimo approccio, che consiste nell’aggiungere nuovi parametri di amministratore, è eccessivo e ho semplicemente trovato il componente giusto in cui aggiungere un outlet del plugin per cambiare tutto…
Hai ragione, non era un problema relativo ai permessi: ho un’estensione che blocca i referrer e non si combina bene con AWS
Editor Markdown + anteprima: il modulo degli eventi è incorporato nell’anteprima (l’ingranaggio mostra una finestra modale con l’editor “avanzato” degli eventi)
Editor Markdown, senza anteprima: il modulo degli eventi è in una finestra modale, il pulsante per passare da un editor all’altro è nel piè di pagina della finestra modale
Editor di testo formattato: il modulo degli eventi è incorporato nell’editor (l’ingranaggio mostra una finestra modale con l’editor “avanzato” degli eventi)
