Feliz Navidad tras la actualización a WordPress 3.5

Con muy poco retraso sobre la fecha originalmente prevista para su lanzamiento, el pasado 12 de diciembre se publicó la versión 3.5 de WordPress, tan esperada por quienes hemos convertido a esta aplicación en nuestro CMS de cabecera. Los cambios que trae consigo son numerosos, y algunos muy importantes, así que remito a los interesados a consultarlos en la página que el Codex dedica a WordPress 3.5, o en el utilísimo resumen que a tal efecto ha publicado el infatigable Fernando Tellado en Ayuda WordPress.

En cuanto se liberó la versión en español, me dispuse a actualizar las más de treinta instalaciones que administro (los detalles sobre casi la mitad de ellas pueden consultarse en el artículo Ochocientas entradas con WordPress). Me alegra decir que, incluso sin desactivar los plugins de la mayor parte de dichas instalaciones (es una acción imprudente, que no debe imitarse), todas las actualizaciones se realizaron a la perfección, en la mayoría de casos de forma casi inmediata y en otros –los sitios más pesados, o con servidores más lentos–, con algún tiempo de retardo, durante el cual la mente febril de este webmaster aficionado se dedicó a imaginar las más variadas catástrofes.

El éxito unánime de estas operaciones, que se caracterizan por lo variado de sus circunstancias –estamos hablando de blogs con apenas diez entradas, pero también de otros que suman varios cientos de artículos, de sitios que tienen media docena de plugins, pero al mismo tiempo de otros con más de cincuenta a sus espaldas, y de alrededor de una decena de instalaciones multisitio–, evidencia la envidiable madurez y facilidad de uso que ha logrado WordPress al menos desde la versión 3.0. No obstante, el diablo está en los detalles, por lo que insisto en las recomendaciones de entradas anteriores sobre este mismo tema: cualquier actualización debe realizarse siempre siguiendo el protocolo oficial, perfectamente definido en Updating WordPress y Upgrading WordPress Extended. Además, y por si acaso vienen mal dadas, recomiendo tener a mano la intervención de Mika Epstein en los foros de WordPress, titulada Troubleshooting WordPress 3.5 Master List, en la que se recopilan diversas incidencias relacionadas con la actualización a la nueva versión, así como la forma de resolverlas.

En mi caso, el proceso de actualización ha comenzado tras recibir los avisos que me envían las dos instalaciones diferentes de InfiniteWP con las que trabajo, una para mis sitios personales (véase la figura 1) y otra para los del PNTE. Desde esta aplicación es muy fácil controlar la actualización de múltiples instalaciones de WordPress, ya que ofrece un recordatorio permanente del estado de cada una de ellas y permite realizar las copias de seguridad; para más detalles sobre su naturaleza y funcionamiento, véase mi artículo InfiniteWP, para gobernarlos a todos.

No obstante, cuando hay que trabajar con sitios muy grandes, o con instalaciones multisitio, no es conveniente utilizar InfiniteWP como único instrumento para la administración del proceso de actualización. Como la casuística es infinita, no solo por la variedad de situaciones posibles, sino también por la gran cantidad de herramientas que se pueden utilizar para gestionarlas, la simplificaré mediante una descripción de los pasos que he seguido para actualizar La Bitácora del Tigre, complementada con ciertos consejos sobre la actualización de multisitios.

1. Actualizar todos los temas y plugins

Antes de comenzar a plantearse la actualización de WordPress, es necesario comprobar que el tema (o los temas, en el caso de un multisitio) y los plugins son compatibles con la versión a la que se va actualizar. No es muy frecuente que un tema obsoleto impida trabajar correctamente con la última versión de WordPress (aunque tampoco es imposible; véase, por ejemplo, este reciente caso relacionado con el tema Arjuna X, que forma parte de la plataforma Multiblog del PNTE), pero sí lo es que algún plugin origine problemas, bien por sí mismo, bien en combinación con alguna otra extensión. Afortunadamente, los repositorios oficiales de WordPress ofrecen una información muy útil (aunque no siempre actualizada, o suficientemente precisa) sobre la compatibilidad, y por ello no está de más consultarla.

2. Anotar la situación de los plugins

En sitios con muchos plugins, conviene anotar todos los que están activados, no solo para no olvidarse de ninguno a la hora de reactivarlos tras la actualización, sino también para activarlos en el orden más conveniente para la comprobación de sus efectos. Si de algo sirve citar mi propia experiencia, diré que en más de una ocasión he creído que algo no funcionaba bien tras efectuar una actualización, y todo por haber dado por activada una o varias extensiones que en realidad no lo estaban.

3. Poner el sitio en modo de mantenimiento

