Cómo sincronizar un blog de WordPress local y remoto usando el control de versiones

¿Alguna vez te has preguntado cómo podrías usar el control de versiones con WordPress? Si prefieres trabajar en tus proyectos de WordPress de forma local pero debes conseguir que se sincronicen de forma remota, este tutorial es para ti. Probablemente habrás intentado sincronizar las dos configuraciones cargando manualmente los archivos modificados y usando PHPmyAdmin para exportar e importar tu base de datos una vez modificada, y (muy probablemente) hayas roto algo durante el proceso. En este tutorial, vamos a automatizar el proceso de sincronización; para que puedas concentrarte en lo que se supone que debes hacer en lugar de luchar con interminables migraciones.

El problema

Normalmente comenzamos el desarrollo de WordPress en nuestros equipos locales. Siempre es más rápido y fácil, especialmente cuando tienes una conexión a Internet lenta. Pero hay momentos en los que necesitas trabajar de forma remota. Es posible que desees hacer un pequeño cambio, corregir algún relleno o simplemente publicar una nueva entrada. Las modificaciones no se guardan en la instalación de WordPress de tu equipo local y ahí empieza el desorden.

El desorden empieza porque es posible que necesites lanzar una nueva versión y, dado que trabajas de forma local, los cambios que realizaste de forma remota deben trasladarse a la instalación local. Es un verdadero dolor de cabeza. Necesitas averiguar qué archivos has modificado y descargarlos vía FTP. A veces los cambios tienen lugar en la base de datos, por lo que necesitarás una herramienta especial como phpmyAdmin para traerlos.

En el proceso, puedes romper algo u olvidar una modificación. Ahí es cuando todo acaba desordenado. En este caso, necesitas dos cosas: control de versiones y sincronización. En este tutorial, voy a describir la solución que estoy siguiendo para organizar mi desarrollo y para crear una sincronización entre mi equipo local y mi servidor remoto.

Paso 1 configurar las bases

Explicación del plan

Primero, permítanme explicar lo que vamos a hacer. Nuestro objetivo es sincronizar fácilmente la versión remota y la local. Trabajarás en la versión que te plazca y luego las harás idénticas. Para ello, primero tenemos que tener en cuenta las diferencias entre la instalación remota y la configuración local.

WordPress almacena información sobre tu blog tanto en los archivos estáticos como en tu base de datos. Parte de esta información es relativa a tu alojamiento actual. Es por eso que cuando subas todo tu directorio de WordPress y reemplaces la versión remota, no funcionará.

La información se divide por desgracia en dos partes:

• Archivos estáticos: WordPress coloca la información del servidor de su base de datos en el archivo wp-config.php.
• Base de datos: WordPress coloca el sitio y la URL de la página de inicio en la tabla wp-options.

Para el archivo wp-config.php, implementaremos un proceso que detecta si estamos en el servidor local o remoto. De este modo, el mismo archivo funcionará en ambos entornos. Para la base de datos, la integraremos con el sistema de control de versiones y la actualizaremos para que coincida con la configuración del servidor local o remoto.

Integración del control de versiones

Yo utilizo Mercurial para el control de versiones. Git es más popular en el ámbito del desarrollo web, pero para nuestro caso son casi similares: Sólo necesitas una herramienta de control de versiones.

Selecciona Mercurial si estás en un equipo Windows. Tiene Tortoise, una interfaz fácil de usar, para administrar tus repositorios. La herramienta de control de versiones debe instalarse tanto en los equipos locales como en los remotos. Dicho esto, necesitarás un servidor dedicado o un VPS para poder instalar la aplicación de terceros.

Para inicializar un repositorio en Mercurial, escribe lo siguiente en la consola

1

2

cd /mydev_directory

3

hg init

4

hg add

5

hg commit

En la primera línea, cambiamos nuestro directorio de trabajo a la carpeta en la que queremos habilitar el control de versiones. Este será tu directorio de WordPress (donde vayas a instalar WordPress). La siguiente línea inicializa el repositorio. La tercera línea indica a Mercurial que controle la versión de todos los archivos del directorio. En esto también se incluirán las subcarpetas. La última línea crea un nuevo conjunto de cambios en el directorio; se abrirá tu editor de texto y se te pedirá que escribas una descripción para esta tarea.

