Sin embargo, a la hora de validar las páginas de la bitácora usando el tema GbMobile con el nuevo tipo de documento, me he encontrado conque el W3C me advertía del uso del atributo "onclick" en ciertos elementos, en concreto, los que tienen que ver con el CAPTCHA de Gesbit, puesto que este permite "recargarse" y "escucharse", y para esto hace uso de los atributos "onclick" y su poquito de Javascript. pero XHTML Mobile Profile 1.0 no pasa por ahí, amigo.

Así que he aprovechado para mejorar un aspecto de la clase CAPTCHA que me viene preocupando desde hace tiempo: la personalización de los elementos del formulario "HTML" en que se muestra la imagen en cuestión, y el resto de código HTML necesario. Ahora, el método "FormFields()" de la clase Captcha de Gesbit permite especificar, entre otras cosas, si se requieren los enlaces para "recargar" y "escuchar" la imagen CAPTCHA, de modo que GbMobile, simplemente, los omite.

Esto no significa que no puedan escribirse comentarios, pero, la mecánica cambia un poco respecto de la habitual en el resto de temas de Gesbit: en el tema de GbMobile no hay "vista previa" del comentario, porque para esto también se usaba cierto atributo "onclick", y, como podrá imaginarse, tampoco es posible "recargar" ni "escuchar" el CAPTCHA. Sin embargo, es posible añadir comentarios, y por supuesto el test CAPTCHA estará ahí si se está usando en la bitácora, que, como sabes, es opcional.

En fin. Termino recomendando la lectura de cierto artículo que me parece muy útil y curioso: Global Authoring Practices for the Mobile Web, de Luca Passani. Y, por cierto, la demostración de Gesbit cuenta con el plugin GbMobile, y puedes probarlo, si te apetece, en el emulador del navegador Opera Mini. Abre el enlace anterior y escribe en el navegador: www.demo.gesbit.com ¡Que usted lo pase bien! ;-)

De hecho, tenía un tanto abandonado el panel de administración en este sentido, y es que, aunque para las páginas de una bitácora procuraba enviar las cabeceras HTTP correspondientes, mediante la clase "FrontEnd" de Gesbit, no era así para los "scripts" del panel de administración, puesto que para estos "scripts" no se utiliza la clase "FrontEnd" en absoluto, pensada sólo para las páginas de las bitácoras.

Sea como sea, trabajando en otra cuestión, me he dado cuenta de que no estaba comprobando correctamente si un agente de usuario acepta la compresión GZip. Concretamente, el validador del W3C no acepta este tipo de compresión en los documentos para validar, y, había un error cuando se comprobaba esto, de modo que no se habilitaba la compresión Gzip correctamente. Al arreglar esto he trasteado en la clase "FrontEnd" y al cabo he acabado con una clase nueva: "UserAgent".

Como una forma de evitar el duplicado de código, y también para poner ciertas cosas en su sitio. Efectivamente, la clase "FrontEnd" contenía métodos que comprobaban si el agente de usuario aceptaba la compresión Gzip, y, por extensión, si este era el validador del "W3C", métodos estos que quedan mejor en una clase aparte, como es "UserAgent", puesto que se trata de obtener información del agente de usuario. Pero además se evita desde ya cierto duplicado de código.

Y es que, como he dicho, ahora se envían las correspondientes cabeceras HTTP también en los "scripts" del panel de administración, y se ha de comprobar si el agente de usuario acepta la compresión GZip, para habilitarla si es el caso, de modo que también la clase "Admin" hace uso de la nueva clase "FrontEnd", y no tiene que implementar (duplicar) lo necesario para averiguar si el agente de usuario soporta este tipo de compresión o no la soporta.

En definitiva, que, en virtud de estos cambios que relato, Gesbit sirve ya las páginas con compresión GZip, si está disponible (la correspondiente extensión para PHP) y la acepta el agente de usuario. Y que esto mismo se hace en los "scripts" del panel de administración. La clase "FrontEnd" se ha aligerado y existe una nueva clase "UserAgent" que ya es ciertamente útil y acaso puede serlo más aún en el futuro. Y esto es lo que tenía que decir respecto a la compresión Gzip. ;-)

Hasta ahora estaba funcionando bien; aparentemente, comprobar si en el directorio del caché existían archivos expirados, lo que significa revisar todos los archivos de dicho directorio, no llevaba mucho tiempo, aunque, como un egregio lector de esta bitácora apuntaba en un comentario, quizá era demasiado revisar esta cuestión a cada petición de los usuarios, puesto que, si la bitácora tenía muchas visitas, muchos archivos "cacheados", esto podía implicar un consumo excesivo de recursos. No quedó claro cómo de excesivo, pero, ciertamente, tampoco se puede dejar de pensar en ello.

