Bitácora de Gesbit

Al final no he tenido sino que llegar a una solución de compromiso con el asunto de las "magic quotes" de que hablaba en la anterior entrada. El asunto es un tanto intrincado, pero, al menos creo que le he tomado por fin las medidas. Veamos qué ocurre exactamente, porqué tenía mi amigo problemas al guardar la descripción (que incluye comillas) de su bitácora.

En primer lugar, dejemos claro que el problema se produce únicamente si se tiene activada al directiva "magic quotes" de PHP, pero, recordemos que esta directiva se considera obsoleta, y en el manual de PHP se deja claro que no es bien basar nuestro trabajo en esta directiva. Ahora bien, supongamos en primer lugar que la directiva no se encuentra activada.

En ese caso, Gesbit guarda en la base de datos sin problemas: incluso sus opciones serializadas, incluso si estas contienen comillas y otros caracteres especiales. Si se piensa un poco así es como debe ser, porque, la función "serialize" no se equivoca con las comillas... a no ser que estas se encuentren escapadas. Por lo tanto, si no se usa "magic quotes", no hay problema.

Entonces hay que pensar en que "magic quotes" llegará a no usarse: por ejemplo, en PHP 6 no estará disponible la directiva, sin más. Ese es el futuro, por lo tanto. Ahora bien, supongamos que tenemos activada esa directiva, como es el caso del servidor de mi amigo, pero, también el de esta misma bitácora. En este caso se puede optar por varias soluciones.

La primera es no hacer nada, es decir, actuar como si la directiva ya no existiera: con el inconveniente de que no podrán guardarse caracteres especiales como las comillas dobles o simples dentro de las opciones de Gesbit, puesto que estas se guardan serializadas, y luego no podrían ser "unserializadas" correctamente. Ahora bien, ¿qué se hace entonces? ¿Codificamos en base 64 la cadena serializada antes de guardarla en la base de datos?

Es una mala solución, sobre todo, porque no me canso de repetir que "magic quotes" es una directiva condenada a desaparecer, y, por lo tanto, basar nuestro trabajo en los posibles inconvenientes que sin duda ocasiona, no es algo que deba hacerse. Ahora bien, ¿entonces qué nos queda? Pues tener en cuenta la directiva en cuestión, y aplicar el "stripslashes" correspondiente, sólo si la directiva está activada, y, lo más importante: sólo si no se trata de un valor "serializado".

Es decir, cuando se guardan las opciones de Gesbit en esta misma bitácora, cuyo servidor tiene habilitada la directiva "magic quotes", no se "escapa" la cadena que contiene las opciones serializadas con la función "stripslashes", sino que se aplica sólo el filtro que en realidad ha de aplicarse (y que basta sin la directiva "magic quotes" activada), que es "mysql_real_scape_string". Si se trata de una valor "no serializado", entonces sí se aplica "stripslashes".

Pero siempre únicamente si la directiva "magic quotes" está activada. Si no lo está, que es lo que se espera en el futuro, se usa sólo "mysql_real_scape_string", tanto para valores serializados como para valores sin serializar, porque, insisto una vez más, sin esta directiva activada no hay ningún problema en que un valor serializado contenga comillas dobles o simples, ni tampoco que las contenga un valor sin serializar.

Y esa es la solución de compromiso a la que he llegado en Gesbit. Digo de compromiso porque acaso lo suyo sería decirle a mi amigo, "mira, estás usando la directiva "magic_quotes", que no se recomienda, y así no podrás incluir comillas dobles o simples en la descripción de tu blog". Podría decirle esto, y él que es muy amable así lo haría, pero, lo cierto es que la directiva fatal no depende de él, sino de su servidor.

Y da la casualidad de que esta directiva en concreto no puede cambiarse en tiempo de ejecución, según el manual de PHP, luego hay que tener acceso al archivo "PHP.ini"; lo que no es posible en el caso de mi amigo, ni tampoco en el mío, por cierto, hablando de esta misma bitácora. Así que de momento creo que el asunto puede quedar como he dicho. En el momento en que la directiva "magic quotes" deje de usarse, se eliminará su comprobación en Gesbit.

