Bitácora de Gesbit

Hace pocas entradas lo comentaba: estaba buscando las vueltas para que los plugins no necesitasen requerir o incluir clases PHP por su cuenta. Después de echar un vistazo a cierta biblioteca para PHP que podría serme útil para cierto plugin, precismante, me percaté de que algo así sería realmente útil. No diré sino que dicha biblioteca cuenta con su propia función "autoload": porque estamos hablando de decenas de clases.

Para utilizar dicha biblioteca en un plugin para Gesbit, por lo tanto, sería preciso hacer unas cuentas decenas de "require" en PHP, para incluir cada una de las clases que, acaso, no iban a utilizarse después. Así que, había que hacer algo, y he dado unas cuentas vueltas al asunto en estos días, hasta hoy, que me he puesto un poco más en serio con ello y he conseguido una implementación a mi manera de ver bastante digna.

Pero, he tenido que equivocarme un par de veces para llegar a la solución que al final he adoptado. Tengo que decir que un primer momento me he liado bastante, porque mi objetivo era conseguir que los plugins pudiera añadir directorios donde buscar clases "a demanda". Es decir, incluir una acción que permitiera a los plugins especificar ciertos directorios donde Gesbit habría de buscar clases cuando fueran necesarias.

Pero, esta implementación me ha parecido un tanto rebuscada, y, en la práctica no era nada sencilla y complicaba las cosas tal vez demasiado. Así que, aunque sin descartar una solución parecida, he optado por simplificar, de modo que además no tuviera que realizar prácticamente cambios en Gesbit. Lo que he hecho ha sido añadir una función al archivo "gb-autoload.php", precisamente, donde se encuentra la función "__autoload" de PHP para Gesbit.

Dicha función es llamada únicamente una vez, precisamente, desde la propia función "__autoload", y lo que hace es reunir los directorios "originales" donde buscar clases (que ya se usaban antes de estos cambios) junto con los directorios "pscripts" de los plugins instalados (ojo, acaso no activados) disponibles en la instalación de Gesbit. Efectivamente, los plugins cuentan con una serie de directorios "predeterminados" y uno de ellos es "pscripts".

Esto pretende hacer la vida más fácil al autor de plugins, puesto que sus plugins, que son clases hijas de la clase "GbPlugin", cuentan con métodos, como por ejemplo, uno que retorna la ruta absoluta al directorio "pscripts" o su URL. Lo mismo vale para directorios como "jscripts", "images" y "styles". Pues bien, a partir de ahora los plugins pueden situar las clases de PHP que necesiten en el directorio "pscripts", y Gesbit las "autocargará" como el resto de clases, cuando sean necesarias.

Sin embargo no está todo dicho, porque el autor del plugin deberá tener alguna cosa en cuenta todavía: se sigue la misma convención que en Gesbit, debe haber una clase por archivo, y el nombre del archivo será el nombre de la clase más la extensión ".class.php". Si además en el directorio se encuentra un archivo "nombre de la clase" más la extensión ".const.php", también será incluido: exactamente igual que se hace en Gesbit.

Dos plugins se están beneficiando ya de este nuevo "sistema", como lo son los plugins "GbDefensio" y "GbTextile" para Gesbit. El "inconveniente" vendría dado (según lo veo ahora) porque hay que seguir las mencionadas convenciones para que "todo funcione", pero, en todo caso, ya podría hacer uso de la biblioteca de que hablaba al principio sin necesidad de hacer decenas de "requires" o "includes".

Quiero decir con esto último que acaso con dejar a los plugins "añadir" sus propios directorios se ganaría en algo, pero, lo que está claro es que también se sumaría cierta complejidad que tal vez merezca la pena ahorrarse en este caso, precisamente. Todo se andará, pero, creo que de momento, con una sola nueva función en Gesbit (y algunos cambios menores) se ha logrado no poco y bastante práctico, creo yo.

En el panel de administración de Gesbit no se hace un uso excesivo de AJAX, es decir, por ejemplo, para cambiar el estado de privacidad de una determinada entrada, desde el formulario de gestión de entradas, hay que "seleccionarla" y ejecutar la correspondiente "tarea". Y esto vale para una entrada o para varias a la vez, si se quiere. Otra posibilidad es editar la entrada, directamente.

