Cómo agilizar las migraciones multisitio de WordPress con MU-Migration

Publicado: 2022-03-10
Resumen rápido ↬ Presentamos la herramienta MU-Migration, un comando WP-CLI que ayuda a los desarrolladores a migrar sitios hacia o entre instancias de sitios múltiples. Las migraciones multisitio tienen varias complejidades técnicas y esta herramienta puede ayudar a aliviarlas.

Migrar un sitio de WordPress independiente a un entorno de red de sitio (o "multisitio") es una tarea tediosa y complicada; lo contrario también es cierto. El importador de WordPress funciona razonablemente bien para sitios más pequeños y simples, pero deja espacio para mejoras. Exporta contenido, pero no datos de configuración del sitio, como configuraciones de widgets y personalizados, complementos y configuraciones del sitio. El Importador también tiene dificultades para manejar una gran cantidad de contenido. En este artículo, aprenderá cómo optimizar este tipo de migración mediante el uso de MU-Migration, un complemento de WP-CLI.

Comprensión de multisitio

Un multisitio de WordPress le permite ejecutar varios sitios web dentro de la misma instalación de WordPress. A menudo se la conoce como "Red multisitio". WordPress.com es probablemente el mayor ejemplo de una red multisitio, que ejecuta miles de sitios dentro de la misma instancia de WordPress.

Un multisitio de WordPress puede ser perfecto para varios casos de uso, algunos de ellos incluyen:

  • Su cliente puede tener múltiples propiedades, y podría tener sentido consolidar todos sus sitios en una única instalación de WordPress, compartiendo un solo dominio, pero sin limitarse a él.

  • Una vez que lo haya configurado, es un proceso simple y directo para activar nuevos sitios y aprovechar los temas y complementos que ya están disponibles en la red.

Una comprensión profunda de cómo funciona el multisitio está más allá del alcance de este artículo, pero puede consultar los siguientes enlaces:

  • "Crear una red", Codex, WordPress.org

  • “WordPress Multisite: Funciones y métodos prácticos”, Kevin Leary, Smashing Magazine

¡Más después del salto! Continúe leyendo a continuación ↓

Comprender los desafíos

Las diferencias entre la estructura de un solo sitio y un multisitio de WordPress son bastante razonables. Con multisitio, cada subsitio obtiene su propio conjunto de tablas de base de datos, con la excepción de la tabla del usuario ( wp_user ) que se comparte en todos los sitios. La forma en que esto funciona en WordPress es que cada conjunto de tablas de subsitio tiene la ID del sitio agregada a cada nombre de tabla ( wp_X_posts , wp_X_postmeta , wp_X_options ).

Esta estructura de base de datos en sí ya presenta algunas complejidades. Por ejemplo, ¿cómo migraría un subsitio de varios sitios a una sola instalación? Obviamente, no puede simplemente exportar e importar la base de datos en la instalación única: ¡los nombres de las tablas son diferentes! Deberá cambiar el nombre de las tablas en el archivo .sql exportado o usar una consulta ALTER TABLE SQL para cambiar el nombre de las tablas después de importarlas. Lo mismo es cierto para la forma opuesta: si está importando un solo sitio en varios sitios, los prefijos de la tabla también deberán actualizarse. Suena como demasiado trabajo, ¿verdad?

La tabla del usuario en multisitio es global, lo que significa que no puede simplemente importar la tabla del usuario desde su sitio único, ya que anularía por completo la tabla del usuario global multisitio. Si está haciendo lo contrario, extrayendo un subsitio de WordPress e importándolo a un solo sitio, transferiría a todos los usuarios de la red, incluso a aquellos que no pertenecen al subsitio que se está migrando. Además, si se migra un subsitio de un multisitio a otro, la exportación de la tabla del usuario está completamente descartada.

La mejor solución es exportar los usuarios por separado, pero presenta otro problema: cuando los usuarios se importan, obtendrán ID diferentes. Para resolver este problema, es necesario realizar un seguimiento de las ID de los nuevos usuarios, crear una tabla de mapeo y usar la tabla de mapeo para actualizar todas las referencias a las ID de los usuarios en WordPress. De nuevo, demasiado trabajo, ¿verdad?

Estos son solo dos ejemplos de los desafíos que uno puede enfrentar cuando se trata de migraciones como esta. Hay un montón de otras cosas menores que también deben tenerse en cuenta, como mover la carpeta de cargas a la ubicación adecuada, migrar los registros en la base de datos que hacen referencia al ID del sitio, etc.