Así lo he apuntado en el código fuente de la función "Escape" de la clase "MySQL", dejando claro que se está haciendo algo "por compromiso", pero, que, en un futuro, la condición que se lleva a cabo y el mirar o no si el valor a escapar es una cadena serializada o no, ya no será necesario, sino que podrá prescindirse de ello sin problema alguno. Otros problemas vendrán, pero, al menos este que es una pesadilla pasará a la historia.

Menudo lío me he montado yo solo (bueno, en realidad no tan así) con las opciones de Gesbit y su serialización. Resulta que ayer me escribe mi amigo Álvaro, que está queriendo usar Gesbit para una de susbitácoras, informándome de cierto problema que se encuentra al querer guardar una determinada opción de Gesbit: la descripción de la bitácora, concretamente. ¡Llevo toda la tarde de ayer y toda la noche de hoy con este asunto y ahora por fin parece que me aclaro un poco!

De todas las soluciones que he intentado, al cabo he optado por la que mejor me parece: olvidarme de la directiva "magic quotes" de PHP. Efectivamente, la clase "MySQL" de Gesbit cuenta con cierto métod para escapar los datos de las consultas SQL que se llevan a cabo, y, en dicho método, si la directiva en cuestión está activada, se hace uso de la función "stripslashes" de PHP, antes de llevar a cabo el filtro de la cadena propiamente dicho. Pues bien, he quitado del medio dicha función, olvidándome de la directiva.

Y es que el manual de PHP lo deja claro: no debe trabajarse en función de dicha directiva, porquese trata de una opción obsoleta, que no estará ya en PHP 6, y que (esto lo digo yo, aunque también lo pone en el manual) no deja de dar problemas en versiones anteriores de PHP, incluida la 5, que es la versión actual y que necesita Gesbit para funcionar. ¡Incluso he llegado a guardar las opciones "serializadas" de Gesbit previamente codificadas en base 64! Pero esto era un error, y he vuelto atrás, porque, en realidad, sin esa directiva, no hay problemas con las opciones, incluso si estas contienen caracteres "especiales" como puedan ser comillas dobles o simples.

Pero... entonces... ¿qué pasa si la directiva "magic quotes" está activada? Pues a mí me funciona como se espera de todas formas, y espero que a mi amigo Álvaro también, pero, estoy dispuesto a darke a Álvaro la siguiente solución: "no uses caracteres especiales en el nombre o en la descripción del blog", antes que pensar en codificar las opciones luego de serializarlas, antes, en fin, de seguir trabajando con una directiva de PHP que está ya considerada obsoleta, y que no hace sino dar problemas, pero, esto ya lo he dicho. Y eso es lo que hay. Creo que por ahora voy a dejarlo tal cual, porque, como he dicho al principio, menudo lío me he montado yo solito...

He llegado a actualizar la versión estable de Gesbit, ¡y la beta!, con los cambios (usando base 64 para las opciones) y claro, he tenido que "volver atrás", y actualizarla de nuevo sin esos cambios. Pero, sea como sea, ahora la versión estable está igualada con la versión "beta", y además ya no hace uso de la directiva de marras, y salga el sol por donde salga, de verdad, porque, menuda pesadilla con este asunto, ¡qué frustrante no saber si estaba haciendo algo bien o qué! Es que no te imaginas los cambios que he procurado, antes de darme cuenta de que bastaba con dejar de usar la directiva "magic quotes", mejor dicho, dejar de "preguntar" si estaba activa o no.

Sea como sea, ya digo, mañana le diré a Álvaro que actualice Gesbit, en realidad sólo un determinado "script" ("mysql.class.php"), si es que no lo hizo ya ayer tarde (porque fue una de las opciones que le propuse) o que descarge la versión estable, ya actualizada y al día, y, en caso de que tenga problemas con la descripción del blog... que no use caracteres especiales, puesto que me consta que su servidor usa "magic quotes", y por ahí puede venir el problema, como digo, de que se corrompan las opciones, por decirlo así. Creo que es la mejor solución, aunque no sea tal, porque, repito, el manual de PHP lo deja claro: "no trabajes en función de la directiva magic quotes, puesto que no se recomienda al estar obsoleta". Uf...

