Guida all’uso

Pubblicato il 2026-04-01 di EmDash CMS Team

Cosa dovrebbe fare questo sito

emdashcmseverything.com non dovrebbe comportarsi come una landing page generica. Dovrebbe funzionare come livello pubblico di conoscenza e distribuzione per l’ecosistema EmDash.

Significa combinare più ruoli di contenuto in un sistema coerente:

• spiegare cos’è EmDash
• insegnare come funziona
• mostrare dove si inserisce
• pubblicare plugin e template
• guidare le migrazioni da WordPress
• annunciare progressi e release del prodotto

Architettura informativa consigliata

La struttura attuale è pensata per supportare quel modello:

• docs/docs per documentazione evergreen
• docs/use-cases per contenuti di adozione guidati dagli scenari
• docs/plugins per le schede della directory plugin
• docs/templates per le schede della directory template
• docs/faq per aggiornamenti, tutorial e contenuti editoriali

È un adattamento migliore che stipare tutto in un’unica homepage marketing o nascondere le informazioni sul prodotto dentro i componenti del framework.

Come usare ogni sezione

Docs

Usa questa sezione per contenuti duraturi e ad alta intenzione:

• prime mosse
• spiegazioni delle funzionalità
• note di deployment
• panoramiche sull’architettura
• FAQ

Queste pagine dovrebbero rispondere alle domande che le persone fanno prima e durante la valutazione.

Use Cases

Usa questa sezione per tradurre le capacità del prodotto nel contesto dell’acquirente. EmDash è più facile da capire quando è inquadrato come adatto a:

• pubblicazione editoriale
• documentazione e knowledge base
• ecosistemi di plugin
• business di template

Questa sezione dovrebbe collegare la forma del prodotto a risultati concreti.

Plugins

Le pagine plugin dovrebbero sembrare piccole pagine prodotto, non solo note di release. Ognuna dovrebbe spiegare:

• cosa fa il plugin
• per chi è
• stato attuale
• prezzi o disponibilità
• percorso di download
• setup e compatibilità

Templates

Le pagine template dovrebbero facilitare il confronto tra starter di sito impacchettati. Buone schede includono:

• pubblico di riferimento
• screenshot
• dettagli dello stack
• versione e data di release
• link alla demo
• link a download o repository

Blog e aggiornamenti

Questa sezione dovrebbe catturare il movimento:

• note di release
• guide alla migrazione
• commenti sul prodotto
• tutorial
• case study

È ciò che mantiene il sito attivo e in crescita composta.

Flusso di pubblicazione

Per questo progetto, il flusso più sano e semplice è:

1. Aggiungere o rivedere contenuti in docs/
2. Rivedere il diff Git
3. Anteprima in locale
4. Deploy del sito statico buildato su Cloudflare Pages

Questo flusso è particolarmente efficace quando l’AI aiuta con bozza, editing, ristrutturazione e coerenza.

Perché questa struttura funziona bene con l’AI

L’editing assistito dall’AI è molto più affidabile quando il sito è costruito attorno a:

• file MDX piccoli
• frontmatter esplicito
• componenti di pagina riutilizzabili
• pattern di route stabili
• contenuti separati dal codice UI

Per questo la forma attuale del sito è volutamente content-first.

Come si collega a EmDash stesso

I materiali ufficiali EmDash enfatizzano collezioni runtime, editing admin, plugin, storage media e portabilità cloud. Sono punti di forza del prodotto. Ma un sito ecosistema pubblico non ha bisogno di tutto subito.

Il sito statico è il livello di presentazione pubblica.

Il runtime EmDash completo è il livello successivo quando servono:

• editor non tecnici che lavorano nel browser
• flussi di contributori autenticati
• media gestiti a runtime
• automazioni più ricche o flussi di submission plugin

Regola pratica editoriale

Ogni pagina dovrebbe rispondere chiaramente a una di queste domande:

• Cos’è EmDash?
• Perché non WordPress?
• Cosa fa questo plugin o template?
• Come migro?
• Come faccio il deploy?
• Perché vale la pena adottarlo adesso?

Se una pagina non risponde bene a nessuna di queste, probabilmente ha bisogno di uno scope più stretto.