Mientras se implementa o no en Gesbit una especie de "Cron", una especie de "gestor de tareas", se me ha ocurrido algo muy sencillo, pero, que, no se me ocurrió en su momento, y es utilizar una variable de sesión para comprobar si ya hemos comprobado el contenido del caché expirado para una determinada sesión de usuario. Es decir, ahora no se comprueba la expiración del caché a cada petición de usuario, sino a cada sesión de usuario, quiere decirse, que nos ahorramos todas las peticiones del mismo usuario, aunque, por supuesto, otros usuarios podrán ejecutar la limpieza del caché, en otra sesión de usuario.

Además, he "movido" el punto en que se comprueba si existe contenido en el caché expirado o no. Efectivamente, este punto es justo el momento en que se va a proceder a enviar contenido cacheado al usuario, por supuesto, si antes ha sido guardado. El cambio consiste en comprobar el caché expirado sólo si la petición del usuario es "cacheable", lo que quiere decir que es posible que exista contenido cacheado para ella. Si la petición de usuario no es cacheable, tampoco se comprobará el caché expirado, y no como se hacía hasta ahora, que se comprobaba en todo caso.

La verdad es que apenas si se nota diferencia. Mejor dicho, no se nota, porque, como he dicho arriba, tampoco se notaba ninguna "perturbación" por comprobar el caché expirado a cada petición del usuario, pero, es de suponer (o al menos así lo he supuesto) que algo se habrá ganado con esta medida. Sobre todo, si llega el caso de que una determinada bitácora gestionada con Gesbit, y que use el caché de contenido integrado, cuenta con una cantidad de visitas formidable. Quizá hasta podría realizarse alguna prueba sobre este asunto, pero, de momento, quédese como está.

Ahora bien, acaso el egregio lector a que me he referido esté leyendo esto, y quisiera preguntarle, ¿qué te parece, maestro, esta solución "ad hoc"? ¿Puede valer o qué? ;-)

Antes de mostrar las cifras, me gustaría decir algo al respecto. Para la comparativa he utilizado versiones recién instaladas, tanto de Gesbit como de Wordpress, si bien he añadido ciertos "Widgets" a este último, como pueda ser el que muestra las últimas entradas en la "barra lateral", puesto que Gesbit lo muestra de forma predeterminada. Lo mismo cabe decir para los últimos comentarios, la "nube de etiquetas", la lista de categorías, fechas, etc. Es decir, he tratado de ambos sistemas muestren información similar en cada uno de sus apartados, de modo que la comparativa fuera, al menos en este punto, más o menos realista.

Otra cosa más me gustaría añadir. Las cifras que se mostrarán a continuación son para los usuarios sin autenticar, es decir, para los lectores de una bitácora, pongamos por caso. Porque, si se trata de usuarios autenticados, a las cifras que daré habrá que sumar dos consultas SQL, en el caso de Gesbit, mientras que, en el caso de Wordpress, no habrá que sumar consulta alguna. Ignoro ahora mismo porqué Gesbit hace las mismas consultas SQL para usuarios autenticados y no autenticados, pero, el caso es que las cifras muestran las consultas necesarias para usuarios sin autenticar, y, como he dicho, Gesbit realiza dos consultas más (en cada apartado) para los usuarios autenticados, precisamente, porque ha de obtener los datos de dichos usuarios.

Sin más dilación, he aquí la comparativa en cuestión, que, después de lo dicho, igual queda hasta un poco ridícula. Sin embargo, puede verse cómo Gesbit realiza menos consultas SQL para mostrar similar información, y, además, persigue el objetivo de hacerlo de este modo: usar las menos consultas SQL posibles, de modo que luego podré añadir algo más a este respecto. Ahora vengan las cifras en cuestión, comparando el número de consultas SQL necesarias para conformar los distintos apartados de una bitácora en ambos sistemas:

Portada: GB 12 - WP 23
 
Entrada: GB 10 - WP 16
 
Página: GB 7 - WP 24
 
Categoría: GB 14 - WP 23
 
Etiqueta: GB 14 - WP 24
 
Autor: GB 13 - WP 23
 
Fecha: GB 12 - WP 23
 
Feed RSS: GB 5 - WP 13

¿Qué te parece? Como puede verse, en todos los apartados Gesbit realiza menos consultas SQL a la base de datos. A veces, como para el caso de mostrar entradas ("singles") la diferencia es de 6 consultas SQL, mientras que, para el caso de mostrar una página de la bitácora, Gesbit lo hace con 7 consultas SQL, mientras que Wordpress require 24. A todo esto he dicho que iba a añadir algo. Y es que, por ejemplo, esta bitácora que lees ahora, hace uso de varios plugins para Gesbit, empero, no suman en absoluto ninguna consulta más a la base de datos.

