Ahora bien, este método, que parecía curioso y bueno, pero, no era así para lo que nos ocupa. Por ejemplo, para borrar los archivos expirados del caché, el método "ClearExpiredCache()" llamaba a "GetCacheFiles()" para obtener los archivos del directorio del caché de contenidos, y luego, tenía que recorrer el "Array" en cuestión, para comprobar si un determinado había expirado, para proceder a su borrado a continuación. Todo parecía bien así, salvo que se está recorriendo dos veces los archivos del directorio del caché.

No, exactamente, pero, primero los archivos "reales", y luego el "Array" que contiene sus rutas, sobre las que trabajar. Pues bien, ahora, cada método que necesita conocer qué archivos se encuentran en el caché, recorren el directorio ellos mismos, de manera que, según van haciéndolo, borran los archivos que sean menester, por ejemplo, llevan a cabo la tarea que tienen encargada, por decirlo así. De este modo se quita del medio el "Array" de archivos, y se quita del medio la necesidad de recorrerlo para actuar sobre los archivos en cuestión.

Probablemente estos cambios no se noten demasiado, realmente estaremos hablando, supongo, de milisegundos... de pocos milisegundos, pero, lo que está claro está claro: se estaba haciendo un trabajo dos veces (aunque no exactamente), de forma innecesaria, porque, es perfectamente posible hacerlo como ahora se hace. En fin, tengo que agradecer de nuevo a Román, porque, de hecho si él no me pone sobre esto quizás ni me habría dado cuenta de este "detalle" de que hablo. Lo que se saca de aquí es que Gesbit mejora cada vez que alguno de vosotros colabora como sea. ;)

Intentaré explicar esto a continuación, a ver si también, de este modo, y puesto que en esta bitácora faltan otros puntos de vista en forma de comentarios (los tuyos, por ejemplo), como he dicho ya más de una vez, escribiré por ver si yo también puedo poner en claro algunas de las cosas que tengo dando vueltas en la cabeza. Así es, ni siquiera yo tengo claro que lo notado tenga alguna relevancia.

Resulta que el sistema de caché hace uso de las URLs de las bitácoras para saber, por decirlo así, si dicha URL está ya "cacheada" o no lo está. Ahora bien, siendo esto así, como lo es, un usuario malintencionado podría solicitar una URL como esta, por ejemplo:

http://www.unabitacora.com/?nocache=1

Como puedes ver, la URL en cuestión incluye en este caso una variable, que Gesbit no tendrá en cuenta, pero, que, en todo caso forma parte de la URL. De este modo, el sistema de caché comprobaría si dicha URL ha sido "cacheada", y, si no lo ha sido, "dejará" que Gesbit genere dinámicamente la página correspondiente. Como acaso ya imagines, la página generada formaría parte entonces del caché de Gesbit (si está en uso) y se serviría en otras ocasiones para la misma URL.

Ahora bien, es fácil suponer que un usuario malintencionado podría usar este tipo de URLs para "forzar" la generación dinámica de páginas, para "saltarse" el sistema de caché, y, en un momento dado, para llevar a cabo un "ataque" de "denegación de servicio" contra el servidor que albergue la bitácora en cuestión. El sistema de caché reconocería estas URLs como distintas, porque, realmente, lo son:

http://www.unabitacora.com/?nocache=2
http://www.unabitacora.com/?nocache=3
http://www.unabitacora.com/?nocache=4
http://www.unabitacora.com/?nocache=N

He comprobado que este "problema" sucede no sólo en el sistema de caché implementado en Gesbit, sino en otros sistemas similares, y es que, como digo, siempre que estos se basen en la URL para conformar un "identificador" para las páginas que se sirven, será posible utilizar la técnica mostrada para "saltarse" el sistema de caché de contenido, para forzar la generación de páginas dinámicas.

He consultado privadamente con el autor de uno de estos "sistemas de caché" y, según él no se trata de un fallo, porque, lo mismo que ocurre con estas URLs ocurriría con cualquier otra que incluyera variables. Creo que entiendo lo que quiere decir, y creo sinceramente que este hombre sabe más que yo de estos menesteres, pero, todavía no me quedo del todo tranquilo.

Y es que el asunto, si es que representa o puede representar un problema, no tiene fácil solución, a lo que se ve. Lo segundo que se le ocurre a uno (por no aburrir no diré lo primero que se le ocurre) es conformar una lista de variables "válidas", de modo que no se tengan en cuenta el resto de variables en las URLs. Esta, que podría parecer una solución ideal, dista mucho de serlo, en el caso de Gesbit, al menos.

