Roots: usare WordPress come si deve

WordPress non è elegante e forse non prova nemmeno a esserlo.

Eppure continua a vincere nei progetti in cui contano ecosistema, plugin, competenze disponibili, integrazioni già pronte e poco attrito per il cliente.

Il punto, nel 2026, non è decidere se WordPress sia bello. Il punto è decidere se puoi governarlo senza affidarti alla fortuna.

È qui che entra in gioco Roots.

Questo articolo parla prima di tutto a chi WordPress lo consegna per mestiere: agenzie, studi e team tecnici che hanno clienti veri, budget veri e siti che dopo il lancio non possono diventare oggetti misteriosi.

E parla anche alle aziende che hanno costruito un asset importante su WordPress, magari con un builder, e iniziano a farsi una domanda scomoda: quanto controllo abbiamo davvero su qualcosa che dovrebbe portarci contatti, vendite o autorevolezza?

Dopo anni passati a sviluppare con Laravel, dove una cartella ha quasi sempre il nome che dovrebbe avere e i coding standard non sembrano un capriccio, sviluppare con il core di WordPress richiede ancora un certo autocontrollo: funzioni interminabili, snake_case ovunque, array associativi come forma di vita dominante, hook sparsi e type hint distribuiti con prudenza monastica, manco si pagassero a peso.

Non lo dico per snobismo. Lo dico perché chi fa consulenza tecnica deve separare due cose: il gusto personale e la convenienza del progetto.

Il gusto personale mi porta spesso altrove. In Encodia, quando il progetto ce lo permette, usiamo volentieri Statamic: è Laravel-native, ha una qualità del codice superiore e spesso è la scelta più naturale quando il cliente può accettare un CMS moderno senza tutta l’eredità storica di WordPress.

La convenienza del progetto, però, qualche volta porta ancora dritta a WordPress: un plugin chiave, un’integrazione pre-esistente, una redazione già formata. Un modello di business che poggia su quell’ecosistema e non vuole, giustamente, ricominciare da zero.

Quando succede, ho una regola: niente WordPress trattato come un sito caricato via FTP!

Se entra in un progetto serio, entra come applicazione PHP seria: dipendenze versionate, ambienti separati, deploy reversibili, configurazione leggibile, responsabilità chiare.

Roots serve esattamente a questo.

Non trasforma WordPress in Laravel. Però lo avvicina a quel modo di lavorare: Composer, configurazioni leggibili, template meno primitivi, ambienti replicabili, deploy che non dipendono dalla fortuna.

La tesi è semplice: Roots non rende WordPress moderno per magia. Lo rende governabile. E in molti progetti la differenza non è estetica, è economica.

Cosa compra davvero chi sceglie Roots

Quando in una riunione mi lascio andare e dico Bedrock, Sage, Trellis, Composer o deploy atomico, vedo spesso lo stesso sguardo: tecnico che parla tecnico.

Tradotto meglio: con Roots non stai comprando una mania da sviluppatore. Stai comprando controllo.

Controllo sugli aggiornamenti. Controllo sugli ambienti. Controllo sul giorno, inevitabile, in cui qualcosa si rompe e bisogna capire chi ha cambiato cosa, quando, e come tornare indietro senza trasformare la produzione in un laboratorio.

Roots è un’organizzazione open source indipendente che dal 2011 produce strumenti per usare WordPress come si userebbe una vera applicazione PHP: Composer per le dipendenze, Git per il versionamento, ambienti separati per sviluppo, staging, UAT e produzione, deploy atomici, server descritti in YAML.

Dal punto di vista di un cliente o di un’azienda, il valore è meno astratto di quanto sembri:

• meno sorprese in produzione: gli ambienti sono coerenti by design, quindi “sulla mia macchina funziona” smette di essere una frase accettabile;
• rollback in pochi secondi se un deploy va storto, perché prima o poi succede a tutti;
• onboarding più rapido per chi arriva da Laravel o da progetti PHP moderni;
• costi di hosting prevedibili, perché con Trellis puoi stare su VPS solide senza consegnarti a un fornitore unico;
• tracciabilità vera: aggiornamenti, plugin, tema e configurazione passano da Git e finiscono in un composer.lock;
• meno dipendenza dall’eroe di turno, quello che “sa dove mettere le mani” ma non ha lasciato una riga di documentazione.