Voy avanzando en el servidor XML-RPC de Gesbit. En la anterior entrada trataba ciertas cosas y adelantaba algunas otras. Por ejemplo, adelantaba que ya estaba mirando la API XML-RPC de Blogger y también la de MetaWeblog. Y ahora puedo decir que las dudas que tenía acerca de qué API o APIs implementar en Gesbit no han hecho sino acrecentarse. Por ejemplo, la API XML-RPC de Blogger es una API obsoleta, que el propio Google no recomienda usar en nuevos clientes.

Y, sin embargo, el cliente Microsoft Live Writer, parece soportar la API de Blogger, además de otras, aunque, no he podido comprobarlo por completo, porque no he llegado a implementar completamente la API de Blogger, y dudo si al final voy a hacerlo, al menos de momento. Voy a tratar de razonar esta negativa a implementar la API de Blogger, y aun el resto de APIs conocidas, y que, debería implementar, si se quiere que una bitácora gestionada con Gesbit pueda ser "editada desde fuera".

Ahora bien, aquí el más tonto hace relojes, y así tenemos que la API de Blogger no está ya recomendada, el API de MetaWeblog cuenta con ciertas extensiones de otras APIs, y no termina de convencerme, porque, entre otras cosas, no cuenta con cierta información que tienen los "posts" de Gesbit, como etiquetas, categorías, etc. Implementar estas APIs no me atrae en absoluto, y casi prefiero implementar una API propia, como, por otro lado, terminan haciendo también otras herramientas similares.

Claro está, hacer algo así, impide que Gesbit se abra al mundo, por decirlo de alguna manera. Quiere decirse que vería muy raro que Microsoft Live Writer, por poner un ejemplo, quisiera alguna vez soportar el API de Gesbit. Hombre, nada es imposible, pero, ahora mismo es pensar en lo excusado. Entonces, ¿para qué un API XML-RPC propia de Gesbit, que no iba a reconocer ninguno de los clientes XML-RPC que existen en el mercado y acaso existan en un futuro? Muy sencillo: porque no dejaría de estar disponible, y algún cliente podría trabajar sobre ella.

Yo mismo, sin ir más lejos, podría crear un cliente XML-RPC que fuera capaz de trabajar con el API correspondiente de Gesbit, si bien no estoy diciendo que sea una tarea sencilla o que pudiera llevarse a cabo de un día para otro. De ahí que esté en dudas: porque si se implementan las APIs conocidas, aunque no me parezcan bien, mejor dicho, aunque no me atraigan en absoluto, lo cierto es que se estará dejando la puerta abierta a no pocos clientes XML-RPC, pero, si no se implementan, y se implementa sólo una propia de Gesbit... el cliente deberá esperar.

Mi idea, ahora mismo, es implementar un API propia de Gesbit, y, después, ya veremos, que dijo un ciego. Temo que hubiera que duplicar cierto código haciéndolo así, porque es más fácil extender alguna de las APIs existentes, para que soporte ciertas características exclusivas de Gesbit, que crear una API de Gesbit "a mi gusto", que no se adaptará en absoluto a otras APIs. De modo que si después se terminan implementando otras APIs, habría que hacerlo prácticamente desde cero. Esto es, si el API de Gesbit tiene un método "InsertPost", y la API de MetaWeblog otro (similar) ambos métodos serían en realidad métodos separados.

Así que en esas estamos. A lo mejor debería tomarme con un poco de calma este asunto, y, en lugar de ponerme a añadir métodos como loco (es un decir) de un API propia de Gesbit, debería, digo, estudiar un poco más el resto de las APIs, y ver hasta qué punto conviene hacer una implementación "mixta" (aprovechando los mismos métodos de unas para otras) o si verdaderamente me decido por no implementar ninguna otra API que no sea la propia de Gesbit. Los lectores de esta bitácora no sois muy dados a comentar (bien es cierto que no hay muchos lectores...), pero, cualquier sugerencia sobre este asunto será bienvenida.