Es verdad que sería posible crear la tal lista de variables "válidas", pero, en el supuesto caso de que los plugins o temas de Gesbit necesitasen usar variables, el asunto no pintaría nada bien. Esto es porque el sistema de caché de contenidos en Gesbit funciona sin necesidad de hacer ni una sola consulta a la base de datos de Gesbit.

El sistema de caché se pone en marcha antes incluso de que el sistema de plugins lo haga, porque este requiere ya de una consulta a la base de datos: para obtener, justamente, las opciones de Gesbit, entre las que se encuentra la que determina qué plugins están "activos", cuál es el tema "actual", etc. Entonces, aquí, surge un dilema.

Si concluimos que sería bien crear la tal lista de variables "válidas" para solucionar el posible "problema" (luego se verá porqué entrecomillo) en el caché de contenidos, entonces será necesario hacer al menos una consulta a la base de datos de Gesbit, antes de que el sistema de caché se ponga en marcha. ¡Y esto es precisamente lo que se pretende evitar!

Por otro lado, y, queriendo entender la opinión del compañero, que, sin duda, sabe más que yo de estos menesteres, quiero pensar que soy demasiado imaginativo... y en realidad el susomentado "problema" con el caché de contenidos en realidad no es tal. Es cierto que el usuario que lo sepa puede "saltarse" el caché y "forzar" la generación de una página dinámica. A esto Gesbit no le preocupa mucho, porque, genera páginas con soltura sin problemas.

Pero, cuando hablo de un posible problema, ¿a qué me estoy refiriendo exactamente? ¿Qué quiero decir? Si lo que pienso, como es la verdad, es que alguien podría realizar una ataque de denegación de servicio a una bitácora, ¿para qué va a tener necesidad nadie de saltarse el caché de contenidos, si puede pedir, directamente, otra página de la bitácora, que, precisamente, no pasa por el caché de contenidos?

Hablo, por ejemplo, de la página que da entrada al panel de administración de Gesbit, por ejemplo. ¡Pero es que valdría cualquier otro archivo, cualquier otra petición, para hacer lo que se pretende! La hoja de estilo de un tema, por ejemplo, alguien puede "pedirla" y "pedirla" al servidor hasta dejarle KO, si es que esto es posible. Y aquí es cuando caigo del guindo.

Tal vez sea por algo alrededor de esto último que digo, por lo que esta persona con la que he consultado, no considera un problema este asunto: si alguien quiere hacer un ataque de denegación de servicio, no necesita saltarse el caché de contenidos... utilizará cualquier otra URL para hacer lo que pretende. Y, por otro lado, ahí acaba todo, es decir, no hay otro problema que ese con el caché de contenidos.

En fin. Que voy a publicar esta entrada, más que nada, porque queda demostrado, una vez más, que escribir sobre algo ayuda a encontrar una posible solución a lo que sea. En este caso no he encontrado una solución, pero, me he quedado más tranquilo, porque, he llegado a la conclusión, creo, acertada. Y el problema que veía al principio, parece que, en realidad, no es tal.

Pues mejor, ¿no te parece a ti también así?

Y no es que se encontrara una solución ideal, puesto que creo que, otra vez más, en este asunto sólo podemos tratar de paliar un posible problema, pero, que, en todo caso, puede llegarse a producir, en un momento dado. Gesbit se encarga ahora de comprobar el "hash" MD5 de los archivos que temas y plugins necesiten, y no incluirá archivos duplicados basándose en dicho "hash".

Esto no garantiza que no se pueda incluir código duplicado, puesto que, por ejemplo, un plugin podría usar una versión de la biblioteca jQuery para JavaScript, y, otro plugin, podría usar otra versión, con lo que sus MD5 ya no coincidirían a buen seguro, y Gesbit terminaría por añadir ambas versiones. Ahora bien, esta circunstancia no parece fácil de evitar, y hasta puede que no sea posible.

Lo único que queda, es, por lo tanto, tratar de paliar el probable problema de la inclusión de código duplicado. De este modo, tal como se implementa ahora este asunto, si un plugin usa la última versión de jQuery, el tema "activo" de Gesbit también la usa, y otros plugins la usan también... Gesbit incluirá el archivo correspondiente una sola vez. Y con esto se cumple nuestro objetivo, si no en todos los casos, sí en varios de ellos.

Lo dicho para el JavaScript se aplica también para los archivos CSS, hojas de estilo en cascada, que también pueden ser requeridas por el tema de Gesbit y por los plugins para el mismo. En este caso, sin embargo, será más complicado que dos archivos CSS sean iguales, pero, el sistema actual garantiza ya que dichos archivos se incluyan entre las etiquetas HTML "head" del tema en uso en Gesbit.

