Perché questo template
Questo repository nasce da un sito reale andato in produzione: non è una demo costruita per sembrare bella. Il codice è quello che serve a far girare un sito vetrina con contenuti che il cliente aggiorna da solo, ripulito da loghi, testi e modelli di dati del cliente originale.
Cosa vogliamo ottenere
Sezione intitolata “Cosa vogliamo ottenere”| Obiettivo | Come lo otteniamo |
|---|---|
| Sito veloce | HTML statico generato in build, niente query a database a runtime |
| Cliente autonomo | WordPress come pannello di redazione, senza toccare il codice |
| Costi bassi | hosting statico; nessun server applicativo da mantenere |
| Sicurezza | il database WordPress non è raggiungibile dal pubblico |
| Riuso | identità e stile in due file; sezioni e componenti già fatte |
| Errori in build, non in produzione | Zod valida i contenuti prima del deploy |
| Manutenzione prevedibile | poche dipendenze, un gate unico (npm run quality) |
Cosa non vogliamo
Sezione intitolata “Cosa non vogliamo”- Un tema WordPress: il frontend non è dentro WordPress. Niente page builder, niente plugin che iniettano markup, niente PHP che genera HTML pubblico.
- Un’app dinamica: niente login utenti, aree riservate, ricerca full-text server-side, prezzi calcolati a runtime, contenuti in tempo reale.
- Un CMS proprietario: il cliente conosce WordPress, gli editori lo sanno usare, i contenuti sono portabili.
- Un monolite: il template deve poter ospitare più siti diversi senza forkarti la logica. Cambiano testi, palette e contenuti, non l’architettura.
Il compromesso principale: statico
Sezione intitolata “Il compromesso principale: statico”Un sito statico è una fotografia: per cambiare una foto bisogna rifarla. Ogni modifica di contenuto richiede un rebuild e un deploy. È il prezzo che paghiamo per velocità, sicurezza e costi quasi nulli.
| Statico (questo template) | Dinamico (SSR/ISR) | |
|---|---|---|
| Tempo di risposta | millisecondi, cache CDN | dipende dal server |
| Superficie d’attacco | file statici | server, DB, sessioni |
| Costo hosting | pochi euro/anno o zero | istanza sempre accesa |
| Pubblicazione contenuti | rebuild (1–2 minuti) | immediata |
| Preview editoriale | assente (si vede dopo il deploy) | immediata |
Per un sito vetrina la latenza di pubblicazione di un paio di minuti non è un problema. Se un progetto ha bisogno di contenuti che cambiano ogni minuto, questo non è il template giusto.
Da dove viene
Sezione intitolata “Da dove viene”Il codice deriva da un sito reale andato in produzione: un hub con calendario eventi, listino, promozioni, FAQ, team, galleria e form contatti. Sono stati rimossi:
- pagine e contenuti del cliente;
- i CPT troppo verticali (percorsi, programmi, produzioni, trasporti);
- colori, font e asset di brand;
- riferimenti nel codice a nomi, email e URL del cliente.
Sono rimasti i modelli e i componenti che si ripresentano nella maggior parte dei progetti: eventi, listino, promozioni, FAQ, team, galleria, partner, timeline, form, consenso cookie.
Come si riconosce un buon uso del template
Sezione intitolata “Come si riconosce un buon uso del template”- Il sito nuovo si avvia modificando
src/data/site.tsesrc/styles/tokens.css. - I contenuti che il cliente cambia spesso stanno in WordPress.
- Le pagine contengono struttura e testi fissi; non contengono query o fetch.
- Aggiungere una sezione significa aggiungere un CPT, non piegare quelli esistenti.
npm run qualityè verde prima di ogni push.
Se ti trovi a modificare componenti condivisi per un singolo cliente, probabilmente stai usando il template come fork. A volte è giusto, ma va deciso consapevolmente.