Aunque WordPress pone el sitio en “modo de mantenimiento”, lo cual equivale a decir que lo convierte en inaccesible mientras dura el proceso de actualización, evitando así que se pueda escribir en la base de datos o realizar cambios indebidos, lo cierto es que el modo de mantenimiento nativo ofrece a los posibles visitantes una información tan parca que resulta intimidatoria y poco útil. Para solventar esta limitación, existen diversos plugins que permiten dar una apariencia algo más presentable y productiva a la legendaria pantalla de “Cerrado por mantenimiento”. En La Bitácora del Tigre suelo utilizar el WP Maintenance Mode (en la figura 2 puede verse el anuncio de mantenimiento que he creado para tales ocasiones), mientras que en instalaciones multisitio empleo el WPMS Site Maintenance Mode, cuya principal ventaja es que permite al superadministrador de un multisitio decidir si quiere desactivar toda la red de blogs, el blog principal o solo los blogs secundarios.

4. Hacer copias de seguridad

Existen muchos plugins cuyo propósito es realizar copias de seguridad, bien de la base de datos de WordPress, bien de los ficheros, bien de ambos elementos (véanse, a este respecto, las extensiones correspondientes a las etiquetas database backup y backup). Mi experiencia en distintas configuraciones y con distintos servidores y cuentas de alojamiento es que, cuando se trata de sitios pequeños, casi todos funcionan bien. Sin embargo, en cuanto los sitios crecen, la mayoría de extensiones fracasan o se vuelven inmanejables, casi siempre por las mismas razones: agotamiento del tiempo de ejecución de scripts definido en el servidor, desbordamiento de la memoria, y otras parecidas. En consecuencia, para sitios de tamaño medio y grande, la mejor solución pasa casi siempre por acudir al volcado de la base de datos, bien directamente (si se tiene acceso por consola al servidor), bien mediante un interfaz web de gestión, cuyo ejemplo más común es phpMyAdmin.

Siempre que sea posible, es aconsejable hacer dos copias de seguridad de la base de datos, cada una con un procedimiento diferente, lo cual permite contar con una seguridad adicional en caso de que una de las dos copias no sea recuperable. Tampoco está de más realizar una exportación selectiva de aquellos elementos esenciales del blog que, de perderse, exigirían un mayor trabajo de recuperación. En La Bitácora del Tigre he llevado a cabo tres exportaciones complementarias, que paso a describir.

4.1. Contenido del sitio

Las entradas, páginas, comentarios, categorías, etiquetas, menús de navegación, autores, campos personalizados y tipos de contenido personalizados de un sitio web elaborado con WordPress, se puede exportar desde el menú Herramientas > Exportar. A su vez, el fichero resultante WXR, que no es otra cosa que un fichero de texto plano en formato XML, se puede importar desde otra instalación de WordPress (menú Herramientas > Importar), lo cual resulta muy útil para diversas situaciones en que es necesario realizar operaciones masivas sobre el contenido de un sitio (para más detalles, véanse los artículos que he publicado en torno a los procedimientos de importación y exportación de un blog). Si he de ser sincero, no he realizado esta operación porque tuviera pensado aplicar el fichero WXR a ninguna situación especial, sino como simple medida de precaución.

4.2. Contenido y configuración de los widgets

Más de una vez me ha ocurrido, tras actualizar una instalación de WordPress, que algún widget se había perdido o se había desconfigurado. Para solucionar este problema y no verme obligado a examinar en la tabla de opciones de WordPress la configuración de los widgets (tarea de lo más odiosa, que no recomiendo ni a mis peores enemigos), utilizo el plugin Widget Settings Importer/Exporter, mediante el cual se genera un fichero de texto que contiene toda la configuración de los widgets del sitio. Como el contenido de este fichero JSON es difícil de interpretar, además he realizado una captura de pantalla de la página en la que el plugin muestra la distribución de los widgets (figura 3).

4.3. Lógica condicional de los widgets

En La Bitácora del Tigre utilizo barras laterales y widgets condicionales (quienes estén interesados en saber más sobre las enormes posibilidades de estos elementos, pueden leer los artículos pertenecientes a la serie La magia de los widgets de WordPress), respectivamente creados mediante los plugins Custom Sidebars y Widget Logic. Esta última extensión dispone de una opción para exportar las condiciones definidas, que he utilizado en ocasiones anteriores. En esta, sin embargo, se me olvidó utilizarla y, como suele ocurrir en estricta aplicación de la Ley de Murphy, tuve que pagar el correspondiente precio, en forma de un trabajo añadido que describiré en el epígrafe 8.

También debe realizarse al menos una copia de todos aquellos ficheros y directorios del sitio web en los que se define la configuración del sitio o albergan elementos de contenido:

• Los ficheros .htaccess y wp-config.php del directorio raíz, ya que contienen los parámetros esenciales de configuración del sitio, así como cualesquiera otros ficheros de configuración importantes que hayan sido creados a lo largo de su historia. Por ejemplo, yo siempre realizo una copia de seguridad de los ficheros sitemap.xml y sitemap.xml.gz, ya que albergan el contenido del mapa del sitio, generado por el plugin Google XML Sitemaps.
• El directorio /wp-content, completo, pues en él se incluyen todos los temas y plugins instalados, los ficheros de traducción de WordPress, el directorio /uploads, al que se suben imágenes, documentos, etc., y, en el caso de los multisitios, el directorio /blogs.dir, que contiene los ficheros subidos a cada uno de los blogs.
• Cualquier archivo de la aplicación que haya sido personalizado. Ya sé que no es una buena idea retocar el código de los ficheros del núcleo de WordPress (pues las actualizaciones eliminan esas modificaciones), pero a veces no hay otro remedio. En todo caso, es imprescindible documentar con precisión todos los cambios realizados, para no olvidarse luego de reproducirlos en la nueva versión.
• Cualquier otro directorio personalizado al que se hayan subido ficheros. Se supone que en el /wp-content/uploads debieran encontrarse todos esos ficheros, pero por razones que no vienen al caso La Bitácora del Tigre cuenta con varios directorios adicionales que es preciso salvaguardar.

5. Desactivar los plugins

Como ya he señalado, buen número de las actualizaciones de WordPress tienen éxito incluso con los plugins activados, pero conviene no confiarse, sobre todo si el sitio cuenta con extensiones muy antiguas o se alberga la más remota sospecha de que alguno de los plugins sea incompatible con la nueva versión de la aplicación.

Con todo, hay plugins cuya desactivación no es aconsejable. Por ejemplo, a mi modo de ver no conviene desactivar Akismet, pues ello podría hacer que el sitio fuera vulnerable a los comentarios basura durante el espacio de tiempo que media entre el fin de la actualización y la reactivación de la extensión. Tampoco soy muy partidario de desactivar plugins como Jetpack o el cliente de InfiniteWP, ya que puede perderse la conexión con los respectivos servicios de los que dependen (WordPress.com e InfiniteWP, respectivamente). Y, por supuesto, si se utiliza un plugin para dejar el sitio web en modo de mantenimiento , como algunos de entre los citados en el epígrafe 2, ese plugin debe quedar activado durante todo el tiempo que dure la actualización y el proceso de verificación posterior.

6. Actualizar

El mecanismo de actualización automática de WordPress, que se lleva a cabo desde el menú Escritorio > Actualizaciones (o, en el caso de los multisitios, desde el menú Actualizaciones > Actualizaciones disponibles y a continuación Actualizaciones > Actualizar red) es muy eficiente, ya que solo afecta a aquellos ficheros que cambian en el paso de una versión a otra; por su parte, la actualización de la base de datos es una operación que apenas consume unos segundos (los interesados pueden averiguar los detalles en el artículo How the WordPress Upgrade Works). No obstante, no en todos los servidores funciona con la misma velocidad, por lo cual es recomendable tener paciencia ante un aparente «congelamiento» del proceso de actualización.

Conviene saber, además, que durante el proceso de actualización WordPress genera un fichero oculto en su directorio raíz, llamado .maintenance, que se borra al terminar la operación. Si esta fracasa (por ejemplo a causa del agotamiento del tiempo disponible para ejecución de scripts en el servidor, o por una conexión a Internet lenta o inestable), puede ocurrir que dicho fichero no se elimine, circunstancia que torna el sitio inaccesible. Pues bien, en tal caso basta con conectarse por FTP y borrar el fichero antedicho. A continuación, habrá que investigar sobre las posibles causas del bloqueo (de nuevo nos encontramos ante una casuística inagotable, aunque pueden encontrarse algunas pistas muy útiles en What to do when Auto-Update Fails) y, una vez resuelto el problema, repetir la actualización automática, o bien optar por la actualización manual, que es más lenta y farragosa, pero no particularmente difícil de realizar.

7. Desactivar el modo de mantenimiento

He situado esta fase en penúltimo lugar, porque hay plugins que no funcionan correctamente si el sitio se encuentra en modo de mantenimiento (parece ser el caso de Jetpack, que en tal circunstancia no es capaz de establecer conexión con WordPress.com), pero lo cierto es que también tiene pleno sentido reactivar todos los plugins en primer lugar, comprobar rigurosamente sus efectos y, solo después de su reactivación, devolver el sitio a su funcionamiento normal. En todo caso, debe quedar claro que el orden relativo de estas dos últimas fases del proceso de actualización depende de circunstancias singulares de cada sitio web –tamaño, complejidad, número de visitas, expectativas de los usuarios, etc.–, que deberán ser valoradas cuidadosamente por sus administradores.