Non è romanticismo tecnico. È riduzione del rischio.

Roots, pezzo per pezzo: Bedrock, Sage, Trellis, Acorn e WP Packages

Roots è una famiglia di strumenti. Puoi usarli insieme, oppure prendere solo il pezzo che serve. Il punto, però, è capire la logica complessiva: riportare ordine in un ecosistema che per cultura storica ha tollerato troppo a lungo il “si è sempre fatto così”.

1. Bedrock: WordPress smette di vivere nel caos

Bedrock è un boilerplate che riorganizza WordPress in modo finalmente sensato e gestisce tutto via Composer: core, plugin e temi.

example.com/
├── composer.json          # tutte le dipendenze, anche il core WordPress
├── config/
│   ├── application.php    # config "Laravel-style"
│   └── environments/
│       ├── development.php
│       └── staging.php
├── web/
│   ├── app/               # wp-content (themes, plugins, mu-plugins)
│   ├── wp/                # core di WordPress gestito da Composer
│   └── wp-config.php
└── .env                   # credenziali fuori dal repository

Un composer.json di progetto, oggi, dovrebbe già ragionare con i namespace di WP Packages:

1
{
2
  "require": {
3
    "php": ">=8.3",
4
    "composer/installers": "^2.3",
5
    "vlucas/phpdotenv": "^5.6",
6
    "roots/bedrock-autoloader": "^1.0",
7
    "roots/wordpress": "^6.7",
8
    "wp-plugin/wordfence": "^7.11",
9
    "wp-plugin/wp-mail-smtp": "^4.2"
10
  },
11
  "repositories": [
12
    {
13
      "type": "composer",
14
      "url": "https://repo.wp-packages.org"
15
    }
16
  ]
17
}

Da qui in avanti, aggiornare WordPress e i plugin non significa più entrare in bacheca, cliccare un bottone e sperare. Significa aggiornare dipendenze, verificare il composer.lock, passare da CI, fare deploy.

Sembra più lento solo se guardi il singolo click. Se guardi il ciclo di vita di un progetto, è l’opposto.

Bedrock v1.29 ha alzato la versione minima di PHP alla 8.3.x e include il supporto Pest out of the box. È un segnale culturale prima ancora che tecnico: anche in WordPress i test devono smettere di essere una cosa strana.

2. Sage: un tema WordPress che non sembra scritto nel 2010

Sage è uno starter theme per scrivere temi WordPress con strumenti che altrove sono normali da anni:

• Blade come motore di template, lo stesso approccio che chi usa Laravel riconosce subito;
• Tailwind CSS preconfigurato;
• Vite per l’asset bundling, con il Roots Vite Plugin aggiornato e più veloce;
• supporto al block editor con theme.json generato dalla configurazione Tailwind.

Un loop in Sage si legge così:

1
{{-- resources/views/index.blade.php --}}
2
@extends('layouts.app')
3

4
@section('content')
5
    @while(have_posts()) @php(the_post())
6
        <article @php(post_class('mb-12'))>
7
            <header>
8
                <h2 class="text-2xl font-bold">
9
                    <a href="{{ get_permalink() }}">{!! get_the_title() !!}</a>
10
                </h2>
11
                <time datetime="{{ get_the_date('c') }}" class="text-sm text-stone-500">
12
                    {{ get_the_date() }}
13
                </time>
14
            </header>
15

16
            <div class="prose mt-4">
17
                {!! get_the_excerpt() !!}
18
            </div>
19
        </article>
20
    @endwhile
21

22
    {!! get_the_posts_navigation() !!}
23
@endsection

Non è solo questione di sintassi più gradevole. È che un tema smette di essere una cartella piena di compromessi e diventa un pezzo di applicazione con struttura, asset pipeline e convenzioni decenti.

Chi arriva da Laravel non ha bisogno di traduzioni. Chi arriva dal WordPress “classico” all’inizio protesta, poi scopre che non dover rincorrere get_template_part() in mezzo progetto è una forma concreta di benessere.

3. Trellis: deploy e server sotto controllo

Trellis è uno stack LEMP basato su Ansible. Descrivi il sito in YAML, lanci il provisioning, ottieni un server Ubuntu 24.04 con Nginx, PHP 8.3, MariaDB, Let’s Encrypt, fail2ban, Redis e il resto dell’infrastruttura che in un progetto serio dovrebbe essere esplicita, non ricordata a memoria da qualcuno.

