WordPress en entorno de desarrollo localhost

No es que yo esté especialmente acostumbrado a trabajar con varios entornos (desarrollo, integrado, producción…) pero al menos unos mínimos sí que tenemos. En nuestro caso solemos tener al menos un entorno previo de «pseudo-desarrollo»… y digo «pseudo» porque normalmente tiramos del mismo servidor de base de datos que en producción, con lo que no podemos hablar de un entorno de desarrollo puro, donde puedes hacer cualquier barbaridad y nadie se entera.

Es curioso que en WordPress no exista una manera sencilla de conseguir un entorno de desarrollo decente… parece como si estuviera pensado para que todo se administrara en vivo directamente en producción, algo demasiado temerario incluso para el El Guerrero de la Carretera.

Esta claro que si quieres puedes conseguirlo:

1. Haciendo una copia en local de código y de la bases de datos.
2. Cambiando el config.php la referencia a la base de datos a «localhost» (en lugar de por su IP o una DNS).
3. Modificando en tu copia local de la base de datos, en la tabla wp_options el valor de la opción «siteurl» y «home» para que apunten a tu dirección local.

Con estos tres pasos en teoría consigues un entorno de desarrollo casi perfecto, completamente independiente del servidor en producción. Pero luego es muy engorroso de mantener, ya que por ejemplo cuando hay que actualizar WordPress o algún plugin debes hacerlo en local y en producción… y no es difícil que se des-sincronicen.

Otra opción es la que propone Pablo, en su post «simular URL reales desde local para CMSs como WordPress«: aunque es una solución más pensada para la fase previa en la que estás desarrollando un site nuevo que quieres luego poder subir a producción sin muchas dificultades.

La solución menos mala para nosotros…

Es compartir la base de datos entre los dos entornos, es decir, tirar tanto en desarrollo como en producción del mismo servidor de base de datos…. y luego tener una copia en local del código fuente, preferiblemente a través de algún cliente FTP que te permita sincronizar una carpeta local con una carpeta remota, ya que es algo que tendrás que repetir de vez en cuando.

Cuando llegue el momento de actualizar algún plugin, lo suyo es primero tener la precaución de subir todas tus modificaciones de desarrollo a producción, actualizar el plugin (o la versión de WordPress) y luego volver a «re-sincronizar» los dos sites, bajándote todo el código del servidor en producción a tu entorno en desarrollo.

Sigue siendo un poco engorroso, pero se puede sobrevivir. Para conseguir esto será necesario que añadas este código personalizándolo a tu situación en el archivo /wp-includes/option.php:

function get_option( $option, $default = false ) {
// intercept these options
if ($option == "siteurl" || $option == "home") {
// some sample logic to determine if we're on the dev site
if (strcasecmp($_SERVER['SERVER_NAME'], 'localhost') == 0) {
return "http://localhost:82";
};
}
// otherwise act as normal; will pull main site info from db

Básicamente lo que hace este código es detectar si el usuario que accede a tu sitio web está en desarrollo o en producción, y en caso de estar en desarrollo cambiar el valor de las opciones «siteurl» y «home» a la URL en desarrollo, en mi caso http://localhost:82 (en lugar de tirar del valor que tiene almacenado en la tabla wp_options en la base de datos).

Después de hacer esto podremos gritar: ¡Eureka!

Este entorno de desarrollo tiene sus limitaciones:

• Bajarte en local tu código fuente puede ser una auténtica pesadilla si utilizas algún plugin de cacheo excesivamente agresivo. Yo utilizo «WP Super Cache» en este blog, que es bastante moderado…. no como «WP3 Total Cache» que te crea miles de archivos.
• Cuando desactivas un plugin en local, se desactiva también en producción… eso puede ser un problema. Es probable que cuando estés programando mejoras necesites desactivar los plugins que te cachean la página en desarrollo y que al hacerlo se desconecten en producción puede ser un problema.
• Conseguir un cliente FTP bueno que te gestione la sincronización correctamente y que te permita excluir en la descarga algunas carpetas (como las de cache) puede convertirse en esencial. A lo mejor debemos pensar en recurrir a un software de control de versiones tipo Git, si tu hosting te lo permite.
• Alguna otra más que ahora no me viene a la memoria… en cualquier caso, date por advertido.

¿Se te ocurre alguna solución mejor? Compártela en los comentarios de esta entrada y no pierdas la oportunidad de demostrarme que no tengo ni idea de lo que estoy hablando.