Conoce MU-Migración

MU-Migration es un complemento de WP-CLI que creé mientras trabajaba en varias migraciones de clientes y luego fue abierto por 10up. Fue concebido para agilizar el proceso de mover sitios de un solo sitio de WordPress a una instancia de varios sitios (o viceversa). Básicamente, exporta todo a un paquete ZIP que luego se puede usar para importar el sitio en la instalación deseada de WordPress.

Funciona exportando el contenido del sitio y, opcionalmente, el tema, los complementos y las carpetas de carga en un paquete zip que se puede importar fácilmente a otra instalación de WordPress. Al utilizar MU-Migration, no necesita preocuparse por los detalles técnicos subyacentes de la migración. Simplemente se encargará de todo eso por usted para que pueda concentrarse en lo que es importante: entregar una migración exitosa a sus clientes.

Instalación de WP-CLI y MU-Migration

Para usar MU-Migration, primero debe instalar WP-CLI, la herramienta de línea de comandos oficial de WordPress. Instalar WP-CLI es tan simple como ejecutar los siguientes comandos en su servidor:

 $ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar $ chmod +x wp-cli.phar $ sudo mv wp-cli.phar /usr/local/bin/wp

Después de ejecutar estos pasos, podrá ejecutar WP-CLI escribiendo solo wp desde cualquier instalación de WordPress, siempre que esté dentro del directorio raíz de WordPress.

Por ejemplo, en su carpeta de instalación de WordPress, intente ejecutar el siguiente comando:

 $ wp theme status

Es un comando simple y mostrará una lista de todos los temas disponibles, destacando cuál está actualmente activo.

Por último, para instalar MU-Migration, puede aprovechar el comando package install . Utilice el siguiente comando para descargar e instalar MU-Migration como complemento de WP-CLI.

 $ wp package install 10up/mu-migration

Ejecutar una migración simple

El uso de MU-Migration es bastante simple. Para nuestro primer escenario, vamos a mover un solo sitio de WordPress a una instalación multisitio de WordPress.

Exportando el sitio único

Comenzaremos exportando el sitio único. Para hacerlo, necesitamos usar el comando exportar todo :

 $ wp mu-migration export all single-site.zip --themes --plugins --uploads

El comando anterior exportará todo el sitio a un paquete ZIP, las banderas --themes , --plugins y --uploads son opcionales e incluirán el tema actual, todos los complementos y la carpeta de cargas, respectivamente, en la exportación. Según el tamaño de su sitio, puede llevar algún tiempo finalizar el proceso, pero para la mayoría de los sitios, el proceso de exportación no debería llevar más de un par de minutos.

Una vez que termine, creará un archivo llamado single-site.zip que contiene todos los datos, temas y complementos del sitio, así como el directorio de carga. El siguiente paso es moverlo al servidor donde vive el multisitio de WordPress. Puede usar su cliente SFTP preferido o una solución más robusta como rsync .

Importación del sitio único en multisitio

Con el archivo exportado en su servidor multisitio, todo lo que necesita hacer es usar el comando de importación desde el directorio multisitio de WordPress; no hace falta decir que tanto WP-CLI como MU-Migration también deben instalarse en el servidor de destino.

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site

El comando anterior tomará el archivo single-site.zip , lo extraerá e importará todo a multisitio. Creará un nuevo subsitio en su red. El parámetro --new_url es opcional; le indicará a MU-Migration que realice una búsqueda y reemplace para reemplazar todas las apariciones de la URL del sitio del sitio exportado con la especificada. Este parámetro es útil cuando la migración incluye un cambio de URL o si está importando localmente, o incluso en un entorno de prueba.

El proceso de importación suele llevar más tiempo y depende del tamaño del sitio que estés importando, pero no temas, MU-Migration te mantendrá actualizado mientras se ejecuta la migración. Cuando finalice el proceso, MU-Migration le informará la URL final de su sitio importado. Se recomienda encarecidamente vaciar todas las capas de caché que se ejecutan en su servidor, especialmente Memcache o Redis.

Volver a ejecutar una migración