He añadido un poco más de AJAX al panel de administración de Gesbit, y, me ha costado hacerlo, no creas. No que haya sido complicado, pero, que me ha costado decidirme a hacerlo o no. Ahora es posible editar "in situ" todas las propiedades de entradas, páginas, comentarios y enlaces. Como digo, no ha sido complicado de implementar, empero, no ha sido esto lo que me ha hecho dudar.

Porque, vamos a ver, está claro que poder cambiar el estado de privacidad de una entrada "con un clic" (en lugar de con un par de ellos) puede resultar útil, empero, siendo posible hacerlo, como digo, con un par de clic... ¿hasta qué punto merece la pena "complicar las cosas"? Básicamente se trata de complicar el código XHTML de los "scripts" en cuestión, si bien no excesivamente.

Además de lo dicho, ¿cada cuánto tiempo necesitas cambiar el estado de privacidad de una entrada? Tengo la sensación de que una bitácora puede ser algo lo suficientemente serio como para tomarse las cosas con más calma. Así, no me importaría tener que editar una entrada sólo para hacerla "privada", porque no es una cosa que se deba tomar a la ligera. Sin embargo,... ahí están los cambios.

Alguna vez he escrito aquí mismo que no pensaba añadir características en Gesbit que no fueran realmente necesarias. Y por eso cuando hago este tipo de añadidos me lo pienso más de una vez y más de dos. Y aún así hay veces que, dado por "terminado" el asunto, implementados los cambios, todavía me queda por saber si he hecho lo correcto o no. Creo que en este caso he acertado.

He acertado porque en realidad no se ha añadido nada a los formularios del panel de administración. Simplemente, donde antes se mostraba un "sí" o un "no" (para indicar si una entrada estaba publicada o no, por ejemplo) ahora se muestra el mismo "sí" o "no", salvo que este es un enlace, que, puede usarse para cambiar el valor de esa misma propiedad. Pero no hay ningún otro misterio, el asunto no va más allá (ni más acá).

Y tampoco se "rompe" con el sistema actual. Quiero decir, la "lista de tareas" que pueden aplicarse sobre entradas, páginas, comentarios, etc., sigue siendo perfectamente válida. Tal vez ya no para ejecutar una tarea sobre una sola entrada, pero, sí para hacerlo sobre varias entradas al mismo tiempo. Además, las tareas no se reducen sólo a cambiar ciertas propiedades de una entrada, por ejemplo, tambiém es posible hacer cosas como exportar una o varias entradas.

En fin, ya lo sabes: ahora es posible cambiar las propiedades "booleanas" de entradas, páginas, comentarios y enlaces, directamente, "in situ", gracias a "AJAX", en el panel de administración de Gesbit. Si quieres, puedes verlo ahora mismo en la demostración de Gesbit. Por lo demás, notarás también algún otro cambio en las "tablas" de los formularios, ahora con algunos elementos "centrados". ;-)

Hace tiempo estuve buscando una buena solución para este asunto, es decir, para disponer de un "autocompletado" en la casilla que sirve para añadir etiquetas a una determinda entrada. Además de algo sólo curioso o bonito, lo cierto es que puede resultar práctico y útil, puesto que de un vistazo permite conocer las etiquetas disponibles sobre un determinado asunto, y además, en el caso de "autocompletado" que he preparado, el número de entradas en que se usan las etiquetas.

Para implementar este asunto he utilizado el plugin Autocomplete para jQuery, que, es verdaderamente completo, todo hay que decirlo. Cuenta con las opciones suficientes y aun más (que nunca se sabe) y está probado (y comprobado) en los navegadores en que se prueba Gesbit: Firefox, Opera, Internet Explorer y Safari. El "autocomplete" se pone en marcha al escribir en la casilla para las etiquetas de una entrada. Un sólo caracter pone en marcha el mecanismos y ya nos ofrecerá posibles resultados. Es posible seguir escribiendo para ir afinando la búsqueda.

En definitiva, una nueva característica en Gesbit que creo que merece la pena. No es que sea el acabose, pero, me alegro de que ya pueda contarse con ella y quería comentarlo aquí además. ;)

