Bitácora de Gesbit

Con un peso de 1,54 KB comprimido y una sóla línea de código, se presenta el plugin GbNoFollow, que, sencillamente, como no podía ser de otra manera, puede usarse para añadir el atributo "nofollow" a los enlaces que se incluyan en el cuerpo de los comentarios de las bitácoras. El atributo "nofollow", mejor dicho, el valor del atributo "rel", "nofollow", se utiliza por algunos buscadores para "no seguir" ciertos enlaces, con el fin de evitar posibles "enlaces spam", por ejemplo, en los comentarios de los sitios web (escritos por terceros, por decirlo así), y de modo además que se mejore en lo posible la calidad de los resultados de dichos buscadores, al no incluir los sitios web enlazados usando esas técnicas de "spam".

En definitiva, un plugin realmente sencillo, como prácticamente todos los "filtros", que, si le hace falta a alguien, podrá utilizar en su bitácora. Personalmente, no creo que lo utilice, puesto que suelo controlar bastante bien, hasta el momento, los comentarios que recibo, de modo que todos son "amigos", por decirlo así, a los cuales se les permite enlazar lo que quieran, porque confío en ellos. Pero, en fin, ahí queda GbNoFollow para quien quiera usarlo, como digo, y también quien quiera puede echar un vistazo a su código fuente, a su línea de código, al plugin, vaya, a ver qué le parece, si es que le parece algo. ;)

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.

Ops... una vez más, tengo que comerme mis palabras, y es que, si en la segunda parte de esta serie de entradas pensaba (y así lo dije) que había encontrado una solución para el problema que me traigo con el plugin GbMobile para Gesbit y el sistema de caché de este, digo, en esta ocasión tengo que decir que no es así, realmente, y que el problema se solucionó sólo a medias, lo que es decir que todavía no tiene solución.

En cierto modo hemos vuelto al principio, si bien la primera solución que se encontró al asunto sigue aún sin convencerme, de modo que podríamos decir que no estamos realmente en el principio, pero, que, algo va mal. Y es que si el plugin GbMobile puede deshabilitar el caché cuando establece el tema "para móviles" en Gesbit, y esto funciona, no es suficiente.

Porque, ¿qué ocurre cuando el plugin GbMobile no deshabilita el caché? Pues que si este está activado guarda la respuesta correspondiente, para servirla después. "Sí; pero es que el plugin GbMobile volverá a deshabilitarla en la siguiente petición". No; porque para cuando el plugin tenga la posibilidad de cambiar el tema el caché ya habrá servido la respuesta.

Así que en ese sentido estamos como al principio: con un problema de uso del plugin GbMobile. De hecho es un problema, porque alguien puede visitar la bitácora con un móvil, y, aunque este plugin esté activado, es posible que se le sirva (al usuario) una respuesta previamente cacheada, y no para un dispotivio móvil, precisamente. ¡Y ahora mismo no se me ocurre nada!

Y no lo digo por decir. O sea, se trata de que no veo otra solución ahora mismo sino que ambas cosas: plugin GbMobile y el sistema de caché de Gesbit, no sean compatibles, es decir, no puedan tenerse "juntas". Lo que me parece algo demencial, porque yo mismo, en esta bitácora, uso las dos cosas, y no me gustaría tener que dejar ninguna de ellas de forma obligada.

Pero el tema es complicado. Porque el plugin puede "comunicarse" el sistema de caché, pero, este no puede hacerlo con el plugin. Recordemos que el sistema de caché se pone en marcha antes de hacer ninguna consulta a la base de datos: antes de que los plugins se inicializaran, por lo tanto, puesto que primero hay que conocer los plugins que están "activos" y los que no.

Y, para esto último, se requiere de una consulta a la base de datos de Gesbit, que, sin entrar en detalles, en todo caso se llevará a cabo luego de que el sistema de caché guardara la respuesta correspondiente, si es que tiene que guardarse. De modo que igual uno puede pensar que hay algo que falla en el sistema de caché de Gesbit, que, por un lado, promete, pero, luego no da.