Y esto último es importante, puesto que, tanto el JavaScript como el CSS deben "cargarse", precisamente, en ese lugar, y no como venía haciéndose hasta ahora, si era necesario, al principio del "body" de la página en cuestión. Para conseguir esto último, y, puesto que las "plantillas para temas" se basan en buena medida en las de Wordpress, he optado en parte por la solución que se ofrece en este otro gestor de blogs.

Ahora los temas de Gesbit, precisamente antes de que la etiqueta HTML "header" sea cerrada, deben hacer una llamada a cierto método de la clase "G" de Gesbit, que será la encargada de poner en marcha el sistema de inclusión de archivos CSS y JavaScript necesarios. Huelga decir que los temas existentes en Gesbit se aplican el cuento y ya utilizan esta nueva forma de incluir archivos CSS y JavaScript.

Por otro lado, todo esto queda explicado ya en las páginas correspondientes de la wiki de Gesbit: Desarrollo de temas y Desarrollo de plugins para Gesbit. Como digo, no es que sea una solución perfecta, y tal vez esta no exista, pero, en todo caso, sí que es un comienzo, y también una especie de declaración de principios: el código duplicado no gusta en Gesbit y será en lo posible evitado. Quiero agradecer una vez más a xEsk el que me acuciara a trabajar en este y otros asuntos en Gesbit. Y también su paciencia conmigo. ;)

Sobre este asunto llevo también dando ya algunas vueltas, incluso antes de que me pusiera con el caché de contenidos. ¿De qué estoy hablando? ¿Qué significa una mejor gestión del JavaScript y CSS que necesiten plugins y temas? Bien. La idea es similar a la localización (traducción) a distintos idiomas de temas y plugins: es Gesbit quien proporciona la infraestructura necesaria, no que cada plugin tenga que hacerlo por su cuenta y riesgo.

La idea parte de la base de que sea Gesbit quien incluya el JavaScript y CSS necesario en el tema en uso, tanto el que necesite el propio tema, como el que puedan necesitar los distintos plugins que puedan estar instalados y activos en Gesbit. ¿Qué sentido tiene esto? Pues que, si se deja a cada quien añadir sus archivos JavaScript y CSS, sobre todo con los primeros, es muy probable que varios plugins incluyeran código duplicado.

Por ejemplo, si un plugin necesita hacer uso de la biblioteca jQuery para JavaScript, y otro plugin necesita también de esta biblioteca, sería un tanto estúpido que se tuviera que enlazar dos veces, separadamente, al mismo archivo JavaScript que contiene a la biblioteca jQuery. Lo suyo sería que el plugin o tema pudieran decir a Gesbit: "Necesito este y este archivo, aquí están sus rutas", y fuera Gesbit el que se encargara de incluirlos, y no hacerlo dos veces.

Sin embargo, no tengo muy claro cómo voy a implementar esto. Sobre todo con los temas, puesto que estos no son "clases", como los plugins, y su gestión se realiza de forma algo distinta. He pensado en hacer obligatorio el uso de cierta clase también para los temas de Gesbit. Es decir, así como los plugins han de derivar de la clase "GbPlugin", que los temas tuvieran que derivar de otra clase que pudiera ser "GbTheme". Esto, creo, simplificaría las cosas.

Porque los temas de Gesbit van ahora un poco "por libre", y, aunque cuentan con un "script" "functions.php", que se incluye con cada tema, y que puede contener código PHP listo para ser ejecutado, creo que este archivo "funcions.php" puede liarse demasiado... de hecho pienso que si el plugin contara con su propia clase, sería a esta a la que podría recurrir, y el archivo "functions.php" dejaría de tener sentido. Sobre todo esto tengo que investigar y experimentar.

Así que no pongo fecha. Y es posible que otras cosas lleguen antes, pero, ya sabes qué será lo próximo en Gesbit. Incluso yo también lo sé. Es decir, que, de nuevo, he escrito todo esto como una manera de concienciarme de la necesidad de llevar a cabo lo dicho, o lo bueno que sería que existiese algo así. De este modo me preparo para lo que toca a continuación, que es trabajar sobre todo esto de que he hablado en esta entrada. Ya contaré cómo va todo. ;)

Poner en marcha el sistema de caché de contenidos es bastante sencillo, depende únicamente de una constante en el archivo de configuración de Gesbit, tal como se explica en esta página de la wiki de Gesbit. No creo que deba extenderme más sobre el asunto, sino decir que ya está disponible en Gesbit, puesto que he hablado de este tema en esta, esta y esta otras entradas de esta bitácora.