Efectivamente, dichos plugins hacen uso de las opciones "autoload", de modo que en una sola consulta se traen las opciones necesarias, tanto para Gesbit como para los plugins que lo requieren. Digo esto, porque, no ya sólo es que me he esforzado en mantener bajo el número de consultas SQL necesarias en Gesbit, sino que lo mismo he hecho mirando por los plugins y temas para Gesbit. En general, los plugins para Gesbit no suman consultas SQL a la base de datos de la bitácora, y tanto estos como los temas se pueden beneficiar del sistema de caché de consultas, que, hay que decirlo, creo que también existe en Wordpress.

Dicho todo esto, que conste que no sólo no tengo nada en contra de Wordpress, sino que, por el contrario, mucho que agradecer a sus autores, puesto que Gesbit utiliza prácticamente la misma estructura de base de datos que la de Wordpress (este asunto no es lo mío, desde luego), con pocos cambios, y también en Gesbit hago uso de ideas y hasta código fuente de Wordpress, algunas funciones, por ejemplo, están recogidas de este estupendo gestor de bitácoras, con el que acaso Gesbit no puede competir, no nos engañemos, ¡siempre que no hablemos del número de consultas SQL que ambos sistemas realizan!

De todos modos, para terminar, me referiré de nuevo a lo "científico" de la comparativa, que no tiene nada de esto. Por ejemplo, no conozco tanto Wordpress como para afirmar a ciencia cierta que estamos comparando cosas iguales. Dicho de otro modo, es posible que Wordpress cuente con alguna característica con la que Gesbit no cuenta, y es posible que dicha característica requierea el uso de la base de datos. En esta comparativa no he mirado estos "detalles". Me he limitado a hacerlo "por encima", porque, por encima, ciertamente, una portada es una portada, una entrada es una entrada, el archivo de etiquetas es lo que es, etc. Es por esto que considero esta comparativa como más o menos válida, pero, júzgalo tú mismo en todo caso. ;-)

Ahora vamos con lo bueno: los cambios, los últimos cambios llevados a cabo, que, han propiciado el salto de versión y que me alegran especialmente, porque tenía ganas hace tiempo de llevarlos a cabo, pero, no me he decidido hasta hoy, que, según he despertado, ha sido pensar en Gesbit y en dichos cambios, y verlos como algo posible y hacedero. Así que me he puesto a ellos. Y aquí están. Hacía ya tiempo que estaba viendo un agravio comparativo (siempre he querido decir esto) entre los temas y plugins para Gesbit. ¿Qué ocurría? Pues, estoy hablando de que los plugins para Gesbit no necesitan cargar su "dominio de texto" para ser traducidos, puesto que de esto se encarga el propio Gesbit, mientras que los temas sí tenían que encargarse de esta tarea.

Para ello contaban con lo necesario, es decir, el archivo "functions.php" (tal vez lo renombre algún día de estos), donde los temas podían implementar funciones útiles para su traducción, de modo que no usaran las funciones "para traducir" conque cuenta Gesbit (ya hablaremos luego), que harían que tuviesen que indicar su "dominio de texto" ("textdomain") a cada paso. De modo que los temas implementaban dichas funciones "auxiliares", y también, en el propio archivo "functions.php" se habían de encargar de establecer el "textdomain" correspondiente, de modo que no hubiera confusión entre distintos "textdomains" (el propio de Gesbit y los de los plugins que lo necesitasen). Ahora bien, ¿por qué no se encargaba Gesbit de cargar el "textdomain" de los temas y sí lo hacía para los plugins?

En realidad no estoy muy seguro. No recuerdo exactamente porqué razón, empero, sí que he sabido casi desde un principio que sería posible para Gesbit cargar el "textdomain" de los temas, de una forma similar a como lo hace con los plugins. Era cuestión de ponerse a ello, como he podido comprobar hoy. Ahora, los temas no necesitan cargar expresamente su "textdomain", Gesbit se encargará de ello, si es que el tema está preparado para su traducción (cuenta con el correspondiente archivo "PO"). Pero, precisamente por esto, ya no son necesarias las funciones auxiliares relacionadas del archivo "functions.php" de los temas, sino que he añadido a la clase "G" (que está para los temas y plugins, básicamente) los métodos necesarios para llevar a cabo la traducción de las cadenas que se utilicen en un determinado tema.

