Quando propongo Kirby per un progetto web, prima o poi arriva la domanda: «Perché non WordPress?».

È una domanda legittima. WordPress è conosciuto, ha un ecosistema enorme, moltissime persone sanno usarlo e, se domani il cliente decide di cambiare sviluppatore, troverà qualcuno nel raggio di pochi chilometri. Probabilmente anche nello stesso condominio.

La risposta breve è che WordPress non è un cattivo CMS. È uno strumento molto potente, maturo e adatto a una quantità impressionante di progetti.

La risposta meno diplomatica è che, per il tipo di siti e applicazioni che sviluppo, molto spesso mi costringe a togliere, aggirare o riconfigurare cose prima ancora di poter cominciare a costruire quelle che servono davvero.

Per questo uso Kirby.

Non perché sia “migliore” in assoluto, ma perché parte da una domanda diversa.

WordPress tende a chiedere: come possiamo adattare questo progetto al sistema?

Kirby mi permette di chiedere: qual è il sistema giusto per questo progetto?

Il problema non è fare pagine

La maggior parte dei siti non è realmente composta da pagine.

È composta da persone, prodotti, categorie, documenti, sedi, eventi, listini, relazioni, stati, lingue, permessi e procedure. La pagina è soltanto uno dei modi in cui questi dati vengono mostrati.

Se progetto il sito partendo dalla pagina, rischio di accorgermi troppo tardi che il problema vero era organizzare le informazioni.

Prendiamo un catalogo industriale. Un prodotto potrebbe avere:

  • una famiglia e una sottocategoria;
  • varianti e caratteristiche tecniche;
  • documenti collegati;
  • applicazioni compatibili;
  • mercati in cui è disponibile;
  • traduzioni;
  • relazioni con altri prodotti;
  • dati provenienti da un gestionale.

Posso certamente costruire tutto questo con WordPress. Esistono custom post type, tassonomie, custom field, tabelle personalizzate, API e plugin per quasi ogni esigenza.

Il punto è un altro: quanta parte del sistema sto progettando io e quanta parte sto negoziando con decisioni prese in precedenza da WordPress, dal tema e dai plugin installati?

In Kirby il modello dei contenuti viene prima

Kirby è un CMS flat-file. Normalmente le pagine e i contenuti vivono in file e cartelle dentro la directory content. Ogni pagina può avere i campi necessari al progetto e la struttura può essere modificata attraverso i blueprint del Panel. La documentazione ufficiale descrive proprio file e cartelle come sorgente dati primaria, pur permettendo di integrare database, API e altre fonti esterne.

Tradotto nel lavoro quotidiano: prima definisco che cosa esiste, come si chiama e quali relazioni deve avere. Poi costruisco l'interfaccia pubblica e quella amministrativa attorno a questa struttura.

Un progetto può avere una pagina azienda con titolo e testo. Un altro può avere prodotti virtuali letti da un database, disponibilità ricevute da un gestionale COBOL e documenti generati da un servizio esterno. Per Kirby sono comunque oggetti con cui posso lavorare attraverso un'API coerente.

Non devo fingere che tutto sia un articolo di blog particolarmente creativo.

I file di contenuto, inoltre, sono leggibili. Posso aprirli con un editor, versionarli con Git, confrontare due revisioni, copiarli, trasformarli con uno script o generarli da un CSV.

Non significa che un database sia un problema. I database sono strumenti eccellenti e, quando servono, li uso. Significa soltanto che non voglio che il database sia un requisito architetturale anche quando il progetto non ne ha bisogno.

Il backend non dovrebbe sembrare uguale per tutti

Uno dei motivi principali per cui scelgo Kirby è il Panel.

Attraverso i blueprint posso decidere quali campi mostrare, come organizzarli, quali file accettare, quali pagine si possono creare, chi può vedere una sezione e quali operazioni sono permesse.

Il risultato non è un pannello generico con molte funzioni che il cliente deve imparare a ignorare. È un backend costruito attorno al suo lavoro.

Chi aggiorna un corso vede lezioni, date, docenti e materiali. Chi gestisce un catalogo vede famiglie, prodotti, schede tecniche e relazioni. Chi pubblica un portfolio vede progetti, categorie, immagini e anni.

