Chiarire il compito e la decisione
Questa guida trasforma la guida all'implementazione di wordpress in un flusso di lavoro operativo rivedibile. Collega le decisioni di dominio, la proprietà, le prove e l'accettazione in modo che il risultato continui a funzionare in produzione.
Scegli deliberatamente il widget o la consegna API, mantieni la pagina originale canonica e pubblica le versioni linguistiche tramite revisioni.
Procedura pratica
- 1
Tipi di origini dell'inventario, identificatori, campi, impostazioni locali, proprietari e stati di pubblicazione.
- 2
Scegli il modello di distribuzione tra volume, latenza, controllo editoriale e tolleranza agli errori.
- 3
Mappare il record di origine su un record di versione in lingua separato con collegamento durevole.
- 4
Aggiungi autenticazione, idempotenza, nuovi tentativi, invalidazione della cache, registrazione e controlli di accesso.
- 5
Testare la pubblicazione, le modifiche all'origine, i risultati non disponibili, il rollback, il funzionamento della tastiera e il monitoraggio prima del rilascio.
Esempio o strumento
Un flusso di lavoro Gutenberg mappa le pagine di origine, gli stati di revisione, le chiavi della cache e la navigazione nella lingua. Nello strumento, registra anche la baseline, il proprietario, la decisione, le prove, il problema aperto e la data di approvazione. Utilizza una pagina o una transazione reale in modo che il team possa vedere le dipendenze, le eccezioni e il lavoro di manutenzione che segue il rilascio.
| Punto decisionale | Documentazione | Criterio di accettazione |
|---|---|---|
| Linea di base | Stato attuale osservato | Fonte e data registrate |
| Decisione | Opzione selezionata e motivazione | Rischio e pubblico considerati |
| Prova | Testare, documentare o misurare | Rivedibile e specifico della versione |
| Approvazione | Nome, ruolo e data | Tutti i criteri obbligatori sono soddisfatti |
Scegli widget, plug-in o consegna API lato server
Utilizza un widget quando la velocità di distribuzione è importante, le pagine di origine dispongono già di identificatori durevoli e una dipendenza lato client è accettabile. Utilizza un plug-in WordPress quando gli editor necessitano di generazione e revisione all'interno dell'interfaccia di amministrazione. Utilizza la consegna API lato server quando le versioni linguistiche devono essere indicizzate, memorizzate nella cache, incluse nei feed e visualizzate anche quando JavaScript non è disponibile. I grandi editori spesso combinano un plug-in per il flusso di lavoro con il rendering lato server per la consegna.
Documentare la scelta rispetto al controllo editoriale, alle prestazioni, all'accessibilità, alla ricerca, al comportamento in caso di fallimento, al flusso di dati e alla proprietà di manutenzione. La pagina originale rimane la fonte autorevole. Una versione in lingua ottiene il proprio post o record strutturato, URL stabile, stato di revisione e collegamento alla revisione della fonte. Evitare di archiviare contenuto alternativo solo in un campo personalizzato senza versione o nella cache del browser perché i revisori non possono approvarlo, ripristinarlo o controllarlo in modo affidabile.
| Modello | La migliore vestibilità | Controllo primario |
|---|---|---|
| widget | Aggiunta rapida a un sito controllato | Fallback accessibile e stato di errore |
| Flusso di lavoro del plug-in | Gli editor lavorano interamente in WordPress | Ruoli, nonce, capacità e revisioni |
| API lato server | Pagine indicizzate, memorizzabili nella cache e resilienti | Operazioni di coda, invalidamento della cache e distribuzione |
Relazioni di origine del modello e stati editoriali
Crea un tipo di post con versione in lingua o utilizza una struttura multilingue che supporti relazioni di origine esplicite. Memorizza l'ID post di origine, l'ID di revisione dell'origine, le impostazioni locali di destinazione, la modalità lingua, l'ID risultato, la versione del glossario, lo stato della revisione, gli approvatori, la revisione pubblicata e l'attivatore della revisione. Mantieni la struttura del blocco trasformata, ove possibile, in modo che intestazioni, elenchi, collegamenti, tabelle e avvisi rimangano semantici anziché essere appiattiti in un unico campo HTML.
Definire gli stati per richiesto, in generazione, bozza, revisione dell'oggetto, revisione della lingua, approvato, pubblicato, obsoleto e non riuscito. Mappa ogni transizione su una funzionalità WordPress, non semplicemente su un pulsante visibile. Un generatore può creare una bozza ma non può approvarla. Quando la fonte cambia, confronta la sua revisione con la revisione della fonte approvata e sposta la versione linguistica su obsoleta o su revisione richiesta. Non pubblicare silenziosamente un risultato rigenerato.
- 1
Registra il record della versione linguistica e i metadati richiesti con autorizzazioni di sanificazione e REST.
- 2
Mappa i blocchi Gutenberg supportati e definisce il comportamento per i blocchi non supportati.
- 3
Configura i ruoli e le transizioni di stato consentite.
- 4
Generare in una revisione separata e presentare un confronto tra le fonti.
- 5
Pubblicare solo dopo le approvazioni richieste per il livello di rischio del contenuto.
Testare il percorso completo di pubblicazione e ripristino
Utilizza una copia temporanea con blocchi Gutenberg rappresentativi, campi personalizzati, moduli incorporati, blocchi riutilizzabili e post con restrizioni. Generazione di test, applicazione dei ruoli, commenti di revisione, pubblicazione pianificata, anteprima, invalidazione della cache, aggiornamento dell'origine, contrassegno non aggiornato, eliminazione, ripristino e rollback. Confermare che gli endpoint REST rifiutino letture e scritture non autorizzate e che i processi in background non possano essere attivati tra siti senza credenziali nonce o server valide.
Prima della produzione, definire il monitoraggio delle code, la proprietà degli errori, la rotazione delle credenziali, il test degli aggiornamenti dei plug-in, il backup del database e una procedura di disabilitazione sicura. L'accettazione richiede un rendering corretto nei punti di interruzione comuni, navigazione tramite tastiera e lettore di schermo, nessun cambiamento di layout rispetto ai contenuti recenti, intestazioni strutturate valide, approvazione tracciabile e ripristino dell'ultima revisione approvata. Registra le configurazioni WordPress, PHP, editor, plug-in multilingue e memorizzazione nella cache supportate.
Ruoli, prove e approvazione
Mantenere la generazione separata dalla pubblicazione. Una risposta efficace è una bozza, non un'approvazione. Archiviare l'identificatore e la versione dell'origine, le impostazioni di trasformazione, l'identificatore del risultato, lo stato della revisione, l'approvatore e l'ora di pubblicazione. Quando la fonte cambia, contrassegna la versione linguistica per la revisione invece di sostituire silenziosamente il contenuto approvato. Ciò rende possibile il rollback e il controllo su tutte le piattaforme.
Operazioni e manutenzione
Il lavoro non termina con la pubblicazione. Collega la versione o la configurazione linguistica alla sua fonte, monitora la qualità e le misure del servizio e definisce criteri concreti di revisione. I fattori scatenanti includono modifiche alla fonte, modifiche legali, nuove esigenze del pubblico, domande di supporto ricorrenti, modifiche tecniche e incidenti. Un proprietario nominato valuta il trigger, apre una nuova revisione quando necessario e registra la rinnovata approvazione.
Lista di controllo per la pubblicazione
L'integrazione utilizza identificatori di origine durevoli.
Le credenziali vengono archiviate lato server e ruotate.
Vengono definiti il comportamento di timeout, nuovi tentativi e limite di velocità.
Le richieste ripetute sono idempotenti.
Il contenuto generato entra in uno stato di revisione.
Le modifiche all'origine invalidano o riapriranno la versione.
La navigazione linguistica funziona tramite tastiera e tecnologia assistiva.
Il monitoraggio copre errori, code, latenza e contenuto non aggiornato.