Vale. Lo reconozco. No se me ha ocurrido otro título más estúpido. Pero, verás que algo tiene que ver con lo que comentaré a continuación. Investigando sobre cómo implementar una determinada característica en Gesbit (básicamente, cómo pueden añadir los plugins nuevos directorios a tener en cuenta en la función "autoload" para clases en Gesbit), digo, me he encontrado con el orden en que se cargaban las clases, al menos las de una instalación "limpia" de Gesbit.

Este orden distaba ya mucho de ser aleatorio, es decir, me estoy refiriendo al orden en que se cargan las clases "principales" de Gesbit, y algunas otras auxiliares, que, puede verse en el archivo "gb-globals.php" y, como digo, sobre el que ya había dado más de una y dos vueltas. Sin embargo, hoy he querido fijarme en dicho orden de nuevo, principalmente, por la clase "GbCache", que, como sabes, también me ha preocupado y aun me preocupa. Pues bien, este era el mencionado orden:

Timer
Input
I18n
CachedFileReader
StringReader
GettextReader
GbCache

No nos fijaremos sino en las siete primeras clases (hay algunas más) para quedarnos en la clase "GbCache", precisamente. Ahora bien, lo que más me llamó la atención fue la necesidad de la clase "I18n", porque, esta a su vez requiere las tres siguientes en la lista, así que me puse a ver para qué usaba esa clase en "GbCache".

En realidad ya lo sabía: la usaba para traducir ciertas cadenas de texto que se usan en la clase "GbCache" en dos circunstancias: para mostrar una especie de mensaje "estadístico" en el pie de cada página servida desde el caché, y, para el mensaje de error que muestra Gesbit si se especifica un directorio para el caché, pero, este resulta inválido.

Ahora bien, ¿era realmente necesario traducir dichas cadenas? Según lo he visto ahora no, no lo era. El error no se mostrará "casi nunca", y, desde luego, está destinado a no mostrarse. Por otro lado, los errores "de requisitos" en Gesbit tampoco se muestran traducidos, sino en el inglés "original", y es que entonces no está siquiera disponible la clase "I18n".

Así pues, quedaba el mensaje que añade información en el pie de las páginas enviadas desde el caché. Este mensaje, hay que decirlo, es una "vacilada". Quiero decir, lo que viene a decir es, "Esta página requirió pocas consultas SQL para su creación, pero, con el caché no requirió ninguna en absoluto". Vale. Me gusta. Es verdad. Está bien. ¿Pero merece la pena traducirse?

Teniendo en cuenta que la "vacilada" significa tener que cargar cuatro clases antes que la clase "GbCache", desde luego, no parece que sea necesaria su traducción. Por lo demás, no es complicado de entender, en mi opinión. Sea como fuera, no hablamos sólo de las cuatro clases necesarias para traducir esa "vacilada", sino que hablamos de cargar el archivo de lenguaje de marras, o sea de unos 50 KB cada vez.

Visto lo visto, no me ha quedado más remedio: he decidido prescindir de la clase "I18n" en la clase "GbCache", de modo que el orden de carga se altera de este modo:

Timer
Input
GbCache

Como ves nos quedamos ahora en las primeras tres clases, puesto que con eso llegamos a la que nos interesa: "GbCache". En este punto me acordé de que la clase "Timer" realizaba una tarea "obsoleta", por decirlo así. Y claro, ya puestos, tenía que ponerme con ello. Se trata de que la clase "Timer" se usa para la vacilada comentada arriba, y en otros lugares, pero, sea como sea, para calcular el tiempo que lleva la respuesta al usario.

Para esto la clase "Timer" se instanciaba en primer lugar, precisamente, para "recoger" el tiempo de "inicio de Gesbit", de modo que después pudiera calcularse el "tiempo final", y así calcular el tiempo de la respuesta al usuario. Ahora bien, la clase "Timer" tenía sentido antes de PHP 5, puesto que, desde esta versión de PHP contamos con la variable "REQUEST_TIME" en el array super global "$_SERVER".

Dicha variable, precisamente, especifica el tiempo de inicio de la respuesta al usuario, y a partir de ella podemos después calcular cuánto tardamos en responder al usuario en total. Así que para quitar la clase "Timer" del medio ha bastado un nuevo método público en la clase "Input", "RequestTime", que proporciona la información que al cabo se perseguía con la clase "Timer".

