Sobre el cambio de alojamiento de un blog con WordPress

Todavía estoy de mudanza, pero lo cierto es que, aunque no del todo bien afinados, ya hace días que los rugidos de La Bitácora del Tigre resuenan desde su nueva guarida, más cómoda, amplia y mejor dotada que la anterior. La migración a un nuevo proveedor de alojamiento ha funcionado de forma bastante satisfactoria, aunque la adaptación de todo el contenido del blog y de sus innumerables plugins a las nuevas condiciones me está costando mucho más trabajo del que yo suponía.

Como creo que la experiencia de este sufrido bloguero puede resultar útil para otros colegas de afición (los testimonios detallados nunca sobran, y por otro lado es más fácil y seguro escarmentar en cabeza ajena), voy a precisar, siguiendo las sugerencias de los siempre atentos Mario FX y Corsaria, lo que he hecho, dónde he acertado, dónde me he equivocado y qué trucos pueden venir bien a quienes tengan que pasar por este trago de trasladar un blog de WordPress a un nuevo hogar.

1. Elección de una nuevo proveedor de alojamiento

Aunque se desarrolle a muy diferente escala y tenga implicaciones mucho menos trascendentes, la elección de un proveedor de alojamiento no es un proceso demasiado distinto a la compra de una vivienda. Por mucho que se analicen y sopesen racionalmente las variables esenciales -precio, espacio, caudal de tráfico, disponibilidad, cuentas de correo y FTP, paneles de control, bases de datos disponibles, servicios complementarios, soporte, idioma, etc.-, a la hora de tomar una decisión también cuentan factores menos tangibles y mensurables, como el consejo de personas de confianza, la comodidad y hasta la intuición.

Antes de decidirme por un nuevo plan de alojamiento, pasé algún tiempo evaluando las ofertas de media docena de empresas, repasando los testimonios de algunos blogueros a quienes solicité consejo hace varios meses y visitando las compañías de que me habían hablado. Aunque pedí información específica sobre ello, de ningún proveedor obtuve referencias claras sobre el maldito fenómeno del «high CPU usage», que afecta de forma especialmente severa a los planes de alojamiento compartidos, y del que ya he tratado en alguna otra ocasión.

El última instancia, mi elección final se vio determinada no tanto por criterios objetivos (precio, servicios), como por la buena impresión que me produjo la respuesta de uno de los proveedores a los que me dirigí, Ferca Network: aunque sus servicios comerciales no llegaron a la precisión que yo hubiera querido respecto al tema de la carga en servidor de un blog lleno de complementos, por lo menos fueron muy diligentes y eficaces al responder a mis preguntas. De momento, puedo decir que esa buena impresión se ha confirmado en varias ocasiones con algunos problemillas de configuración que se me han presentado a lo largo del proceso de migración del blog.

2. Preparación de la copia de seguridad de la base de datos

Todo cuanto se diga sobre la importancia de la copia de seguridad a la hora de llevar a cabo una acción de importancia en la configuración del blog es poco. Por si las moscas, yo hice varios backups de la base de datos, tanto desde el interfaz del phpMyAdmin de mi antiguo proveedor de alojamiento como a través del plugin WP-DBManager. Para mejorar la eficacia del proceso de exportación-importación, antes de crear los backups definitivos, eliminé algunas tablas que ocupaban una enorme cantidad de espacio, como las correspondientes a los plugins FAlbum y Spam Karma. En cambio, mantuve las tablas generadas por el plugin Ultimate Tag Warrior 3 (son tres, wp_post2tag, wp_tags y wp_tag_synonyms), pues sabía que me iban a hacer falta posteriormente.

También repasé la base de datos en busca de enlaces que apuntaran al antiguo subdominio del blog (en blogdeltigre.coconia.net), tarea que debí haber abordado en noviembre de 2006, cuando migré el blog por primera vez, y de restos diversos que pudieran entorpecer la limpieza del fichero SQL resultante del backup. Limpié mucho, pero no todo lo necesario. Tras la restauración, me di cuenta de que me había olvidado de buscar en varios campos que contenían restos de antiguas etapas del blog. Por si a alguien le interesa, esos fósiles se localizan en varios lugares que conviene repasar antes de generar el fichero SQL definitivo:

• Tabla wp_postmeta: contiene los metadatos de las entradas. Es necesario escudriñar a fondo en sus registros para eliminar datos anticuados o incorrectos, tales como referencias a archivos multimedia inexistentes o que han cambiado de URL, etiquetas duplicadas (que no sé bien por qué se producen), etc.
• Tabla wp_posts: el corazón del blog, pues alberga el contenido de las entradas. Hay varios campos que exigen una atención especial:
  • post_content: tuve que repasar todas y cada una de las entradas del blog (nada menos que 328) para revisar este campo y actualizar las URLs del antiguo subdominio y las que apuntaban a las direcciones generadas por la estructura de permalinks que WordPress trae por defecto (modificada en junio de 2006). Esta pesadísima tarea la realicé con el editor del blog, hasta que me di cuenta de que de este modo se generaban nuevos comentarios-pingback, que inducían a confusión, por lo que tuve que eliminarlos. Por tanto, aconsejo a los usuarios que se hallen en una situación parecida que no editen las entradas desde el editor de WordPress, sino que recurran a la edición de la base de datos desde el phpMyAdmin o aplicación similar (siempre que sepan lo que hacen, claro está).
  • pinged: contiene las direcciones de los pingbacks. También aquí tuve que repasar las URLs antiguas y sustituirlas por las nuevas.
  • guid: contiene el identificador de las URLs completas de las entradas. Otro campo que revisé a fondo, por las mismas razones que los anteriores. Por cierto, en el Codex de WordPress hay un documento que explica cómo llevar a cabo esta acción, en casos de cambio de dominio del blog, de una sola vez, mediante una simple sentencia SQL. No obstante, como soy un poco torpe con la sintaxis de SQL y la documentación advierte de los riesgos de la operación, no la puse en práctica, aunque no hay por qué dudar de su eficacia.
• Tabla wp_options: una fuente de innumerables problemas, porque a lo largo de la existencia de una bitácora no hace más que crecer y crecer. Además, la forma en que WordPress almacena los parámetros del blog (entre ellos, todos los controles y configuraciones de los plugins, incluso los desactivados y, lo que es peor, muchos de los ya desinstalados) opone una fuerte resistencia a cualquier tipo de edición mediante los métodos seguidos en otras tablas. Invertí unas cuantas horas en buscar información sobre cómo limpiar la tabla de forma eficaz, antes de hacer el backup correspondiente. Incluso edité el fichero SQL generado por el backup para encontrar líneas de la tabla wp_options que pudieran ser eliminadas sin riesgo (parafraseando el refrán gallego sobre las meigas, puedo decir que «haberlas haylas», por muy escondidas que estén). Tras largas horas de trabajo, y a la vista de lo improbable de un resultado satisfactorio de tanto esfuerzo, me decidí por una solución drástica: prescindir en el proceso de importación de las líneas correspondientes a esta tabla, y proceder a una instalación «limpia».

3. Copia de seguridad de los ficheros de WordPress

Todos los tutoriales aconsejan la copia de los ficheros que forman parte de una instalación de WordPress, sobre todo si se han hecho modificaciones en los scripts que forman parte del programa, o si se han editado los plugins o los temas. En mi caso sólo era estrictamente necesario mantener los ficheros del directorio /wp-content (plugins y temas), así como otros directorios de documentos e imágenes, el fichero .htaccess y el fichero /wp-includes/languages/es_ES.mo, de traducción del blog al español. No obstante, copié el sitio en su integridad y en un par de ubicaciones diferentes, por si acaso.

Además, realicé capturas de todas las pantallas de configuración del backend de la bitácora, plugins incluidos: casi setenta imágenes, que me han venido muy bien para ir recuperando la configuración original cuando he tenido alguna duda. Admito que el procedimiento es algo chapucero y que podía haber obtenido esa información de los registros correspondientes en la tabla wp_options, pero ya he comentado que dicha tabla almacena las opciones de configuración de manera harto complicada para quien no esté en posesión de los secretos más íntimos de WordPress.