Es decir, es estupendo que el sistema de caché no use la base de datos: eso ahorra recursos, y de eso se trata, precisamente. Pero, al hacerse de este modo, se da al menos el inconveniente que es parte del problema de que vengo hablando en estas últimas entradas. Es un problema de base, que, podría solucionar en un pispas: simplemente, inicializando los plugins antes que el sistema de caché.

Pero, claro, ¿qué hay entonces de la mejora que representa que no sea necesaria ninguna consulta a la base de datos en absoluto? ¿Tú cómo lo ves? Yo pienso que esto último puede llegar a ser una posible solución (párrafos más arriba no sabía de ninguna...) y además ofrecer alguna ventaja: precisamente, la de que los plugins puedan interactuar con el sistema de caché, y viceversa.

Pero ya no podría decirse aquello de "servida sin ninguna consulta a la base de datos"... :(

Actualización: Por el momento descarto esto último (que no suena por lo demás muy descabellado) y vuelvo a usar el "agente de usuario" a la hora de guardar una respuesta en el caché. Esto evita cualquier problema, es decir, nos deja como estábamos en la primera entrada de esta serie, al menos: de este modo el sistema de caché pierde un tanto en eficacia. Y sólo puedo decir que este asunto continuará...

Cuánto me alegra poder escribir la segunda parte de la entrada Vamos a contar verdades. Como sabes, si has leído la primera parte, el sistema de caché integrado en Gesbit sufrió una especie de retroceso en sus virtudes, que creo que alguna tiene, modestia aparte, como consecuencia, digo, de la entrada en escena del plugin GbMobile para Gesbit. El asunto, muy resumido, era la posibilidad de que se "cacheara" la respuesta para un dispositivo móvil, siendo que otro usuario podría recibir dicha respuesta "cacheada" navegando tranquilamente desde su ordenador personal, es decir, no con un dispotivo móvil, sino con otro tipo de navegador.

La solución que tomé en su momento fue añadir al caché de Gesbit el "agente de usuario", lo que identificaba también a los posibles dispositivos móviles, de modo que no fuera posible que la respuesta cacheada para un dispositivo móvil fuera servida a un usuario que no navegara con dicho dispositivo. Pero, en la entrada Vamos a contar verdades se asumía por mi parte lo evidente: era una mala solución, porque hacer uso del "agente de usuario" implicaba que se cachearían más contenidos, siendo así que el sistema de caché, sin perder toda su potencia, sí que la veía mermada.

Entonces ya intuí otra posible solución, pero, no sé si fruto del calentamiento que tenía encima, la dejé pasar, hasta hoy, que he vuelto a retomar el asunto, y he visto que, efectivamente, se trata de una mejor solución que la vista e implementada en un primer momento. Ahora el sistema de caché no hace uso del "agente de usuario", tal como era al principio, de modo que la potencia del sistema de caché ha vuelto a sus orígenes, dicho mal y pronto. Ahora un usuario que navegara con Opera, por ejemplo, recibiría la misma respuesta cacheada que otro usuario que navegara con Firefox.

¿Cómo lo he hecho? La verdad es que el asunto era sencillo, pero, había que verlo. Se trataba de deshabilitar el caché, en caso de que el plugin GbMobile entrara en acción. El quid del asunto estriba en que el plugin establece el tema "móvil" antes de que el sistema de caché de Gesbit guarde la respuesta correspondiente. De este modo, he añadido a la clase "GbCache" sendos métodos, para habilitar o deshabilitar el caché, y el plugin "GbMobile" hace uso de este último, deshabilitando el caché en caso de que se reconozca un dispositivo móvil y se establezca el tema correspondiente para el mismo.

Luego entonces, dirás, ¿no se guardan en caché las respuestas para dispositivos móbiles? Pues así es, actualmente, y, sin embargo, esta solución es mejor que la primera por razones evidentes. En primer lugar, como queda dicho, al no usar el "agente de usuario" para preparar respuestas cacheadas, el sistema de caché es más potente, o vuelve a ser tan potente como lo era en un principio. En segundo lugar, las respuestas "móviles" (que no se cachean) son respuestas de muy poco peso, del orden de 2 KB. No digo que no merezca la pena cachearlas, pero, compárese con lo que significaba tener en cuenta el "agente de usuario" en el sistema de caché.

Además, ha de tenerse en cuenta que era el sistema de caché el que estaba adaptándose al plugin GbMobile, por decirlo así: fue por este plugin que se comenzó a tener en cuenta el "agente de usuario" en el sistema de caché. Pero no todo el mundo usará el plugin "GbMobile", ni siquiera todo el mundo usará el sistema de caché (que en Gesbit es opcional, por cierto, y de entrada no está "activado"), así que no tenía mucho sentido tener presente que alguien pudiera usar dicho plugin, sino que había de ser el plugin quien tuviera sus costes, por decirlo así, y no todo el sistema de caché de Gesbit. En definitiva, y, sea como sea, esta solución me agrada mucho más que la primera.

¿A ti no te lo parece? Yo desde luego estoy contento sabiendo que el caché de Gesbit vuelve a ser el que era, que no por eso tengo que dejar el plugin "GbMobile", puesto que, aunque sus respuestas no se cacheen, me sigue pareciendo un buen plugin, que cumple con su función bastante decentemente. Y ya está. ¡Si me vieras! Ahora mismo estoy sonriendo, pensando que cuando llevé a cabo estos cambios era perfectamente consciente de que la poca previsión, por decirlo así, de que el sistema de caché había perdido parte de su potencia, y yo no supe encontrar entonces una solución mejor. Hasta hoy. ;-)

