Implementación de actualizaciones de contenido del servidor provisional en el servidor activo

Estamos tratando de implementar actualizaciones de contenido de nuestro servidor provisional en nuestro servidor en vivo, pero estamos teniendo dificultades para encontrar una buena manera de hacerlo. Necesitamos poder desplegar nuevas páginas, actualizaciones de página y ocasionalmente eliminaciones de página. Nuestro sitio también hace un uso extensivo del módulo de libro, por lo que el módulo de implementación no funciona para nosotros en este momento. Estamos utilizando funciones para actualizaciones de grandes estructuras. Entonces, nuestra preocupación son solo las actualizaciones diarias de contenido.

¿Hay algún módulo que pueda hacer esto y manejar páginas de libros?

Las funciones UUID y UUID le permiten exportar un nodo a una función, que podría ser justo lo que busca, lo que significa que no necesita meterse con la base de datos.

¿Has probado node_export y Backup Migrate ? Ambos módulos se utilizan para migrar contenido entre instalaciones de Drupal. Aquí hay una comparación entre los módulos de importación / exportación de datos que pueden resultarle útiles.

Estoy asumiendo Drupal 6 aquí, y no sé personalmente si funcionará con el módulo de libro, pero ¿ha investigado la implementación ?

También puedes probar Phing , con el que puedes automáticamente:

• Volcar la base de datos provisional usando mysqldump.
• Copie el archivo mysqldump de un servidor a otro utilizando SCP y el cifrado de clave pública-privada.
• Importe el mysqldump del sistema de archivos a la base de datos.
• Ejecute el comando Feature Revert All ( drush fra -y) para que su servidor de producción elija la configuración de producción (como bloques, vistas, contextos, etc.) que se encuentra en su código de características.

Problemas que veo con este enfoque:

Tendrá que hacer una exportación de base de datos muy fina, esto significa tomar solo tablas de nodo, nodo_revisiones, cck y menú.

En ese último punto (enlaces de menú), a menos que acceda tanto a su servidor de escenario como a su prod utilizando los mismos alias de URL, tendrá diferentes entradas de elementos de menú, y esto será un problema grave.

De hecho, me gusta el método de volcado de DB completo, que puede ser programado y, a menudo, puede completarse en solo unos segundos. (Mantener sus revisiones bajo control y excluir las tablas de caché, etc. puede reducir mucho el tamaño). Incluso podría crear un módulo simple para proporcionar una interfaz para que los editores de contenido activen este proceso.

Debe tener en cuenta cualquier contenido que pueda aceptar de los usuarios de su sitio en vivo, como comentarios o envíos de formularios de contacto. Si hay alguno, sorprendentemente a menudo no lo hay, puede usar un servicio externo, como Disqus para comentarios o Marketo para formularios de generación de leads, segregar cuidadosamente dichos envíos en una base de datos de Drupal separada que no se sobrescribe, o cuidadosamente no sobrescribirlos tablas afectadas durante el proceso de exportación / importación.

Donde se puede hacer que funcione, puede terminar siendo el método más simple, rápido y confiable. Y un sitio que nunca acepta aportes de los usuarios (que no sean servicios externos) abre muchas puertas para hacerse mucho más rápido y seguro.