Tan sólo terminaré diciendo que, igual no lo notas, pero, es posible que esta página que lees ahora se trajese desde el caché de contenidos de la misma, con lo que su procesado fue un poco más rápido y menos costoso para el servidor. De todas formas, el uso del caché en Gesbit es opcional: no todas las bitácoras lo necesitarán, puesto que, por ejempo, las mías, funcionan muy bien sin el mismo, aunque ahora lo utilicen a modo de prueba, como digo.

He hecho bastantes pruebas, varios intentos, llevo cuatro o cinco días trabajando en este asunto, y, sin embargo, estoy seguro de que aparecerán problemas. Como he dicho ya, guardo una copia de seguridad de la rama de Gesbit que no incluye el caché de contenidos, por si las moscas, pero, espero no tener que recurrir a ella, y que, los problemas que se presenten, se dejen solucionar con más o menos trabajo. No importa. Hoy, de nuevo, creo, Gesbit es un poquito mejor.

De entre todos los intentos de implementación, sin duda este último es en el que he llegado más lejos, y el que mejor ha salido de todos. En primer lugar hay que decir que Gesbit no delega el caché de contenido a un posible plugin. ¿Por qué razón? Porque inicializar el sistema de plugins de Gesbit tiene un coste: una consulta SQL a la base de datos, y además sería necesaria la ejecución de más código PHP del verdaderamente necesario.

Dejando a Gesbit encargado del caché conseguimos varias cosas, por lo tanto. En primer lugar, la clase "GbCache" se instancia acto seguido de las clases "Timer", "Input" y "Localize" (esta última podría evitarse, si se viera necesario). En ese punto Gesbit no ha hecho ni una sola consulta SQL a la base de datos, y la clase "GbCache" ya puede hacer su trabajo, uno de ellos: servir contenido previamente "cacheado".

En ese punto, como digo, Gesbit tampoco ha necesitado instanciar otras clases, como "GbDb", "User", "GbPlugins", "GbOptions", "DateUtils" o "Themes". De modo que no sólo nos ahorramos consultas SQL a la base de datos, sino que además nos ahorramos no poco del código PHP necesario para la inicialización y puesta en marcha de Gesbit. La clase "GbCache" se encarga de todo, de guardar contenido en caché y de recuperarlo.

¿Qué es lo que se guarda en el caché de contenido? Gesbit puede guardar en el caché de contenido todo el XHTML y el RSS que produce. La portada de la bitácora, la páginas de categorías, etiquetas o autores, el archivo, las entradas "solas", las páginas de la bitácora, eso en lo que respecta al XHTML, pero, Gesbit también guarda en el caché el RSS de todos los "feeds" que puede generar en una bitácora determinada.

La verdad es que ha sido muy interesante trabajar en la clase "GbCache". Y es que resulta curioso cómo funciona. Por ejemplo, podría pensarse que todos los usuarios reciben el mismo contenido "cacheado", pero, lo cierto es que Gesbit tiene en cuenta cierta información "única" para cada usuario, "cachea" el contenido, y se lo sirve a ese mismo usuario, y no a otro que no corresponde. Esta información se basa en ciertas "cookies" de Gesbit, y en la URL de la petición del usuario.

Obviamente, no se trata de que siempre sea de este modo. Si tú visitas una bitácora por primera vez, no eres un usuario registrado, y nunca has dejado un comentario en la misma, tú no tendrás "cookies" de Gesbit en tu navegador. Si yo estoy en tu misma situación y visito la bitácora, recibiré el contenido "cacheado" que en realidad se generó para ti: como ambos estamos en igual situación, tu contenido sirve para mí perfectamente.

Otra curiosidad se da en el nombre de los archivos que guardan el contenido "cacheado", que no está ni mucho menos elegido al azar. Todos los archivos tienen la misma longitud: 21 caracteres, puesto que no todos los sistemas en que pueda funcionar Gesbit permitirán cualquier número de caracteres como nombres de archivos. El nombre se divide en dos partes separadas por un "guión", aunque esto último daría igual que no fuera así.

Ambas partes del archivo son en realidad parte de un "hash" único, en teoría. Así se consigue que el nombre del archivo nunca supere una cantidad máxima de caracteres: 10 por cada hash y 1 del guión, igual, 21 caracteres, en todo caso. La primera parte del archivo es un identificador de contenido, por decirlo así, "file token", como lo llamo en el código fuente de Gesbit. Supongamos que Gesbit va a "cachear" una entrada, cuyo título es "¡Hola mundo!", la primera parte del archivo podría ser esta:

single-hola-mundo

Estoy tiene una función, y es que, de esa entrada, podemos "cachear" su "feed", de modo que la primera parte del nombre del archivo quedaría así en ese caso:

single-hola-mundo-rss

De ese modo, si se actualiza o se borra de la bitácora la entrada en cuestión, nosotros sabremos localizar y borrar no sólo el archivo que comience por "single-hola-mundo", sino también el archivo que comience por "single-hola-mundo-rss", puesto que ambos guardarían contenido "obsoleto", desde el momento en que se actualizó o borró la entrada. Más de lo mismo ocurre para el resto del contenido: se sigue el mismo patrón para etiquetas, entradas, autores, etc.

tag-neil-young

tag-neil-young-rss

category-musica

category-musica-rss

autor-admin

El contenido más general, como pueda ser la portada de una bitácora, y las distintas páginas de entradas (de más recientes a más antiguas), así como los "feeds" "generales", también tiene su propia "primera parte" en el nombre del correspondiente archivo. En este caso el identificador es "index", simplemente. De este modo, podemos borrar todos los índices, en caso de que se borre una entrada, pero, sin necesidad de borrar del caché el resto de entradas, etiquetas, categorías, etc.

Eso en lo que respecta a la primera parte del archivo, que, como hemos dicho, tampoco se guarda "tal cual", sino que a partir del identificador se consigue un "hash" único, de 10 caracteres, que es lo que en realidad formará parte del archivo. Ahora, sin querer ser pesado, toca hablar de la segunda parte del archivo. Esta es más sencilla de obtener, puesto que, como ya he mencionado, se basa en información guardada en un par de "cookies", y en la propia URL que esté procesándose.

El valor de las "cookies" y la URL conforman un identificador único, no porque nosotros lo necesitemos, quiero decir, para localizar contenido en el caché para su borrado, por ejemplo, sino que este identificador único está dispuesto para seguir a usuarios únicos, a lectores únicos de la bitácora. Como mencioné más arriba, varias personas pueden ser, para los efectos del caché de contenido en Gesbit, únicas.

En definitiva, una misma URL, y unos mismos valores en las "cookies" (o ningún valor), conformarán una segunda parte del archivo única, pero, que, puede servir para varias personas, justamente, las que visitan la misma URL, y tienen los mismos valores (o ningún valor) en las "cookies" necesarias. De esta "cadena" formada con la URL y el valor de las "cookies", obtenemos un "hash" de 10 caracteres, que formarán parte del nombre del archivo, como queda dicho.

Sobre el caché de contenido cabría añadir que este se guarda "comprimido", aunque esto supone el coste de la "descompresión", a la hora de recuperar el contenido "cacheado". Sin embargo, creo que merece la pena: el rendimiento es muy rápido, y, en lugar de guardar y leer archivos de hasta 50 KB, lo que guardamos y leemos son archivos de 3, 6, 16 KB poco más o menos. Y, dicho esto, creo que básicamente terminamos con una parte del trabajo de la clase "GbCache" de Gesbit.

Por otro lado, cabe decir que el caché de contenidos en Gesbit se gestiona "solo", en caso de usarlo. Su uso es opcional y depende únicamente de una constante en el archivo de configuración de Gesbit. Esta constante, de entrada, será una cadena vacía, y, siendo así, la clase "GbCache" entenderá en su momento que no debe realizar su trabajo, que el usuario no precisa el uso del caché de contenidos. Así, bastará que esta constante contenga una cadena para que la clase "GbCache" se ponga en marcha.

Ahora bien, lógicamente, no vale cualquier cadena en la constante de configuración. La propia clase "GbCache" se encargará de comprobar que esa cadena de caracteres contiene la ruta de un directorio válido. Esta ruta puede ser absoluta, o relativa al directorio de instalación de Gesbit. Por directorio de caché válido se entenderá un directorio existente y con los suficientes permisos de escritura.

Por el momento, y puesto que el caché de contenido es opcional además, Gesbit no intentará crear ningún directorio, ni comprobará los permisos de escritura, ni tratará de cambiar los permisos al mismo: si el directorio es válido, Gesbit hará su trabajo, y, si no lo es, advertirá al usuario del problema y de la forma de corregirlo, y hasta le invitará a no usar el sistema de caché, puesto que Gesbit funcionará sin el mismo.