En todo caso, he de admitir que, a pesar del cuidado con que registré el estado del blog previo a su migración a un nuevo alojamiento, me dejé cosas en el tintero: por ejemplo, aunque anoté los widgets que tenía instalados en la barra lateral y el orden en que aparecían, no fui consciente de la necesidad de copiar el contenido de los widgets de texto, lo cual me obligó, una vez realizada la migración, a volver sobre el fichero SQL de backup para encontrar en la tabla wp_options los registros correspondientes (labor detectivesca que puede resultar fatigosa en una tabla muy castigada por el uso) y volver a crear los widgets. Algo parecido me ocurrió con plugins como AdSense-DeLuxe o Audio Player, cuyos datos de configuración no aparecen en las capturas de pantalla; si no se guardan antes de la mudanza, luego será necesario recuperarlos de la tabla de opciones.

4. Nueva instalación y configuración preliminar

Una vez activado el nuevo alojamiento (mientras se propagaban los DNS tuve que configurar el navegador para que poder conectarme al blog mediante una dirección de proxy que amablemente me proporcionó mi proveedor), y en posesión de una cuenta FTP, subí al servidor las últimas versiones disponibles de WordPress (la 2.1.3) y del tema Tarski (la 1.4), previamente traducido al español. Modifiqué el fichero config.php original con los parámetros necesarios para que el blog funcionara en el nuevo alojamiento y procedí a realizar el proceso de instalación, que se efectuó en un periquete. A continuación, desde una cuenta provisional de administrador, modifiqué todas las opciones del tablero de WordPress para que coincidieran con los de mi anterior alojamiento. Todo el proceso se desarrolló con gran limpieza, con dos únicas excepciones que me trajeron por la calle de la amargura:

• La sustitución de la fuente RSS original de WordPress por la de FeedBurner, que administro gracias al plugin FeedBurner Feed Replacement (gracias a MarioFX, por advertirme sobre la última versión). Como el cambio de alojamiento, que además coincidió con una nueva suspensión temporal de mi antigua cuenta a causa, una vez más, del exceso de carga del servidor, tardó algún tiempo en propagarse debido al cambio de DNS, FeedBurner no se enteró de la existencia de mi fuente original, y durante unos cuantos días comunicó errores. Me fui de vacaciones a Galicia sin saber cómo quedaba el asunto, pero al volver descubrí, con alivio, que tras la propagación de los DNS todo había vuelto a la normalidad, al menos hasta donde yo he sido capaz de comprobar. Si alguien sigue experimentado problemas con el feed de La Bitácora del Tigre, agradeceré que me lo comunique.
• La activación de la estructura de permalinks que había definido para el blog. El correcto funcionamiento de las URLs amigables se me resistió una y otra vez, hasta que consulté a mi nuevo proveedor de alojamiento, cuyo servicio técnico resolvió el problema de forma casi inmediata, con una modificación de una línea en el fichero .htaccess del blog.

5. Importación del contenido

Tras comprobar que todas las funciones originales de WordPress operaban correctamente, tomé aire, hice una silenciosa invocación a mis santos protectores, y comencé a importar las tablas procedentes del fichero SQL de backup, mediante el phpMyAdmin de mi nuevo proveedor de alojamiento. Si no recuerdo mal, seguí el siguiente orden, que me pareció el más lógico y eficiente:

• Tablas de usuarios: wp_users y wp_usermeta. Como el fichero SQL de backup incluye las órdenes para eliminar las tablas en caso de que éstas ya existan, la operación eliminó el usuario administrador provisional y lo sustituyó por el que ya tenía antes. Salí del blog, me volví a conectar con los datos de dicho usuario y no hizo falta más.
• Tablas de categorías y enlaces: por este orden, wp_categories, wp_links y wp_link2cat. De nuevo, las órdenes de borrado del fichero SQL funcionaron perfectamente y sustituyeron el contenido que WordPress genera para dichas tablas en una instalación por defecto por la que La Bitácora del Tigre tenía hasta entonces.
• Tablas de entradas: por este orden, wp_posts, wp_postmeta y wp_post2cat. La importación se realizó sin ningún problema. La única dificultad es la de seleccionar del fichero SQL el contenido correspondiente a cualquiera de ellas, pues puede ocupar cientos o miles de líneas. Si uno pierde el pulso de la mano con que maneja el ratón, va listo.
• Tablas de comentarios: wp_comments. La importación añadió al blog sin ninguna incidencia (excepto la ya mencionada de la tensión en la mano del ratón, pues la tabla puede ser muy larga) todos los comentarios originales, perfectamente asociados a sus respectivas entradas.