1
# trellis/group_vars/production/wordpress_sites.yml
2
wordpress_sites:
3
  cliente.it:
4
    site_hosts:
5
      - canonical: davideprevosto.it
6
        redirects:
7
          - www.davideprevosto.it
8
    local_path: ../site
9
    repo: git@github.com:davideprevosto/davideprevosto.it.git
10
    branch: main
11
    multisite:
12
      enabled: false
13
    ssl:
14
      enabled: true
15
      provider: letsencrypt
16
    cache:
17
      enabled: true
18
    xmlrpc:
19
      enabled: false

Il deploy è una riga:

1
$ trellis deploy production

Dietro quella riga, però, succedono cose importanti: Trellis crea una nuova release, lancia composer install, aggiorna il symlink current/ in modo atomico. Se qualcosa va storto, trellis rollback production torna alla release precedente in pochi secondi.

Questa è la parte che spesso il cliente capisce solo dopo il primo incidente evitato.

Le versioni recenti hanno aggiunto HTTP/3, hardening WordPress runtime opt-in, sessioni PHP su Redis e compatibilità Ansible 2.19. Da qualche tempo Trellis ha mandato in pensione Vagrant e VirtualBox a favore di Lima per lo sviluppo locale: meno peso, meno attese, meno scuse.

Trellis gira su qualsiasi VPS Ubuntu. Zero vendor lock-in. Domani vuoi spostare tutto da DigitalOcean a Hetzner? Cambi un IP, rilanci trellis provision, sistemi DNS e ci sei.

Questa libertà sembra un dettaglio finché non ti serve davvero.

4. Acorn: Laravel dentro WordPress, dove serve

Acorn è il ponte fra il mondo WordPress e il modo in cui molti sviluppatori PHP moderni ragionano già da anni. Con Acorn, in un progetto WordPress puoi usare il container di servizi di Laravel, le facade, il routing, Eloquent, le View, i config provider.

Non trasforma WordPress in Laravel. E per fortuna: sarebbe una promessa sbagliata.

Fa una cosa più concreta: ti permette di scrivere certe parti dell’applicazione con strumenti più solidi, senza uscire dall’ecosistema WordPress.

Una rotta “virtuale” in Acorn, utile per health-check, webhook o endpoint REST custom che non hanno senso come pagine di WordPress:

1
// app/Routes/web.php
2
use Illuminate\Support\Facades\Route;
3

4
Route::get('/health', function () {
5
    return response()->json([
6
        'status' => 'ok',
7
        'php'    => PHP_VERSION,
8
        'wp'     => get_bloginfo('version'),
9
        'env'    => wp_get_environment_type(),
10
    ]);
11
});

Un service provider che chiunque abbia lavorato con Laravel riconosce senza manuale:

1
// app/Providers/AppServiceProvider.php
2
namespace App\Providers;
3

4
use Roots\Acorn\ServiceProvider;
5
use App\Services\HubSpotClient;
6

7
class AppServiceProvider extends ServiceProvider
8
{
9
    public function register(): void
10
    {
11
        $this->app->singleton(HubSpotClient::class, function () {
12
            return new HubSpotClient(
13
                token: config()->string('services.hubspot.token'),
14
            );
15
        });
16
    }
17
}

L’ultima major (Acorn v6.1) è del 26 aprile 2026. Tra i pacchetti ufficiali segnalo roots/acorn-ai, che integra la WordPress Abilities API per i workflow di intelligenza artificiale, e roots/acorn-post-types, che permette di dichiarare custom post type e tassonomie in modo dichiarativo.

Qui il vantaggio non è scrivere codice “più bello”. È scrivere codice che un team può leggere, testare e mantenere senza dover ricostruire ogni volta il pensiero di chi lo ha scritto.

5. WP Packages: quando il controllo della filiera diventa tecnico

Questa è la novità più interessante del 2026, perché non riguarda solo la comodità. Riguarda il controllo dell’infrastruttura.

WPackagist è stato per anni il mirror Composer di fatto per plugin e temi del repository ufficiale di WordPress. Era un servizio della community, gestito dall’agenzia Outlandish. A marzo 2026 è stato acquisito da WP Engine.

La domanda non è ideologica. È pratica.

