Abbiamo configurato il plugin Wordpress per pubblicare argomenti completi in una categoria di annunci sul nostro forum. Questo funziona abbastanza bene, ma i messaggi email che Discourse invia sono contrassegnati come Content-Type: text/plain; charset=UTF-8.
Per quanto ne so, questo è tecnicamente vero, poiché il formato atteso è markdown, che è una specie di plain-text. Ma, naturalmente, il markdown include anche, nel bene o nel male, “l’html è valido anche, yolo!”.
E, infatti, i post provenienti da Wordpress sono un mucchio di HTML.
Come stanno affrontando questa situazione gli altri? C’è un modo per far sì che le versioni pubblicate su Discourse siano un markdown ragionevolmente leggibile per l’uomo? Oppure, c’è un modo per forzare il content type HTML per le email generate in questa categoria? O… altre idee? Grazie!
Sì, scusa. Con “messaggi” intendevo “messaggi di posta elettronica”. E con “esso” intendevo Discourse, non il plugin Wordpress. Modificherò il post in alto per chiarire.
Nella mia immaginazione, la cosa più bella sarebbe che i messaggi di posta elettronica fossero multi-parte con un markdown renderizzato in testo pulito text/plain e un text/html separato. Ma non sono nemmeno sicuro di come funzionerebbe.
Mi scusi, ancora solo per chiarire, solleva questo problema perché le notifiche email dei post di Discourse contenenti HTML (ad esempio, post collegati a post di Wordpress nella tua categoria annunci) contengono erroneamente entità HTML? In tal caso, potresti condividere un esempio?
Il motivo per cui insisto su questo è che la generazione delle notifiche email in Discourse è piuttosto separata da qualsiasi cosa relativa al plugin Wordpress. Le notifiche email hanno una loro pipeline e ci sono diversi modi in cui puoi finire con entità HTML in un post di Discourse, un post di Wordpress è solo uno.
In altre parole, il fatto che ci sia HTML in un post di Discourse è un problema diverso da ciò che contengono le notifiche email su quel post e come sono codificate. Comprendere il problema specifico che stai riscontrando / sollevando aiuterà a portare gli occhi e l’attenzione giusti su di esso.
Potrei fraintendere cosa sta succedendo, ma ecco cosa credo stia succedendo:
Il post di WordPress viene pubblicato.
Il plugin risponde a ciò e crea un post di Discourse.
I post di Discourse sono tutti Markdown, ma succede che il post proveniente da WordPress tramite il plugin sia un pasticcio di HTML (che è perfettamente valido in Markdown).
Gli utenti iscritti alle notifiche via email ricevono un’email contenente quel testo, che assomiglia a un pasticcio di HTML.
Mi rendo conto che qualcuno potrebbe creare manualmente un post di Discourse con un sacco di HTML nello stesso modo, ma praticamente non è di solito un problema (e se lo fosse, potrebbe essere risolto per lo più con un gentile “ehi, potresti non farlo?”).
Sembra così, sia in Discourse se vai a modificare il post sia quando viene inviato:
<small>Pubblicato originariamente su: https://communityblog.fedoraproject.org/cpe-hiring-a-software-engineer/
</small><br><p>Il gruppo Community Platform Engineering, o CPE per brevità, è il team Red Hat che combina l'ingegneria IT e di rilascio per Fedora e CentOS. Attualmente abbiamo una posizione aperta per un <a href="https://global-redhat.icims.com/jobs/96157/software-engineer/job?mobile=true&width=412&height=732&bga=true&needsRedirect=false&jan1offset=-480&jun1offset=-420">ingegnere del software in India</a>.</p>
<h2>Informazioni sul ruolo</h2>
<p>Stiamo <a href="https://global-redhat.icims.com/jobs/96157/software-engineer/job?mobile=true&width=412&height=732&bga=true&needsRedirect=false&jan1offset=-480&jun1offset=-420">assumendo nuovo talento</a> per lavorare a tempo pieno su Fedora, principalmente come parte del nostro gruppo di Release Engineering. Lavorerai sull'infrastruttura che crea e distribuisce gli artefatti e gli aggiornamenti delle release di Fedora Linux. Questo ruolo è perfetto per chiunque abbia esperienza o interesse nel Release Engineering.</p>
<h2>Informazioni su CPE</h2>
<p>Il nostro obiettivo è mantenere in funzione e aggiornati i server e i servizi principali, creare release ed eseguire altre attività strategiche che richiedono più tempo dedicato di quanto i volontari possano offrire.</p>
<p>Vedi <a href="https://docs.fedoraproject.org/en-US/cpe/">la nostra documentazione</a> per maggiori informazioni. Non vediamo l'ora di conoscerti e, si spera, di lavorare presto con te!</p>
Ok, risponderò separatamente ai problemi che stai sollevando qui. Capisco perché li stai collegando, ma spero che tu possa vedere perché si tratta di problemi distinti.
Entità HTML nelle notifiche email in testo normale
la cosa migliore sarebbe che i messaggi email fossero multipartiti, con una versione text/plain renderizzata in markdown pulito e una versione separata text/html.
Questo è effettivamente come funzionano attualmente le notifiche email di Discourse. Se guardi l’“originale” di una notifica email di Discourse, vedrai che esiste una versione in testo e una versione HTML.
Quello che sembra stia dicendo, anche se non sono ancora al 100% chiaro su questo punto, è che stai ricevendo entità HTML nella versione in testo normale delle notifiche email di Discourse, il che comporta che vedi le entità HTML effettive nel corpo dell’email quando la visualizzi in un client di posta che non supporta l’HTML. È questo che intendi? Potresti condividere uno screenshot di questo da un client di posta (che non supporta l’HTML)?
Se è così, questo è un problema specifico della generazione e formattazione dei contenuti email di Discourse e sarebbe meglio separarlo in un argomento più mirato in Support o Contribute > Bug.
HTML nei post di Discourse
Stai sollevando un problema pertinente qui, ma da una prospettiva tecnica la questione riguarda come Discourse affronta più in generale i contenuti importati. L’impostazione predefinita attuale per i contenuti importati è HTML, non markdown.
Altri contesti in cui puoi vedere questo è il plugin RSS Polling, che, come il plugin WP Discourse, importa HTML nel contenuto del post. Nota anche che l’impostazione del sito embed support markdown è disattivata per impostazione predefinita e tutte le altre impostazioni del sito relative all’HTML incorporato nei post (ad es. allowed embed selectors) sono configurate di conseguenza.
Sto indovinando in parte qui, ma le ragioni più probabili per cui questa decisione strategica è stata presa nei primi giorni di gestione dei contenuti importati in Discourse sono state una combinazione di semplicità e fedeltà, ovvero le conversioni da HTML a markdown saranno imperfette. C’è un’eccezione chiave a questo che menzionerò di seguito.
Il plugin WP Discourse potrebbe tentare di convertire l’HTML dei post di WordPress in markdown prima di inviarli a Discourse. Sì, esistono librerie PHP esistenti che convertono HTML in markdown, ma non è mai così semplice quando si converte un linguaggio di markup, considerando in particolare le diverse varianti di markdown.
Infatti, il tentativo da parte del plugin WP Discourse di gestire la conversione sarebbe effettivamente fuorviante, considerando che esiste già un convertitore personalizzato HtmlToMarkdown in Discourse. Attualmente, questo convertitore gestisce la conversione da HTML a markdown nelle email importate in Discourse. Se l’HTML dei post da WordPress dovesse essere convertito in markdown di Discourse, dovrebbe essere gestito da quel convertitore.
Attualmente, il plugin WP Discourse utilizza l’API di Discourse per pubblicare i post, ovvero l’endpoint /posts. Quindi essenzialmente quello che stai dicendo è che vuoi che venga aggiunto il supporto del convertitore HtmlToMarkdown all’endpoint /posts di Discourse (ovvero come parametro di query opzionale). Potresti fare pressione per questo e, se implementato, il plugin WP Discourse lo adotterebbe come impostazione opzionale.