Come mostrato nella figura sottostante, i plugin normali non hanno “css+html” personalizzati, mentre la maggior parte dei “componenti del tema” di solito necessita di regolare “css+html”, il che ci porta a creare un gran numero di css personalizzati corrispondenti, rendendo difficile la nostra identificazione.
2 Mi Piace
Generalmente consigliamo di utilizzare GitHub o un sistema di controllo versione simile, poiché ciò semplifica il monitoraggio del codice nel tempo.
In precedenza avevamo un pulsante CSS/HTML su tutti i temi e componenti tematici, ma durante la modifica di un tema remoto, le modifiche upstream nel repository remoto sovrascrivevano la personalizzazione locale e l’esperienza era pessima, facendo sì che le persone avessero paura di aggiornare.
Suppongo che una possibile soluzione sarebbe mantenere il livello di personalizzazione separato dal repository remoto, ma questo è essenzialmente ciò che consigliamo ora (utilizzare un componente tematico per la personalizzazione locale di un tema remoto), ma forse con qualche passaggio in meno.
7 Mi Piace
Una soluzione, specialmente per i componenti del tema, sarebbe quella di effettuare un fork dei componenti del tema e apportare le tue modifiche nel tuo fork.
1 Mi Piace
Quello che intendo è che quando utilizziamo plugin di altre persone, in molti casi noi utenti abbiamo bisogno di un CSS personalizzato per regolare l’aspetto, ma quei plugin non hanno l’opzione di CSS personalizzato, il che ci porta a dover creare plugin CSS indipendenti per abbinare i plugin corrispondenti, il che porta a molti plugin disordinati, il che è molto confusionario.
Quindi spero che l’ufficiale possa supportare la personalizzazione quando si utilizzano plugin su GitHub, ad esempio: allegare automaticamente opzioni CSS+HTML personalizzabili dopo l’installazione del plugin. Se non impostiamo nulla, allora non è necessario salvare alcun dato. Se lo impostiamo, allora i dati vengono generati e archiviati secondo l’“ID del plugin”. Naturalmente, non so come fare nello specifico.
Si prega di guardare la quantità di CSS personalizzato che ho e si capirà davvero quanto sia complicato. Spesso non riesco a trovare i miei file CSS personalizzati a causa degli aggiornamenti dei plugin di altri su GitHub…
Se si desidera che la propria istanza Discourse sia priva di componenti tematici indipendenti responsabili dell’aggiunta di CSS personalizzato per un particolare plugin, si potrebbe invece creare un singolo componente tematico responsabile di tutte le personalizzazioni uniche che si desiderano per i plugin installati.
All’interno di quel componente tematico, è quindi possibile suddividere tutti i file in molteplici file .scss e importarli in un file common.scss principale.
my-theme-component/
├── about.json
├── common/
│ ├── common.scss
│ └── head_tag.html
├── scss/
│ ├── announcement-bar.scss
│ ├── banner-featured-links.scss
│ ├── category-banners.scss
│ ├── disco-toc.scss
│ ├── topic-list-excerpts.scss
│ ├── topic-list-thumbnails.scss
│ └── disco-toc.scss
└── settings.yml
3 Mi Piace
So che ci sono molti modi per implementare CSS personalizzato, ma ho pubblicato questo argomento per rendere Discourse più utile e per dare suggerimenti. Capisco il risultato della tua risposta. In breve, non sei interessato a rendere Discourse più conciso. Aggiorna la tua risposta e questo argomento può essere chiuso.
Ah, hai ragione, errore mio, ho frainteso. Volevo principalmente segnalare un suggerimento per aiutarti nel tuo caso specifico ed evidenziare la funzionalità di suddivisione dei file .scss che abbiamo per i componenti del tema, di cui pensavo potessi non essere a conoscenza.
Forse questo argomento è più adatto a Feature e poi il team di prodotto potrà intervenire e valutare se si tratta di un’aggiunta adatta.
2 Mi Piace
Preferirei un livello di personalizzazione dedicato relativo al CSS nelle impostazioni del componente con un pulsante per abilitarlo o disabilitarlo. Per qualsiasi cosa relativa all’HTML, è meglio fare un fork del componente, poiché non avrebbe senso in un livello separato, credo. Sarà più facile per un utente gestirlo riducendo il bloat non necessario del componente. 
4 Mi Piace
Questo è qualcosa di cui io e @david abbiamo discusso di recente.
Penso che l’idea valga la pena di essere considerata, ma dobbiamo pensare attentamente ai rischi: il sistema dei temi è già piuttosto flessibile e ci sono già molti modi in cui le persone si mettono nei guai, cosa che non è sempre immediatamente evidente.
Con temi, componenti e personalizzazioni manuali in cima a un Discourse in evoluzione, non è troppo difficile esporsi a modifiche che interrompono alcuni nodi del grafo di dipendenza che costruiscono per sé.
Faremo del lavoro sui temi in un futuro non troppo lontano che metterà alla prova il nostro sistema di temi in vari modi, il che potrebbe portarci a dare priorità ad alcune modifiche qui, ma, facendo ciò, penseremo più a fondo a come abilitare personalizzazioni più manutenibili. Non è ancora chiaro dove ciò ci porterà, ma potrebbe informare le nostre opinioni su questa richiesta.
4 Mi Piace