DBA con Wiki come database online by Claude Documenti tecnici

 

Sì, assolutamente — un wiki è uno strumento molto flessibile e si adatta bene a un catalogo "misto" come quello che descrivi. Dipende però da quale software wiki scegli e come lo configuri.

MediaWiki (il software dietro Wikipedia) è la scelta più potente per questo scopo: permette di creare pagine strutturate per libri, documenti, eventi e notizie, usare template per uniformare la presentazione, categorie per organizzare i contenuti, e con l'estensione Cargo o Semantic MediaWiki puoi aggiungere dati strutturati e query tipo database (es. "tutti gli eventi del 2025", "libri di un certo autore").

Alternative più leggere come DokuWiki o Wiki.js sono più semplici da installare e gestire, ma meno potenti per cataloghi complessi.

Alcune domande per aiutarti a capire se è la scelta giusta per te:

D: Chi gestirà il catalogo? R: Un piccolo gruppo

D: Che livello tecnico hai per l'installazione? R: sono interessato a tutti i livelli. Voglio realizzare un documento per una valutazione sulla base di costi/benefici

D: Cosa ti interessa di più? (Seleziona tutte le opzioni applicabili) R: Ricerca e filtri avanzati, Facile inserimento dati

Ottima impostazione — un'analisi costi/benefici è il modo giusto per affrontare la scelta. Ti preparo un documento strutturato.Ecco il documento Word completo. Contiene:

• Confronto tecnico tra MediaWiki, DokuWiki, Wiki.js e Confluence su 9 caratteristiche chiave
• Stima dei costi anno 1 per ciascuna soluzione (licenza, hosting, setup, formazione, manutenzione)
• Matrice benefici ponderata con i criteri prioritari che hai indicato (ricerca avanzata, facilità inserimento, gestione piccolo gruppo, accesso pubblico, controllo dati)
• Raccomandazione motivata: MediaWiki + estensioni semantiche come prima scelta, DokuWiki come alternativa rapida ed economica

La raccomandazione sintetica: MediaWiki vince sui benefici nel lungo periodo, ma richiede più investimento iniziale. DokuWiki è l'alternativa pragmatica per partire subito con budget contenuto. Fammi sapere se vuoi approfondire qualche aspetto o modificare i criteri di valutazione.

========================================

Software Wiki per Catalogo Misto

Analisi Costi / Benefici • Documento di Valutazione

1. Contesto e obiettivi

Il gruppo intende realizzare un catalogo online di tipo misto, che includa schede su libri e altri documenti, notizie ed eventi. Il sistema dovrà essere gestito da un piccolo gruppo di redattori e garantire ricerca avanzata e facilità di inserimento dati.

Questo documento confronta quattro soluzioni wiki rappresentative, valutandone i costi e i benefici in relazione alle esigenze specifiche del progetto.

2. Software analizzati

Le soluzioni considerate sono:

• MediaWiki — il motore di Wikipedia, molto potente e personalizzabile.

• DokuWiki — soluzione leggera, senza database, ideale per team piccoli.

• Wiki.js — wiki moderno con interfaccia curata e supporto Markdown/WYSIWYG.

• Confluence (Atlassian) — strumento commerciale SaaS, completo ma con costi ricorrenti.

3. Confronto delle caratteristiche

La tabella seguente riassume le principali caratteristiche tecniche e funzionali di ciascuna soluzione.

