Sì, penso che questa sia probabilmente l’opzione migliore. Avevo iniziato a lavorarci a giugno 2020, ma si è rivelato un lavoro molto impegnativo e ho dovuto passare ad altri progetti. Avevo due approcci per permettere URL upload:// nei tag <img… nessuno dei due è perfetto. Dai miei appunti:
Implementazione 1:
Nel flusso di elaborazione del markdown, analizzare il contenuto di ogni html_block (abusando leggermente della libreria xss.js) ed elaborare tutti i tag immagine con attributi src che iniziano con upload://.
Vantaggi: tutto avviene nel flusso del markdown, l’elaborazione viene eseguita solo sui token html_block
Svantaggi: un po’ un uso improprio del sanificatore xss.js. Potrebbe non essere un parser HTML5 perfetto
Questa opzione potrebbe essere migliorata utilizzando un’implementazione DOM JavaScript conforme agli standard (ad esempio jsdom) sul server, ma sembra piuttosto pesante.
Implementazione 2:
Permettere attributi src con upload:// per tutto il flusso del markdown, per poi sostituirli in un secondo momento. Sul client, questo è in realtà piuttosto semplice: stavamo già sostituendo asincronamente gli URL upload:// dopo la cottura. Sul server, questo richiede un’ulteriore fase di elaborazione utilizzando Nokogiri.
Vantaggi: il parser è conforme agli standard HTML5
Svantaggi: implementazione diversa su client/server, rende il flusso leggermente più complesso
Penso che l’opzione 2 sia probabilmente la strada da seguire. Dovremo quindi aggiornare il job pull_hotlinked_images per mantenere i tag <img, senza sostituirli con il Markdown. Spero di riuscire a trovare il tempo per riprendere questo lavoro presto 