Este tutorial no cubre cómo usar Mercurial. Si no conoces el control de versiones, entonces debes aprenderlo. Esa es una importante herramienta a añadir a tu conjunto de habilidades. Aquí hay algunos tutoriales que sugiero:

• Hginit: Definitivamente el mejor tutorial sobre Mercurial, hasta la fecha.
• Mercurial en Ubuntu: Este tutorial muestra cómo configurar Mercurial en Ubuntu. Es útil si ejecutas Ubuntu en tu VPS o servidor dedicado.

Paso 2 configurar tu blog local de WordPress

Crearemos una nueva instalación de WordPress en nuestro equipo local. Descarga la última versión de WordPress, extráela dentro de un directorio vacío de tu elección en tu servidor web, e instálalo desde tu navegador o cambiando el archivo wp-config.php.

Ahora vamos a activar el control de versiones en nuestro directorio de WordPress

1

2

cd /testpress

3

Hg init

4

Hg add

5

Hg commit

Estos comandos inicializan el repositorio y crean el primer conjunto de cambios. Ahora, simplemente podemos clonar este repositorio en nuestro servidor, instalar WordPress, y ser capaces de sincronizar de ida y vuelta entre la distribución local y remota.

Sin embargo, como dijimos anteriormente, hay diferencias. Antes de implementar el proceso de sincronización, necesitamos implementar un script que compruebe dónde se ejecuta la instalación de WordPress y cargue la configuración correcta.
La configuración que debe modificarse es la información de la base de datos. Se encuentra en el archivo wp-config.php y WordPress la carga desde este archivo. Mi versión local se ve así

1

2

// ** MySQL settings - You can get this info from your web host ** //

3

/** The name of the database for WordPress */

4

define('DB_NAME', 'test');

5

6

/** MySQL database username */

7

define('DB_USER', 'root');

8

9

/** MySQL database password */

10

define('DB_PASSWORD', 'xxxxx');

11

12

/** MySQL hostname */

13

define('DB_HOST', 'localhost');

14

15

/** Database Charset to use in creating database tables. */

16

define('DB_CHARSET', 'utf8');

17

18

/** The Database Collate type. Don't change this if in doubt. */

19

define('DB_COLLATE', '');

Ten en cuenta que sólo copié la parte que importa. En mi servidor remoto, esta parte debe diferir ligeramente

1

2

// ** MySQL settings - You can get this info from your web host ** //

3

/** The name of the database for WordPress */

4

define('DB_NAME', 'user_blog');

5

6

/** MySQL database username */

7

define('DB_USER', 'root');

8

9

/** MySQL database password */

10

define('DB_PASSWORD', 'xyxyx');

11

12

/** MySQL hostname */

13

define('DB_HOST', 'localhost');

14

15

/** Database Charset to use in creating database tables. */

16

define('DB_CHARSET', 'utf8');

17

18

/** The Database Collate type. Don't change this if in doubt. */

19

define('DB_COLLATE', '');

El truco consiste en escribir código que detecte dónde se encuentra WordPress. La variable a utilizar es la variable PHP _SERVER["HTTP_HOST"]. El código evalúa la variable y asigna la configuración de la base de datos.

1

2

/*

3

 * Unified variables

4

 */

5

$user_name = 'root';

6

$hostname = 'localhost';

7

$charset = 'UTF-8';

8

$collate = '';

9

/*

10

 * Check for the current environment

11

 */

12

if ($_SERVER["HTTP_HOST"] === 'onlineqrlab.com') {

13

  $db_name = 'user_wordpress';

14

  $password = 'xyxyxy';

15

} else if ($_SERVER["HTTP_HOST"] === 'localhost') {

16

  $db_name = 'test';

17

  $password = 'xxxxxx';

18

}

19

20

// ** MySQL settings - You can get this info from your web host ** //

21