El tema era un tanto peliagudo, porque, el sistema de caché de Gesbit está integrado para algo... y es que se pone en marcha antes que nada, y, si encuentra la respuesta "cacheada" para la petición "actual", simplemente, procede a su envío. El caché de Gesbit no hace uso en absoluto de la base de datos, no hace ni una sola consulta. Ahora bien, lo que se hace ahora es no guardar la respuesta correspondiente, incluso si el caché está activado, en caso de que el plugin GbMobile entre en acción. De este modo, en una siguiente petición, el sistema de caché buscará una posible respuesta guardada, pero, no la encontrará, y dejará seguir adelante a Gesbit.

Mi amigo Álvaro Martínez, quien, por cierto, está traduciendo Gesbit al catalán, me comentó hace un tiempo sobre la posibilidad de utilizar el servicio que ofrece reCAPTCHA en Gesbit, en lugar del CAPTCHA que Gesbit ofrece, opcionalmente, desde un principio. En su momento no lo ví claro, pero, esta noche me he puesto con ello y ya está disponible una primera versión del plugin GbReCaptcha para Gesbit.

Creo que la implementación ha quedado bastante bien. He hecho cambios en la clase "Captcha" de Gesbit, de modo que cualquier plugin puede "interceptar" las correspondientes (nuevas) "acciones" para hacer uso de su propio sistema de CAPTCHA. El plugin GbReCaptcha así lo hace, sustituyendo el CAPTCHA original de Gesbit por el de reCAPTCHA, pero, sin intervención alguna por parte del usuario de Gesbit: se instala el plugin, se rellenan sus opciones, y ya está.

Además he probado el plugin junto con GbContactForm, puesto que este hace también uso del CAPTCHA original de Gesbit. Y funciona como se espera. De hecho, como digo, se sigue usando la clase "Captcha" de Gesbit, sólo que esta ahora interactúa con los plugins instalados, y, para estos es posible sustituir el CAPTCHA de Gesbit por el suyo propio: pero "por fuera" todo funciona igual.