Ti va bene che un pezzo di infrastruttura così centrale, quello che risolve le dipendenze di moltissimi progetti WordPress moderni, sia controllato da una singola corporation a partecipazione private equity?

Per alcuni la risposta è sì. Per altri è: non ci avevo mai pensato, ma adesso che lo dici no, non mi piace.

Roots ha risposto con un’alternativa indipendente: WP Packages. È nato come WP Composer, poi rinominato a marzo 2026. I numeri dichiarati sono interessanti perché non sono solo marketing:

• circa 17 volte più veloce sul resolve a freddo, grazie al supporto pieno del protocollo metadata-url di Composer 2;
• aggiornamenti ogni 5 minuti, invece di finestre molto più lunghe;
• composer.lock riproducibili anche per plugin senza tag, con pinning a revision SVN;
• statistiche pubbliche, status page in tempo reale, codice open source.

La migrazione è quasi banale. Cambiano i namespace: wpackagist-plugin/* diventa wp-plugin/*, wpackagist-theme/* diventa wp-theme/*. Il repository Composer punta a https://repo.wp-packages.org.

1
$ composer remove wpackagist-plugin/woocommerce
2

3
$ composer config --unset repositories.wpackagist \
4
  && composer config repositories.wp-packages composer https://repo.wp-packages.org
5

6
$ composer require wp-plugin/woocommerce

Per un progetto nuovo nel 2026, partire direttamente da WP Packages è la scelta più pulita. Per un progetto esistente, è una migrazione da valutare con calma, ma difficilmente la ignorerei: build più veloci, lock file più affidabili, meno dipendenza da un attore solo.

Non è una questione da puristi. È gestione del rischio di filiera.

Radicle: la scorciatoia seria

Radicle è il punto d’ingresso consigliato da quando è stato lanciato nel 2024. È una distribuzione “opinionated” (yeah) che combina Bedrock + Sage + Acorn + Trellis in una struttura già allineata al folder layout di Laravel, con public/ come document root al posto di web/ (presto Bedrock si adeguerà anche a questo particolare).

progetto/
├── app/                  # codice applicativo (providers, models, jobs)
├── bootstrap/
├── config/
├── public/               # document root
│   ├── content/          # wp-content (themes, plugins)
│   └── wp/               # core
├── resources/
│   ├── views/            # template Blade
│   └── styles/
├── routes/
├── storage/
├── trellis/              # config server, se serve
├── composer.json
└── .env

Per chi viene da Laravel, il carico cognitivo è basso. Per chi viene da WordPress classico, la curva c’è. Ma su progetti di un certo livello è una curva che si ripaga.

Per crearne uno nuovo:

1
$ composer create-project roots/radicle nuovo-progetto
2
$ cd nuovo-progetto
3
$ cp .env.example .env
4
$ wp acorn radicle:install

Versione corrente: v2.6.0 (aprile 2026). Un dettaglio non secondario: Radicle è a pagamento per l’uso commerciale. A me sembra una cosa sana. Se una toolchain mi fa risparmiare giorni di lavoro e abbassa il rischio operativo di un progetto, il problema non è pagarla. Il problema è illudersi che l’infrastruttura buona nasca gratis e resti buona per inerzia.

In Encodia, quando parte un progetto WordPress nuovo di un certo livello, Radicle è spesso il punto da cui iniziamo a ragionare. Non per fede. Perché oggi è uno dei compromessi migliori tra pragmatismo WordPress e disciplina da applicazione moderna.

Quando Roots ripaga

Roots ha senso quando il progetto ha una vita tecnica davanti, non quando deve solo esistere online.

L’adozione paga soprattutto in questi casi:

• team di più di una persona, perché Composer, Git e ambienti coerenti ripagano il costo iniziale appena non sei più da solo;
• più ambienti, perché sviluppo, staging, UAT e produzione devono smettere di essere parenti lontani;
• CI/CD non opzionale, con deploy che passano da GitHub Actions e processi ripetibili;
• codice custom non banale, come custom post type, integrazioni REST, CRM, ERP, blocchi Gutenberg server-rendered;
• audit di sicurezza periodici, dove composer.lock e composer audit danno tracciabilità reale;
• indipendenza dai fornitori, perché Trellis su Ubuntu e WP Packages indipendente riducono il rischio di restare incastrati.

La domanda vera, lato business, non è “Roots è moderno?”. La domanda è: quante volte toccheremo questo codice nei prossimi due anni?

Se la risposta è “spesso”, Roots può ripagarsi molte volte. Se la risposta è “quasi mai”, probabilmente no.

Quando è solo ingegneria inutile

Voglio essere chiaro: Roots può essere overkill.

Per un sito brochure di cinque pagine che il cliente aggiorna due volte all’anno, un hosting managed serio e un tema fatto bene sono più che sufficienti.

Per un cliente che vuole gestirsi tutto da solo, senza un partner tecnico, Composer e Git rischiano di diventare un costo cognitivo che nessuno assorbirà davvero. Il risultato peggiore è consegnare un progetto teoricamente elegante, ma che poi nessuno tocca più. In questi casi un Builder (l’ho scritto) è forse l’unica soluzione possibile.

Per un sito costruito attorno a plugin commerciali che non distribuiscono via Composer, il lavoro non finisce con un “non si può”. Si può lavorare con repository privati, composer/satis o wikimedia/composer-merge-plugin. In Encodia usiamo Satis quando serve proprio per mettere sotto controllo anche dipendenze private e plugin commerciali: è una competenza pratica, non una nota a margine.

La parte da chiarire prima è un’altra: se una quota importante del valore del sito sta dentro plugin chiusi, il progetto richiede disciplina, budget e responsabilità adeguate. Roots resta una buona scelta, ma va governato da chi sa mettere ordine anche dove l’ecosistema WordPress non lo offre già pronto.

E poi ci sono i progetti piccoli, con budget piccolo e una sola persona coinvolta. In quei casi WordPress vanilla su un hosting decente può essere la scelta giusta.

Non bisogna ingegnerizzare per sentirsi più intelligenti.

Dove si vede la differenza

Un sito WordPress non costa quando lo pubblichi. Costa nei due anni dopo.

Costa quando un aggiornamento rompe una parte critica. Costa quando lo staging non assomiglia alla produzione. Costa quando il fornitore precedente ha lavorato “direttamente online”. Costa quando nessuno sa più quali plugin siano necessari e quali siano rimasti lì per paura di toccarli.

Roots non elimina questi problemi. Sarebbe una promessa da venditore.

Fa una cosa più utile: li rende gestibili.

E in un progetto WordPress serio, questa è quasi sempre la differenza tra un sito che cresce e un sito che, a un certo punto, tutti hanno paura di modificare.

Per le agenzie significa meno chiamate perché “il sito è giù”, meno ore perse su ambienti incoerenti, meno dipendenza da quel singolo plugin che fa miracoli ma che nessuno sa più chi mantenga.

Per le aziende significa poter chiedere conto del processo, non solo del risultato visibile: come si aggiorna, come si torna indietro, chi ha responsabilità su cosa, quanto il sito dipende da scelte che nessuno sa più spiegare.

Per i colleghi significa fare WordPress senza sentirsi nel 2010.

Se un’azienda sta valutando un partner tecnologico per i propri asset web, e in quegli asset c’è WordPress, io farei tre domande prima ancora di guardare il preventivo:

1. Come gestite dipendenze e aggiornamenti?
2. Quanto tempo serve per fare rollback dopo un deploy andato male?
3. Se domani un fornitore chiude, viene acquisito o cambia condizioni, quanto siete esposti?

Sono domande che separano chi vende tranquillità a parole da chi ha davvero le mani nel motore.

Se vuoi parlarne sul serio

Se sei arrivato fin qui, probabilmente non stai cercando “un sito WordPress”. Stai cercando un modo per non ritrovarti fra un anno con un asset importante che nessuno vuole toccare.

Dal refactor di un’installazione esistente alla migrazione a Bedrock o Radicle, dal disegno di una pipeline CI/CD all’audit tecnico di un fornitore che già gestisce il tuo sito, questo è il tipo di lavoro su cui posso entrare nel merito senza giri di parole.

Una premessa onesta: una consulenza di questo tipo paga sopra una certa soglia di complessità. Progetti con team interni, integrazioni, fatturato che passa dal sito, responsabilità operative reali.

Se la situazione è “WordPress vanilla su un hosting managed, va già abbastanza bene così”, questo articolo è probabilmente il consiglio più utile che potessi darti. In tutti gli altri casi, scrivimi.