/** The name of the database for WordPress */

22

define('DB_NAME', $db_name);

23

24

/** MySQL database username */

25

define('DB_USER', $user_name);

26

27

/** MySQL database password */

28

define('DB_PASSWORD', $password);

29

30

/** MySQL hostname */

31

define('DB_HOST', $hostname);

32

33

/** Database Charset to use in creating database tables. */

34

define('DB_CHARSET', $chartset);

35

36

/** The Database Collate type. Don't change this if in doubt. */

37

define('DB_COLLATE', $collate);

En el ejemplo anterior, solo tengo dos parámetros que han cambiado: El nombre de la base de datos y la contraseña. Puede que tengas más cambios que estos. Por ejemplo, si hospedas MySQL en un servidor externo, deberás cambiar el nombre del host de la configuración del servidor remoto. Es mejor que limites también el acceso del blog de WordPress a nivel de usuario con capacidades limitadas en lugar de usar el nivel de administrador.

Comprueba que tu versión local de WordPress funciona. Si lo hace, ¡entonces está medio hecho!

Paso 3 sincronizar los repositorios Mercurial

Configurar el repositorio del servidor remoto

Ahora puedes empezar a trabajar en tu instalación local de WordPress. Cada vez que realices una modificación importante, realiza una confirmación con Mercurial para realizar un seguimiento de los cambios. En el servidor remoto, suponiendo que tengas instalado Apache, crea una nueva carpeta donde cargarás tu repositorio de WordPress.

1

2

cd /apache

3

mkdir mywp_repo

4

cd mywp_repo

Ten en cuenta que estos comandos deben ejecutarse en el servidor remoto. También necesitarás acceso SSH y una línea de comandos. Para conectarme a mi servidor, estoy usando Putty en Windows.
Una vez que nuestro repositorio se inicialice, podemos empujar (subir) y extraer (descargar) conjuntos de cambios de otros repositorios para mantenerlo actualizado. Para que este proceso se realice, necesitarás o el servidor local o el remoto de manera que puedas publicar el repositorio para extraerlo o empujarlo.

Al servidor web Mercurial le faltan algunas características importantes como el control de acceso, la autenticación y SSL. Así que, usarlo en su servidor remoto no es seguro. Preferiblemente, deberás ejecutar el servidor web Mercurial localmente y extraer los cambios del servidor local al servidor remoto.
Para ejecutar el servidor Mercurial, escribe lo siguiente en el equipo local:

1

2

hg serve

Ahora deberías poder acceder a tu repositorio desde tu navegador. Escribe la dirección URL que se muestra en la línea de comandos. Por lo general, será localhost:8000. El repositorio también está disponible online. Puedes acceder a él desde cualquier ordenador conectado a Internet utilizando tudirecciónip:8000.

1

2

Hg pull  192.xxx.xxx.xxx:8000

3

Hg update

Pero yo no recomiendo este método porque no es seguro. Hay una manera fácil y segura de hacerlo. Es un repositorio intermedio alojado por un servicio de terceros. Estoy usando BitBucket. Tiene un servicio bueno y confiable y también ofrece seguimiento de errores y un wiki.

Regístrate y crea una cuenta en BitBucket. Ofrecen repositorios privados y públicos ilimitados con hasta 5 usuarios de forma gratuita. Crea un nuevo repositorio en BitBucket y deberías ser redirigido a esta página.

BitBucket tiene compatibilidad con HTTPS y SSH. Si tu repositorio es privado, como en mi caso, tendrás que autenticarte con tu nombre de usuario y contraseña para poder empujar y extraer del repositorio.
Después de crear el nuevo repositorio en BitBucket, ejecuta los siguientes comandos en el equipo local

1

2

hg push https://username@bitbucket.org/username/repository

Se te pedirá que proporciones tu contraseña y el repositorio se cargará en BitBucket. Después de cargar en BitBucket, clona el repositorio en el servidor remoto.

1

2

hg clone https://username@bitbucket.org/username/repository

3

hg update

