WordPress 2.2 y una solución al problema con UTF-8
Publicado el Monday 28 de May 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
-
MarioQuartz:
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
-
MarioQuartz:
si lo hago a mano necesitare herederos en 4o grado un grado detras de otro…
-
Techsfera:
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:
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:
Hola Armonth, tengo una cosa que comentarte y como yo no tengo opción me gustaría que contactases conmigo.
-
Alex:
Excelente el post Armonth, creo que podrás ayudar a mucha gente :)
-
Carmen:
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.
-
Carmen:
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,
-
Carmen:
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:
Propongo casamiento con carmen!!
jajaja. -
Ismael:
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!
-
Ismael:
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:
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:
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:
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:
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