Total, que el orden de carga de las clases en Gesbit queda tal que: "Input", "GbCache", siendo necesaria sólo una clase hasta llegar a la clase "GbCache" y que esta se ponga en marcha. Recuérdese que hablo de clases, pero, en realidad me estoy refiriendo a variables globales. En el archivo "gb-globals.php" se inicializan las principales de Gesbit, y ahora el orden queda como se ha dicho.

Input
GbCache

Luego de la clase "Input" (que realmente necesita, a no ser que le demos acaso demasiadas vueltas al asunto) la clase "GbCache" se pone en marcha, lo que quiere decir que en caso de contar con contenido en el caché, el mismo será enviado en ese punto al usuario. Algo hemos ganado, pues, con estos cambios, aunque me temo que hablemos de pocos milisegundos. Pero tal vez algos más. ¿No te parece?

Creo que voy a dejar un poco el asunto del CAPTCHA de Gesbit, puesto que ya es posible recargarlo, es posible escucharlo. El caso es que he seguido con el asunto, y, por ejemplo, ahora también es posible "estilizar" el CAPTCHA mucho mejor, es decir, todos sus elementos se encuentran "identificados" o "clasificados", de modo que mediante CSS (como se hace ahora también en los temas de Gesbit) es posible determinar cómo y de qué manera se muestran los distintos elementos.

La última novedad, sin embargo, sobre la que quería comentar aquí, es que he añadido al "CAPTCHA sonoro" ciertos ruidos aleatorios. No son ruidos de fondo, pero, fragmentos de audio que intercalan entre los caracteres del propio CAPTCHA. Estos ruidos son cuatro, actualmente, el mismo número que fuentes usa el CAPTCHA, y, como estas, se escogen aleatoriamente, de modo que va a ser complicado que un mismo CAPTCHA, incluso con iguales caracteres, se escuche igual.

Debido a este último cambio me he decidido por dejar en tres el número de caracteres que muestra la imagen del CAPTCHA. Cuando se escucha el CAPTCHA, de este modo, este "dura" cinco segundos apróximadamente, y ni uno más. Además, pienso que esto no compromete demasiado la seguridad del CAPTCHA, puesto que, aunque supongo que no será invulnerable, creo que sus colores y fuentes aleatorias dejan el listón al menos no demasiado bajo. Creo yo. ¿Eh?

Al final no he podido resistirme. Tal como apuntaba en esta anterior entrada, luego de poder "recargar" el CAPTCHA de Gesbit, quedaba pendiente ver de poder "escucharlo". Y eso es lo que ahora puede hacerse, tanto en inglés como en español, pudiendo en un momento dado añadir más lenguajes, añadiendo archivos WAV, de la misma manera que se pueden añadir más fuentes o cambiar las actuales para usar en el CAPTCHA de Gesbit.

Se sabía que algo así iba a incrementar el tamaño de la distribución de Gesbit, pero, al cabo no han sido muchos kilobytes, dejando el audio lo más "pequeño" posible, y además teniendo en cuenta que se añaden sendos alfabetos (si bien no completos) tanto para inglés como para español. Gesbit se encuentra de entrada disponible en estos dos lenguajes, así que el CAPTCHA debía tener en cuenta al menos esto. Lo que se me ha ocurrido a última hora ya no es tan sencillo: en qué lenguaje leer el CAPTCHA.

Ahora mismo se usa el lenguaje de la bitácora, siempre que sea inglés o español, y, en caso de que no sea ninguno de estos... se usaría el inglés para leer el CAPTCHA, lo que me deja un tanto parado, primero, porque he caído en este asunto al final, y, segundo, porque no sé muy bien qué solución podría aportarse. No todo el mundo sabrá cómo se pronuncia la letra "F" en inglés, por ejemplo. O qué pasaría si un angloparlante quiere dejar un comentario en nuestra bitácora, aunque esta se escriba en español.

Sea como sea, no he querido echarme atrás. Al fin y al cabo esta es una característica que podía echarse en falta desde un principio. Efectivamente, el CAPTCHA, junto con algún filtro antispam (proporcionado por el plugin GbDefensio) y la moderación de comentarios, hacen que el SPAM sea prácticamente inexistente (a día de hoy) en las bitácoras que gestiono con Gesbit. Ahora bien, un CAPTCHA no accesible... un CAPTCHA que podía recargarse, y que no podía escucharse... dejaba fuera a ciertas personas sin más ni más. Así que estoy contento de haber podido por fin incorporar estas últimas características en el CAPTCHA de Gesbit, ahora un poco mejor, más completo, más accesible.