Caratteristica	MediaWiki	DokuWiki	Wiki.js	Confluence
Tipo di licenza	Open source (GPL)	Open source (GPL2)	Open source (AGPL)	Commerciale (SaaS/self-hosted)
Costo licenza	Gratuito	Gratuito	Gratuito	Da €5/utente/mese
Dati strutturati / catalogo	★★★★★ (con SMW/Cargo)	★★★ (con plugin)	★★★ (moduli base)	★★★★ (Database nativa)
Ricerca avanzata	Eccellente (+ estensioni)	Buona	Buona (Elasticsearch opt.)	Eccellente
Facilità inserimento dati	Media (wiki markup / VE)	Alta (editor semplice)	Alta (editor moderno)	Alta (WYSIWYG)
Gestione utenti / ruoli	Buona	Base	Buona	Eccellente
Complessità installazione	Media-alta	Bassa	Media	Bassa (SaaS)
Scalabilità	Molto alta	Media	Alta	Alta
Community / documentazione	Enorme	Attiva	In crescita	Ampia (Atlassian)

Nota: per MediaWiki, il massimo punteggio sui dati strutturati si ottiene installando le estensioni Semantic MediaWiki (SMW) o Cargo, indispensabili per gestire un catalogo avanzato.

4. Stima dei costi

I valori seguenti sono stime indicative basate su scenari realistici per un piccolo gruppo. I costi di hosting si riferiscono a VPS o hosting condiviso di fascia media.

Voce di costo	MediaWiki	DokuWiki	Wiki.js	Confluence
Licenza sw (annuale)	€ 0	€ 0	€ 0	€ 300–600*
Hosting / server (annuale)	€ 120–600	€ 60–240	€ 120–480	Incluso (SaaS)
Setup e configurazione iniziale	€ 500–2.000	€ 100–400	€ 200–800	€ 200–500
Formazione team (stima)	€ 400–1.000	€ 100–300	€ 200–500	€ 200–500
Manutenzione annuale (stima)	€ 300–1.000	€ 100–300	€ 200–600	Inclusa
TOTALE STIMATO anno 1	€ 1.300–4.600	€ 360–1.240	€ 720–2.380	€ 700–1.600

* Confluence: il prezzo indicato si riferisce al piano Standard per 5 utenti. Disponibile anche in versione self-hosted (Data Center), ma con costi di licenza significativamente più elevati.

5. Valutazione dei benefici

I criteri di valutazione sono stati ponderati in base alle priorità dichiarate (★★★ = massima priorità, ★★ = alta, ★ = normale).

Criterio (peso)	MediaWiki	DokuWiki	Wiki.js	Confluence
Catalogo misto (libri, doc, eventi) ★★★	5/5	3/5	3/5	4/5
Ricerca e filtri avanzati ★★★	5/5	3/5	4/5	5/5
Facilità inserimento dati ★★★	3/5	5/5	4/5	4/5
Gestione piccolo gruppo ★★	4/5	4/5	4/5	5/5
Accesso pubblico senza registrazione ★★	5/5	5/5	4/5	3/5
Indipendenza e controllo dei dati ★★	5/5	5/5	5/5	2/5
Sostenibilità a lungo termine ★	5/5	4/5	4/5	3/5
PUNTEGGIO PONDERATO TOTALE	31/35	25/35	24/35	22/35

6. Raccomandazione

Prima scelta: MediaWiki + Semantic MediaWiki / Cargo

MediaWiki è la soluzione più potente per la gestione di un catalogo misto strutturato. Con le estensioni SMW o Cargo è possibile creare schede con campi personalizzati (autore, data, tipologia, ecc.) e interrogarle come un database, mantenendo al contempo tutta la flessibilità di un wiki aperto.

• Costo zero di licenza e massimo controllo dei dati.

• Ottima scalabilità nel tempo, anche se il catalogo cresce molto.

• Curva di apprendimento più ripida per i redattori: richiede investimento iniziale in formazione e template.

Alternativa consigliata: DokuWiki

Se il gruppo ha competenze tecniche limitate e vuole partire rapidamente con budget contenuto, DokuWiki è la scelta migliore. Non richiede database, è semplice da installare e da mantenere. I limiti principali sono la minore potenza nella gestione di dati strutturati e una ricerca meno avanzata.

Quando scegliere Confluence