8. Reactivar los plugins

La reactivación de los plugins es una tarea en la que debe extremarse la atención y el cuidado. La técnica más recomendable consiste en activar las extensiones una a una, para de este modo identificar las posibles incompatibilidades de cada plugin con la nueva versión de WordPress, y aislar los conflictos que puedan producirse entre dos plugins cualesquiera o entre uno de ellos y el tema del sitio. Una vez reactivado cada plugin, hay que comprobar sus efectos tanto en el frontend como en el backend del blog, para lo cual no solo hay que navegar por el sitio sino, siempre que sea posible, poner en práctica las acciones propias de la configuración y funcionamiento de cada una de las extensiones.

La realización de pruebas y verificaciones tras la reactivación de los plugins no es solo una recomendación genérica, sino una absoluta necesidad. El riesgo derivado de no hacer bien las cosas puede ser elevado, y una prueba de ello es el incidente que experimentó La Bitácora del Tigre tras la actualización a WordPress 3.5. En efecto, tras reactivar el plugin Custom Sidebars, llevé a cabo una comprobación muy superficial, lo cual me impidió advertir desde el principio un fallo de funcionamiento que, a día de hoy, no sé si es imputable al propio plugin. Sea como fuere, a las pocas horas de dar por bueno todo el proceso de actualización, me di cuenta de que con el plugin activado, era imposible seguir editando los widgets.

Tras numerosas pruebas, muchas consultas y unas cuantas intervenciones en los foros de WordPress, complementadas, hoy mismo, por otra en el blog de Javier Márquez, autor del plugin (el comentario no es visible; supongo que debe de estar pendiente de moderación), se me ocurrió eliminar la barra lateral personalizada para entradas y páginas individuales que en su momento había definido, tras lo cual recuperé el control del sistema de edición de widgets, pero a costa de perder los que formaban parte de dicha barra lateral. No ha sido una pérdida irrecuperable, y de hecho ha tenido su parte positiva, porque así me he visto obligado a revisar todo el sistema de widgets del blog, al cual he incorporado nuevas barras laterales personalizadas y una lógica mejorada, pero, claro está, todo el proceso ha supuesto unas cuantas horas de trabajo adicionales.

En cuanto al orden de reactivación de los plugins, este depende de las circunstancias de cada caso, y por tanto no es fácil ofrecer orientaciones universalmente válidas; sin embargo, a la luz de mi experiencia, se me ocurren al menos tres criterios que, valorados en conjunto, deberían determinar la prioridad en la activación:

• Activar en primer lugar aquellos plugins que más condicionan la funcionalidad global del sitio. Un caso evidente de plugin que debe activarse en primerísimo lugar es Akismet, pero en una situación similar se encuentran otros plugins esenciales, como los de caché, los generadores de mapas del sitio, los de estadísticas y SEO, las extensiones de redireccionamiento, las que incorporan medidas de seguridad, etc.
• Activar en primer lugar aquellos plugins de los que depende la correcta ejecución de otros, o que afectan al funcionamiento del tema del sitio.
• Activar en primer lugar aquellos plugins de cuyo funcionamiento depende la correcta presentación de una parte sustancial de los artículos del sitio.

Acabo ya, con una brevísima valoración de la nueva versión. De este WordPress actualizado sobre el que se cimenta y construye La Bitácora del Tigre me gusta casi todo, comenzando por el nuevo gestor de elementos multimedia, mucho más ágil, intuitivo y potente que el anterior (véase la figura 4), y terminando por las ligeras, pero sustanciosas mejoras en la instalación y administración de los multisitios. Lo único que me disgusta es que las nuevas instalaciones de WordPress ya no incluyan por defecto el tema Twenty Ten, que ha constituido toda una escuela de aprendizaje para quienes hemos dedicado una gran cantidad de tiempo a experimentar con la aplicación. Claro que se puede instalar a posteriori, en apenas un par de clics de ratón, pero, qué quieren que les diga, se le echa de menos.

Habrá que acostumbrarse a esos cambios, y para ello nada mejor que trastear por entre los recovecos de WordPress 3.5, o escribir artículos tan largos como el presente, cuya elaboración ha sido amenizada con la escucha en Spotify de unos cuantos discos de música coral con motivos navideñsos, y de alguna curiosidad de título tan apropiadamente bloguero como esta de Twitter Birds Blog, que he incrustado a continuación. Que ustedes disfruten de la música, de WordPress 3.5 y, por supuesto, de las fiestas navideñas.