Vale. Supongamos entonces que Gesbit cuenta con un directorio válido, con los suficientes permisos de escritura. Entonces, Gesbit guardará en dicho directorio el caché de contenidos, esto es varios archivos, actualmente, hasta dos horas después de su creación. Efectivamente, el caché de contenidos tiene un "salvavidas", una forma de asegurarse de que el contenido que está ofreciendo Gesbit está actualizado, y es borrando los archivos del caché que superen un determinado tiempo de vida.

El mecanismo de borrado del caché de contenidos "expirado" se pone en marcha al procesar la petición del usuario, es decir, cada vez que tú visitas una bitácora, Gesbit comprobará antes de nada si existe contenido "expirado" en el caché, y lo borrará si así es, de modo que tú mismo ya recibas contenido actualizado, si es menester, y a partir de ti el resto de lectores que visiten la bitácora en cuestión.

Esto último es parte de la magia de todo este asunto. Al menos a mí me parece curioso, qué le voy a hacer. Se trata de que tú, sin saberlo, puedes estar generando el caché de contenido que luego otras personas podrán utilizar después. Y tú también puedes estar sin darte cuenta actualizando el caché de contenido, asegurando que el mismo no contenga datos expirados, ¡y sólo por visitar la bitácora! Te conviertes en una especie de colaborador inconsciente de Gesbit. Y Gesbit te lo agradecerá, puesto que lo mismo que tú haces para otros, otros lo harán para ti.

Por otro lado, que sea Gesbit el que implemente el sistema de caché de contenidos, implica que en varios puntos del mismo ha de entrar en juego la clase "GbCache". Dicho brevemente, cada vez que se borra una entrada, que se actualiza, que se añade una etiqueta, que se edita, una categoría, un enlace, un usuario, se cambian las opciones, se activan o desactivan plugins, se cambia el tema de la bitácora... cada vez que esto ocurre hay que informar a la clase "GbCache".

Me gustaría terminar con algo que comenté en las anteriores entradas en que he tratado más o menos sobre el sistema de caché de contenidos en Gesbit. Y es que este no puede ser perfecto, y, uno de los pasos que he tenido que dar, es concienciarme de esta circunstancia, asumirla, para tratar de llegar a una especie de acuerdo entre lo perfecto y lo verdaderamente posible sin un esfuerzo exagerado y tal vez desproporcionado. El sistema parece funcionar, cumple con su objetivo.

Y el objetivo, puesto que además el caché se "auto actualiza", como he dicho, podría decirse que es el aguantar cierto tirón de visitas en una determinada bitácora. No es un sistema de caché escrupulosamente programado, medido hasta el mínimo detalle, pero, asegurará que, en caso de que una bitácora reciba "de pronto" 1.000 visitas, buena parte del contenido se sirva desde el caché de contenidos, descongestionando el servidor, evitando la base de datos, en fin, como era nuestro deseo.

Hoy he caído en que ocurría algo similar con el script "404.php" de los temas de Gesbit. Estos mostraban el menú de la bitácora, de modo que requerían una serie de consultas, que, en verdad, pueden muy bien omitirse. Ahora estos scripts muestran lo que importa: información al usuario de que su "consulta" no ha producido resultados, posibles soluciones y un formulario de búsqueda en la bitácora, por si quiere utilizarlo.

Con esto se ahorran varias consultas SQL en este tipo de "scripts". Hay que decir, además, que este tipo de "scripts", no es "cacheado" nunca por el sistema de caché de Gesbit (si es que este llega a buen puerto, ya sabes que todavía sigo trabajando en ello) de modo que este ahorro se producirá en todo caso. Respecto del caché de Gesbit, ahora mismo en preparación, creo que va por buen camino, pero, seguiré informando en su momento.

No digo que otra persona no viera más allá que yo, estoy seguro de que así será, pero, en lo que a mí respecta, estoy empezando a asumir que el sistema de caché no será perfecto, pero, por lo menos, servirá en bastantes ocasiones. Creo que es bastante resumir todo este misterio en una pregunta: ¿Qué ocurre cuando se borra una entrada de una bitácora? La respuesta obvia es: habrá que borrar esa entrada del caché de contenidos. Lo imperfecto llega cuando a la pregunta anterior se suma la siguiente, ¿y qué pasa con las páginas que pueden seguir mostrando esa entrada después incluso de borrarla?

Dicho de otro modo, por si no se me ha entendido, Gesbit puede "servir" una página correspondiente a cierta etiqueta X. Dicha página mostrará la entrada Y, porque la entrada Y se guarda bajo la misma etiqueta X. Así que guardamos en el caché la página de la etiqueta X, pero, luego borramos la entrada Y... ¿qué hay de la página de la etiqueta X que guardamos en el caché? Porque esta contendrá la entrada Y, pero, esta entrada ya ha sido borrada de la bitácora. Ahora bien, téngase en cuenta que hablamos de etiquetas, pero, igual podríamos hablar de categorías, porque ocurre el mismo caso.