El servicio que ofrece reCAPTCHA es interesante, porque, además de proporcionar un CAPTCHA seguro, pero también accesible (cosa que no hace, hay que decirlo, el CAPTCHA original de Gesbit), además también sirve para colaborar con una buena causa: la digitalización de ciertos libros, concretamente. Puedes encontrar más información en el sitio web de reCAPTCHA. Además, para usar este plugin, es preciso que cuentes con ciertas "Api Keys", que te ofrece el sitio web de "reCAPTCHA" de forma gratuita.

Cabe añadir que este plugin no funcionará en la versión "estable" actual de Gesbit. Debido a que se han llevado a cabo cambios en la clase "Captcha" y en la clase "GbPlugins" de Gesbit, y estos cambios no están presentes en la versión "estable" de Gesbit. Por el momento, el plugin sólo funcionará en la versión "beta". Ciertamente, sobre esto tengo dudas: no sé si actualizar la versión estable o no, puesto que por este "añadido" no dejaría de ser estable. Se admiten sugerencias.

Comento aquí ciertos cambios que he llevado a cabo en el plugin GbLightbox para Gesbit, porque me parecen ciertamente curiosos por lo menos. Este plugin tiene la característica de ser el primero que desarrollo que necesita la traducción de ciertas cadenas "en JavaScript". Es decir, el resto de plugins también son multilenguaje, pero, este necesitaba además que ciertas variables de JavaScript contuvieran las correspondientes cadenas localizadas.

Gesbit cuenta con una clase "JScript" (que acaso habría que revisar) que a su vez tiene un método que "imprime" variables de JavaScript con un determinado valor, y este era el método que he estado usando en GbLightbox, de manera que en el código fuente de las bitácoras en que uso el plugin, podía verse el código JavaScript necesario, es decir, las variables que contenían las cadenas que necesita el plugin debidamente traducidas. Pues bien, veamos los cambios.

En un primer momento se me ha ocurrido utilizar un "script" PHP. De este modo, en lugar de requerir el archivo JavaScript que pone en marcha el plugin, he pensado en que este script fuera en realidad procesado por PHP, de modo que ahí mismo podía llevar a cabo la traducción de las cadenas correspondientes. Sin embargo, esta solución pasaba por requerir el archivo de inicialización de Gesbit, claro está, para poder contar con los recursos necesarios.

He llevado a cabo esta solución, como digo, pero, acto seguido me he dado cuenta de que podía aún mejorarse. Efectivamente, estamos hablando de cinco o seis cadenas a traducir, y todo podía hacerse de una forma más sencilla. ¿Cómo? Preparando varios archivos JavaScript. Cada uno de los cuales inicializa el plugin en el lenguaje correspondiente. Al requerir los archivos JavaScript necesarios, se busca el que debería corresponder al lenguaje usado en Gesbit.

No obstante se comprueba antes la existencia de dicho archivo, y, de no existir, se requiere el archivo "por defecto", que corresponde al idioma inglés. Actualmente GbLightbox está disponible en inglés y en español, pero, añadir nuevos idiomas es tan sencillo como "clonar" uno de los archivos existentes, de alguno de los idiomas disponibles, y traducir las cadenas necesarias al idioma al que se quiera traducir el plugin. En todo caso, esta solución, parece mejor que la primera que intenté, y, por supuesto, parece en todo caso mejor que como se hacía al principio.

Ahora no se ve código JavaScript en el código XHTML de mis bitácoras, puesto que se requiere el archivo JavaScript correspondiente sin más. Pero además este es un archivo JavaScript, es decir, estático, no un archivo PHP, como en la primera solución, de modo que nos ahorramos los recursos necesarios para procesar dicho archivo, inicializar Gesbit, traducir las cadenas, etc. Creo que he tenido un momento de inspiración que sin duda tendré que tener en cuenta para futuros plugins. Esta parece ser una solución mucho más elegante, y me felicito por ello. ¡Que no tengo abuela! ;-)