Confluence è la scelta giusta se il gruppo preferisce zero manutenzione tecnica e dispone di budget ricorrente. Offre la migliore esperienza utente, ma il lock-in sul fornitore e i costi crescenti nel tempo ne limitano la sostenibilità per progetti no-profit o con budget ridotto.

7. Conclusioni

In sintesi, per un catalogo misto con priorità su ricerca avanzata e gestione strutturata dei contenuti, MediaWiki con estensioni semantiche offre il miglior rapporto costi/benefici nel lungo periodo.

Per un avvio più rapido con minori costi di setup, DokuWiki rappresenta una valida alternativa di ingresso, con la possibilità di migrare a MediaWiki in un secondo momento qualora le esigenze del progetto crescessero.

Si raccomanda di pianificare una fase pilota di 2–3 mesi con la soluzione prescelta prima del rilascio pubblico, dedicando particolare attenzione alla definizione dei template di inserimento dati e alla formazione del gruppo redazionale.

Documento generato il 13/03/2026 — soggetto a revisione sulla base di specifiche aggiuntive.

========================================

Sì, esistono diverse opzioni — sia demo online pronte all'uso, sia installazioni locali rapide. Ecco il quadro completo:

---

MediaWiki — demo online

Su opensourcecms.com/mediawiki è disponibile una demo condivisa con accesso admin. È anche possibile richiedere un'istanza personale con durata di 24 ore, ideale per evitare che le modifiche vengano sovrascritte da altri utenti.

Un'altra opzione ufficiale è mediawiki.org/wiki/Special:MyLanguage/Manual:Demo (il wiki ufficiale stesso), dove puoi esplorare tutte le funzionalità senza credenziali di admin.

---

DokuWiki — demo online

Su opensourcecms.com/dokuwiki c'è un'installazione pubblica condivisa che si resetta ogni ora. È anche possibile richiedere una propria istanza demo con durata di 24 ore.

In alternativa, installatron.com/dokuwiki/demo offre una demo live con credenziali pubbliche (username: admin, password: demo), con accesso sia al frontend che al pannello di amministrazione.

---

Installazione locale rapida (senza hosting)

Se vuoi un ambiente più stabile e controllato per i test del gruppo, entrambi i software si installano in pochi minuti in locale con Docker:

# MediaWiki
docker run -p 8080:80 mediawiki

# DokuWiki
docker run -p 8081:80 bitnami/dokuwiki

Non serve un server: basta avere Docker sul proprio PC e si accede dal browser su localhost:8080.

---

Qual è la soluzione migliore per i test del tuo gruppo?

Per una valutazione iniziale, ti consiglio di partire dalle demo online a 24 ore (una per ciascun software), così ogni membro del gruppo può esplorare liberamente senza interferire con gli altri. Se poi volete fare test più approfonditi con dati reali (inserire schede di libri, eventi, ecc.), vale la pena montare un'istanza Docker locale o su un piccolo VPS.

Vuoi che prepari una guida passo-passo per installare uno dei due con Docker?

====================================

un altro quesito. Gestisco un blog Word Press e vorrei inserire nel menu un accesso alla biblioteca. Quali livelli di integrazione posso realizzare tra il sito e la biblioteca/wiki?

=============================================

D: Cosa vuoi che l'utente possa fare dalla parte WordPress? (Seleziona tutte le opzioni applicabili) R: Solo leggere la biblioteca (sola lettura), Cercare libri/documenti dal blog, Ricevere notifiche su novità della biblioteca

D: Gli utenti del blog e della biblioteca saranno gli stessi? R: In parte sovrapposti

D: Quale software wiki stai orientandoti a scegliere? R: Non ancora deciso

Perfetto — con queste esigenze (lettura, ricerca e notifiche, senza necessità di editing dal lato WordPress) il quadro si semplifica molto: non serve il Single Sign-On, e puoi ottenere un'integrazione di buon livello senza costi tecnici elevati.