Día de cambios en Gesbit, vive el Espagueti Volador. Para empezar, estoy ya planteándome la posibilidad de añadir alguna API (aunque sea la propia de Gesbit, para empezar) de modo que sea posible efectuar tareas sobre una bitácora desde una aplicación de terceros, utilizando el protocolo XML-RPC. Gesbit cuenta desde casi un principio con un servidor XML-RPC, de modo que acepta este tipo de peticiones, empero, todavía no se implementó ninguna API, así que en realidad es algo que no puede utilizarse actualmente, aunque ciertos cimientos estén disponibles, como digo.

Hoy he comenzado una aproximación sobre este asunto, y, lo primero que he hecho ha sido implementar en Gesbit el "Really Simple Discoverability 1.0" o simplemente RSD. Esto ha consistido en dos cosas. La primera, completar la cabecera de los temas por parte de Gesbit, de modo que se incluya el apropiado "meta enlace", de modo que una aplicación pueda "descubrir" a partir de ahí dónde encontrar cierto archivo XML, que a su vez contiene información acerca de las APIs que la aplicación soporta, en este caso Gesbit, a través del protocolo XML-RPC.

Así que he incorporado a Gesbit un nuevo tipo de petición (mediante la clase "Query" de Gesbit), que es a la que apunta el "meta enlace" susomentado, y esta parte de una URL que es: "www.bitacora.com/rsd/". En esa URL las aplicaciones de terceros podrán encontrar una respuesta en forma de archivo XML, que sigue la especificación RSD. Dicho archivo XML contiene información acerca de la aplicación (Gesbit) y también las URLs de los puntos de entrada de las distintas APIs soportadas. En el caso de Gesbit sólo hay un punto de entrada: "www.bitacora.com/xmlrpc/" y ahí se indica a las aplicaciones que pueden realizar sus peticiones XML-RPC.

Por otro lado, pero, sin salirnos en realidad del mismo tema, hacía tiempo que quise añadir una opción a Gesbit, de modo que los usuarios puedan especificar si quieren que aplicaciones de terceros tengan acceso a dichas APIs a través del protocolo XML-RPC. Este es otro de los cambios incorporados a Gesbit, de modo que, efectivamente, existe ya una nueva acción "de escritura" para determinar si quiere hacerse uso del mencionado protocolo en la bitácora o si no quiere hacerse uso del mismo. De forma predeterminada esta opción especifica que no se permita el uso de dicho protocolo.

He hecho otros cambios y mejoras en Gesbit al hilo de todo esto, y, por ejemplo, estoy contento de que añadir una nueva opción de este tipo a Gesbit no represente ningún cambio en la base de datos, es decir, por el momento, incluso con esta "novedad", los usuarios de la versión 1.0 estable de Gesbit podrán pasar a la siguiente versión (digo, de momento) sin necesidad de que Gesbit necesite hacer cambios en la estructura de la base de datos, o tenga que añadir nuevos datos para que estén disponibles. Al contrario, bastará revisar las opciones de escritura para que las opciones se actualizen "por sí solas", y, cuando no se haga esto, la opción correspondiente tiene, como todas las demás, un valor por defecto, que será el que se utilice.

Claro, dicho lo anterior pareciera que todo este asunto del soporte para XML-RPC está resuelto, pero, lo cierto es que nada más lejos de la realidad. Aún queda implementar alguna API, no sé si empezando por la que podría incorporar el propio Gesbit (acaso mejor pensada que las otras... no, mejor dicho, pensada a mí manera... je je je) y terminando por las que fueran menester, puesto que hay varias disponibles, conque las herramientas de terceros mencionadas pueden comunicarse en mayor o menor medida. Está la API de Blogger, la de MetaWeblog, y unas cuentas más. Así que lo que he hecho hasta ahora es preparar el asunto, pero, todavía queda mucho por hacer de todos modos.