Y también de las búsquedas, del archivo por fechas, de los RSS, etc., etc. Todo está relacionado. Si se borra una etiqueta, por ejemplo, y no se borra la entrada que contiene esa etiqueta, el caché de la página que muestra la entrada, mostrará la etiqueta, que ya no existe. Y este asunto no tiene fácil solución. No tiene, de hecho, una solución. Porque podríamos intentar ser tajantes y razonar: "Si se actualiza una entrada, etiqueta, categoría, autor, lo que sea... se borra todo el contenido del caché.". Efectivamente, así acabaríamos de golpe con los problemas, pero, ¿para que serviría un caché que se borraría entero cada vez que alguien añada un comentario a la bitácora, por ejemplo?

Aún así, se podría decir: "Todavía serviría el caché, porque, aunque fuera durante el tiempo en que "nada cambia" en la bitácora, se estaría utilizando el caché.". Y es cierto. Pero, si no queremos ser tajantes, si no queremos tomar una decisión como esta, entonces tendremos que llegar a un acuerdo, asumir ciertos "costes", y guardarnos las espaldas. ¿Cómo haremos todo esto? Pues, por ejemplo, cuando se borra una etiqueta, podemos borrar las páginas correspondientes a esa etiqueta, pero, no borrar todo lo demás. "¿Cömo? Pero, si hacemos esto, sería posible que una entrada se mostrase desde el caché de contenido, y mostrase que se guarda bajo una etiqueta, que, en realidad, ya no existe.".

Así es. Pero, ¿qué se puede hacer? Es un costo que hay que medir, hay que ver hasta qué punto es asumible que algo así ocurra, y si merece la pena que algo así pueda ocurrir, con el fin de mantener en el caché el máximo contenido posible. Ahora bien, al final tendremos guardadas las espaldas. ¿De qué manera? Porque el caché de contenido tiene una tiempo de expiración. Es decir, el contenido guardado en el caché es borrado del mismo una vez excedido el tiempo máximo de expiración. ¿Cuál es este tiempo máximo? Podría ser una hora, dos horas, tres horas... Pero no podría ser mucho más tiempo, y hasta es posible que la cifra dependa del "tráfico" de una determinada bitácora.

Por ejemplo, en una bitácora que se actualizara a menudo, el caché podría terminar con demasiado contenido obsoleto, si el tiempo de expiración es demasiado grande. El tiempo de expiración, por decirlo así, es una especie de salvaguarda, que, por ejemplo, cada hora, asegura que el caché se renueva completamente. Y, en fin, en estas estoy. Viendo qué borrar y qué no borrar en según qué situaciones. Por lo demás todo parece funcionar razonablemente bien: el contenido, cuando se sirve desde el caché, no ha necesitado previamente de consulta SQL alguna a la base de datos. Seguiré dándole vueltas al asunto y veremos en qué queda.

Si a alguno de vosotros, lectores pocos, y menos comentadores, de esta bitácora, se os ocurre alguna idea o sugerencia relacionada con todo esto de que vengo hablando, huelga decir que esta será bienvenida y agradecida como se debe. :P

Como sabes, una bitácora tiene, además de entradas, que forman parte de la cronología de la bitácora, también páginas, que están fuera de la cronología de la bitácora, que van un poco "a su aire". Pues bien, mira tú por dónde, ayer descubrí que Gesbit necesitaba 17 consultas SQL para conformar la página de una bitácora. Enseguida pensé que algo iba mal, que había algún error ahí, puesto que, para la portada de una bitácora, Gesbit necesita de 12 consultas SQL, por ejemplo.

Efectivamente, no es que fuera nada mal. Pero, en los temas de Gesbit estaba mostrándose, en las páginas, también el menú de la bitácora o "sidebar". Esto no se hace así cuando se muestran entradas "solas", y de hecho para conformar una entrada "sola" Gesbit precisa de 10 consultas SQL. Así que era eso, sumar a las consultas necesarias para conformar las páginas, las necesarias para conformar el menú de la bitácora, hasta que se sobrepasaba la marca de Gesbit en cuando a consultas SQL para conformar su contenido: nada menos que 17 consultas SQL.