Quienes hayan leído hasta aquí ya habrán advertido que queda fuera de la lista la tabla wp_options, que es la que completa una instalación estándar de WordPress y la que registra todos los parámetros de configuración del blog. Como ya he dicho antes, no la he importado, sino que he decidido crearla ex novo, para conseguir una instalación lo más limpia posible. Ya se encargará la evolución del blog de ir enguarrándola.

A los usuarios de WordPress que opten por este procedimiento «por etapas» les aconsejo que, además de realizarlo con cuidado, comprueben sus efectos en cada uno de los pasos, antes de continuar con el siguiente. Por ejemplo, yo me atasqué en la recuperación de las entradas al haberme olvidado de importar la tabla wp_post2cat, lo cual me dejaba las entradas huérfanas de categorías. Bastó con importar la tercera tabla para conseguir el efecto deseado.

Conviene señalar, en todo caso, que el procedimiento que yo he seguido no es el único posible. Las últimas ediciones de WordPress disponen de un par de opciones en el backend, bajo la pestaña Administrar, para generar un fichero de exportación en formato XML y para importarlo desde una nueva instalación del CMS. El procedimiento está cuidadosamente descrito en el artículo Importing Content del Codex de WordPress; si yo no lo he seguido no ha sido por falta de confianza en él, sino por el deseo de investigar y aprender. En todo caso, aconsejo a los usuarios que lean con atención los artículos de la sección Advanced Topics del Codex (todos ellos en inglés; aunque también existe una versión española del Codex, no contiene la traducción de todos los tutoriales), donde se detallan varias técnicas para hacer copias de seguridad, exportar, importar, mover un blog de alojamiento, alojarlo en un directorio diferente, etc.

6. Añadir plugins

Antes de comenzar con la tarea, he tenido que sopesar con cuidado qué plugins me resultaban imprescindibles, cuáles eran simplemente necesarios y de cuáles me podía ir olvidando, al menos hasta que el blog se asiente en su nuevo alojamiento y lleve algún tiempo de rodaje. Hasta la fecha, he instalado los siguientes complementos:

• Akismet: del todo imprescindible para evitar una inundación de spam en un blog que, desgraciadamente, es objeto de la atención de toda suerte de anunciantes sin escrúpulos.
• CompleteRSS: también imprescindible para no defraudar a los usuarios de La Bitácora del Tigre que siguen el blog a través de sus lectores de feeds.
• FeedBurner Feed Replacement: un poco menos imprescindible que los anteriores, aunque muy útil para el administrador del blog. Como ya he señalado antes, me dio un montón de guerra por culpa del retraso en la propagación de los DNS.
• Spam Karma 2: otro plugin crucial en la lucha contra la amenaza del spam. Se integra bien con Akismet y, de momento (¡crucemos los dedos!) no me ha dado problemas. Ojalá dure y, sobre todo, no me sobrecargue el servidor.
• Widgets: un plugin utilísimo para gestionar de manera eficaz la barra lateral del blog. En mi caso, el widgets estándar se complementa con dos plugins de la serie King Widget, que permiten ejecutar código PHP en la barra lateral: el King Framework y el King Text Widget. El King Framework no es compatible con la versión 2.1 de WordPress, pero tras leer los comentarios 47 y siguientes, he conseguido resolver el problema mediante el siguiente truco: editar el fichero /library/king_widget_functions.php y sustituir las llamadas a la librería prototype-lite.js por otras que invocan el fichero original de WordPress, ubicado en /wp-includes/js/scriptaculous/prototype.js.
• Ultimate Tag Warrior 3: es el único plugin cuyas tablas he conservado. Tras instalarlo y volcar en la base de datos el contenido del fichero SQL de backup correspondiente a las tablas wp_tags, wp_tag_synonyms y wp_post2tag, he conseguido que todas las entradas del blog que contaban con etiquetas las recuperen. Por cierto, aviso a todos los visitantes de La Bitácora del Tigre que la página de etiquetas tiene nueva ubicación.
• Live Comment Preview: uno de los plugins recomendados por los creadores del tema Tarski, que permite disponer de una vista previa del texto del comentario antes de publicarlo. Esencial para los comentaristas que añaden a sus textos etiquetas de formato.
• Clean Archives 2.0: también recomendado por los creadores del tema Tarski, sirve para generar, de forma rápida y sencilla, una página de archivo histórico del blog (también esta página ha cambiado de URL).
• Otros plugins, tales como el Creative Commons Configurator, el WP-PostViews y el WP-Print, respectivamente destinados a mostrar la licencia CC que regula el uso de los textos del blog, a contar las visitas a las entradas y las páginas y a generar una versión «lista para imprimir» de cada una de las entradas. Todavía no he conseguido que el WP-Print funcione a la perfección, probablemente a causa de un fenómeno relacionado con la configuración del servidor que aloja la bitácora, pero espero tenerlo listo en breve.

