// caso-studio
wp-bootstrap
CLI in Bash che provisiona un sito WordPress locale completo in un comando - clone, core, database, tema child, plugin, vhost Apache e primo sync - con step idempotenti, resume e test in puro Bash.
Cos'è
Ogni nuovo progetto WordPress in agenzia iniziava con la stessa ora di setup manuale: clonare il repo, scaricare il core, creare database e utente, generare wp-config.php, installare tema e plugin, configurare il virtual host, lanciare il primo pull del database. Ogni volta uguale, ogni volta un'occasione per sbagliare qualcosa.
wp-bootstrap comprime tutto in un comando: ./wp-bootstrap.sh --name progetto e qualche minuto dopo il sito di staging locale è su, con smoke test passato e primo db:pull fatto. È l'esempio letterale del principio che guida come lavoro: quando un flusso mi serve più di una volta, lo trasformo in uno strumento.
Come funziona
La pipeline è divisa in 16 step numerati e idempotenti (clone → core → DB → config → temi → plugin → vhost → smoke test → sync), ognuno un file sorgente a sé. Uno state tracker su file registra cosa è già stato completato, e da lì nascono le feature che rendono lo strumento affidabile:
--resumeriparte dallo step fallito, senza rifare quelli già a posto--force-step 07rigioca un singolo step--dry-runstampa ogni comando che verrebbe eseguito, senza toccare nulla--force --yesricostruisce da zero in modo non interattivo
Ogni run scrive una ricetta YAML (.bootstrap.yml) con le risposte date: il prossimo bootstrap dello stesso progetto si fa con --from-file, zero domande. Le password si inseriscono solo da prompt — mai come flag, per non finire nella history della shell — e nel riepilogo compaiono mascherate.
Dettagli a cui tengo: il blocco del vhost Apache è delimitato da marker, così i re-run lo sostituiscono invece di accumularne copie; un plugin con slug morto produce un warning e non un abort; wp-config.php nasce da un template con i salt scaricati live dall'API di WordPress.org.
I test (sì, in Bash)
La parte meno ovvia del repo: una suite di test in puro Bash, senza framework, con il suo harness run-all.sh. Coprono il parsing dei flag, la precedenza tra .env e argomenti, il round-trip delle ricette YAML — inclusa una password con spazi, apici e # dentro — la persistenza dello stato e la sostituzione dei template.
# Il round-trip YAML deve sopravvivere anche alla password peggiore.
save_bootstrap_yml "$TMP_YML_DIR"
load_bootstrap_yml "$TMP_YML_DIR/.bootstrap.yml"
[[ "$NAME" == "sample-project" ]] || fail "yml NAME=$NAME"
[[ "$DB_PASSWORD" == 'pa ss"with:special#' ]] || fail "yml DB_PASSWORD=$DB_PASSWORD"
[[ "$SKIP_PULL" == "true" ]] || fail "yml SKIP_PULL=$SKIP_PULL"
Testare uno script di provisioning è scomodo, ed è esattamente il motivo per cui i punti più fragili (parsing, escaping, stato) sono coperti: sono quelli che rompono il bootstrap alle 9 di mattina di un lunedì di consegna.
Limiti consapevoli
È uno strumento nato per uno stack preciso — macOS, Homebrew, Apache, WP-CLI — e non pretende di essere universale: la lista plugin è opinionata e il flusso è cucito sul workflow di agenzia. È il suo pregio: fa una cosa sola, quella che serviva, e la fa sempre allo stesso modo.