Últimamente le estoy dando a este del CAPTCHA bastante tralla, como suele decirse. Sobre todo en lo que se refiere al plugin GbReCaptcha para Gesbit, pero, también al CAPTCHA que incorpora el propio Gesbit "de serie". Lo último es que ya es posible recargar la imagen CAPTCHA, es decir, para los casos en que esta muestre caracteres poco legibles o confusos. En realidad ha bastado con un poquito de JavaScript, aunque, en honor a la verdad, ha sido el código de PHP Captcha el que me ha puesto la solución en bandeja de plata.

En realidad he llegado a plantearme la posibilidad de integrar PHP Captcha en Gesbit, es decir, no como un plugin, como en el caso de GbReCaptcha, sino sustituir el código que se utiliza ahora por el de PHP Captcha, bien utilizando la clase conque Gesbit cuenta, bien haciendo las cosas desde un principio, por decirlo así, replanteándome la situación. Las características de PHP Captcha son muy curiosas, y bueno, no estaría mal que Gesbit contase con algo así de entrada, he pensado. Sin embargo de momento dejo las cosas como están, si bien, como digo, acabo de añadir la posibilidad de recargar el CAPTCHA "in situ".

Otra de las características de PHP Captcha (o de reCAPTCHA) es la posibilidad de escuchar el CAPTCHA, lo que supongo vendrá bien para personas con dificultad visual, dicho mal y pronto. Sin embargo esto lo cubre perfectamente (mejor que bien) el servicio de reCAPTCHA, es decir el plugin GbReCAPTCHA para Gesbit. Implementar algo como lo que hace PHP Captcha no sería del todo dificultoso, sino que añadiría peso a Gesbit, puesto que se trata de contar con tantos archivos de audio como caracteres (letras y números) admita el CAPTCHA, de forma que luego se "unen" y forman un sólo archivo que el usuario puede escuchar.

reCAPTCHA va más allá que eso, puesto que cuando uno escucha uno de sus CAPTCHA no escuchará las palabras que aparecen en la imagen, sino una serie de números, además en el lenguaje en que se use el servicio, que será lo que el usuario haya de proporcionar para superar el test. PHP Captcha se limita (lo que no es poco, por otro lado) a deletrear el CAPTCHA, pero, como digo, para esto necesita de una serie de archivos de audio que ocupan unos 700 KB, y que están disponibles sólo en inglés. Quizás le esté dando demasiadas vueltas a este asunto: todo para evitarme el trabajo y dejar el CAPTCHA de Gesbit como está ahora mismo.

Sea como sea, lo añadido ahora, es decir, la posibilidad de recargar la imagen del CAPTCHA sin salirse del formulario en cuestión, era una característica que se echaba más o menos en falta y que ya está disponible. Lo de que el CAPTCHA pueda "escucharse" tampoco es una característica desdeñable, y así acaso me plantee añadirla, igual dejando los archivos de audio fuera de la distribución de Gesbit, de modo que quien quiera usarlos tenga que descargarlos aparte. Algo parecido a como se hace ahora con las fuentes del propio CAPTCHA, que pueden cambiarse a voluntad también. En fin, ya veremos... o ya escucharemos...

No hace mucho que publiqué la primera versión del plugin reCAPTCHA para Gesbit, y, hoy le he dado una vuelta de tuerca más, aprovechando las características que ofrece el servicio de reCAPTCHA para personalizar el "widget" en el que se muestra la imagen CAPTCHA en cuestión, pero, también mucho más... y es que este reCAPTCHA es mucho CAPTCHA, ciertamente.

Ahora el plugin utiliza un "tema personalizado" para reCAPTCHA, de modo que se adaptará mejor (o esa es la idea) a los diferentes temas de Gesbit. Además el plugin aprovecha ahora el lenguaje en uso en una determinada bitácora, de modo que, por ejemplo, la ayuda de reCAPTCHA se muestre en el lenguaje correspondiente.