Me queda todavía bastante trabajo por hacer, pues tengo pendiente la instalación de unos cuantos complementos para la administración de imágenes, audio y vídeo, gestión de formularios y estadísticas, etc., pero lo esencial ya está terminado. A partir de ahora, es cuestión de ir observando el funcionamiento del blog y mejorando sus funciones, pero sin prisas. No vaya a ser que por correr me pegue algún tortazo.

7. Algunas observaciones a modo de conclusión

En primer lugar, quiero ofrecer un consejo a todos los usuarios que en alguna ocasión se hayan planteado cambiar de alojamiento para sus sitios web, sean blogs o no: ¡que no lo hagan coincidiendo con unas vacaciones! Hay que tener tiempo por delante para realizar previsiones, responder con rapidez a los errores detectados y contactar con los servicios técnicos y los sistemas de soporte. Si uno deja el blog colgado a medio instalar, como hice yo, lo más probable es que algo no funcione bien y no sea posible repararlo en un breve lapso de tiempo. Además de quedar muy mal con su público, el bloguero que planifique su traslado con tanto desacierto como yo se convierte en firme candidato a sufrir un ataque al corazón.

La segunda observación va en la misma línea de la primera: no conviene realizar mudanzas en coincidencia con las efemérides del blog. El cambio de alojamiento de La Bitácora del Tigre me ha impedido celebrar su segundo cumpleaños del modo y manera que a mí me hubiera gustado. En vez de invertir mis energías en fuegos artificiales retóricos, reseñas peleonas y algún poema festivo de esos que tanto me gusta perpetrar, me he visto obligado a hundirme hasta los corvejones en las minucias de WordPress. Añádasele a ello que, en medio de las vacaciones galaicas, me vi desagradablemente sorprendido por un correo enviado por la compañía que aloja Lengua en Secundaria, con la advertencia de que su dominio no iba a ser renovado; más vale que el aviso resultó ser un error, porque yo ya estaba de los nervios.

La tercera observación es, en realidad, un ofrecimiento público de excusas: mi prometida reseña de la novela Kafka en la orilla, de Haruki Murakami, se ha visto desbaratada por el aluvión de problemas de mantenimiento del blog que he tenido que afrontar. Lo mismo ha ocurrido con varias reseñas de películas que he visto en las últimas semanas (El último rey de Escocia, 300, La cosecha, Days of glory, El buen pastor), algunas comenzadas y otras en estado de simple proyecto, todas ellas arrumbadas por causas de fuerza mayor. También he estado ausente de la blogosfera educativa y de mis cotidianas visitas a Planeta Educativo, que era ya un hábito consolidado en mis ratos de vagabundeo por la Red. Tendré que hacer un esfuerzo extraordinario para ponerme al corriente.

En fin, espero recuperar el tono muscular y espero también que esta larguísima crónica sirva de ayuda, guía o simple consuelo (lo digo por aquello de «mal de muchos…») a los usuarios de WordPress, una aplicación excelente, sí, pero también muy exigente con quien desee obtener de ella todo su potencial.