Nota: mamá, en serio, ésta entrada puedes saltártela, va del programa con que funciona este blog y, de verdad, es un tanto aburrida. Te dejo un enlace, que seguro que te gustará más. Besos.
Aviso: todo lo que se cuenta en esta chuleta se ha probado, primero, en un entorno de pruebas. Si eres tan estúpido (no, no tiene otro nombre), como para hacer pruebas sobre un servidor en producción, no vengas llorando por aquí. Para la realización de esta migración, es necesario contar con unos conocimientos previos adquiridos, a saber: sentido común, algo de SGBD, un poco de sed, vim y bash y una pizca de coherencia. De nuevo, si no cumples con esto, no vengas a lamentarte.
Esta entrada no deja de ser una lista ordenada de todos los pasos que me llevaron a conseguir el objetivo final. Me funcionó a mí, cierto, y lo escribo por si vuelvo a necesitarlo. Declino cualquier problema o responsabilidad que la aplicación de dichos procesos pueda ocasionar en blogs ajenos. Por si a alguien le interesa, me llevé por delante una docena de veces el blog, antes de conseguir dar con la tecla.
Advertidos estáis.
Hace unas pocas semanas me enfrenté a un desafío que llevaba tiempo esquivando por falta de ideas para abordarlo. Tenía que actualizar el CMS de La curuxa, un Wordpress añejo y, según la documentación oficial, iba a tener que migrar de 2.0.1 a 2.2, luego a 2.4, más tarde a 2.6 y, finalmente, a 2.8. Todo un planazo.
Dicen que la ignorancia es atrevida hasta límites insospechados y, quizá por eso, me propuse explorar nuevas vías. En vez de realizar las recursivas actualizaciones y [ironia=on]mis vastos conocimientos en bases de datos[ironia=off], quise ver qué pasaba cuando utilizas la última versión de WP con una versión de su base de datos antediluviana. El resultado, más o menos esperado, es que WP exigía que se ejecutase el script de actualización y que, a continuación, el blog estaba completo y actualizado, pero con caracteres raros.
«ÿsto va a ser de la base de datos», me dije. Y fisgando en su estructura me encontré con que la codificación de la misma era latin1, mientras que WP sólo hablaba utf8. Así que, los caracteres raros eran problemas de traducción. Para solucionarlo se me pasó por la cabeza usar una compleja pero eficaz sentencia en SQL pero, dado que mis conocimientos en la materia se quedaron en aquel tren, me pasé a la guerra de guerrillas y los script sucios, chapuzas. Ahí, en ese escenario, doy lo mejor de mí.
Al final, tras docena y media de pruebas y errores, de borrón y cuenta nueva, conseguí dejar la base de datos con la codificación correcta y actualizada a la última versión.
Un poco mejor explicado, paso por paso y ordenado:
- hacer un backup de la base de datos de producción, con la codificación de caracteres
utf8, ya que es la codificación de WP. - editar el fichero de backup, sustituir el nombre del dominio, en mi caso
http://lacuruxa.orgyhttp://www.lacuruxa.org, por una dirección local. Yo utilicéhttp://curu.n1mh.orgy lo sustituí con dos comandos de sed:sed -i 's/http:\/\/lacuruxa.org/http:\/\/curu.n1mh.org/g' fichero.sql
sed -i 's/http:\/\/www.lacuruxa.org/http:\/\/curu.n1mh.org/g' fichero.sql - instalar el nuevo WP en la dirección local creada a tal efecto. Después, sobreescribir la base de datos con la obtenida de producción. Abrir la zona de administración en el navegador (
http://curu.n1mh.org/wp-admin/) y, ante la petición de actualización, actualizar. Los caracteres extraños inundan el blog. Ante todo, tranquilidad. - editar con vim el fichero de la base de datos, buscando el caracter ÿ y sustituir todos los posibles caracteres raros. En mi caso y usando vim, busqué y sustituí los siguientes:
:%s/ÿ¡/á/g
:%s/ÿ©/é/g
:%s/ÿ/í/g
:%s/ÿ³/ó/g
:%s/ÿº/ú/g
:%s/ÿ±/ñ/g
:%s/ÿ<91>/ÿ/g
:%s/ÿ¼/û/g
:%s/¿/ÿ¿/g
:%s/¡/ÿ¡/g
:%s/«/ÿ«/g
:%s/»/ÿ»/g - el resto de caracteres raros, que los hay, comienzan por el caracter ÿ y es conveniente buscarlos y eliminarlos a mano. Para todos aquellos que no se puedan procesar con vim, mi recomendación es buscarlos en el blog, copiarlos y pegarlos en vim, que los sustituirá con gusto. Los más problemáticos fueron
â?<9d>, â?Ž<8f> y â?<80>. - sustituir la base de datos de prueba con la nueva base de datos e ir viendo qué caracteres fallan. Es, de largo, la parte más tediosa y mecánica. La importación debe hacerse con la codificación correcta:
mysql -u root -p mysql_user --default-character-set=utf8 < ~diego/Desktop/fichero.sql - con cada importación de la base de datos, hay que acceder desde el navegador a la zona de administración de WP,
http://curu.n1mh.org/wp-admin/, y proceder a actualizarla base de datos. - una vez estemos seguros de que están todos los caracteres correctamente codificados, toca revertir el dominio temporal por el bueno. Hacemos una copia de seguridad de la nueva base de datos en un fichero, lo editamos y ejecutamos:
sed -i 's/http:\/\/curu.n1mh.org/http:\/\/www.lacuruxa.org/g' fichero.sql - y, por último, sólo hay que subir la nueva versión de WP a la web y actualizar la base de datos de producción.
Fácil, ¿verdad? En realidad es más aparatoso que complicado. A partir del noveno punto, comienza una tarea bastante más árdua y callada, la de escoger un tema, adecuarlo, llenarlo de plugins y configurarlo. Pero eso, querido lector, ya es otro cuento.
El resultado, bien visible, se puede ver en la página web de la Agrupación Deportiva La Curuxa.
