Déploiement des mises à jour de contenu du serveur de transfert vers le serveur en direct

Nous essayons de déployer des mises à jour de contenu de notre serveur de transfert vers notre serveur en direct, mais nous avons du mal à trouver un bon moyen de le faire. Nous devons être en mesure de déployer de nouvelles pages, des mises à jour de pages et parfois des suppressions de pages. Notre site utilise également largement le module livre, de sorte que le module Déployer ne fonctionne pas pour nous pour le moment. Nous utilisons des fonctionnalités pour les mises à jour de grandes structures. Donc, notre préoccupation est simplement les mises à jour quotidiennes du contenu.

Y a-t-il des modules qui peuvent faire cela et gérer les pages de livre?

Les fonctionnalités UUID et UUID vous permettent d'exporter un nœud vers une fonctionnalité, ce qui pourrait être exactement ce que vous recherchez, ce qui signifie qu'il n'est pas nécessaire de jouer avec la base de données.

Avez-vous essayé node_export et Backup Migrate . Les deux modules sont utilisés pour migrer le contenu entre les installations Drupal. Voici une comparaison entre les modules d'importation / exportation de données que vous pourriez trouver utiles.

Je suppose que Drupal 6 est ici, et je ne sais pas personnellement si cela fonctionnera avec le module livre, mais avez-vous étudié le déploiement ?

Vous pouvez également essayer Phing , avec lequel vous pouvez automatiquement:

• Vider la base de données intermédiaire à l'aide de mysqldump.
• Copiez le fichier mysqldump d'un serveur à un autre à l'aide du cryptage SCP et de la clé publique-privée.
• Importez le mysqldump du système de fichiers dans la base de données.
• Exécutez la commande Feature Revert All ( drush fra -y) pour que votre serveur de production récupère les paramètres de production (tels que les blocs, les vues, les contextes, etc.) trouvés dans votre code de fonctionnalités.

Problèmes que je vois avec cette approche:

Vous devrez effectuer une exportation de base de données à grain très fin, ce qui signifie prendre uniquement les tables node, node_revisions, cck et menu.

Sur ce dernier point (liens de menu), à moins que vous n'accédiez à la fois à votre scène et à votre serveur de prod en utilisant les mêmes alias d'URL, vous aurez différentes entrées d'élément de menu, et ce sera un problème grave.

En fait, j'aime la méthode complète de vidage de base de données, qui peut être scriptée et peut souvent se terminer en quelques secondes. (Garder vos révisions sous contrôle et exclure les tables de cache, etc. peut réduire considérablement la taille.) Vous pouvez même créer un module simple pour fournir une interface aux éditeurs de contenu pour déclencher ce processus.

Vous devez tenir compte de tout contenu que vous pourriez accepter des utilisateurs de votre site en direct, comme les commentaires ou les soumissions de formulaire de contact. S'il y en a - étonnamment souvent il n'y en a pas - vous pouvez soit utiliser un service externe, comme Disqus pour les commentaires ou Marketo pour les formulaires de génération de leads, séparer soigneusement ces soumissions dans une base de données Drupal distincte qui n'est pas écrasée, ou soigneusement ne pas les écraser tables affectées pendant le processus d'exportation / importation.

Là où elle peut fonctionner, elle peut finir par être la méthode la plus simple, la plus rapide et la plus fiable. Et un site qui n'accepte jamais les commentaires des utilisateurs (sauf dans les services externes) ouvre de nombreuses portes pour être rendu beaucoup plus rapide et plus sûr.