Sembra una differenza estetica, ma non lo è.

Un backend più aderente al processo riduce errori, campi usati male, contenuti inseriti nel posto sbagliato e telefonate che cominciano con: «Scusa, dove devo cliccare?».

Il CMS non è soltanto il posto in cui si modifica il testo. È una parte dell'interfaccia del progetto, e qualcuno dovrà usarla ogni giorno.

Meno livelli tra il problema e il codice

WordPress è progettato per essere esteso. Il suo sistema di action e filter consente a core, temi e plugin di interagire in punti prestabiliti dell'esecuzione. È uno dei motivi del suo successo: permette a componenti sviluppati da soggetti diversi di collaborare senza modificare il core.

È anche il punto in cui, nei progetti molto personalizzati, posso cominciare a perdere il controllo.

Una funzione può dipendere dal core, dal tema, dal child theme, da un plugin, da un add-on del plugin e da uno snippet aggiunto anni fa perché l'add-on non faceva esattamente quello che prometteva. Ognuno interviene attraverso hook, priorità, impostazioni e convenzioni proprie.

Quando qualcosa smette di funzionare, la domanda non è più soltanto “dov'è l'errore?”, ma “chi sta modificando questo dato, in quale momento e perché?”.

In Kirby, nella maggior parte dei miei progetti, il percorso è più corto:

  1. il contenuto ha una struttura definita;
  2. un controller o un modello lo prepara;
  3. un template lo presenta;
  4. un plugin aggiunge soltanto le funzioni specifiche che servono.

Questo non rende automaticamente il codice buono. È perfettamente possibile scrivere pessimo software anche con pochissimi file: è una delle libertà fondamentali dello sviluppatore.

Ma rende più facile capire da dove arriva un comportamento e dove deve essere modificato.

Dipendenze: ogni comodità presenta il conto

Un plugin non è un male. È codice già scritto, provato e mantenuto da qualcun altro. Può far risparmiare settimane di lavoro e offrire funzionalità che non avrebbe senso sviluppare internamente.

Il problema nasce quando il progetto diventa la somma delle dipendenze invece di usarle consapevolmente.

Ogni plugin porta con sé:

  • aggiornamenti;
  • compatibilità con il core e con PHP;
  • possibili conflitti;
  • scelte nell'interfaccia;
  • codice eseguito anche dove magari non serve;
  • un autore o un'azienda dalla cui continuità dipendiamo.

Questo vale anche per Kirby, naturalmente. Anche Kirby ha plugin, aggiornamenti e dipendenze. La differenza, nel mio modo di usarlo, è che parto da una base molto piccola e aggiungo una dipendenza solo quando il vantaggio supera chiaramente il costo.

Se una funzione specifica richiede quaranta righe di PHP comprensibili, preferisco spesso scrivere quelle quaranta righe. Se richiede un sistema complesso, delicato e già risolto bene da una libreria affidabile, uso la libreria.

La scelta non è tra “fare tutto da soli” e “installare tutto”. È tra dipendenze intenzionali e dipendenze accidentali.

Integrazioni: il sito non è sempre il centro del mondo

Molte aziende possiedono già i dati che il sito deve mostrare.

Sono dentro gestionali, database, file CSV, API, fogli Excel, software scritti vent'anni fa o sistemi che nessuno vuole toccare perché l'unica persona che li conosce è andata in pensione.

In questi casi il CMS non dovrebbe pretendere di diventare la nuova fonte assoluta della verità. Dovrebbe saper dialogare con ciò che esiste.

Kirby permette di combinare contenuti su file con dati provenienti da database e API. Le pagine virtuali, per esempio, consentono di trasformare dati esterni in oggetti che nel frontend si comportano come normali pagine Kirby.

È un approccio che trovo particolarmente efficace: il sito può essere contemporaneamente editoriale e applicativo. Alcuni contenuti vengono gestiti dal Panel; altri arrivano dal gestionale; altri ancora vengono calcolati o generati.

Non devo duplicare tutto dentro il CMS soltanto per poterlo visualizzare.