Ecco lo scenario consigliato, livello per livello:

---

Navigazione unificata (Livello 2) Il wiki su biblioteca.tuosito.it con tema grafico allineato al blog WordPress. Nel menu WordPress una voce "Biblioteca" apre il wiki in modo trasparente per l'utente. Entrambi i software (MediaWiki e DokuWiki) supportano temi personalizzati — DokuWiki è leggermente più semplice da personalizzare graficamente per un non-tecnico.

---

Ricerca dal blog (Livello 3) Questa è la funzione più interessante per te. Ci sono due approcci praticabili:

• Widget di ricerca: un blocco Gutenberg nel blog con un campo di ricerca che interroga l'API del wiki e mostra i risultati in una pagina WordPress. MediaWiki espone un'API REST matura (api.php?action=query&list=search&srsearch=...); DokuWiki ha l'API XML-RPC o il plugin DokuWiki API. Con un piccolo plugin WordPress su misura (poche decine di righe di codice) si può costruire questa funzione.
• Ricerca Google Site Search: soluzione più rapida e zero-code, che cerca solo nell'URL del wiki tramite Google. Meno elegante ma funzionante senza sviluppo.

---

Notifiche sulle novità (Livello 3) Entrambi i wiki generano feed RSS/Atom delle pagine recenti. In WordPress puoi usare il plugin WP RSS Aggregator (gratuito) per importare automaticamente le novità della biblioteca come post o widget nella sidebar del blog. In alternativa, per notifiche via email agli iscritti puoi collegare il feed RSS a Mailchimp o MailPoet (già integrato in WordPress).

---

Impatto sulla scelta del wiki

Detto questo, le tue esigenze di integrazione orientano leggermente la scelta:

• MediaWiki ha un'API REST più potente e documentata — meglio se vuoi una ricerca integrata raffinata o vuoi evolvere l'integrazione in futuro.
• DokuWiki è più semplice da configurare per RSS e notifiche base, e richiede meno lavoro di setup generale. Sufficiente se la ricerca integrata non è una priorità immediata.

---

Vuoi che prepari un documento di specifica tecnica per questa integrazione, o preferisci prima completare la valutazione del software wiki da adottare?

=====================================

Ecco la specifica tecnica completa. Il documento copre 11 sezioni:

• Architettura generale — schema dei flussi tra WordPress e wiki
• Livello 1 — sottodominio, SSL, tema grafico allineato, voce di menu
• Livello 2 — widget di ricerca con API MediaWiki (parametri, codice JavaScript di esempio) e alternative per DokuWiki
• Livello 3 — feed RSS/Atom, widget "Novità" con WP RSS Aggregator, newsletter automatica con MailPoet
• Plugin consigliati — tabella con licenze e note
• Stima effort — da 21 a 50 ore totali, suddivise per attività e profilo
• Sicurezza — SSL, CORS, rate limiting, backup
• Roadmap — tre fasi su 7 settimane
• Evoluzione futura — SSO con OAuth 2.0 come opzione Livello 4

Se durante i test sulle demo online emergono domande specifiche su come configurare un'API o un feed RSS, posso aiutarti con i dettagli.

Specifica Tecnica di Integrazione

WordPress Blog ↔ Wiki Biblioteca

Lettura • Ricerca • Notifiche novità

1. Scopo del documento

Questo documento descrive l’architettura tecnica e le modalità di integrazione tra il blog WordPress esistente e la futura biblioteca/wiki (MediaWiki o DokuWiki). L’obiettivo è consentire agli utenti del blog di consultare la biblioteca, effettuare ricerche sui contenuti e ricevere notifiche sulle novità, senza dover gestire due accessi separati.

Le funzionalità target sono:

• Navigazione unificata: accesso alla biblioteca dal menu WordPress.

• Ricerca integrata: campo di ricerca nel blog che interroga il wiki.