Esto ya está arreglado, dada además mi obsesión por estas cuestiones. Actualmente, Gesbit no muestra el menú de la bitácora en las páginas, de modo que ahora son sólo necesarias 8 consultas SQL para conformar las páginas de una bitácora. Sólo el número de consultas puede hacer pensar que el menú estaba demás en las páginas, dado su costo, pero, no sé si engañado, también creo que es más o menos lógico que el menú no se muestre en las páginas: como tampoco se muestra en las entradas "solas". Quizás me engaño, ya digo, pero, así quedan las cosas, de momento.

Respecto del asunto del caché... en este penúltimo intento estoy implementándolo en el "corazón" de Gesbit. En realidad Gesbit añade una clase más, "GbCache", que es la que se encarga de realizar el trabajo necesario, básicamente. En anteriores intentos había ido más por el lado de utilizar plugins, pero, haciéndolo como ahora puede asegurarse que Gesbit no necesitará hacer ninguna consulta a la base de datos para servir contenido guardado previamente en el caché. Todavía tiene que ejecutar algo de PHP, pero, no hace ni una sola consulta SQL. Veremos en qué queda todo esto.

Como los que seguís esta bitácora ya sabéis, la portada de una bitácora en Gesbit necesita realizar sólo (creo que puedo decirlo así) 12 consultas SQL a la base de datos. Además, la mayoría de ellas son bastante sencillas, que incluso ni requieren datos. Sin embargo, un sistema de caché evitaría todavía más consultas SQL, y, en el caso de bitácoras con muchas, no sé cuántas, pero, muchas visitas, no es que piense que Gesbit vaya a ir mal, pero, un sistema de caché ayudaría al servidor, sería bien. Como ya he dicho, he hecho varios intentos, y, escribo esto por si se me ocurre algo.

Hoy he puesto en orden el archivo "gb-globals.php", donde se "inicializan" las principales "variables globales" de Gesbit. Lo he hecho pensando en que el caché de Gesbit se implementase por medio de un plugin, no desde el propio "corazón" de Gesbit. Y tengo algunas, muchas dudas. El archivo que he mencionado procura guardar cierto orden en la inicialización de las variables, de tal modo, que, cuando se inicializa la variable "GbPlugins" (el gestor de plugins de Gesbit) tan sólo se han realizado dos consultas SQL a la base de datos. ¿Por qué veo estas dos consultas necesarias?

Bien. La idea es la siguiente. Para actuar, para ponerse en marcha, un plugin necesita "estar activo". Una de las dos consultas, por lo tanto, es la que requiere las opciones "auto cargables" de Gesbit, y entre estas se encuentra la que especifica qué plugins están activos. La otra consulta no retorna datos: se trata de establecer en la base de datos el "charset" que se utilizará. Estas dos consultas SQL son necesarias, tal como lo veo ahora. Podría pensarse entonces qué sentido tiene el sistema de caché implementado de este modo, si, de todas formas, va a requerir consultas a la base de datos, aunque sean sólo dos.

Pero, creo que mi razonamiento no falla, dicho de otro modo, si me pregunto, ¿el plugin que implemente el sistema de caché tiene o no tiene que saber si está activo o no? Es evidente que sí. Luego, entonces, no hay más que hablar, es necesaria la consulta SQL correspondiente. Ahora bien, queda otra posibilidad: que sea el propio Gesbit quien implemente un sistema de caché. ¿Sería necesario en este caso recurrir a la base de datos? No. Puesto que Gesbit, antes de hacerlo, podría poner en marcha el sistema de caché, que comprobaría si existe el contenido que se solicita, y servirlo, directamente, sin más ni más.

Creo que hay que valorar, entonces, esta cuestión. Yo quisiera un sistema de caché que no requiera de la base de datos para funcionar. Luego entonces este sistema no podría implementarlo un plugin, si el funcionamiento de este necesita de al menos dos consultas SQL a la base de datos. Pero integrar el sistema de caché en el propio Gesbit, aunque no me parece mal, de entrada, implica una serie de cuestiones. Por ejemplo, habría que especificar el directorio donde guardar el contenido mediante alguna constante: puesto que se trata de evitar el trato con la base de datos. Y luego estarían los correspondientes permisos...

Permisos que tendría que tener Gesbit para escribir en el directorio susomentado, manteniendo hasta ahora en Gesbit la especie de norma de que este no requiera permisos de escritura en ningún directorio del servidor. Pero está claro que algo habría que sacrificar y si es menester contar con permisos en un directorio, para guardar el contenido en "caché", así será, una excepción a la regla. Al escribir esto estoy dándole vueltas al coco, y veo atractiva la posibilidad de que Gesbit implemente de suyo un sistema de caché. Ya iremos viendo en qué queda todo este asunto.