PD. Si quieres ver este plugin "en acción", puedes echar un vistazo a esta entrada de mi bitácora personal.

No he hecho sino publicarlo (ayer mismo) y ya he hecho unos cuantos cambios en el plugin GbMobile para Gesbit. El que acabo de llevar a cabo es especialmente relevante, por cuanto era algo que se me había pasado por completo. Como sabes, una de las características del tema que incluye GbMobile, es el hecho de producir código HTML mínimo, con muy poco de CSS, y nada de JavaScript.

Pues bien, nada menos que se me había pasado evitar el "Complete Theme Header" de Gesbit, de modo que incluso el tema de GbMobile estaba incluyendo el JavaScript que incoporan a Gesbit ciertos plugins. Me he dado cuenta al echar un vistazo a mi propia bitácora, puesto que el tema predeterminado en Gesbit no incluye nada de JavaScript y no me había percatado del asunto.

El caso es que ahora, luego de este cambio, la portada de mi bitácora personal con el tema GbMobile, ocupa menos de 2 KB. Como lo oyes, en concreto 1,50 KB poco más o menos. Y una entrada "en solitario", con todo su texto, viene a ocupar menos de 4 KB, unos 3,50 más o menos. Estos son cifras, creo, más o menos razonables para dispotivos móviles. Y para eso GbMobile.

Si visitas de casualidad esta bitácora con algún dispositivo móvil, como pueda ser un teléfono, una consola, un "PDA", es posible que el nuevo plugin GbMobile lo "reconozca", y establezca cierto tema ("GbMobile", que incluye el propio plugin) de manera que el contenido de la bitácora se te muestre de la forma más amable posible para el dispositivo con el que la estás leyendo.

Básicamente, como digo, se trata de comprobar el dispositivo navegador que estás utilizando, de modo que si el plugin lo encuentra entre sus "posibles", cambia el tema que en ese momento esté establecido en tu bitácora, a uno propio que incorpora el plugin, y que muestra menos contenido, por decirlo así, y utilizando un código HTML algo más rudimentario, si se puede decir así.

Sin embargo, todos los apartados de una bitácora están disponibles: es posible navegar por entre etiquetas, categorías, autores, fechas, etc. Pero el tema "GbMobile" no muestra, por ejemplo, el contenido de las entradas, cuando se solicita la portada de la bitácora, sino sólo los títulos de las entradas, categorías y etiquetas en que se guardó, y enlaces para verla completa.

El HTML que envía el tema "GbMobile", por tanto, ocupará menos. Del contenido de las entradas se eliminan las imágenes, al menos por ahora, de modo que se envía sólo su texto. Es posible leer y publicar nuevos comentarios, así como buscar en la bitácora. En general el tema "GbMobile" es como cualquier otro, pero, en lo posible adaptado a dispositivos móviles.

Por supuesto, al tratarse de un plugin que incorpora un tema, este último se "lista" junto con el resto de temas disponibles, e incluso podría utilizarse sin más. El plugin comprueba si el tema que está en uso es ya "GbMobile", de modo que no hace nada, en el sentido de que ya lo tiene todo hecho. Sin embargo, el uso de "GbMobile" es más o menos el que he dicho antes.

Se trata de tratar de reconocer si el dispositivo conque se visita tu bitácora es un dispositivo móvil, y sólo en este caso el plugin entra en acción cambiando el tema. Además, el cambio es temporal, y no deja rastro en el cliente en forma de "cookies" o algo así. El tema se cambia sólo para la petición de un usuario, en caso de que dicho usuario navege con un dispositivo móvil. Y punto.

Quiero dar las gracias a Julián, que fue quien me acució a que me pusiera con algo así. Además le doy las gracias por anticipado, porque le pido que me diga cómo se ve Gesbit desde su móvil, si es que le reconoce... cómo se ve el tema "GbMobile", y qué tal se mueve uno por él, si no es mucho pedir. Por hache o por be yo no puedo probarlo ahora mismo sino en mi ordenador.

