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 vedrai perché sono problemi separati.
Entità HTML nelle notifiche email di testo normale
La cosa migliore sarebbe che i messaggi email fossero multipart con un rendering markdown in testo pulito text/plain e un text/html separato.
Questo è in realtà il modo in cui funzionano attualmente le notifiche email di Discourse. Se guardi l’“originale” di una notifica email di Discourse, vedrai che c’è una versione testuale e una versione HTML.
Quello che sembra che tu stia dicendo, ma non sono ancora sicuro al 100%, è che stai ricevendo entità HTML nella versione di testo normale delle notifiche email di Discourse, il risultato è che stai vedendo le vere entità HTML nel corpo dell’email quando la guardi in un client di posta elettronica che non supporta HTML. È questo che stai dicendo? Potresti condividere uno screenshot di questo da un client di posta elettronica (che non supporta HTML)?
Se questo è il caso, si tratta di un problema specifico della generazione e formattazione dei contenuti delle email di Discourse e sarebbe meglio dividerlo in un argomento più mirato in Support o Bug.
HTML nei post di Discourse
Stai sollevando un problema pertinente qui, ma da una prospettiva tecnica la questione riguarda come Discourse gestisce i contenuti importati in generale. L’impostazione predefinita attuale per i contenuti importati è HTML, non markdown.
Altri contesti in cui puoi vederlo è 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 che riguardano l’HTML incorporato nei post (ad esempio, allowed embed selectors).
Sto indovinando in parte, ma il motivo più probabile per cui questa decisione strategica è stata presa nei primi giorni di Discourse nella gestione dei contenuti importati è stata 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 i diversi sapori di markdown.
Infatti, il plugin WP Discourse che tenta di gestire la conversione sarebbe effettivamente fuorviante, considerando che esiste già un convertitore personalizzato HtmlToMarkdown in Discourse. Attualmente questo convertitore gestisce la conversione di HTML in 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 post, ovvero l’endpoint /posts. Quindi, essenzialmente, quello che stai dicendo è che desideri che il supporto del convertitore HtmlToMarkdown venga aggiunto all’endpoint /posts di Discourse (cioè come parametro di query opzionale). Potresti sostenere questo e, se implementato, il plugin WP Discourse lo adotterebbe come impostazione opzionale.