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


8

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?


Penso che questo sia in qualche modo correlato a drupal.stackexchange.com/q/137/134 . Puoi dare un'occhiata alla risposta lì e vedere se aiuta, o chiarire la tua domanda sul perché è diverso.
Chaulky

Nessuna di queste risposte funziona per le pagine dei libri o per le cancellazioni. Entrambi sono molto importanti per noi. Inoltre, fare un dump completo di file e DB ogni volta sembra un grave sovraccarico.
antgiant

È possibile stabilire un blocco dei contenuti durante la produzione mentre si modifica il sistema di gestione temporanea?
BetaRide,

Risposte:


3

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.




0

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.


3
Sto cercando di rimanere con i moduli Drupal, se possibile. E, francamente, questa idea sembra un incidente di corruzione dei dati in attesa di accadere.
antgiant

0

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.