La clonación descarga los archivos en un nuevo directorio (con el mismo nombre que el directorio del repositorio); puedes cambiar el nombre de este directorio. Esto hará que el primer paso en esta sección (donde creamos el directorio de configuración de WordPress) bastante obsoleto.

Piense en BitBucket como un intermediario entre tu ordenador y tu host remoto. Es posible tener tu propio servidor Mercurial seguro en tu servidor remoto, pero esto está fuera del alcance de este tutorial. La ventaja es la independencia de intermediarios. Esto permite insertar los cambios directamente en el servidor web.

Entonces, ¿cómo puede ser esto mejor que FTP?

1. No tienes que averiguar qué archivos han cambiado.
2. Es más conveniente y consume menos tiempo.
3. Mucho más rápido ya que Mercurial empuja sólo los archivos que han cambiado.

Instalar el blog del servidor remoto

¿Ya estás cansado? No te preocupes, ya casi hemos llegado. Después de extraer el repositorio ya sea de tu equipo local o de BitBucket, tendrás que ejecutar la instalación de WordPress de nuevo; esta vez en el sitio del servidor remoto. Asegúrate de que los ajustes que pongas en el archivo wp-config.php que hicimos anteriormente sean correctos, y carga tu sitio remoto de WordPress.

Se te pedirá que vuelvas a instalar tu blog de WordPress, eso es porque tu base de datos está vacía. Después de la instalación, tu blog de WordPress está listo. Puedes realizar cambios en la versión remota o local y sincronizarlos con Mercurial.

Pero todavía hay un problema importante: la base de datos no se sincroniza con los archivos. Esto es importante porque cosas como las entradas del blog, los comentarios, las tablas personalizadas de plugin... no serán lo mismo en la versión local y la remota.
WordPress tiene una función de importación y exportación. Pero no es útil, ya que no hace una sincronización real. Lo que necesitas es ir a tu phpMyAdmin, exportar todas tus tablas de WordPress en un lado (remoto o local) y luego ir al otro lado phpMyAdmin y reemplazar las tablas.

Después de hacer esto, tus bases de datos de WordPress se convertirán en las mismas. Sin embargo, tendrás que cambiar la fila site_url de la tabla wp_options. Este proceso llega a ser doloroso conforme la base de datos se vuelve más pesada.

Paso 4 sincronizar las bases de datos

Como vimos antes, la base de datos es un poco problemática. No se sincroniza con los archivos, esto es más difícil de alcanzar y requiere actualizar dos campos cada vez que se sincroniza. No es divertido hacerlo una y otra vez. La automatización es la solución; y en realidad, ese es nuestro trabajo.

Lo que necesitamos es un script que sincronice las bases de datos locales y remotas sin romper nada. La idea que me vino a la mente es incluir la base de datos en el control de revisión. El contenido de la base de datos se exportará a un archivo al que el control de revisión realiza un seguimiento. Cada vez que extraigamos cambios, el contenido de la base de datos será reemplazado por este archivo, consiguiendo que nuestra base de datos esté actualizada.

Dado que hay un par de filas que difieren de un host a otro (la URL del sitio y la URL de la página de inicio), necesitamos otro script MySQL que actualice estos con los valores correctos.
Otra cosa importante son los conflictos. Si estás trabajando y realizando cambios (confirmaciones) en la versión remota y la local, esto creará un conflicto. Un escenario típico es cuando estás trabajando y confirmando en tu versión local, y alguien (online) está añadiendo contenido nuevo en tu blog. No puedo ayudar en esta situación, necesitas aprender sobre Mercurial (o tu sistema de control de revisiones) fusión y trabajo en equipo.

Para evitar conflictos, asegúrate de extraer el repositorio de BitBucket antes de realizar cambios; y también para confirmar e impulsar los cambios en BitBucket después de haberlos hecho. Esto garantizará que BitBucket siempre tenga la versión más reciente y también que estás trabajando en la versión más reciente.

