¿Cómo actualizar Wordpress y los complementos al implementar con Capistrano?

Question

Espero que alguien pueda confirmar si el siguiente escenario es un problema con la implementación de actualizaciones en sitios de WordPress y, de ser así, ¿tiene alguna solución sobre cómo gestionarlo mejor?

Los fundamentos:

• que tienen un proyecto de desarrollo local de WordPress para varios sitios para los cuales yo utilizo GIT y Capistrano para desplegar la estadificación a distancia y la producción servidores.
• Todo, EXCEPTO las cargas y los directorios de blogs.dir (en wp-content) están bajo control de versión. Sí, el núcleo de WordPress, temas, complementos, etc. se actualizan localmente, se comprometen, se implementan y se implementa . Esto significa que tengo que iniciar sesión y activar plugins inicialmente - que simplemente se instalan a través de la implementación de Capistrano
• Las bases de datos sobre el desarrollo, puesta en escena y la producción son diferentes y No estoy preocupado por tratar de sincronizar estos hasta

mi preocupación:

Muchos cambios a plugins y núcleo de WordPress también realizan cambios a la base de datos cuando se realiza una actualización automática a través de la administración. Estoy actualizando el núcleo y los complementos de WordPress localmente en mi instalación de desarrollo. El código de estas actualizaciones termina siendo comprometido, empujado e implementado. Sin embargo, cuando se implementa el código, simplemente se agrega/elimina/reemplaza los archivos modificados a los servidores de transición y producción. A la producción y la puesta en escena les falta alguna de las actualizaciones de la base de datos, ya que generalmente es parte del proceso de actualización automática, por ejemplo, desactivar, actualizar, activar (ejecutar cualquier actualización en la base de datos).

Mis preguntas:

1. Es mi preocupación por los servidores de producción y puesta en escena que tiene la última versión del código pero faltan las actualizaciones de bases de datos necesarias para el último código precisa?
2. Si es así, ¿alguien tiene alguna idea sobre cómo puedo modificar el código de implementación de Capistrano para desactivar/reactivar los complementos? ¿Qué pasa con los cambios en WordPress, por ejemplo, 3.2 a 3.3?
3. Si Capistrano no es la herramienta para esto - y tengo que hacerlo más a "manualmente" por la tala en el administrador - ¿existe un modo de mantenimiento herramienta/plugin que algo va a automatizar la desactivación/activación del complementos para que se activen las actualizaciones luego de la activación?

Muchas gracias,

Matt

Answer 1

Es importante tener en cuenta que no es necesario para activar y desactivar los plugins cuando actualizar el núcleo de WordPress de una versión a otra. Here is an explanation from Ryan Boren on why. Sin embargo, dependiendo del plugin, algunos de ellos pueden tener un proceso de actualización integrado en su actualización, es decir, la actualización del complemento, no de WordPress. No obstante, revisaré sus tres preguntas y las responderé tan directamente como pueda.

1.¿Me preocupa que los servidores de producción y almacenamiento cuenten con el código más reciente pero no tengan las actualizaciones de base de datos necesarias para que el último código sea exacto?

Sí, al actualizar, si hay un cambio en el esquema de la base de datos, WordPress no funcionará correctamente a menos que exista el nuevo esquema. Al intentar acceder al lado de administración de WordPress, si la versión de db es inferior a lo que espera su versión de WordPress, lo redirigirá a una página de actualización de la base de datos.

WordPress establece un global llamada $wp_db_version en el archivo /wp-includes/version.php y mantiene cada uno de los scripts de migración para actualizar la base de datos de forma incremental cada versiones anteriores a la siguiente hasta que el número de versión es hasta la fecha, seen here. Aquí hay una lista más simple en las preguntas frecuentes que muestra cómo los números de revisión se correlacionan con WordPress versions..

2. Si es así, ¿alguien tiene alguna idea sobre cómo puedo modificar el código de implementación de Capistrano para desactivar/reactivar los complementos?

Como he dicho anteriormente, no es necesario activar/desactivar plugins después de las actualizaciones principales, a menos que suponga que el plugin específicamente requiere que lo haga. Si el esquema cambia en WordPress rompe un complemento, entonces los desarrolladores del complemento necesitarán lanzar una nueva versión. Al actualizar ese complemento, se apagará y se reiniciará, y es responsabilidad de esos desarrolladores asegurarse de que todo lo que deba llevarse a cabo lo haga.

Sin embargo, es posible que necesite desactivar/activar por separado en entornos implementados como el suyo, ya que el proceso de actualización real se lleva a cabo en una máquina diferente y probablemente una base de datos diferente de la que finalmente se utilizará.

Quizás lo mejor que se puede hacer es que su script de implementación llegue a un URI de un plugin dentro de WordPress, un plugin que debería desactivar/activar plugins, o uno existente que ya lo hace.

Es posible que algunos complementos salientes manejen partes de lo que usted busca, pero considero que el componente clave de su pregunta es la automatización, y evitar tener que iniciar sesión en cada entorno y actualizar los complementos para cada uno, desarrollando uno que hace exactamente lo que necesita puede ser el camino a seguir. Desarrollar un complemento es posible si utiliza las herramientas que WordPress ya proporciona.

• activate_plugin()
• activate_plugins()
• deactivate_plugins()
• validate_plugin()
• Plugin_Upgrader class (tal vez)

Mire a través de todo el archivo /wp-admin/includes/plugin.php a ver qué le puede resultar útil. Además, el código de pago que realmente maneja los complementos en el lado de administración en /wp-admin/plugins.php - solo para ver cómo se hace. Es posible que desee evitar que los ganchos deactivate_plugin eliminen la configuración del complemento con complementos que se limpian después de ellos, así que considere pasar $silent como true al desactivar el complemento.

Para hacer esto realmente pulido, es probable que desee para agarrar get_option('active_plugins') para ver los plugins que ya se activaron, y sólo ejecutar el script en los (asegúrese de que el plugin se excluye del proceso)

3. ¿Qué pasa con los cambios en WordPress, por ejemplo, 3.2 a 3.3?

Los cambios de 3.2 a 3.3 deben considerarse como diferentes de cualquier otro conjunto de cambios, por lo que se aplica todo lo que se indica aquí.

4. Si Capistrano no es la herramienta para esto, y tengo que hacerlo de forma más "manual" iniciando sesión en el administrador, ¿existe alguna herramienta/complemento de modo de mantenimiento que automatice la desactivación/activación de los complementos para que se desencadenen las actualizaciones luego de la activación?

No creo que Capistrano haga nada pesado aquí, pero tampoco está en el camino. Debería solo poder acceder a un URI dentro del complemento, y eso debería hacer que las cosas funcionen dentro de la aplicación. Lo importante es que, obviamente, todas esas funciones deben estar disponibles, por lo que no se puede ejecutar como en un script independiente.