Al realizar migraciones, es bastante común realizar primero una prueba con el fin de probar las cosas antes de ejecutar la migración final, lo que generalmente significa realizar otra exportación y volver a importar en la instalación multisitio de destino. Sin embargo, tenga en cuenta que en nuestro primer ejemplo de migración, MU-Migration creó un nuevo subsitio dentro de la red para importar el sitio único encima. Ejecutar exactamente el mismo comando nuevamente conduciría a la creación de otro subsitio, que no es exactamente lo que esperaríamos.

Afortunadamente, es posible especificar un blog_id , que le indica a MU-Migration que anule el subsitio con el blog_id especificado. Por ejemplo, supongamos que el comando de importación anterior creó un subsitio con 2 como ID y desea volver a ejecutar la migración. Podrías hacer lo siguiente:

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site --blog_id=2

Si no conoce el blog_id , puede obtenerlo a través de la Configuración de administración de red o ejecutando $ wp site list .

Extracción de un subsitio de una instalación multisitio

MU-Migration también admite la extracción de subsitios de instalaciones multisitio y su importación en otro multisitio o en un único sitio.

Para estos dos escenarios, ejecutaríamos el comando de exportación desde una instalación multisitio y no desde un solo sitio; esto significa que necesitamos una forma de especificar qué subsitio queremos exportar. Para hacer eso, solo necesitamos pasar el parámetro --blog_id al comando de exportación:

 $ wp mu-migration export all subsite-3.zip --themes --plugins --uploads --blog_id=3

En este ejemplo, estamos exportando un subsitio con ID igual a 3; esto creará un archivo ZIP que está listo para ser importado a otro multisitio o en un solo sitio. El comando para importar en un sitio único y multisitio es exactamente el mismo, MU-Migration detectará si se está ejecutando en multisitio o no y se ajustará a eso automáticamente. Como nota al margen, al importar a otra instancia de varios sitios, también puede especificar el parámetro --blog_id para anular un subsitio existente.

 $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ]

Sugerencias para ejecutar grandes migraciones

Si bien los ejemplos anteriores funcionan muy bien para migraciones de tamaño pequeño a mediano, la migración de sitios grandes hacia o desde sitios múltiples puede llevar una cantidad de tiempo razonable. En esta sección, compartiré algunas lecciones aprendidas al realizar varias migraciones de tipo empresarial.

Crear un plan de migración

Las migraciones de datos a menudo son necesarias, pero son una parte descuidada de muchos proyectos. Las migraciones pueden ser engorrosas y complejas, pero cuando se planifican adecuadamente, pueden ser sencillas. La creación de un plan de migración debe ser el primer paso de cualquier proyecto de migración.

Un plan de migración típico incluye cosas como:

  • El impacto de la migración en cualquier proceso editorial de producción (es decir, congelaciones de contenido, requisitos de migración diferenciales).

  • ¿Cuánto tiempo se espera que se ejecute la migración?

  • ¿Cómo se restaurarán las copias de seguridad? ¿Cómo se manejará una migración fallida?

  • ¿Cómo afectará el proceso de exportación al rendimiento del sitio? Muchos sitios no pueden permitirse exportar una base de datos durante las horas pico.

Como regla general, las migraciones deben ser lo más fluidas posible e, idealmente, el día del lanzamiento, todo el trabajo pesado ya se habría completado y solo se deberían realizar los pasos estrictamente necesarios. Esto significa que debe migrar todo lo que pueda antes de la fecha de lanzamiento real, ya que le dará espacio para corregir errores y realizar el control de calidad. Si se trata de una nueva creación de sitio y está migrando datos, a menudo puede beneficiarse de una ventana de congelación de contenido y mover su contenido con anticipación. También puedes usar estrategias para mover progresivamente tu contenido si es posible. Consulte la siguiente sección para ver un ejemplo de esta técnica.

Aunque se descuide muchas veces, un plan de migración adecuado puede evitar una amplia variedad de problemas en una migración. No permita que circunstancias inesperadas hagan que su migración falle, ¡planifique con anticipación! Para una discusión más profunda sobre la planificación de una migración, lo animo a consultar la sección de migración de las mejores prácticas de 10up.

Use Rsync para copiar progresivamente las cargas

