Hmmm, in quell’esempio e nell’intero codice sorgente dell’email che mi hai inviato (grazie!), l’attributo moz-do-not-send non dovrebbe influenzare la visualizzazione dei tag <img> o <a> in cui quell’attributo appare. Il filtro mozfilter controlla solo i valori nell’attributo class, e non riesco a vedere immediatamente nessun altro punto in cui potrebbe essere filtrato.
Di conseguenza, non riesco a capire perché il contenuto e l’href del link con alias vengano separati, a meno che, per qualche motivo, l’importatore di Discourse non abbia deciso improvvisamente di utilizzare la parte plain/text dell’email codificata in Mime (che effettivamente ha testo e URL separati). Non so perché dovrebbe farlo.
Nel tuo ambiente di test di Discourse, puoi provare a importare o inviare via email un’email HTML di Thunderbird contenente sia un link con alias che, ad esempio, un’immagine incorporata o qualcos’altro che la identifichi chiaramente come la parte HTML dell’email?
Sto ancora pensando che potrebbe trattarsi di Discourse che utilizza le altre parti MIME (in questo caso una parte plain/text seguita da una parte image/… dell’email per crearne la versione in markdown, anche se non so perché. Forse un validatore HTML sta rifiutando la parte text/html a causa di attributi non strettamente validi come moz-do-not-send!?
Potresti fare un altro test con lo stesso post (del testo con un’immagine nel mezzo, ma rendi anche in grassetto alcune parti del testo, anche solo una parola, non tutte). Credo che questo determinerà se la parte di testo proviene da un blocco text/plain o text/html.
E scusa per la richiesta, ma per sicurezza, hai impostato incoming_email_prefer_html su true (spuntato)?!
Grazie @Flominator. Vedo che il testo in grassetto è diventato corsivo, quindi sicuramente non sta usando direttamente l’HTML, ma in qualche modo sta rilevando l’enfasi. Mi chiedo se la parte text/plain dell’email riceva qualche tipo di markup aggiunto – potresti inviarmi in MP il codice sorgente dell’email come la volta scorsa?
Ciao @Flominator, grazie per l’email grezza. Guardando la parte alternativa text/plain dell’email, si nota effettivamente che ci sono asterischi intorno al testo che è in grassetto nella parte text/html. La maggior parte dei renderer markdown (come quello di Discourse) interpreta questo come testo in corsivo. Ecco il segmento text/plain copiato e incollato da solo:
Bild in die Mitte dann wieder Text von dem ein Teil sogar fett
geschrieben ist
Gruß
Flo
che appare identico allo screenshot che hai inviato.
Quindi, quello che penso stia accadendo è che il segmento text/html venga rifiutato come HTML non valido (probabilmente a causa dell’attributo non standard moz-do-not-send nei tag a). Questo richiederà una patch per modificare il modo in cui viene controllato l’HTML valido (forse rimuovendo semplicemente quegli attributi), ma sono meno sicuro di quanto sarà stabile senza che ciò venga integrato nel codice principale. Ci darò un’occhiata quando avrò un po’ di tempo.
Ciò significa che la patch allegata in un commento precedente fallirà (probabilmente non in modo “spettacolare” ma potrebbe richiedere una ricompilazione per riprendere gli aggiornamenti) quando si aggiornerà per includere questo nuovo commit (probabilmente il prossimo aggiornamento).
Se lo si applica automaticamente (ad esempio con un comando git apply in app.yml come descritto sopra), è necessario rimuoverlo prima del prossimo aggiornamento. In effetti, una ricompilazione potrebbe essere opportuna poiché quel commit potrebbe non riuscire ad applicarsi poiché il punto in receiver.rb in cui si desidera applicare la differenza del commit è già stato modificato dalla patch.
Farò quanto segue: 1) rimuovere il comando git apply da app.yml, 2) ricompilare l’app, 3) aggiornare (se non è già stato fatto nella ricompilazione). Vi farò sapere come va…
[10 minuti dopo…]
Alla fine ho fatto questo invece perché non richiede tempi di inattività durante la ricompilazione.
rimuovere il git apply per la patch da app.yml (è necessario farlo solo prima della prossima ricompilazione del container dell’app)
ripristinare il file patchato con:
i) launcher enter app
ii) (ora nel container dell’app) cd /var/www/discourse git checkout ./lib/email/receiver.rb exit
aggiornare discourse utilizzando l’aggiornamento web admin.