• Notifiche novità: aggiornamenti automatici agli iscritti tramite RSS/newsletter.

Nota: Il Single Sign-On (SSO) non rientra nello scope attuale ma è documentato come evoluzione futura (Livello 4).

2. Architettura generale

Il sistema è composto da due ambienti distinti che comunicano tramite API e feed standard:

• — ospitato sul dominio principale, es. www.tuosito.it

• — ospitato su sottodominio, es. biblioteca.tuosito.it

La comunicazione avviene in modo unidirezionale: il blog legge i dati del wiki (API REST per la ricerca, feed RSS per le novità). Il wiki non interagisce con WordPress. Questa scelta minimizza la complessità e i rischi di sicurezza.

2.1 Schema delle componenti

Di seguito il flusso delle tre funzionalità principali:

Menu WordPress → link sottodominio wiki → utente naviga la biblioteca

Campo ricerca WP → chiamata API wiki → risultati visualizzati nella pagina WP

Wiki pubblica novità → feed RSS/Atom → WP RSS Aggregator → widget/newsletter

3. Livelli di integrazione

La tabella seguente riassume i quattro livelli disponibili. Per il progetto attuale sono previsti i livelli 1, 2 e 3. Il livello 4 (SSO) è documentato come opzione futura.

Livello	Funzionalità	Tecnologia	Complessità	Compatibilità
1	Menu + sottodominio allineato	Tema wiki personalizzato	Bassa	MediaWiki / DokuWiki
2	Widget ricerca dal blog	API REST wiki + plugin WP	Media	MediaWiki (preferito) / DokuWiki
3	Notifiche novità nel blog	RSS/Atom + WP RSS Aggregator	Bassa	MediaWiki / DokuWiki
4*	Single Sign-On (opzionale)	OAuth 2.0 / Keycloak	Alta	MediaWiki (estensione OAuth)

Nota: Livello 4 (SSO) consigliato solo se il numero di redattori cresce oltre 10 unità o se si vuole unificare l’iscrizione alla newsletter con l’account wiki.

4. Livello 1 — Navigazione unificata

4.1 Sottodominio e certificato SSL

Creare il record DNS di tipo CNAME o A per biblioteca.tuosito.it puntando al server del wiki. Abilitare il certificato SSL tramite Let’s Encrypt (gratuito, rinnovo automatico). La maggior parte dei provider hosting offre questa funzione dal pannello di controllo (cPanel, Plesk, ecc.).

4.2 Personalizzazione grafica del wiki

Per garantire continuità visiva con il blog WordPress, il tema del wiki dovrà adottare gli stessi colori, logo e font principali.

MediaWiki: modificare il file LocalSettings.php e il tema Vector/Timeless. Creare il file MediaWiki:Common.css per sovrascrivere i colori principali. Esempio:

/* MediaWiki:Common.css */

#mw-page-base { background-color: #1F4E79; }

.mw-wiki-logo { background-image: url('/images/logo.png'); }

DokuWiki: selezionare un template (es. Bootstrap3 o Mikio) e personalizzarlo tramite l’interfaccia di amministrazione. È possibile caricare un CSS custom senza modificare file di sistema.

4.3 Voce di menu in WordPress

In WordPress: Aspetto → Menù → Aggiungi link personalizzato con URL https://biblioteca.tuosito.it e etichetta “Biblioteca” (o il nome scelto). Spuntare “Apri in nuova scheda” solo se si vuole mantenere il blog aperto in background.

5. Livello 2 — Widget di ricerca integrato

5.1 API di ricerca: MediaWiki

MediaWiki espone un’API REST nativa accessibile all’endpoint:

https://biblioteca.tuosito.it/api.php

Parametri per una ricerca full-text:

Parametro	Valore / Descrizione
action	query
list	search
srsearch	{termine inserito dall’utente}
srnamespace	0 (articoli principali)
srlimit	10 (risultati per pagina)
format	json

