Articulo originalmente escrito en el blog: http://juank.black-byte.com/varios-caso-problemas-live-writer-wordpress/
Sigueme en Twitter: @JuanKRuiz
-------------------------------------------------------
Como de seguro a muchos de mis lectores les sucede Live Writer se ha convertido e una herramienta fundamental.
Live Writer es una de las herramientas por excelencia para los blogueros más avanzados.
Por mucho tiempo fue mi herramienta infaltable hasta que un día… no se que paso, ni como ni donde ni porqué… pero lo cierto es que dejo de funcionar.
Lo acepto, me dio pereza utilizar mis super poderes de developer, así que busque en foros , blogs, amigos etc. sin éxito y comencé a hacerlo de nuevo en el blog de notas… probé otros blog writers, sin quedar satisfecho.
Hasta que en un día de Junio me harté.
Respire, mire a mis adentros y me dije, es hora de utilizar mis super poderes y lo solucione.
Esta es la historia.
El error
Cada vez que trataba de hacer algo con mi blog desde Live Writer me salía este error
Así que decidí volver a inscribir el blog en Live Writer con tan mala suerte que sucedió exactamente lo mismo y ya nunca más funciono.
En busca de soluciones
El Log
Como pueden ver el mensaje de error sirve para poco y nada.
"Error al intentar conectar con tu servicio de blog:
Respuesta de servidor no válida –
La respuesta al método blogger.getUsersBlogs recibida desde el servidor de blogs no era válida:
Invalid response document returned from XmlRpc server Intenta solucionar el problema y, a continuación, inténtalo de nuevo."
Me pregunto que $#%#$ es blogger.getUsersBlogs y que tiene que ver con WordPress :S
Así que era el momento de buscar logs.
El log de Live Writer en Windows Vista y Windows 7 esta en "%localappdata%\Windows Live Writer" , en el caso de XP y otras versiones de Windows puede variar.
Allí esta el archivo "Windows Live Writer.log" el cual podemos revisar.
Lo primero que notamos es que vuelve a aparecer el tema de XmlRpc lo cual aún no nos dice nada, pero algo si es muy importante: "La respuesta del servidor no es válida" aunque hasta el momento eso tampoco nos sirve de nada.
Este es uno de esos momentos en que te das por vencido esperando que alguna vez WordPress o Live Writer corrijan un bug en su código… si algún día.
Salvo que uses tus super poderes de developer.
Buscando en internet encontré muchos problemas diferentes de Live Writer los cuales para solucionarlos hay que revisar el archivo xmlrpc.php de WordPress, sin embargo para no comer entero busqué de donde salía ese archivo.
Lo usual es que podemos cambiar el inicio de Live Writer para que el log sea más detallado, eso se hace llamando al ejecutable de Live Writer así
WindowsLiveWriter.exe /verbose
Una vez hecho de esa manera, debes replicar el error y de nuevo revisar el log el cual ahora es más detallado, en mi caso encontré esto:
La palabra clave es Request y la URL de dicho Request … así llegamos al archivo xmlrpc.php de WordPress.
http://juank.black-byte.com/wordpress/xmlrpc.php
Con esta información podemos suponer que ese Request esta devolviendo una respuesta incorrecta.
Al revisar el archivo xmlrpc.php de WordPress me pregunte ¿Cómo es que de la noche a la mañana ahí hay algo mal si yo nunca le he hecho nada?
Gran pregunta, pero sospeche de los plugin, por lo cual desactive todos ellos y taraaaaaaaaaaaaaaaan: no paso nada, el error persistia. #Fail
Revise el código meticulosamente, pero no encontré nada extraño.
Toco sacar el developer super sayayin nivel 2.
Revisando el request
Al ingresar http://juank.black-byte.com/wordpress/xmlrpc.php por el explorador web, obtengo la respuesta
XML-RPC server accepts POST requests only.
así que tenia que hacer un Request vía POST y de seguro comenzar a obtener tanta información como pudiera de su respuesta.
Comencé a indagar en internet acerca de como hacer un Request a una URL sin necesidad de hacer mi propio programa, lo cual era de una vez mi plan B. De esta forma encontré una herramienta llamada Feedler la cual tiene un nombre bastante self explained: "Feedler Web Debugging Proxy".
Lo pueden obtener acá: http://www.fiddler2.com/fiddler2/
No entrare en detalles de como hace feedler para funcionar, pero el que lo desee puede investigarlo.
Así que uso feedler para hacer un Request a http://juank.black-byte.com/wordpress/xmlrpc.php .
Voy a la pestaña "Request Builder" donde configuro la URL y el método del Request el cual es POST:
Le doy execute e inmediatamente obtengo esto:
Content-Length mismatch: Response Header indicated 386 bytes, but server sent 389 bytes.
Bingo!! mm no tan rápido.
Doy doble clic sobre el Request fallido, recién hecho, para examinar sus detalles, estos detalles de la respuesta salen a la derecha en la parte inferior, aparentemente no dice nada del otro mundo pero entonces me voy a la pestaña Raw para ver la respuesta sin procesar, tal como es enviada por el servidor.
Tampoco veo nada anómalo, entro en depresión. (jejeje)
De repente veo la pestaña HexView la cual es aún más Raw (jejeje), ahora si estamos hablando el mismo idioma: bytes.
Comparando la vista Raw con la Hexa me doy cuenta que puedo diferenciar fácilmente el header del Response de su contenido, sumado a que en la vista Hexa Feedler me pone el header de color verde como se ve aquí:
Todo va bien hasta que comienzo a ver los bytes traspasar por mi cuerpo y lo veo allí…
Neo: Hiya, fellas.
Agent Johnson: It’s him.
Agent Thompson: The anomaly.
Agent Jackson: Do we proceed?
Agent Johnson: Yes…
Agent Thompson: …he is still…
Agent Jackson: …only human.
Estos 3 caracteres  son los 3 primeros caracteres después de los header.
Desconozco los detalles de longitud de los headers, pero el error anterior era claro: "en el header se indican 386 bytes, pero el servidor envió 389 bytes".
La diferencia según el mensaje son 3 bytes y casualmente ‘la anomalía’ es de 3 bytes. Te tengo!
Como muchos de ustedes pueden saber y sino de una vez les cuento PHP tiene la particularidad de que si se incluyen líneas en blanco antes o después de los tag <?php … ?> se pueden generar resultados inesperados… que belleza.
Procedí, entonces a revisar el archivo xmlrpc.php para eliminar dichos espacios, pero para mi sorpresa no había ninguno.
Como es de suponerse las funcionalidades de ese archivo son llamadas desde otros archivos así que por descarte escogí los archivos de WordPress que yo si había modificado: los de el tema actual del blog, los revise uno por uno y encontré varios con líneas en blanco al inicio o al final… o en ambos casos.
Procedí a eliminarlos pero al probar Live Writer… no había funcionado.
Nuevamente me quede sin opciones.No había podido solucionar el problema. #fail
A debugguear! o algo así.
Solución … a medias pero solución
Estaba seguro que el problema estaba en los 3 bytes, eso era un hecho, para descartar fui a xmlrpc.php de WordPress y verificando sus referencias llegue a class-wp-xmlrpc-server.php y a class-IXR.php.
Para mi alegre sorpresa encontré que class-wp-xmlrpc-server.php esta repleto de llamados a métodos llamados getUsersBlogs y que casualmente cuando se llama a wp_getUsersBlog aparece esto
1 2 3 4 5 6 7 8 9 10 | function wp_getUsersBlogs( $args )
{
global $current_site;
if ( !is_multisite() )
{
array_unshift( $args, 1 );
return $this->blogger_getUsersBlogs( $args );
}
}
|
De allí se origina el error que al inicio del blog nos arrojaba el Live Writer. Continúe con mi búsqueda revisando en donde se escribían los headers exactamente el header de la longitud del Response, pero no lo encontré, por lo cual supuse que era una funcionalidad heredada.
Verificando el código línea a línea llegue a class-IXR.php y allí estaba:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | function output($xml)
{
$xml = '<?xml version="1.0"?>'."\n".$xml;
$length = strlen($xml);
header('Connection: close');
header('Content-Length: '.$length);
header('Content-Type: text/xml');
header('Date: '.date('r'));
echo $xml;
exit;
}
|
Lo revise meticulosamente y en apariencia no había nada que hiciera que el header "Content-Length" reportara un tamaño incorrecto.
Así que nada más por descartar en la parte donde se establece el tamaño, en el encabezado, le sume 3 bytes.
Ejecuté Live Writer y FUNCIONO!!
Ok, pero esta no es una solución decente, porque si me volvía a pasar que debería hacer?
modificar todas las veces este fuente y forzar que el conteo sea el correcto.
Eso no es nada profesional… y por demás… dónde se genera la anomalía?
Hasta acá no tenia idea de que más hacer y ya se había hecho bastante
Pero bueno, podemos ser super saiyayin nivel 3.
Buscando la anomalía, desde sus raíces – BOM .
Los bytes anómalos son EF BB BF respectivamente: 
Inicie mi búsqueda por internet con los caracteres anómalos y aunque habían algunas pistas no me llevaba a nada concreto, así que busque por los valores hexa y el primer artículo que salió era de Wikipedia:
Byte order mark : http://en.wikipedia.org/wiki/Byte_order_mark
Resulta que exactamente estos tres caracteres (BOM) son una marca de bytes utilizada en archivos de texto de manera opcional para indicar que codificación trae el archivo, si lo trae el archivo es un archivo codificado en UTF-8 sin lugar a duda… pero BOM ya es poco usado porque se presta para malas interpretaciones.
Esos caracteres BOM pudieron haber sido agregados a cualquier archivo de php dentro de mi WordPress, de hecho mi problema original era con 6 caracteres y no con 3 como lo he explicado para simplificar un poco el problema, lo cual me hacia pensar que como mínimo habían dos archivos con ese problema.
El problema con BOM es que muchos editores no muestran esos caracteres porque precisamente saben que son BOM y que no se muestran sino que se usan como guía para saber que tipo de codificación tiene el archivo. Así que no es cuestión de abrir los archivos y editarlos.
Estas imagen muestran como se ve un archivo con BOM en un editor de texto y como se ve en un editor binario:
Potencialmente cualquier archivo .php en mi WordPress podría tener ese problema pero revisar algo así como 1000 archivos en modo binario desde Visual Studio para remover 3 bytes en cada uno podría ser dispendioso, más aún cuando no en todos debería quitar esos 3 bytes sino solo en los que tuviesen BOM.
Deshice los cambios que sumaban 3 bytes en el header.
De nuevo hacer un programa por mi cuenta era el plan B. Buscando por Internet Llegué a esta herramienta gratuita
Replace Pioner http://www.mind-pioneer.com/
Debo admitir… es un enrredo internamente muy bueno pero una UI de la vieja guardia.
Les diré como usarlo para este problema puntual. Lo primero es que baje mi sitio de WordPress a carpeta local.
- Abrimos replace pioner
- Vamos a Tools>_Batch Runner
- Como no sabemos cuantos archivos de nuestra instalación de WordPress tienen ese problema usamos la opción Search Files y filtramos todos los archivos .php del directorio y subdirectorios de WordPress
- Clic en Search y listo tenemos listados todos los archivos .php
- Cerramos el dialogo
- En la parte inferior de Batch Runner tenemos el botón "Fast Replace" lo presionamos.
- En el dialogo que se abre seleccionamos el template de "binary file — remove utf-8 BOM"
- Presionamos Add
- Seguidamente Start
Tomara unos segundos y podemos ver el log de los cambios realizados, eso nos permitirá saber que archivos eran los culpables.
Una vez finalice el proceso copiamos los archivos de nuevo a nuestro sitio, vamos a Windows Live Writer y BINGO!!
Ahora si todo funcionando y de la manera más profesional posible.
Como prevenirlo
En algún lugar de la web encontré algo ingenioso.
Si bien puedes ser prevenido y siempre desde tu editor darle "guardar como" y seleccionar todo menos UTF-8 un truco es que al menos en los comentarios incluyan una letra que no sea de UTF-8 por ejemplo la ‘ñ’ con esto automáticamente el editor no hará uso del BOM ni nada similar.
Estoy seguro que este artículo les habrá encantado.
Byte!