Tema e plugin WordPress su misura o pronti? Il costo vero sta nelle dipendenze

La domanda «tema pronto o su misura?» viene quasi sempre posta in termini di prezzo iniziale, e quasi sempre è la domanda sbagliata. Lo stesso vale per i plugin. Il costo vero di un sito WordPress non sta nel tema o nel singolo plugin, ma nel grafo di dipendenze che si costruisce intorno: chi aggiorna cosa, quando, e cosa si rompe di conseguenza.

Il problema non è il tema, è l'accoppiamento

Un tema multiuso commerciale è un prodotto progettato per vendere al maggior numero di persone possibile. Per farlo integra un page builder, decine di layout, uno slider, spesso un framework di opzioni proprio, e «consiglia» (cioè richiede) una manciata di plugin companion.

Il risultato tecnico è un forte accoppiamento:

• contenuti legati al tema: shortcode e meta proprietari del builder finiscono nel post_content. Cambiare tema significa ritrovarsi pagine piene di [vc_row] o markup non interpretabile;
• aggiornamenti a catena: il tema dipende da una versione del builder, il builder da una versione di PHP, un add-on da entrambi. Un aggiornamento fuori sequenza e il layout si rompe;
• asset globali: CSS e JavaScript di funzioni che il sito non usa vengono caricati su ogni pagina, perché il tema non può sapere cosa userai.

Con i plugin succede la stessa cosa in piccolo. Ogni plugin aggiunge hook su init, wp_head e the_content, opzioni nella tabella wp_options (spesso in autoload, cioè caricate a ogni richiesta), a volte tabelle proprie che nessuno ripulirà alla disinstallazione.

Superficie d'attacco: il punto che si sottovaluta

La gran parte delle vulnerabilità di WordPress non sta nel core, che è maturo e ben presidiato, ma nell'ecosistema di plugin e temi. Ogni componente di terze parti è codice che non hai scritto, aggiornato con tempi che non controlli, a volte abbandonato dall'autore.

Ci sono due conseguenze concrete:

1. più componenti, più finestre di esposizione: tra la pubblicazione di una vulnerabilità e l'aggiornamento effettivo del sito passano giorni o settimane. Con trenta plugin, quelle finestre si sovrappongono quasi di continuo;
2. i componenti popolari sono bersagli migliori: un difetto in un plugin installato su milioni di siti giustifica uno scanner automatico. Anche un plugin scritto per un solo sito può essere colpito da scansioni generiche o da un attacco mirato: la scarsa diffusione non è una misura di sicurezza.

Un plugin su misura non è sicuro per definizione: richiede controllo delle capability, validazione degli input, escaping dell’output, query parametrizzate e protezione CSRF dove pertinente. Questi controlli riducono il rischio senza garantire l’assenza di vulnerabilità. Può ridurre il codice esposto se il perimetro è limitato, ma la sicurezza va verificata anche sul codice personalizzato.

Quando il pronto è la scelta giusta

Il pronto ha senso, e lo dico senza ironia, quando:

• il sito è semplice, il budget è stretto e la vita prevista è breve (un evento, un test di mercato);
• la funzione richiesta è standard e risolta bene da un plugin maturo e mantenuto: moduli, SEO, cache, e-commerce di base;
• il plugin fa una cosa sola e la fa bene, con un autore riconoscibile e una cronologia di aggiornamenti regolare.

Prima di installare un plugin pronto, guardo sempre tre cose: data dell'ultimo rilascio e frequenza, cronologia delle vulnerabilità (e quanto in fretta sono state chiuse), e cosa carica sul frontend di una pagina che non lo usa.

Quando il su misura conviene davvero

Il su misura conviene quando:

• c'è un design da rispettare, magari in Figma: forzare un tema multiuso costa più che scrivere i template (ne parlo in Da Figma a WordPress);
• i contenuti sono strutturati: schede, eventi, cataloghi. Custom post type, campi e blocchi pensati per quei dati rendono il pannello ordinato e il frontend leggero;
• tre o quattro plugin servono a fare una cosa sola: un unico plugin scritto per quello scopo pesa meno ed è più facile da mantenere;
• serve un'integrazione con un gestionale, un CRM o un'API esterna: va verificato se il plugin esistente copre errori, limiti, riconciliazione e casi specifici, senza ricorrere a personalizzazioni fragili.