Esempio di URL completo:

https://biblioteca.tuosito.it/api.php?action=query&list=search

&srsearch=calvino&srnamespace=0&srlimit=10&format=json&origin=*

Nota: Il parametro origin=* è necessario per consentire le chiamate CORS dal dominio WordPress.

5.2 API di ricerca: DokuWiki

DokuWiki non ha un’API REST nativa paragonabile. Le opzioni disponibili sono:

• Plugin DokuWiki-API (disponibile su GitHub): aggiunge endpoint REST di base.

• XML-RPC nativo (wiki.getSearchResults): meno immediato ma stabile.

• In alternativa, redirect al motore di ricerca interno del wiki tramite URL:

https://biblioteca.tuosito.it/doku.php?do=search&id={termine}

Nota: Per DokuWiki la ricerca completamente integrata nel blog richiede più lavoro custom. Se la ricerca integrata è prioritaria, MediaWiki è la scelta consigliata.

5.3 Implementazione del widget WordPress

Il widget di ricerca si implementa come blocco Gutenberg custom o come shortcode PHP. Il flusso è:

1. L’utente digita un termine nel campo di ricerca della pagina WordPress.

2. WordPress esegue una chiamata fetch() JavaScript all’API del wiki (lato client).

3. I risultati (titolo, snippet, URL) vengono visualizzati nella stessa pagina in un elenco dinamico.

4. Ogni risultato è un link che apre la scheda corrispondente sul wiki.

Struttura del codice JavaScript (semplificata):

async function cercaBiblioteca(termine) {

const url = 'https://biblioteca.tuosito.it/api.php'

+ '?action=query&list=search&srsearch='

+ encodeURIComponent(termine)

+ '&srnamespace=0&srlimit=10&format=json&origin=*';

const risposta = await fetch(url);

const dati = await risposta.json();

return dati.query.search; // array di risultati

}

Il codice viene inserito tramite il plugin WPCode (o Code Snippets) come blocco HTML/JS in una pagina WordPress dedicata oppure nella sidebar.

6. Livello 3 — Notifiche novità

6.1 Feed RSS/Atom del wiki

Entrambi i wiki generano automaticamente feed RSS delle pagine recenti:

• https://biblioteca.tuosito.it/api.php?action=feedrecentchanges&feedformat=rss

• https://biblioteca.tuosito.it/feed.php?type=changes&mode=list

I feed includono: titolo della pagina modificata/creata, data, autore e link diretto alla scheda.

6.2 Widget “Novità dalla Biblioteca” nel blog

Installare il plugin WP RSS Aggregator (gratuito) in WordPress. Configurazione:

5. Aggiungere il feed RSS del wiki come sorgente.

6. Impostare frequenza di aggiornamento (consigliato: ogni 6 ore).

7. Inserire il widget “Feed Items” nella sidebar o in una pagina dedicata.

8. Personalizzare il template di visualizzazione (titolo + data + link).

6.3 Newsletter automatica agli iscritti

Utilizzare il plugin MailPoet (già integrato in molti temi WP) per inviare automaticamente una digest settimanale con le novità della biblioteca:

9. Creare una newsletter automatica di tipo “Ultimi post/elementi RSS”.

10. Collegare il feed RSS del wiki come sorgente.

11. Impostare frequenza di invio (es. ogni lunedì) e grafica dell’email.

12. Gli utenti si iscrivono tramite il form di iscrizione già presente nel blog.

Nota: Gli iscritti alla newsletter del blog riceveranno automaticamente le novità della biblioteca senza necessità di un secondo account wiki.

7. Plugin WordPress consigliati

Plugin	Funzione	Licenza	Note
WP RSS Aggregator	Importa feed RSS dal wiki	Gratuito (freemium)	Supporta RSS e Atom
MailPoet	Newsletter da RSS	Gratuito fino 1.000 iscr.	Integrato in WP
WPCode / Code Snippets	Inserisce widget ricerca	Gratuito	Blocco Gutenberg custom
Miniature Gallery / Shortcode	Visualizza anteprime schede	Dipende dal plugin scelto	Via API + template PHP

