WordPress 2.2 y una solución al problema con UTF-8
Publicado el Lunes 28 de Mayo del 2007 @ 21:02 por Armonth.
- 22
- 7
Comentar
Un conocido acaba de actualizar a WordPress 2.2 y me ha comentado que tiene problemas al mostrar la codificación UTF-8 y es algo ya comentado antes por los comentaristas de SigT:
WordPress usa UTF-8 por defecto para el contenido y mostrar las páginas, pero la codificación de la base de datos siguen estando en latin1. En el fichero wp-config.php hay dos entradas al respecto:
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
En principio, si actualizáis desde una versión anterior, lo mejor sería quitar el utf8 de la primera quedando:
define('DB_CHARSET', '',);
define('DB_COLLATE','');
Al menos a mí amigo le ha funcionado, quizá en algunos casos haya que comentar la segunda línea, dejarlas las dos con el utf8, comentar las dos o directamente ninguna (si no os da ningún problema).
Pero esto — toca decirlo — es un apaño temporal y más tarde o más temprano tendremos que tener un WordPress 100% UTF-8 (ahora tenemos ficheros y “contenido” de la base de datos, falta la base de datos). Para ello podemos leer un borrador en el Codex WordPress llamado “Converting Database Character Sets“ enfocado 100% a WordPress 2.2.
Voy a traducir/adaptar rápidamente las partes importantes del borrador (como siempre, haced copia de seguridad antes de tocar nada):
Cómo convertir la codificación de la base de datos
Hasta WordPress 2.1.3 (ésta incluida), las bases de datos de WordPress eran creadas con la codificación latin1 y de orden alfabético (N.dT: collation) latin1_swedish_ci.
Con la versión 2.2, WordPress permite definir ambas opciones (codificación y orden alfabético) de la base de datos en el fichero wp-config.php. Definir los valores DB_CHARSET y DB_COLLATE en el fichero wp-config.php provoca que WordPress cree la base de datos con los valores adecuados. Pero esto sólo puede hacerse para nuevas instalaciones y no para las instalaciones “ya instaladas” o actualizadas de versiones anteriores. Para “reconvertir” la base de datos vamos a asumir que la base de datos está en latin1 y se necesita convertir a utf-8.
El problema
Cambiar la codificación requiere el uso del comando de MySQL ALTER TABLE. Cuando se cambia la codificación, todos los campos TEXT y similares son convertidos a UTF-8 pero esta conversión ROMPE los TEXT existentes ya que presupone y espera que el contenido alojado en estos campos TEXT está en latin1, pero WordPress aloja caracteres unicode en la base de datos latin1 y, como resultado, los datos se llenan de basura después de la conversión.
La solución
La solución es ALTER(AR) todos los campos TEXT y relacionados a campos BLOB, luego cambiar la codificación y devolver los campos BLOB a TEXT.
Pasos de ejemplo:
- Avisa con tiempo y pon el blog fuera de servicio.
- Haz una copia de seguridad.
ALTER TABLE wp_users MODIFY display_name BLOB;- Repetir paso 3 para el resto de tablas/columnas.
ALTER DATABASE wordpress charset=utf8;ALTER TABLE wp_users charset=utf8;- Repetir paso 6 para el resto de tablas.
ALTER TABLE wp_users MODIFY display_name TEXT CHARACTER SET utf8;- Repetir paso 8 para el resto de tablas/columnas.
- Añadir el
DB_CHARSETyDB_COLLATEcorrespondientes alwp-config.php. - Pon en marcha de nuevo el blog.
Así pues, en los pasos 3 y 4 hay que cambiar CHAR, VARCHAR, TEXT, ENUM y SET cambiándolos el campo a BLOG, en el paso 5 hay que cambiar la base de datos a UTF-8, en los pasos 6 y 7 cambiar todas las tablas a UTF-8 y, finalmente, en el paso 8 y 9 devolver los campos BLOB a su estado anterior (ya fuese CHAR, VARCHAR, TEXT, ENUM y SET) con el campo UTF-8 configurado.
La clave en la conversión es que los campos BLOB, a diferencia de CHAR, VARCHAR, TEXT, ENUM y SET, no son convertidos en basura cuando la base de datos y sus tablas son cambiadas a UTF-8.
Finalizando
Recomendación personal: si sabes lo que haces (y tienes tiempo), sigue los pasos del “borrador”, si no haz el cambio que he dicho al principio y espera que una de las nuevas versiones actualice automáticamente la base de datos, salga un script que lo haga o similar.
22 Comentarios (feed)
-
MarioQuartz nos comenta:
Y una bd normal que tiene registros en ansi y en utf-8 ¿como lo podria hacer? Por que me estoy cargando el contenido de una pagina con utf8_decode por que se aplica tanto a ansi como a utf8
-
Armonth nos comenta:
Pues la única solución que le veo yo es primero convertir todos los registros (registros = datos introducidos ¿no? :P) a UTF8.
-
MarioQuartz nos comenta:
si lo hago a mano necesitare herederos en 4o grado un grado detras de otro…
-
Armonth nos comenta:
O iconv :P
-
Techsfera nos comenta:
Hace poco actualicé un blog a Wordpress 2.2 y me encontré con ese fallo, al eliminar utf8 en las dos líneas quedó perfecto!.
Gracias por el artículo.
Esperamos tener pronto un Wordpress todo en utf8.
Salu2.
-
Francisco nos comenta:
Yo he actualizado hace un rato y me ha pasado exactamente lo mismo, además lo he solucionado como explican en el enlace. Por ahora sin problemas.
-
Carmen nos comenta:
Hola Armonth, tengo una cosa que comentarte y como yo no tengo opción me gustaría que contactases conmigo.
-
Armonth nos comenta:
Carmen si no tienes la opción en el fichero simplemente añadela copy&paste :P
-
Alex nos comenta:
Excelente el post Armonth, creo que podrás ayudar a mucha gente :)
-
Carmen nos comenta:
Hola Armonth no se trata de eso, simplemente es que yo también tengo creative commons en el contenido de mi blog, y al igual que yo respeto el de los demás me gusta que respeten el mío.
1.- Escribí el detalle del problema con la solución ayer 28 de Mayo a las 10:47 am hora española.
2.- En el artículo envié un pingback a SigT, exactamente a la entrada en la que hablabas del bug que afecta wordpress 2.1 y 2.0.
3.- A las 20:15 p.m. tengo registrada una entrada en mi blog desde el panel de control de SigT, más concretamente desde los comentarios spam y desde ese pingback.
4.- A las 21:02 publicaste este artículo
No veo la referencia por ningún lado, ni a mi blog ni al blog que realmente ha dado la solución, que yo si he referenciado y me he limitado a difundir. Al igual que hago con muchas de tus soluciones, respetando la licencia que tienes.
Quisiera haberlo comentado contigo en privado, de todas formas espero haber dejado suficientes enlaces como para que tu filtro antispam lo mantenga fuera de ser publicado pero espero que te llegue la información.
-
Armonth nos comenta:
Hola Carmen, paso a contestarte directamente por aquí (se agradece que quieras comentarlo en privado pero ya que lo haces por aquí no tengo ningún inconveniente en defenderme publicamente):
1. Te doy la razón en un punto y es que falta la fuente. Mea culpa porque con la traducción rápida sinceramente se me olvido. Pero:
2. La fuente que yo use fue el primer resultado que me dió Technorati: A Mind, un blog en inglés de donde saqué el enlace al borrador para migrar la base de datos.
Además el bug ya era conocido desde casi casi que salió Getz y concretamente ya me informaba Magarto en el primer comentario de esa entrada sobre los cambios relativos a latin1/utf8. Por otro lado sigo el trac y recuerdo haber leído algo.
3. En el tercer y cuarto punto permiteme dudarlo: debo decirte que con Firefox uso RefControl configurado para que no deje nunca referidos, no sabes lo que aumenta el spam si visitas un sitio-spam desde el sistema de estadísticas :P. Eso puede haber sido por dos cosas aunque no sé cual de ellas:
(a) alguna de las personas que de vez en cuando escriben en SigT (casi siempre soy yo el que escribo pero en SigT somos más personas) o (b) que haya mirado la lista de spam desde casa de un conocido que tiene la (muy mala en mi opinión) costumbre de usar Firefox + Fasterfox y al cargar una página precarga todos los enlaces de la misma.
Pido disculpas por los mal entendidos que pueda haber generado, es cierto que a veces se me olvidan las cosas — ojalá sólo fuera a estas horas — y en otras ocasiones he pedido disculpas reconociendo el error, pero considero que en ésta ocasión es sólo casualidad.
PD: Arriba-derecha está la sección de autores que aunque anda bastante desactualizada tiene mi email (mi nick terminado en @gmail.com) para cualquier otra cosa que creas oportuna y/o si no quieres seguir por aquí (y si no quieres seguir por aquí también puedo borrar los dos últimos comentarios, no tengo ningún problema por ello).
-
Carmen nos comenta:
Gracias por contestar Armonth, y aclarar la situación, por ello prefería comentarlo en privado, aunque tampoco tengo problema en decirlo por aqui.
Espero que entiendas mi mosqueo, era mucha coincidencia, que en un espacio de 45 minutos se produjese la visita desde el panel de administración de SigT y se publicase la entrada. Como comprenderás con datos que tengo es más fácil pensar lo que comenté al principio que lo que acabas de explicar tú ahora, por eso quería aclararlo.
Respecto al registro de la visita desde SigT, por si te queda alguna duda, a continuación te dejo la captura,
-
Armonth nos comenta:
Lo aclaro precisamente porque te creo, veo posible que se haya producido esta casualidad y más en WordPress donde los temas suelen salir muy a menudo de las mismas fuentes en inglés.
Sobre lo de no mosquearme del otro comentario, tranquila que no lo hago. Si hubieras venido en plan troll (te contesté en medio de una oleada de comentarios-troll de un pavo que me “invitaba” a crackear la web de un gobierno, imagina xD) o con mala educación pues obviamente mi contestación hubiera sido otra pero como no es el caso estoy contento de haberlo aclarado :).
-
Carmen nos comenta:
No hay problema, entiendo perfectamente la circunstancia de los trolls y admiro la templanza en tu contestación y por supuesto la educación que has tenido
-
Francisco nos comenta:
Propongo casamiento con carmen!!
jajaja. -
Ismael nos comenta:
Bueno yo soy otro de los “afortunados” que lleva horas buscando una solución al “famoso” problema del utf8 al importar la base de datos de Wordpress.
Dando vueltas por multitud de páginas, webs, blogs,…al final NADA me ha servido, hasta que he caído en este blog, pero vaya por dios…mis conocimientos no llegan a la altura de las circunstancias y no tengo ni idea de hacer todos esos pasos “decentemente”.
Pero he encontrado un script que creo que hace lo mismo que se dice en este blog y en el code de Wordpress, pero claro en vez de hacerlo manualmente lo hace automático, mucho mejor para los que no somos unos “gurús” en esto de la informática.
Total que el script es este : http://kunde.apt.no/aso/wordpress/convert_to_utf8_sql_generator.txt
Pero claro, ahi va otro problema, lo he pasado a extension php y ejecutado en mi host, pero no sé si lo estoy haciendo bien…o no…
Bueno a ver si alguien me ayuda!
-
Armonth nos comenta:
-
Ismael nos comenta:
Gracias Armonth, pero el plugin ya lo instalé (el servicio técnico de Dreamhost lo recomienda) pero nada…sigo viendo mis carácteres “raritos”….esto es un sin vivir…
-
ManiKomiO nos comenta:
Estoy en la misma situación que todos los demás: me estoy mudando de host pero nada, no hay manera de restaurar la Base de datos de forma correcta. Instalé el Plugin citado pero únicamente me pone bien la descripción del blog, los posts siguen jodidos.
Además me da errores el wp-admin cuando quiero publicar…pfffff…una basura vamos. Lo mejor es tener un Host para toda la vida y no cambiar nunca ya que parece que lo de restaurar las bases de datos dan mogollón de problemas a todo dios. Si no es una cosa es otra.
Supongo que me quedará importar el archivo wordpress.xml y a joderse, poniendo todo bien cómo el original.
De todas formas se agradece la ayuda que intentais prestarle a los usuarios con problemas. Se que requiere mucho tiempo, pero esto muestra una vez más la bondad y la paciencia de muchos internautas en ayudarse unos a los otros en situaciones complicadas.
Saludos
-
ManiKomiO nos comenta:
Me acaba de ocurrir algo curioso. Os comento: llevo ya un buen rato con este rollo y no daba conseguido importar correctamente la Base de Datos. Sin embargo ahora parece funcionar.
1. Desactivé todos los Plugins
2. Hice la Copia de Seguridad con el Plugin “WordPress Database Backup”
3. Deje define(’DB_CHARSET’, ‘utf8′); y define(’DB_COLLATE’, ‘’); como estaba en un principio (anteriormente los había dejado en blanco como se mencionaba en el post)
4. Importe de forma normal y corriente la Base de Datos en phpMyAdmin
5. Comprobé el blog y todo parece funcionar a la perfección (de momento)Hmmm…curioso. No se, yo lo intenté de mila maneras, con el plugin ““Converting Database Character Sets“”, con el UltraEdit guardando a UTF-8, dejando el DB_CHARSET en blanco, con el xml exportado de Wordpress,…¡vamos para acabar hasta los cojones!
Ahora con esos 5 sencillos pasos todo parece funcionar. No se si la BD está completamente en UTF-8, ya que tampoco entiendo mucho de todo eso sobre los juegos de caracteres, pero vamos, la cosa funciona.
De todas formas me gustaría saber ¿porque es tan importante lo del juego de caracteres UTF-8 en wordpress?
Gracias y saludos
-
ManiKomiO nos comenta:
Jajaja y eso que soy bastante gafe para todo esto…parece que todas los detalles chungos que pasan en WordPress me ocurren a mi :(
Ya llevo con unos cuantos problemas a lo largo del tiempo…espero que realmente funcione todo…
-
ManiKomiO nos comenta:
Otra pregunta: ¿será necesario ejecutar ese Plugin “UTF-8 Database Converter” de la Web de http://g30rg3x.com en mi caso? (arriba lo había puesto mal cuando hablaba del Plugin “Converting Database Character Sets“. Me refería a este: “UTF-8 Database Converter”)
Gracias
