---
title: "Perché ho (avevo) scelto Grav CMS"
date: 2024-12-07
updated: 2025-10-19
lang: it
tags: [Grav CMS, PHP]
description: "Che strumento utilizzare per gestire i propri contenuti? Grav CMS è una valida scelta per chi vuole scrivere un blog"
---

Perché scrivere un blog? Dove pubblicare i propri contenuti? Che strumento utilizzare per gestirli? Sono uno sviluppatore web: _faccio tutto da me_ o mi affido a un CMS o una piattaforma già pronta?

## ~Ho~ avevo scelto Grav CMS

Ho aggiornato questo articolo, dato che il 19 ottobre 2025 ho deciso di utilizzare [Astro](https://astro.build/ "Astro") al posto di Grav CMS.

Le considerazioni su Grav CMS riportate restano sostanzialmente valide; tuttavia, nel frattempo ho riscontrato qualche problema con la gestione dei contenuti multilingua (probabilmente risolvibili con un po' di pazienza, ricerche e tempo) che mi ha lasciato un po' insoddisfatto. Aggiungiamo il fatto che successivamente ho iniziato a *giocare* con Astro... Alla fine ho preferito adottare quest'ultimo. 


## Perché un blog? Perché no?

Era da un po' di tempo che mi frullava in testa l'idea di mettere su un **blog personale**. Perché? La risposta è: perché no?  
Lo spunto per il primo contenuto me l'ha dato un "argomento" poco tecnico che ha sempre attirato la mia attenzione: la pronuncia sbagliata di termini inglesi usati quotidianamente sul lavoro.
Così, alla veneranda età di 45 anni, ho registrato questo dominio, ho scelto quale strumento utilizzare e ho pubblicato il [mio primo post](/it/blog/orrori-di-pronuncia-in-inglese/) proprio su quell'argomento.  
Apprezzo molto chi ha **qualcosa da dire** e porta avanti questa attività con **passione** e **costanza**, trovando il tempo di pubblicare contenuti che eventualmente **possano essere utili** a qualcuno e, perché no, anche a sé stessi. Non mi riferisco a chi scrive contenuti sul web per monetizzare (nulla di sbagliato) o per autocelebrarsi (non condivido troppo, ma nulla di male neanche in questo caso), ma a chi lo fa per altri motivi. Scrivere può risultare utile sotto vari aspetti:
* aiuta a **migliorarsi** nella scrittura e nell'esposizione di contenuti
* sprona ad **approfondire** gli argomenti su cui si vuole scrivere: a volte, pensiamo di conoscere una materia in dettaglio, per poi scoprire che abbiamo varie lacune o che, nel momento in cui dobbiamo spiegare un concetto ad altri, realizziamo di non saperlo fare a dovere (_se non sai spiegare qualcosa, vuol dire che non l'hai capito_)
* spinge ad approfondire tematiche quali **copywriting**, **SEO**, **ottimizzazioni tecniche** di vario genere: migliorare i tempi di risposta, capire perché una pagina non viene indicizzata dai motori di ricerca, indagare sul perché un articolo sia stato molto apprezzato da una specifica fascia di utenti e così via
* espone a **confronti**, **suggerimenti** e **critiche**: può risultare utile a modificare o rafforzare le proprie idee, ma anche per imparare a gestire situazioni emotive legate a commenti negativi o simili.

## Quale strumento / framework / CMS usare?

Oggigiorno la scelta è **sterminata**.  
C'è davvero l'imbarazzo della scelta: piattaforme già pronte dedicate al _blogging_, framework scritti in ogni linguaggio, generatori di siti statici, CMS tuttofare sempre più perfezionati, CMS _flat-file_, _headless_ e chi più ne ha più ne metta.  
Non credo ci sia uno strumento in assoluto migliore di altri: come al solito, la risposta è l'antipatica "_dipende_". Da cosa? _E' ovvio_ (come direbbe Trimagasi, uno dei protagonisti dello splendido film "[Il buco](https://it.wikipedia.org/wiki/Il_buco_(film_2019))"): dalle proprie esigenze (e dalle proprie conoscenze).  
Le mie, erano/sono queste:
* uno **strumento semplice**: poco sforzo, poca manutenzione
* un prodotto sufficientemente **mantenuto** e **aggiornato**: niente progetti ottimi sulla carta, ma il cui ultimo aggiornamento risale a tre anni prima
* niente **linguaggi di sviluppo** che uso molto poco o che non conosco: è inutile che mi affidi a Rust, Scala o Node.js se poi devo passare più tempo a capire come far funzionare il tutto che a scrivere
* **dominio dedicato**: voglio ospitare in autonomia i contenuti che pubblico, con tutti i pro e i contro che ne conseguono
* **contenuti** facilmente **trasportabili**: se un domani volessi cambiare piattaforma o tecnologia, non voglio combattere con esportazioni, migrazioni e simili
* **flat-file**: l'assenza di un database si traduce in una componente in meno da gestire e in una maggiore sicurezza (banalmente, niente problemi di [SQL injection](https://it.wikipedia.org/wiki/SQL_injection))
* **interfaccia di amministrazione**: va benissimo scrivere Markdown con Vim collegandosi via SSH, ma farlo utilizzando una _UI_ tramite browser è ancora più piacevole, immediato e consente l'accesso da qualunque postazione
* dotazione più che sufficiente di **funzionalità tipiche di un CMS**: programmare la pubblicazione di un contenuto, gestire i redirect, ecc.
* gestione del **multilingua**: al momento sto scrivendo solo in italiano, ma vorrei pubblicare anche contenuti in inglese
* strumento **gratuito**

Sulla base di queste esigenze, ho vagliato mentalmente una serie di possibili strumenti che alla fine ho scartato. Di seguito una carrellata delle possibilità che ho escluso e le motivazioni.

### Piattaforme di blogging

Il web pullula di piattaforme / _community_ orientate alla pubblicazione di contenuti a tema (sviluppo web / software, nel mio caso). Non sto nemmeno ad elencarle: se stai leggendo questo articolo, è molto probabile che tu le conosca già.

**Pro**: è sufficiente registrarsi e pubblicare; potenzialmente si può avere molta visibilità  
**Contro**: pubblicare su una piattaforma di cui non si è proprietari che, magari con scarsa probabilità, potrebbe anche sparire; nessuna o limitata possibilità di personalizzare _UI_, struttura e altri aspetti tecnici

### Laravel

Utilizzo professionalmente **PHP** dal 2003 (ho iniziato con la versione 4.x) e **Laravel** quotidianamente ormai da parecchi anni (versione 4.x anche in questo caso), per cui una possibile scelta sarebbe stata quella di usare proprio Laravel e scrivermi un prodotto completamente personalizzato, ottimizzato e ritagliato sulle mie esigenze.

**Pro**: soluzione molto invitante, che mi consente di utilizzare gli strumenti che meglio conosco. Controllo completo su ogni aspetto dell'applicazione, delle componenti utilizzate e dell'infrastruttura  
**Contro**: richiede troppo tempo, impegno, manutenzione. Lo scopo è pubblicare contenuti, non scrivere codice e mantenere un altro progetto: lo faccio già per lavoro

### CMS basati su Laravel

**Pro**: utilizzare un prodotto già pronto, basato su un linguaggio e framework che conosco molto bene  
**Contro**: non ho trovato una soluzione matura e completa che mi abbia spinto ad approfondire e adottare il prodotto (fa eccezione **Statamic**, di cui parlo più sotto)

### CMS basati su altri linguaggi o framework

Vale quanto ho già scritto più sopra: il mio scopo era individuare uno strumento comodo e semplice che mi consentisse di gestire agevolmente contenuti, senza "perdere tempo" a installare, configurare, combattere con errori di runtime, fare debug, eccetera.  
Utilizzare un prodotto, un linguaggio o uno stack tecnologico nuovo (o già usato in precedenza, ma sporadicamente) è sicuramente istruttivo, stimolante e utile; tuttavia, è molto probabile che i problemi da affrontare aumentino, si debba investire parecchio tempo a capire come risolverli e, soprattutto, si rischi di sottovalutare aspetti legati alla sicurezza.

**Pro**: il prodotto più adatto alle proprie esigenze potrebbe essere quello scritto in un linguaggio che usiamo poco o che ancora non conosciamo  
**Contro**: si rischia di "perdere tempo" in questioni tecniche e perdere di vista l'obiettivo principale

### WordPress

Parliamo del CMS più diffuso al mondo: semplice da usare (soprattutto per chi non è uno sviluppatore), ricco di funzionalità, nato proprio per realizzare blog, con un ecosistema ricchissimo di plugin e temi.  
Praticamente c'è una soluzione pronta (quasi sempre gratuita)  per ogni problema che si possa presentare. Pur essendo nato per realizzare blog, nel tempo si è evoluto al punto da poter essere utilizzato per realizzare siti e applicazioni di ogni genere: "gestionali" (virgolette d'obbligo), e-commerce, siti istituzionali, _landing page_, CMS _headless_ accoppiati ad altre soluzioni (es. **Astro**), eccetera. La sua versatilità a mio parere è anche il suo punto debole: il fatto che sia possibile realizzare quasi tutto, non significa che il risultato sia ottimale, soprattutto dal punto di vista dello sviluppatore. Per ottenere lo scopo desiderato, è probabile che si dovranno installare svariati plugin (o scriverne alcuni), dovendo scendere a compromessi ("non è proprio come me lo immaginavo, ma andrà bene lo stesso...") e finendo per ottenere prestazioni non proprio ottimali, tempi di risposta poco brillanti, pagine appesantite da markup generato da qualche plugin su cui si ha poco o nessun controllo, eccetera. C'è una soluzione a tutto ciò, ma richiede molto tempo da impiegare in ottimizzazioni tecniche e non, "trucchi del mestiere" e accorgimenti che si acquisiscono dopo aver _smanettato_ con WordPress per parecchio tempo, preferibilmente conoscendo in modo approfondito le sue API e il suo Codex. Riassumendo: bisogna padroneggiare lo strumento.   
Ho usato WordPress relativamente poche volte e confesso di non essere un esperto in materia, ma nemmeno un fan: non amo com'è scritto il codice (procedurale, sintassi _snake case_, ecc.) e alcuni dei concetti che stanno alla base del suo funzionamento, per cui ho immediatamente escluso anche lui; codice a parte, non apprezzo particolarmente il prodotto in sé, nonostante la versatilità e la ricchezza di funzionalità. Inoltre, volevo provare qualcosa di nuovo.

* **Pro**: diffusissimo, ecosistema ricchissimo, perfetto per fare blog, semplice da usare
* **Contro**: codice *legacy* e procedurale; non sono un fan del prodotto


### Statamic

[Statamic](https://statamic.com/) è un ottimo prodotto: maturo, flessibile, accattivante, mantenuto e costantemente aggiornato, con un buon ecosistema di plugin e temi già pronti. E, sotto il cofano, c'è **Laravel** (con la possibilità, volendo, di utilizzare **Blade** come _template engine_ al posto di **Antlers**), il che lo rende un ottimo candidato ad eventuali personalizzazioni ben scritte.  
Di default Statamic utilizza la modalità _flat-file_, ma è anche possibile utilizzare un database.  
Non è diffuso come WordPress né probabilmente lo sarà mai, non ha la stessa quantità mostruosa di plugin, temi e integrazioni di ogni genere, ma per uno sviluppatore Statamic è molto molto meglio, per tanti motivi.
Dovessi dare una definizione personale di Statamic, sarebbe questa:

> WordPress scritto molto meglio, con tutto ciò che su WordPress spesso è un plugin

In effetti Statamic è stata la mia prima scelta. Allora **perché l'ho scartato**? Semplice: il supporto multisito (che comprende anche il multilingua) richiede una licenza professionale a pagamento.  
Intendiamoci: i 275 dollari richiesti per la versione Pro (primo anno, poi si passa a 65 dollari) valgono fino all'ultimo centesimo, specialmente se viene utilizzato per sviluppare una soluzione professionale dove ci sia _budget_. Tuttavia, nel mio caso, parliamo di un piccolo blog personale, dove il budget è... Zero. Il mio ragionamento è opinabile? Certamente. Se un prodotto a pagamento semplifica e migliora la vita dello sviluppatore e la sua cosiddetta DX (_Developer eXperience_), ben venga la spesa! Tuttavia, nel mio caso, ho ritenuto che il gioco non valesse la candela.

* **Pro**: scritto molto bene, mantenuto, estensibile, basato su Laravel
* **Contro**: per il multi-sito / multi-lingua è necessaria una licenza a pagamento


## La soluzione: Grav CMS

Alla fine ho scelto [Grav CMS](https://getgrav.org/). Come mai? Perché soddisfa le esigenze che ho elencato:
* si tratta di un **CMS** la cui installazione e gestione si sono rivelate davvero **semplici**, così come l'utilizzo. Trattandosi di un prodotto che non avevo mai usato ha richiesto un minimo di prove, lettura della documentazione, esplorazione della configurazione, ma si è rivelato tutto piuttosto immediato, grazie anche all'**interfaccia di amministrazione** (opzionale, installabile come plugin). Trovo che abbia una **curva di apprendimento piuttosto bassa**
* è un [progetto open-source](https://github.com/getgrav/grav) (quindi non occorre alcuna licenza a pagamento) e l'ultimo _commit_ risale a pochi giorni fa
* è scritto in **PHP**: dovessi avere necessità di scrivere un plugin, modificare una funzionalità o aprire una _pull request_ su GitHub, so dove mettere le mani
* i requisiti sono semplicissimi: **PHP** >= 7.3.6 (io uso la **8.3.x**) e un web server (**Nginx**, nel mio caso). E, chiaramente, un **nome a dominio**
* è un **CMS flat-file**, con tutti i vantaggi che ne conseguono; per creare i **contenuti** si utilizza [Markdown](https://en.wikipedia.org/wiki/Markdown) - comodo, pratico, standard, facilmente trasportabile. E' sufficiente creare un file .md, inserire il contenuto e specificare eventuali opzioni tramite [frontmatter](https://learn.getgrav.org/17/content/headers), il tutto con un qualsiasi editor di testo (ad esempio, **Vim**). In alternativa, è possibile creare un contenuto tramite l'interfaccia di amministrazione: il risultato finale sarà lo stesso
* è dotato di numerose **funzionalità** più che sufficienti a produrre e gestire contenuti, con tutte le attenzioni del caso alla **SEO**
* consente di gestire **più lingue**, con varie opzioni relative a _fallback_, redirect, ecc.

Ma non finisce qui. Ecco una lista di caratteristiche presenti su Grav CMS:
* **installazione rapida**: è sufficiente decomprimere un file zip, ma sono disponibili anche altri metodi (tramite Composer, clonando il repository GIT, utilizzando Docker)
* sistema di **cache** per servire rapidamente i contenuti
* interfaccia a riga di comando (**CLI**) per installare dipendenze, effettuare manutenzione, creare utenti, eliminare la cache, ecc.
* gestore di dipendenze (**package manager**) tramite il quale **installare** o **aggiornare** versione di Grav, **temi**, **plugin**
* configurazione basata su file **YAML**, facilmente estensibile (ad esempio sulla base dell'ambiente corrente di esecuzione)
* gestione di **utenti** e **ruoli** per impostare permessi e limitare l'accesso a determinate pagine
* può essere utilizzato in modalità **multi-sito**
* possibilità di effettuare **backup** e restore in modo rapido, anche da CLI
* possibilità di scrivere contenuto in **Markdown** ma anche in **HTML**
* **routing** e **redirect** configurabili per migliorare l'usabilità e la flessibilità
* **tassonomie** personalizzabili e **campi dinamici** personalizzabili
* i **temi** possono essere estesi, in modo da **ereditare** le funzionalità da un teme esistente, modificando solo ciò che si desidera
* possibilità di realizzare **form**

e molto altro.  
Per quanto riguarda l'**aspetto**, non avevo grosse esigenze e mi sono limitato a utilizzare il tema base, modificandolo leggermente; volendo, è possibile realizzare un proprio tema da zero (oppure estendendone uno  esistente), utilizzando il _template engine_ **Twig** e scegliendo il proprio framework **CSS**.

## Conclusioni

Devo dire di essere rimasto piacevolmente stupito da questo CMS. Si adatta perfettamente alle mie esigenze, senza inutili complicazioni, e offre ben più di quanto mi serva per gestire questo blog.  
Per il momento si sta comportando egregiamente e sembra che lo sviluppo venga portato avanti.  
Come ho premesso, a mio parere non esiste uno strumento universale migliore di tutti gli altri, che si presti a soddisfare ogni tipo di esigenza e gusto: ciò che per me risulta ottimale potrebbe non esserlo per un'altra tipologia di utente. Tuttavia, se la necessità è, ad esempio, creare un blog personale, consiglio vivamente di provare **Grav CMS**. Detto così, suona un po' male e lo sminuisce... Rifaccio: il prodotto è ottimo e davvero versatile. Trovo che possa prestarsi bene come strumento per realizzare progetti web di vario tipo.