Versionamento, backup e deploy

Il fatto che i contenuti siano file rende alcune operazioni sorprendentemente concrete.

Posso fare il backup di un progetto copiando una struttura di cartelle. Posso includere contenuti e configurazione in un repository privato. Posso vedere quali campi sono cambiati in una revisione. Posso preparare trasformazioni automatiche senza passare da esportazioni e importazioni proprietarie.

Anche il deploy può rimanere leggibile: template, blueprint, plugin, asset e contenuti sono file. Non devo necessariamente coordinare codice e migrazioni del database per ogni modifica strutturale.

Naturalmente la semplicità non elimina la necessità di lavorare bene. Servono backup, permessi corretti, protezione delle directory sensibili, controllo delle modifiche e una strategia di pubblicazione.

“Flat-file” non significa “magicamente sicuro”. Significa che i pezzi del sistema sono più facili da vedere.

Prestazioni e sicurezza: niente slogan

Si sente spesso dire che Kirby è veloce perché non usa un database e che WordPress è lento perché lo usa. È una semplificazione poco utile.

Un WordPress ben progettato, con caching corretto, infrastruttura adeguata e plugin scelti con criterio può essere estremamente veloce. Un Kirby scritto male può essere lento.

Allo stesso modo, la popolarità di WordPress lo rende un bersaglio molto visibile, ma il vero problema di sicurezza non è il logo del CMS. Sono aggiornamenti trascurati, plugin abbandonati, password deboli, permessi sbagliati e codice non verificato.

Il vantaggio che cerco in Kirby non è l'invulnerabilità. È una superficie progettuale più piccola: meno componenti, meno comportamenti impliciti e più facilità nel capire che cosa è realmente in esecuzione.

La sicurezza non deriva dall'avere meno file. Deriva dal riuscire a conoscere e mantenere il sistema.

Quando sceglierei WordPress

Ci sono progetti per i quali WordPress è probabilmente la scelta migliore.

Lo prenderei seriamente in considerazione quando:

  • il progetto è soprattutto editoriale e segue strutture molto comuni;
  • il cliente possiede già un flusso di lavoro consolidato su WordPress;
  • serve un ecosistema pronto di integrazioni specifiche;
  • un plugin maturo risolve davvero il problema principale;
  • molti redattori conoscono già l'interfaccia;
  • la facile reperibilità di sviluppatori WordPress è un requisito prioritario;
  • tempi e budget rendono più sensato configurare una soluzione esistente che svilupparne una su misura.

Anche l'e-commerce merita una valutazione separata. WooCommerce, con tutti i suoi compromessi, offre un ecosistema enorme. Prima di ricostruire pagamenti, spedizioni, fiscalità, promozioni e integrazioni commerciali, conviene avere motivi molto solidi.

Scegliere uno strumento più piccolo soltanto per sentirsi più raffinati è un ottimo modo per trasformare il cliente nel finanziatore delle proprie preferenze personali.

Non cerco un CMS che faccia tutto

Non scelgo Kirby perché faccia più cose di WordPress.

Lo scelgo perché decide meno cose al posto mio.

Mi offre routing, contenuti, utenti, file, API, caching e un Panel altamente configurabile, ma lascia che la forma finale del progetto dipenda dalla sua architettura e non da un modello predefinito.

Per me è importante perché lavoro spesso su siti che non sono soltanto siti: cataloghi collegati a gestionali, aree riservate, strumenti di ricerca, generatori di documenti, flussi di iscrizione e piccole applicazioni web.

In questi casi voglio che contenuto, interfaccia e codice siano parti dello stesso progetto, non tre sistemi che cercano faticosamente di mettersi d'accordo.

Il CMS ideale non è quello con il maggior numero di funzioni.

È quello che, una volta costruito il progetto, quasi scompare.

Per molti dei miei lavori quel CMS è Kirby.

Per altri potrebbe essere WordPress, un framework, un servizio headless o qualcosa che non ho ancora utilizzato.

La decisione tecnica non dovrebbe cominciare dal nome dello strumento.

Dovrebbe cominciare dal problema.