WordPress
Lavoro con WordPress dal 2005 e dal 2006 sono iscritto a wordpress.org. Da allora l’ho visto cambiare più volte i temi classici, i framework, i page builder, i blocchi e l’ho seguito in ogni fase, sempre con lo stesso criterio: capire come funziona sotto, non solo come si usa. È la piattaforma su cui costruisco tutto, dai siti dei clienti a i miei progetti, e a cui restituisco qualcosa con plugin e contributi.
Sviluppo su misura
Il mio modo preferito di costruire un sito oggi è un tema a blocchi con un child theme custom: blocchi e pattern dedicati per le sezioni ricorrenti, personalizzazioni via theme.json, editor Gutenberg nativo senza page builder. È l’impostazione che uso per i miei siti, questo compreso, perché produce pagine leggere, manutenibili e senza lock-in. Per i temi costruiti da zero ho lavorato a lungo con framework come Genesis e con Bootstrap sul front-end.
Lavorare su misura non significa però lavorare solo da zero. Buona parte dei siti in produzione è costruita sui temi commerciali e i page builder più diffusi, e so intervenire su queste basi rispettandone la logica: child theme, hook e filtri al posto di modifiche al codice del tema, integrazioni che sopravvivono agli aggiornamenti.
Quando WordPress da solo non basta, scrivo plugin dedicati. A volte sono mu-plugin, piccoli e mirati: sentinelle che rilevano una configurazione alterata, la correggono e avvisano via email; controllo granulare degli aggiornamenti automatici; funzionalità esposte a ruoli specifici senza concedere privilegi da amministratore. È anche il primo livello di hardening applicativo di un sito, della sicurezza a livello di server e di incident response (vedi DevOps).
Lavoro spesso su siti multilingua: traduzioni, cache delle stringhe, configurazioni duplicate per lingua e valuta, e tutti i casi limite che emergono solo quando le lingue in produzione sono più di due. Per lo stesso motivo i plugin che sviluppo sono predisposti al multilingua fin dall’inizio.
WooCommerce
Gran parte del mio lavoro di sviluppo ruota attorno a WooCommerce, su negozi in produzione con volumi reali: catalogo, spedizioni, tassazione, metodi di pagamento. Conosco le parti che si vedono meno ma decidono se un negozio funziona: abbonamenti e la gestione dei rinnovi, HPOS e le sue differenze rispetto al modello classico degli ordini, Action Scheduler e le code di azioni pianificate.
Sul fronte pagamenti lavoro con i principali gateway, dalla verifica dell’integrazione alla diagnosi dei pagamenti rifiutati. E quando il negozio deve dialogare con l’esterno, costruisco le integrazioni: sincronizzazione con i marketplace, invio di ordini e documenti a un ERP, import di listini.
Intervenire su un e-commerce aperto richiede metodo: staging, backup, deploy, verifica, e un criterio chiaro per distinguere ciò che si può fare a sito aperto da ciò che no.
Debugging e manutenzione
La competenza che uso più spesso non è scrivere codice nuovo: è capire perché il codice esistente si comporta in un certo modo. I guasti più interessanti sono quelli che non lasciano traccia nei log, una pagina bianca senza errori, un salvataggio che non salva. Per questi ho un metodo strutturato: isolare la fase di caricamento responsabile, tracciare gli hook, distinguere un errore fatale da un’interruzione esplicita, escludere singoli plugin in modo condizionale senza impatto sui visitatori.
WP-CLI è lo strumento centrale di questo lavoro: gestione di plugin, temi, utenze, cron e database da riga di comando, inclusi i casi in cui va escluso il caricamento dei plugin per aggirare proprio il componente che compromette l’esecuzione.
Un capitolo a parte è la compatibilità con le nuove versioni di PHP: molti plugin datati si rompono per costrutti rimossi o per insidie sottili, come il cambio delle regole di confronto tra stringhe e numeri, che ribalta il comportamento dei controlli di versione. Individuare il punto esatto, correggerlo e portare il sito sulla versione nuova senza interruzioni è un lavoro che ho fatto molte volte.