8. Stima dell’effort di implementazione

Le stime seguenti si riferiscono a un’implementazione standard senza personalizzazioni avanzate. Il profilo “Sviluppatore PHP/JS” può essere sostituito da un freelance o da un membro del gruppo con competenze web di base.

Attività		Ore stimate	Profilo	MediaWiki	DokuWiki
Setup sottodominio + SSL		2–4 h	Sysadmin	=	=
Personalizzazione tema wiki		4–12 h	Web designer	Media	Bassa
Configurazione RSS + WP plugin		1–2 h	WP admin	=	=
Widget ricerca API (sviluppo)		8–20 h	Sviluppatore PHP/JS	Bassa	Media
Setup newsletter (MailPoet)		2–4 h	WP admin	=	=
Test e collaudo completo		4–8 h	Team	=	=
TOTALE STIMATO	21–50 h			Variabile per profilo tecnico del team

Nota: Le ore indicate sono stime indicative. L’effort effettivo dipende dalla familiarità con WordPress e dal grado di personalizzazione grafica desiderato.

9. Considerazioni di sicurezza

• SSL obbligatorio su entrambi i domini (WordPress e wiki) per evitare avvisi del browser e proteggere i dati in transito.

• API wiki in sola lettura: le chiamate API dal blog non richiedono autenticazione poiché accedono solo a contenuti pubblici.

• CORS: configurare il wiki per accettare richieste dal dominio WordPress (parametro origin nell’API MediaWiki; header nel file .htaccess per DokuWiki).

• Rate limiting: limitare le chiamate API a max 10 richieste/secondo per prevenire abusi (configurabile in LocalSettings.php per MediaWiki).

• Backup: mantenere backup settimanali automatici sia del database WordPress sia dei file del wiki.

10. Roadmap di implementazione

Si suggerisce il seguente ordine di implementazione, distribuito in tre fasi:

Fase 1 — Infrastruttura base (settimane 1–2)

13. Installazione e configurazione wiki sul sottodominio.

14. Configurazione SSL e DNS.

15. Personalizzazione grafica del wiki (allineamento al blog).

16. Inserimento voce “Biblioteca” nel menu WordPress.

Fase 2 — Notifiche e newsletter (settimane 3–4)

17. Configurazione WP RSS Aggregator con feed del wiki.

18. Creazione widget “Novità” nella sidebar del blog.

19. Configurazione newsletter automatica con MailPoet.

Fase 3 — Ricerca integrata (settimane 5–7)

20. Sviluppo del widget di ricerca (JavaScript + API wiki).

21. Inserimento del blocco Gutenberg/shortcode in WordPress.

22. Test funzionale e collaudo con il gruppo.

23. Rilascio pubblico e monitoraggio.

11. Evoluzione futura: Single Sign-On (Livello 4)

Qualora il progetto crescesse e richiedesse una gestione unificata degli account utente (es. redattori che modificano sia il blog sia il wiki con un unico login), si può implementare il Single Sign-On tramite:

• OAuth 2.0 + Extension:OAuth (MediaWiki): permette agli utenti WordPress di autenticarsi nel wiki tramite il loro account WP. Richiede un plugin WordPress OAuth Server e la configurazione dell’estensione nel wiki.

• Keycloak (Identity Provider centralizzato): soluzione più robusta per ambienti multi-applicazione. Richiede un server dedicato e competenze di amministrazione avanzate.

Nota: Il Livello 4 è consigliato solo in una fase successiva, una volta che il sistema base (livelli 1–3) sia stabile e collaudato.

Documento redatto il 13/03/2026 — Rev. 1.0 — Soggetto a revisione.

========================================