La carpeta de carga de sitios grandes puede ser extremadamente grande, y comprimirla en un archivo ZIP para su posterior extracción no siempre es la mejor y más rápida solución. Hay varias otras formas de copiar la carpeta de cargas en el servidor de destino. Una herramienta de uso común para la migración de tipo empresarial es rsync , que puede transferir archivos entre servidores más rápido que usar una solución SFTP estándar y, como ventaja adicional, puede pausar y restaurar transferencias. Realiza un seguimiento de lo que ya se ha transferido, lo que significa que podemos sincronizar progresivamente nuestros archivos. Por ejemplo, puede comenzar a sincronizar los archivos un par de días antes de la migración real para ganar algo de tiempo. Luego, el día de la migración, todo lo que necesita hacer es sincronizar los archivos para asegurarse de que todo lo que se agregó desde la última sincronización se transfiera al servidor de destino.

La única advertencia de este enfoque es que deberá mover manualmente los subdirectorios de cargas al lugar correcto, ya que multisitio tiene una estructura ligeramente diferente para la carpeta de cargas: cada sitio tiene su propia subcarpeta donde su nombre es la ID del sitio. .

Como ejemplo final, veamos cómo podríamos migrar un solo sitio grande a una instancia de varios sitios. Comenzaremos exportando el sitio único a un paquete ZIP y ejecutando una prueba de funcionamiento en seco en el servidor de destino. En ese momento, nadie podrá acceder al sitio, ya que el dominio todavía apunta al servidor anterior, lo que significa que puede apuntar con seguridad el archivo de su host al nuevo servidor para probar la migración. También puede habilitar un complemento como Restringir el acceso al sitio en el sitio de destino para asegurarse de que no sea accesible públicamente de ninguna manera.

Para nuestra prueba de ejecución, exportaríamos el sitio unos días o semanas antes de la fecha de migración planificada para probar y tener una idea de cuánto tiempo llevará el proceso. Tenga en cuenta que la carpeta de cargas no está incluida.

Haz una prueba primero

Siempre haga una prueba en seco primero. Idealmente, una ejecución en seco debería ocurrir en el servidor real o en un entorno de prueba con una pila de servidor similar.

Considere usar el --mysql-single-transaction

El comando de importación también admite un --mysql-single-transaction que envolverá la exportación de SQL en una sola transacción para confirmar todos los cambios de la importación a la vez, evitando que la escritura abrume el servidor de la base de datos, especialmente en entornos MySQL agrupados.

 $ cd /path/to/wordpress $ wp mu-migration export all site.zip --themes --plugins

Con rsync , podemos transferir fácilmente el archivo exportado generado:

 $ rsync -aP site.zip [email protected]:/var/www/multisite/

Luego ejecutamos el comando de importación en el servidor de destino:

 $ ssh [email protected] $ cd /var/www/multisite $ wp mu-migration import all site.zip

Ahora necesitamos saber cuál es el blog_id del subsitio recién creado; podemos obtener esa información ejecutando:

$ wp lista de sitios
blog_id URL última actualización registrado
1 https://multisitio.com/ 2017-09-09 20:59:31 2016-11-23 21:59:34
2 https://siglesite.com/ 2017-06-21 18:30:09 2017-04-25 13:07:46

Del resultado del comando anterior sabemos que nuestro sitio ha sido importado con el ID 2. Lo necesitaremos para mover correctamente la carpeta de cargas usando rsync . Desde el servidor de sitio único, ejecutaríamos lo siguiente:

 $ rsync -azP wp-content/uploads/ [email protected]:/var/www/multisite/wp-content/uploads/sites/2/

El comando anterior copiará toda la carpeta de cargas en el lugar correcto en una instalación multisitio, que se encuentra debajo de la carpeta de sitios y dentro de una carpeta donde su nombre es solo la ID del sitio (en este caso, 2). En este punto, ahora podemos editar el archivo del host para apuntar el dominio del sitio único al servidor multisitio; luego podemos hacer algunas pruebas para asegurarnos de que la migración funcionó como se esperaba.

Para la migración final, todo sería igual, con la excepción de que --blog_id=2 al comando de importación:

 $ wp mu-migration import all site.zip --blog_id=2

Y como beneficio, la sincronización de las cargas será mucho más rápida, ya que rsync solo transferirá los archivos que se hayan modificado o agregado desde la última sincronización.

Conclusión

La migración hacia o desde varios sitios es difícil y la herramienta presentada en este artículo simplifica todo el proceso de migración al reducir el esfuerzo a un par de comandos CLI. MU-Migration se ha utilizado activamente en producción durante más de un año y es un proyecto completamente de código abierto. ¡El complemento está desarrollado en Github y las solicitudes de extracción son bienvenidas!