Passare dal Classic block all’editor a blocchi WordPress non dovrebbe essere una corsa a convertire ogni vecchia pagina. Prima di decidere tempi e perimetro del lavoro, verificate lo stato corrente del Classic block e delle release WordPress nella documentazione e negli annunci ufficiali del progetto.
La domanda più utile per un sito aziendale è un’altra: quali contenuti sono oggi lenti, difficili o rischiosi da aggiornare? Una migrazione ha valore quando riduce dipendenze operative concrete: shortcode poco leggibili, markup storico, pulsanti TinyMCE personalizzati, form, componenti ripetuti e procedure editoriali che richiedono sempre un intervento tecnico.
Questo approccio evita due errori opposti: lasciare inalterate pagine importanti che il team non riesce più a gestire bene, oppure avviare una conversione massiva senza sapere quali funzioni si possono alterare.
Classic Editor, Classic block e TinyMCE: tre elementi diversi
La distinzione è essenziale per pianificare correttamente il lavoro.
- Classic Editor è un plugin che abilita il precedente flusso di modifica. Disattivarlo non converte automaticamente i contenuti già pubblicati.
- Classic block è un blocco disponibile nell’editor a blocchi che riproduce un’esperienza di editing classica. La documentazione del blocco descrive anche l’azione Convert to blocks.
- TinyMCE è l’editor visuale rich-text associato all’esperienza classica. Estensioni create per la sua toolbar non diventano automaticamente funzioni del block editor.
Una pagina può quindi aprirsi nell’editor a blocchi e contenere ancora un Classic block. Convertire quel blocco, inoltre, non elimina automaticamente dipendenze da plugin, meta box, CSS, JavaScript o template sviluppati attorno al vecchio flusso editoriale.
Segnali da analizzare prima della conversione: pulsanti aggiuntivi nella toolbar, formattazioni proprietarie, shortcode inseriti tramite pulsanti, plugin che modificano l’editor, selettori CSS o JavaScript legati a markup storico, meta box e template personalizzati.
Usare una matrice di dipendenza editoriale
Non tutte le pagine legacy hanno lo stesso rischio o lo stesso valore. Per ogni URL, registrate una classe tecnica e due indicatori di business: frequenza di aggiornamento e impatto commerciale.
| Classe | Contenuti tipici | Scelta iniziale |
|---|---|---|
| Verde | Testo, titoli, immagini semplici, elenchi | Convertire in blocchi nativi e verificare il rendering. |
| Giallo | Embed, gallery, tabelle, shortcode standard | Testare caso per caso; non sempre occorre reingegnerizzare. |
| Rosso | HTML complesso, form critici, shortcode proprietari, page builder, meta box, comandi TinyMCE | Fare analisi tecnica e un pilot dedicato prima di convertire. |
In genere meritano priorità le pagine aggiornate spesso e rilevanti per campagne, richieste commerciali o acquisizione contatti: landing page, CTA, pagine servizio e sezioni promozionali. Se blocchi e pattern rendono queste modifiche più coerenti e autonome, esiste un motivo concreto per intervenire.
Al contrario, una pagina archivio stabile e tecnicamente delicata può restare temporaneamente nel Classic block. L’età del contenuto non basta a stabilire una priorità; nemmeno la conversione, da sola, garantisce benefici SEO, prestazionali o di conversione.
Scegliere la destinazione, non solo la conversione
Convertire non significa trasformare ogni elemento in un blocco nativo. La destinazione va scelta in base al comportamento richiesto e alle persone che dovranno aggiornare il contenuto in futuro.
Contenuti semplici
Testi, titoli, immagini ed elenchi sono candidati naturali ai blocchi nativi. Dopo la conversione, controllate gerarchia dei titoli, didascalie, link, allineamenti e spaziature sul front-end.
Shortcode semplici e stabili
Uno shortcode non deve necessariamente diventare un blocco dedicato. Il blocco Shortcode è pensato per ospitare shortcode esistenti. Se lo shortcode è stabile, poco usato e comprensibile per il team, mantenerlo può essere la soluzione meno rischiosa.
Shortcode frequenti o complessi
Se uno shortcode richiede molti parametri, genera un output rilevante o viene configurato spesso da persone non tecniche, valutate un blocco dedicato. Per integrazioni proprietarie, uno sviluppatore può usare i block transforms per trasformare shortcode in blocchi con attributi e contenuto strutturato. La compatibilità con lo shortcode originario va mantenuta finché esistono contenuti che lo usano.
HTML da preservare
Quando il markup deve rimanere invariato, il blocco HTML personalizzato è una scelta conservativa. Preserva il codice, ma non rende necessariamente più semplice il lavoro editoriale: chi interviene su quella sezione dovrà continuare a comprendere HTML e dipendenze collegate.
Componenti ricorrenti
CTA, sezioni contatto, FAQ e moduli ripetuti sono candidati adatti ai pattern. I pattern sincronizzati permettono di riutilizzare un componente in più pagine; definite quindi chi può modificarli, chi approva le modifiche e quali pagine possono esserne influenzate.
Il pilot su staging: piccolo ma rappresentativo
Prima di intervenire sul sito pubblico, create un ambiente di staging il più possibile coerente con il live e verificate di avere un backup ripristinabile. Un campione iniziale di 10-20 URL può essere sufficiente se copre le dipendenze effettive del sito:
- una landing che genera contatti;
- un articolo con immagini e link;
- una pagina con form;
- una pagina con shortcode;
- una pagina con tabella o HTML personalizzato;
- almeno un caso per ciascun plugin o integrazione critica.
Per ogni URL, registrate la versione iniziale e lavorate in bozza o su una copia. L’azione Convert to blocks, descritta nella documentazione del Classic block, può essere utile per il contenuto semplice; un risultato convertito non dimostra però che layout e funzionalità siano rimasti corretti.
Controllate l’anteprima nell’editor e il rendering sul front-end, anche da mobile. La checklist minima comprende URL e link interni, immagini e allineamenti, CTA, form e messaggi di conferma, eventi analytics, pixel, consenso cookie, dati strutturati e accessibilità di base. Per testare un form, simulate l’invio senza impiegare dati personali reali.
Conversione, QA e rollback per piccoli lotti
Un ciclo limitato e ripetibile è più controllabile di una conversione indiscriminata:
- duplicare la pagina o lavorare in bozza;
- convertire e correggere gli elementi necessari;
- controllare editor, front-end e funzionalità;
- far validare il risultato a chi conosce contenuto e obiettivo della pagina;
- pubblicare un lotto ridotto;
- monitorare anomalie e aggiornare il registro prima del lotto successivo.
Revisioni e bozze aiutano nel rollback editoriale. Per modifiche a plugin, tema, database o molte pagine serve invece un piano di ripristino separato, basato su backup verificati e sulle procedure del vostro ambiente.
WordPress può segnalare blocchi non validi quando il contenuto salvato non corrisponde a quanto il blocco si aspetta di rigenerare. Le opzioni di recupero o conversione vanno valutate sul singolo caso: recuperare testo e markup non implica sempre il ripristino esatto dell’aspetto o del comportamento. Per il contesto tecnico, consultate la documentazione su modifica, salvataggio e validazione dei blocchi.
Mantenete un registro con URL, classe di rischio, dipendenze rilevate, test eseguiti, responsabile, esito e decisione finale. È il documento che rende la migrazione tracciabile e che consente di capire quali casi richiedono sviluppo, quali solo QA e quali possono restare invariati.
Quando evitare la conversione massiva
Non iniziate dalla homepage e non pubblicate nello stesso giorno molte pagine commerciali. Per contenuti eterogenei, “automatico” non significa “verificato”: tabelle, shortcode inline, HTML storico e layout costruiti da plugin possono richiedere controlli differenti.
Evitate anche search-and-replace indiscriminati nel database per sostituire shortcode o markup. Se un intervento sui dati è necessario, eseguite prima un dry run, disponete di un backup e usate strumenti adatti ai dati serializzati. La documentazione di WP-CLI search-replace descrive opzioni utili per pianificare e verificare questo tipo di operazione.
Il successo non è il numero di Classic block eliminati. Conta la continuità dell’esperienza per chi visita il sito, il funzionamento di form e tracciamenti e una maggiore autonomia del team sulle attività editoriali che cambiano davvero con frequenza.
Una migrazione selettiva rende il sito più governabile
Non convertite tutto per principio. Convertite dove blocchi nativi, shortcode gestiti consapevolmente e pattern rendono gli aggiornamenti più sicuri, coerenti e semplici.
Il primo passo pratico è creare una matrice con cinque colonne: URL, dipendenze editoriali e tecniche, classe di rischio, frequenza di aggiornamento e impatto commerciale. Da qui potete scegliere un pilot rappresentativo, stabilire la destinazione di ogni componente e pianificare il rilascio senza trasformare il sito live in un ambiente di prova.
Fonti e documentazione
- Documentazione del Classic block
- Documentazione del blocco Shortcode
- Documentazione dei block pattern
- Guida ai block transforms
- Indicazioni per convertire shortcode in blocchi
- Documentazione su modifica e salvataggio dei blocchi
- Documentazione WP-CLI search-replace