Con todo y con eso, ya puesto, no me he querido quedar ahí. Gesbit usa funciones auxiliares (implementadas en el archivo "gb-i18naid.php") para tratar con la clase "I18n". Son funciones de "nombre corto", porque, se usan profusamente a lo largo de todo el código fuente. Estas funciones sirven para traducir cadenas, para retornar cadenas traducidas y para imprimirlas, directamente. Estoy hablando de las funciones "_r()", "_e()", "_rp()" y "_ep()". Pues bien, el cambio en este sentido ha ido por acortar el identificador, prescindiendo de los "guiones bajos", de modo que ahora queden en "r()", "e()", etc. Ahora bien, había un pequeño lío con los identificadores de estas funciones en relación con temas y plugins, y es que cada uno de estos elementos las nombraba de forma distinta.

Esto se vió bien en su momento porque para trabajar con archivos "PO", hay que especificar la serie de identificadores, correspondientes a funciones (o métodos) que contienen de algún modo las cadenas a traducir: en su momento se comprobó que si se usaban los mismos identificadores para Gesbit, temas y plugins, a la hora de "actualizar desde las fuentes" el archivo "PO" de turno, las cadenas podían entremezclarse, es decir, el archivo "PO" de un tema, por ejemplo, tomaría como propias las cadenas que en realidad pertenecen al "corazón" de Gesbit. Este es un problema real, que, efectivamente, existe, pero, la solución que se dio en su momento: usar diferentes identificadores, era poco elegante, confusa, solucionaba un problema poniendo en medio otros.

Otros problemas a un nivel mucho más bajo que los archivos "PO", porque una cosa es "tener cuidado" cuando se actualiza un archivo "PO", y otra marcar a fuego distintos identificadores en el propio código fuente de Gesbit, plugins y temas incluidos. ¿Adónde quiero llegar? Pues a que ahora se utilizan siempre los mismos identificadores, esto es, "r", "e", "rp" y "ep", tanto en Gesbit, como en temas y plugins, sólo que estos se encuentran separados por su ámbito, lo que además ayuda a clarificar bastante las cosas. Gesbit usará la función "r()", un tema usará el método "r()" de la clase "G", y un plugin usará un método propio (heredado de la clase "GbPlugin) también de nombre "r()". Habrá que prestar atención a la hora de "actualizar desde las fuentes" los archivos "PO", pero, considero que es mucho mejor esto que la solución (provocadora de confusión) que tomé en un principio ante este "problema".

En definitiva, hoy es otro de esos días en que estoy contento del desarrollo de Gesbit, porque, cuando me percato de este tipo de cosas, sólo caben dos salidas: dejar las cosas como están (porque al fin y al cabo funcionan) o llevar a cabo los cambios necesarios, y tirar adelante con una mejor solución, que para eso se hacen los cambios. Los plugins de Gesbit más o menos siguen como antes (he actualizado todos ellos, a la vez que el propio Gesbit y las bitácoras en que lo uso, y todo ha ido rápido, a pedir de boca, muy sencillo, quizás porque tengo a Gesbit en la cabeza desde hace meses), salvo que en lugar de usar sus métodos "_r" y "_e", por ejemplo, usan los nuevos métodos "r" y "e". Para los temas (los tres que existen actualmente y que yo mismo desarrollo) el asunto pinta mejor: ya no necesitan cargar su "textdomain", ni siquiera preocuparse de ello, sino que es Gesbit quien lo hace cuando es menester.

Esto simplifica la traducción de temas, puesto que para que un tema pueda ser traducido el desarrollador no necesita sino escribir algo como "G::r('Cadena')", en lugar de sólo "cadena" (literalmente). A partir de ahí, podrá incorporarse al tema un archivo "PO", y este ser traducido a distintos idiomas, sin que sea menester por parte del desarrollador del tema absolutamente nada más. Así no hay muchas excusas para hacer un tema "intraducible", ¿no te parece? No hay que cargar "textdomains", ni preocuparse de preparar "funciones auxiliares". Sólamente usar el método "G::r()" cada vez que queremos retornar una cadena traducida, o bien "G::e()" cada vez que queramos imprimirla, sin más. Y, en fin, estos y algunos otros cambios menores, además de todos los cambios llevados a cabo desde la publicación de la versión 1.0, han sido los que me han animado a publicar la actual versión 1.1 estable de Gesbit, así como la correspondiente "beta".

Ya sabes que puedes descargar Gesbit desde su sitio web. Puedes descargar temas y plugins desde su wiki (que algún día tendré que revisar, aunque ya lo he hecho respecto de estos últimos cambios, y está al día, pero, quisiera hacer cambios y completarla en lo posible una año de estos...) y puedes, por último, probar Gesbit "en línea" en su demostración. Me gustaría que te fuera de utilidad y lo disfrutases en lo posible. Eso es todo. ¡Hasta la próxima! ;-)