Distribuzione degli aggiornamenti del contenuto dal server di gestione temporanea al server live

Stiamo provando a distribuire gli aggiornamenti dei contenuti dal nostro server di gestione temporanea sul nostro server live ma abbiamo difficoltà a trovare un buon modo per farlo. Dobbiamo essere in grado di distribuire nuove pagine, aggiornamenti di pagine ed eliminazioni di pagine occasionali. Il nostro sito fa inoltre ampio uso del modulo libro, quindi il modulo Distribuisci non funziona per noi in questo momento. Stiamo utilizzando le funzionalità per gli aggiornamenti di grandi strutture. Quindi, la nostra preoccupazione sono solo gli aggiornamenti quotidiani dei contenuti.

Ci sono dei moduli che possono farlo e gestire le pagine dei libri?

Le funzionalità UUID e UUID ti consentono di esportare un nodo in una funzione, che potrebbe essere proprio quello che stai cercando, significa che non è necessario pasticciare con il database.

Hai provato node_export e Backup Migrate . Entrambi i moduli vengono utilizzati per la migrazione dei contenuti tra le installazioni di Drupal. Ecco un confronto tra i moduli di importazione / esportazione dei dati che potresti trovare utili.

Sto assumendo Drupal 6 qui, e personalmente non so se funzionerà con il modulo del libro, ma hai esaminato Deployment ?

Puoi anche provare Phing , con il quale puoi automaticamente:

• Dump del database di gestione temporanea utilizzando mysqldump.
• Copia il file mysqldump da un server all'altro utilizzando la crittografia SCP e chiave pubblica-privata.
• Importare mysqldump dal filesystem nel database.
• Esegui il comando Ripristina funzionalità tutto ( drush fra -y) in modo che il tuo server di produzione raccolga le impostazioni di produzione (come blocchi, viste, contesti, ecc.) Presenti nel codice delle caratteristiche.

Problemi che vedo con questo approccio:

Dovrai eseguire un'esportazione di database a grana molto fine, questo significa prendere solo le tabelle node, node_revisions, cck e menu.

In quest'ultimo punto (collegamenti ai menu), a meno che non si acceda allo stage e al prod server utilizzando gli stessi alias URL, si avranno voci di voci di menu diverse e questo sarà un problema serio.

In realtà mi piace il metodo di dump completo del DB, che potrebbe essere copiato da script e spesso può essere completato in pochi secondi. (Mantenere le revisioni sotto controllo ed escludere tabelle di cache ecc. Può ridurne notevolmente le dimensioni.) È anche possibile creare un modulo semplice per fornire un'interfaccia per gli editori di contenuti per attivare questo processo.

Devi tenere conto di tutti i contenuti che potresti accettare dagli utenti del tuo sito live, come commenti o invii di moduli di contatto. Se ce ne sono - sorprendentemente spesso non ce ne sono - potresti usare un servizio esterno, come Disqus per commenti o Marketo per moduli di generazione di lead, separare attentamente tali invii in un database Drupal separato che non viene sovrascritto o attentamente non sovrascrivere quelli tabelle interessate durante il processo di esportazione / importazione.

Dove può essere fatto funzionare, può finire per essere il metodo più semplice, veloce e affidabile. E un sito che non accetta mai input da parte degli utenti (oltre ai servizi esterni) apre molte porte per essere reso molto più veloce e più sicuro.