El pasado miércoles, Felipe Zayas me pidió ayuda para actualizar su bitácora, Darle a la lengua, por entonces anclada en una versión, la 2.5.1, con algo más de un año de antigüedad (se publicó el 25 de abril de 2008). Catorce meses no son nada en la historia de una vida, pero en la de las aplicaciones informáticas equivalen casi a una era geológica, como tuve ocasión de comprobar tras finalizar el proceso de actualización del blog. En efecto, nada más acceder al frontend para comprobar los resultados del cambio a WordPress 2.8, me recorrió el espinazo un escalofrío de horror (el segundo de la tarde, después del primer gol de la selección de Estados Unidos, en el partido de semifinales de la Copa Confederaciones), pues el blog mostraba caracteres extraños allí donde debían estar las vocales con tilde, las eñes y otros signos característicos de nuestro alfabeto.
Enseguida me di cuenta de que se había producido un problema con la codificación de la base de datos, por lo que acudí a Google en busca de explicaciones y posibles soluciones. Rápidamente di con un artículo del Codex de WordPress en el que se explica muy claramente el problema: resulta que hasta la versión 2.1.3, WordPress creaba las base de datos con el juego de caracteres latin1 y el cotejamiento latin1_swedish_ci. A partir de la versión 2.2., la aplicación permite al usuario definir tanto el juego de caracteres como el cotejamiento en el fichero wp-config.php, mediante las variables DB_CHARSET y DB_COLLATE. Ahora bien, esta configuración sólo sirve para nuevas instalaciones, no para las ya existentes, y de aquí que al actualizar el blog se produjera un lío mayúsculo con los caracteres del blog.
Algunos problemas derivados de la actualización a WordPress 2.6
28 de Julio de 2008 en Bitácoras y WordPress por Eduardo Larequi | 9 comentarios
En la entrada sobre La actualización de La Bitácora del Tigre a la versión 2.6 de WordPress expuse, de forma un tanto apresurada (pues al día siguiente me iba de vacaciones), algunas de las novedades de esta última edición. Entre ellas, la posibilidad de guardar las revisiones de una entrada, una función muy útil cuando se trata de volver atrás en el proceso de edición de una entrada, pero que para la mayoría de blogs, que sólo tienen un autor y un proceso de edición lineal, carece de interés.
De interés y de rentabilidad, cabe añadir, porque las sucesivas versiones de una entrada las guarda WordPress como registros adicionales en varias tablas: no sólo wp_posts, como cabría esperar, sino también wp_postmeta, donde se alojan todos los metadatos de las sucesivas instancias, y wp_term_relationships, a la cual van a parar los datos de clasificación temática y etiquetado semántico de la entrada original y sus revisiones.
Continuar leyendo »