Come imposto un tema su misura

Un tema su misura, come lo intendo io, è un tema a blocchi o ibrido con pochissime dipendenze:

• template e blocchi scritti per i contenuti reali, con theme.json per colori, tipografia e spaziature, così l'editor mostra solo le scelte coerenti con il design;
• editor a blocchi nativo, con blocchi personalizzati dove servono. I blocchi serializzano markup e attributi nel contenuto: va prevista una strategia di compatibilità quando cambiano o vengono rimossi;
• asset caricati solo dove servono, registrati per blocco;
• campi e tipi di contenuto registrati in un plugin separato dal tema, così i dati sopravvivono a un futuro cambio di aspetto;
• repository Git, ambiente di prova e documentazione, perché chi arriva dopo possa lavorarci senza indovinare.

Il sito di Dotcampus, per esempio, l'ho programmato in WordPress a blocchi proprio così: pagine composte da blocchi riutilizzabili, gestibili dal cliente senza toccare il codice e senza poter rompere il layout. Sagre Autentiche è all'estremo opposto per complessità, con mappa, API e dashboard utente, ma la regola è la stessa: codice scritto a mano, pochi componenti di terze parti.

Una regola pratica per i plugin

Per ogni plugin, mi chiedo: se domani l'autore lo abbandonasse, quanto mi costerebbe sostituirlo? Se la risposta è «poco», si può usare quello pronto. Se la risposta è «dovrei rifare mezzo sito», quel plugin è una dipendenza strutturale e merita di essere valutato con la stessa cura con cui si sceglie un fornitore.

La checklist di sicurezza del codice personalizzato

Per un’azione amministrativa verifico autenticazione e capability, poi la protezione CSRF quando pertinente. Il nonce non sostituisce l’autorizzazione. Gli input vengono validati rispetto al dominio dei dati; la sanificazione normalizza il valore dove necessario, mentre l’escaping va applicato nel contesto di output. Le query usano parametri e gli endpoint REST dichiarano controlli di permesso.

Per gli upload controllo tipo, dimensione, destinazione e possibilità di esecuzione, senza fidarmi del solo nome del file. Registro gli errori senza copiare password, token o dati personali superflui nei log.

La revisione include dipendenze, aggiornamenti e possibilità di sostituzione. Un plugin piccolo e poco diffuso può contenere una vulnerabilità grave: il vantaggio del su misura va dimostrato nel codice e nella manutenzione.

Riferimento: nonce e autorizzazione, WordPress.

Come la vedo io

Amo WordPress: ci lavoro da anni, ci ho costruito progetti di cui vado fiero e per molti siti resta la scelta più sensata. Ma negli ultimi anni ho visto peggiorare il modo in cui viene usato. Temi che fanno tutto, plugin per ogni cosa, siti in cui tutto è legato a tutto e un singolo aggiornamento può far cadere il castello. Nel frattempo gli attacchi automatici sono aumentati, e ogni componente in più è una porta in più.

Per questo, quando faccio WordPress, lo faccio asciutto: tema su misura, pochi plugin scelti uno per uno, codice mio dove conta. E per questo, quando un progetto non ha davvero bisogno di un pannello di amministrazione dinamico, propongo sempre più spesso di passare ad altro.

Perché affidarlo a me

Scrivo temi e plugin WordPress da molti anni: dal 1999 ho consegnato più di 300 progetti, con più di 30 agenzie, da Roma e da remoto.

Se stai valutando se tenere, sfoltire o rifare un tema o un insieme di plugin, scrivimi: in una chiacchierata di circa 20 minuti ti dico con franchezza dove sta il rischio e cosa conviene toccare per primo. Il dettaglio dei servizi è in Temi WordPress su misura e Plugin WordPress su misura.