Este paso es un poco delicado, así que asegúrate de que estás siguiendo los pasos cuidadosamente. En primer lugar, voy a explicar cómo funciona la solución final. Vas a tener dos guiones: push y pull. Dependiendo de tu sistema operativo, va a ser push.sh y pull.sh (Linux) o push.bat y pull.bat (Windows). Yo estoy usando Windows localmente, y Linux (Ubuntu) remotamente, por lo que este tutorial cubrirá ambos sistemas operativos.

El primer script insertará los cambios en el servidor Bitbucket. Cuando realices algunos cambios en la base de datos, utiliza el script de inserción para cargar los cambios en el repositorio de BitBucket. Push volteará la base de datos actual en un archivo (/db/db_sync.sql) al que el sistema de control de versiones realiza un seguimiento. El archivo se insertará junto con los otros archivos y se cargará en BitBucket.

El segundo script extraerá los cambios del servidor Bitbucket. El script de extracción también leerá el archivo (/db/db_sync.sql) y reemplazará la base de datos. Esto actualizará la base de datos con la versión que insertaste. Dado que tienen diferentes nombres de host, el script de extracción modificará los campos necesarios, a saber, la URL del sitio y la URL de la página de inicio.

Empujando a BitBucket

En el servidor remoto y local, crea un nuevo directorio llamado "db". El archivo de base de datos exportado se guardará allí. En el servidor local (asumo que estás utilizando Windows) crea un nuevo archivo llamado push.bat. Realmente no importa dónde coloques el archivo (simplemente asegúrate de que estás utilizando las rutas correctas). Puse el archivo en el directorio raíz de mi repositorio de WordPress.

1

2

mysqldump -u username -ppassword database_name > db/db_sync.sql

3

hg add db/db_sync.sql

4

hg commit

5

hg push https://username@bitbucket.org/username/repository

Puedes quitar el comando "hg add db/db_sync.sql" después de ejecutar el script por primera vez. Esto sólo es necesario una vez.

En el lado del servidor (Linux/Ubuntu), las cosas no son realmente muy diferentes. La extensión del archivo cambia de .bat a .sh, y posiblemente tu nombre de usuario del servidor MySQL, contraseña y nombre de la base de datos. El contenido del archivo es exactamente el mismo.

Tirando de BitBucket

Empujar es un poco más difícil. Requiere importar el archivo SQL y también cambiar algunos campos críticos que difieren de un entorno a otro.

En tu equipo local, crea un archivo llamado pull.bat

1

2

hg pull https://username@bitbucket.org/username/repository

3

hg update

4

cd db

5

mysql -u username -ppassword testpress < db_sync.sql

6

mysql -u username -ppassword testpress < db.sql

En la carpeta db, añade un archivo denominado "db.sql". Este archivo tiene instrucciones SQL que realizarán los cambios necesarios para que coincidan con la configuración del host. Puedes añadir más instrucciones si es necesario.

1

2

USE testpress;

3

UPDATE wp_options SET option_value="http://localhost/testpress" WHERE option_name="siteurl";

4

UPDATE wp_options SET option_value="http://localhost/testpress" WHERE option_name="home";

Aparte de la extensión de archivo, ajustes de MySQL y el nombre de la base de datos no cambia nada realmente en el servidor remoto. Esto se debe a que estamos ejecutando comandos de programas. Los comandos y su uso son independientes de la plataforma. Asegúrate de introducir los valores correctos para la dirección URL del sitio web en el archivo "db.sql". Deben coincidir con la URL de tu blog, si no estás seguro, siempre puedes comprobar los valores en la tabla wp_options.

Para ejecutar los scripts, en Windows haz doble clic en el archivo ".bat" y en el terminal del servidor remoto ejecuta el comando "sh script_name.sh".

El proceso

Ahora deberías tener 2 archivos ejecutables en cada entorno (extraer y empujar). También debes tener un script sql (db.sql) que no debe ser añadido a la versión de control. Ahora podemos probar nuestro pequeño sistema.

1. En tu máquina local, añade una nueva entrada de blog
2. Empuja los cambios desde tu máquina local
3. Extrae los cambios en la máquina remota
4. Comprueba si el blog está siendo ejecutado correctamente y que se haya añadido la entrada del blog