Ayer por la tarde, tras tomar las debidas precauciones (copia de seguridad de todos los archivos y dos copias de la base de datos, por si acaso), actualicé el blog a la versión 2.5.1 de WordPress. Seguí con todo cuidado el procedimiento habitual (o al menos eso es lo que yo creía), pero tras ejecutar el script de actualización me encontré con un mensaje de error relacionado con los widgets. Tras una rápida consulta a los foros de WordPress, vi que se podía resolver el problema borrando el registro correspondiente en la tabla wp_options, y así lo hice. El mensaje de error en la cabecera del blog desapareció.

Pero aquí no acababan los sustos. Al volver al frontend del blog, para ver cómo había quedado tras la actualización, me quedé de piedra: la codificación de los caracteres se había trastornado, y todas las vocales con tilde, las eñes y ciertos signos de puntuación (signos de abrir interrogación y admiración, guiones, comillas, etc.) habían sido sustituidos por caracteres ajenos a la codificación original. Enseguida me di cuenta de la gravedad del caso, y empecé a buscar cómo solucionar el problema. No voy a aburrir a la concurrencia relatando mis zozobras con los ficheros SQL, los scripts para modificar los cotejamientos de la base de datos y demás monstruosidades. Al final, después de más de seis horas de esfuerzos inútiles, decidí tirar por la calle de en medio y proceder a un downgrade, es decir, volver a la versión anterior de WordPress.

La vuelta atrás ha funcionado, pero no del todo. La operación sobre la base de datos que he descrito en el primer párrafo ha hecho que los widgets de texto no se puedan editar, y ademas ha provocado que desaparezcan todos los widgets que soportan múltiples instancias. Más vale que la mayoría de las operaciones sobre las diversas barras laterales de mi blog están realizadas con el plugin MyCustom Widgets, lo cual me permite prescindir de los widgets de texto nativos de WordPress, porque si no estaría vendido.

Tras devanarme los sesos buscando la causa del problema con el cotejamiento de la base de datos, creo que ya lo he identificado. De hecho, el caso está perfectamente documentado en el Codex de WordPress, pero, como suele suceder en estos casos, no había leído la advertencia. Resulta que el fichero config.php de las nuevas versiones de WordPress añade a las variables de configuración un par de líneas:

define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');

Si se utiliza un config.php con estas líneas en la actualización de un blog creado con alguna versión anterior a la 2.2, el resultado es que se pierde el cotejamiento original, con los problemas consiguientes.

En fin, de todo se aprende, y mi experiencia le vendrá bien a algún colega de afición bloguera para escarmentar en cabeza ajena. Lo malo es que mi blog probablemente se halle en un estado inestable, con errores e inconsistencias (si algún visitante las descubre, me hará un gran favor informándome de su existencia), lo cual me obliga a plantearme una solución radical, que seguramente pasa por una instalación ex novo y la importación del fichero XML resultante de exportar el contenido íntegro de la bitácora. No es una solución que me apasione, pues no está exenta de problemas, pero al menos me servirá para limpiar el blog y librarme de la basura acumulada en estos tres años de andadura.

alojamiento wordpress