Se han añadido varios enlaces "fuera" del "widget" de reCAPTCHA, para recargar la imagen, para "escucharla" (mediante un plugin para el navegador), para escucharla sin necesidad de plugin alguno, para mostrar la ayuda susomentada, y para volver a mostrar una imagen luego de haber utilizado el enlace para escucharla.

Lo cierto es que el plugin reCAPTCHA para Gesbit todavía podría ir un poco más allá, por ejemplo, dejando al usuario la posibilidad de elegir uno de los temas disponibles para el "widget" de reCAPTCHA. Sin embargo, de momento, como queda dicho, no se usa ningún tema en concreto, sino un "widget" completamente personalizado. Pero todo se andará.

Actualización: Estaba claro. ¿Para qué tratar de personalizar algo que no iba a quedar bien en todos sitios? ¿Por qué no usar, directamente, uno de los temas que están disponibles para el "widget" de reCAPTCHA? Esto es lo que se puede hacer ahora con el plugin para Gesbit. Es posible elegir uno de los temas disponibles, y el "widget" se mostrará así mejor de todas, todas.

Me alegra poder escribir esta entrada. Hacía tiempo que quería llevar a cabo ciertos cambios, ciertas mejoras en Gesbit, relativas a la exportación de entradas y páginas. Hasta hoy esta tarea se llevaba a cabo desde un apartado propio en el panel de administración de Gesbit, y ahí sigue, empero, he llevado a cabo ciertos cambios en la clase "GbExporter" de Gesbit, de modo que ahora esta se desliga de ese apartado en concreto.

Esto quiere decir que no sólo podrán exportarse todas las entradas de una bitácora desde el susomentado apartado, que, dicho sea de paso, me preocupa un tanto, en cuanto a que se pueden aplicar ciertas restricciones en la exportación, pero, no el límite de entradas a exportar, lo que quiere decir que en bitácoras con muchas entradas podría resultar un problema. Exportar del orden de 1000 entradas no entraña ninguno, y hasta ahí he podido llegar yo.

Sin embargo, no descarto hacer algunos cambios en el futuro, de forma que se pueda establecer un límite, digamos, de 1000 entradas, de modo que pudieran exportarse poco a poco. Sea como sea, la exportación en Gesbit no pretende cubrir la necesidad de las copias de seguridad, que pueden llevarse a cabo por otro lado, de manera que toda nuestra base de datos esté a salvo: no sólo entradas y páginas. El exportador está más bien pensado para poder copiar algunas entradas.

Por ejemplo, todas las entradas publicadas de un determinado autor, pueden exportarse de una bitácora gestionada con Gesbit, y exportarse en otra bitácora también gestionada con Gesbit. Todo se exporta: comentarios, categorías, etiquetas, de modo que sería posible copiar, trasladar entradas y páginas de unas bitácoras a otras. Sea como fuere, el caso es que hasta ahora era un todo o nada: Gesbit proporcionaba el exportador susomentado y punto pelota.

Pero, gracias a los cambios que he llevado cabo en la clase "GbExporter" y algunos otros añadidos, ahora es posible exportar una o más entradas y páginas, directamente, desde sus respectivos formularios que sirven para gestionarlas. De esta forma, será posible localizar aquella o aquellas entradas que queramos exportar, exportarlas, y tenerlas ya disponible para su importación en alguna otra bitácora gestionada con Gesbit.

¿No es mala idea, verdad? Sabía que te gustaría. :P

Hace un tiempo dejé de usar en Gesbit, cuando se lleva a cabo la "gran consulta", una consulta SQL, precisamente, del tipo "LIKE", para pasar a usar una de tipo "MATCH", que ofrece mejores resultados. Hoy le he dado una vuelta de tuerca más a este asunto, he añadido índices "fulltext" a no pocos campos de la base de datos, y he dejado de usar el "LIKE" donde venía usándose hasta ahora todavía en formularios del panel de administración de Gesbit.

Como digo, además he añadido algunos índices y editado otros. Por ejemplo, el buscador de las bitácoras venía buscando en el campo "contenido" de las mismas, y ahora lo hará también en el campo "título". En los formularios del panel de administración se notará más, puesto que, por ejemplo, de buscar sólo en el cuerpo de los comentarios, ahora se buscará ahí, usando "MATCH" en lugar de "LIKE", y también en los campos "author", "email" y "url".