No diré que sea cosa de coser y cantar, nada de eso, pero, gracias a las recientes mejoras introducidas en Gesbit, es posible comenzar a pensar en plugins para Gesbit que tengan por objetivo el panel de administración de Gesbit. Es cierto que quedaría mucho por decir, pero, fíjate lo que puede hacerse en un par de minutos:

(Haz clic en las imágenes para agrandarlas)

Como ves en las imágenes, se trata de cambiar el estilo del panel de administración de Gesbit, "de blanco a negro". Obviamente, el trabajo llevaría más de dos minutos: eso es lo que me ha costado cambiar un par de valores en la hoja de estilo, de manera que puedas ver el escritorio del panel de administración de Gesbit negro, completamente distinto a como viene de forma predeterminada.

Cuando hablo de cambiar la hoja de estilo, es justamente a eso a lo que me refiero, y es que, para hacer lo que vengo diciendo, he utilizado un plugin que implementa un sólo método "PrinterCallback()" tal que así:

public function PrinterCallback($printerID){
  if($printerID == GBPLUGINS_PRINTER_ADMIN_HEADER){
    $this->IncludeCSSInAdminPanel(
      new CssFile(
        $this->GetDirStylesUrl() 
         . 'my-gb-admin.css'
      )
    );
    $this->UnIncludeCSSInAdminPanel(
      GbUrls::GetAuxiliarsUrl() 
        . 'styles/gb-admin.css'
    );      
  }
}

Es decir, que, como puedes ver, efectivamente, lo que hacemos es quitar la hoja de estilo que añade el propio Gesbit, y sustituirla por nuestra propia hoja de estilo, que es la que cambiaría de aspecto el panel de administración de Gesbit. Ya. No se me escapa que eso se dice muy fácil... pero que conllevaría su buen trabajo. Pero lo que yo quería decir, como habrás podido imaginar, es que ahora es posible hacer algo así en Gesbit, gracias a las mejoras recién introducidas.

Lo mismo aplicaría para archivos JavaScript. Ahora un plugin puede incluir los suyos propios dentro del panel de administración, y también, en un momento dado, sustituir alguno de los que incluya Gesbit por su cuenta. Huelga decir que con sólo lo dicho habría que ver cómo y de qué manera es posible desarrollar un plugin curioso para el panel de administración: estoy seguro de que "faltan cosas", pero, al menos hoy se está mejor que ayer en este sentido.

Ya está disponible la primera versión de un nuevo plugin para Gesbit, muy sencillo, pero, espero que útil a más de una persona. Se trata del plugin GbRandomPost, y, como su nombre, en inglés, trata de expresar, el plugin se puede utilizar para ofrecer a los lectores de una bitácora la posibilidad de mostrar una entrada "aleatoria" de entre todas las publicadas.

El plugin no necesita sino de un enlace (ver el archivo "README" que se incluye con el plugin) que los lectores de una bitácora pueden seguir, de manera que "GbRandomPost" se pondrá en marcha, escogerá una entrada al azar, pero publicada, y no privada, y redirigirá sin más al lector a dicha entrada escogida aleatoriamente. No es necesario más.

Tal vez en un futuro podría determinarse que la entrada aleatoria perteneciera a una determinada categoría, por ejemplo, pero, por el momento, el plugin escoge entradas, como he dicho, publicadas, no privadas, con fecha anterior "a la actual", y de cualquier categoría existente. También incluye a las páginas de la bitácora, por otro lado. Y eso es todo.

Actualización: Lo había puesto en mi bitácora, pero, por error, lo he añadido también en esta, y ya lo dejo ahí donde está. Me refiero al enlace "¡Salta!" que puedes ver en la parte superior de esta misma página, a tu derecha: ese enlace hace uso del plugin "GbRandomPost" de que hablamos en esta entrada.