WordPress: correggere tag HTML visibili dopo la pubblicazione via WP-CLI

Guida basata su interventi documentati. Correzione effettivamente applicata su sette post che mostravano <code> e <strong> come testo invece di formattazione HTML.

Il difetto

Alcuni articoli generati in HTML contenevano entità come &lt;code&gt; e &lt;strong&gt; dentro i paragrafi. Il browser visualizzava i tag in chiaro e rendeva la lettura poco professionale.

Origine tecnica

La pipeline usava l'escaping HTML su un intero paragrafo che comprendeva intenzionalmente tag di markup. html.escape() è corretto per i dati non fidati, ma se applicato al markup desiderato lo trasforma in testo.

Verificare il post

wp post get ID_POST --field=post_content | grep -E '&lt;(code|strong)&gt;'
curl -sSL https://SITO/PERCORSO/ | grep -o '&lt;code&gt;' | head

Controllare il sorgente e il rendering della pagina. La presenza di entità nel codice di una spiegazione può anche essere intenzionale: non convertire automaticamente tutto il contenuto.

Correzione mirata

È stata eseguita una sostituzione controllata soltanto delle entità che rappresentavano tag inline ammessi: code, strong ed em, conservando gli escape di altri caratteri e dei frammenti dentro i blocchi di codice.

Controllare il salvataggio

Dopo wp_update_post(), rileggere post_content e verificare che il testo non contenga ancora &lt;code&gt; nei paragrafi. Nei casi in cui sono presenti backslash, usare wp_slash() per evitare la rimozione indesiderata durante il salvataggio.

Esito

I post corretti sono stati verificati via HTTP: la pagina di prova non conteneva più le entità errate e il browser riceveva i tag inline corretti. Questo controllo va inserito nel processo editoriale prima della pubblicazione massiva.

Prevenzione

Generare elementi e testo separatamente: effettuare l'escaping dei dati testuali, non del markup HTML che si intende effettivamente pubblicare.