Bitácora de Gesbit

Me alegra presentar la nueva versión estable de Gesbit, la versión 1.7 Wilco, que, ya puedes descargar desde el sitio web de Gesbit. Como viene siendo habitual, además, presento al mismo tiempo la que será la siguiente versión de Gesbit, la versión 1.8 Division (beta), para no perder la costumbre, dedicada esta vez a la banda de música Joy Division. He querido plasmar los últimos cambios que he llevado a cabo en Gesbit en los últimos dos meses, desde que se publicase la anterior versión estable.

Estos cambios son varios, pero, quizá podrían destacarse algunos de ellos. El primero que quisiera destacar tiene que ver con cierto reporte de error enviado por el amigo Jordi, cuya solución devino en prescindir en Gesbit de la opción "allow_url_fopen" de PHP, es decir, Gesbit no necesita ya que esta opción esté "activada" para poder funcionar adecuadamente. Esta opción viene activada por defecto en PHP, pero, algunos servidores la deshabilitan.

Se han llevado a cabo bastantes cambios más en Gesbit. El último de ellos, que, también quiero destacar aquí, ha sido la incorporación de una nueva "opción de escritura", que, permite establecer la zona horaria de una bitácora. Con esto conseguimos adentrarnos en el maravilloso mundo de las zonas horarias (gracias Román), y, de rebote, poder establecer en Gesbit el nivel de reporte de errores de PHP en el "modo estricto", cosa que quería conseguir hace tiempo.

Quizá esos sean los cambios más destacables (que recuerde ahora mismo), empero, si descargas Gesbit y echas un vistazo al "ChangeLog", verás que ha habido muchos otros cambios, más o menos "visibles". Y creo que eso es todo. Huelga decir que aconsejo actualizar Gesbit a la última versión estable, por la cantidad de mejoras que incluye, además de haber solucionado por el camino algunos errores más o menos importantes. ¡Que disfrutes Gesbit!

Cambios más o menos importantes en Gesbit, para adaptarlo de manera que no sea necesario que esté "activada" la opción "allow_url_open" de PHP. Todo ha sido a raíz de este mensaje de Jordi en los foros de Gesbit, donde comentaba un problema que al final tenía que ver con la opción susomentada: Gesbit necesitaba dicha opción, y Jordi no puede activarla en su servidor, y yo ni me había percatado, porque en mi servidor está activada. A partir de ahora ya no será más necesaria, o eso procuraremos, ahora que sabemos que sabemos este caso. Echa un vistazo al mensaje en el foro, si precisas más información, es bastante largo, pero, chico, si no tienes otra cosa que hacer. Por cierto, gracias también desde aquí a Jordi por reportar el problema: gracias a ti ya no será más problema para nadie, o eso hemos intentando por lo menos. ;)

Ya adelantaba novedades en la anterior entrada, y, tras un par de días y de puesta a punto, por votación popular, ya está disponible la opción de "fijar" una página de la bitácora, de modo que esta sea la "portada" de la misma. Sí; es otra idea más tomada de Wordpress, y, es que croe que merece la pena. Ya está Gesbit actualizado, y todos los temas que yo llevo a cabo, incluso puedes ver como ejemplo mi bitácora personal y en la bitácora de mis NeoPlugins.

Como verás cada tema puede mostrar una página fija de diferentes formas, y, por otro lado, el contenido de dicha página también puede a adaptarse a la portada de la bitácora. La opción añadida a Gesbit es eso, una opción, no está "activada" de forma predeterminada, pero, no cuesta nada hacerlo si se quiere. No cuesta nada a nivel de más consultas, por ejemplo. Y eso es todo cuando tenía que decir y ya lo he dicho.

P.S. También has podido notar un cambio en el subdomino de esta bitácora, que ya no es "bitacora", sino "blog". Las redirecciones desde el anterior subdominio se llevan a cabo automáticamente. He hecho lo mismo con mi propia bitácora, donde ya no uso subdominio, sino el propio dominio davidesperalta.com. Las redirecciones también se hacen automáticamente, así que en principio no debe haber problema alguno. Si notas algo raro y quieres hacérmelo saber, no dudes en contactar conmigo.

Dando vueltas al método "PerformQuery" de la clase "GbQueryEx" he caído en dos optimizaciones que aún me sorprende cómo podían habérseme pasado por alto, porque parecen muy lógicas, y, sin embargo, un año y pico después de estar desarrollando Gesbit, ha sido hoy cuando he caído en que se estaban haciendo consultas SQL innecesarias en algunos casos. Ya sabes que procuro hacer pocas consultas, que he tratado este asunto en esta bitácora, así que comprenderás que me alegre de encontrar este tipo de optimizaciones, por llamarlas de alguna manera.

Estaba trabajando en otra característica en Gesbit (que tal vez termine presentando pronto aquí) cuando me he encontrado con lo siguiente. Cada vez que se solicitaba una entrada o página de la bitácora, se estaban realizando hasta dos consultas para traer los comentarios de dicha entrada o página, con el fin de mostrarlos luego al lector. Ahora bien, resulta que no tiene mucho sentido traer los comentarios de una entrada o página... si esta no tiene comentarios. Y esto es algo que es posible saber antes de hacer las consultas en cuestión. Dicho y hecho, por lo tanto.

Con lo anterior nos ahorraremos dos consultas SQL, tanto en el caso de mostrar entradas o páginas en una bitácora, siempre que estas no tengan comentarios. Pero, me he topado con otra posible optimización, igual de lógica y evidente... ahora que la he visto, claro. Resulta que en el mismo tipo de peticiones anteriores, han de traerse también de la base de datos los "términos" de las entradas y páginas, esto es, etiquetas y categorías. ¡Pero las páginas no tienen etiquetas o categorías!

Cuando se solicita una página de una bitácora, es innecesario (por inútil) buscar las posibles etiquetas y categorías de la página, porque, sencillamente, las páginas no cuentan con estos "atributos", como sí cuentan las entradas. De este modo, cada vez que se pide ahora una página de la bitácora, idependientemente de que tenga o no comentarios, se estará haciendo una consulta SQL menos. Consulta que nos ahorramos y nos quedamos tan contentos.

Resumiendo. Habrá peticiones que ahora requieran tres consultas SQL menos: cuando se soliciten páginas de una bitácora que además no tengan comentarios. Habrá peticiones que requieran dos consultas menos: cuando se soliciten entradas que no tengan comentarios. Y habrá peticiones que requieran una consulta SQL menos: cuando se pidan páginas con comentarios, pero, sin términos: como no puede ser de otra forma. Y eso es lo que quería decir. Y ya está.

Seguro que recuerdas cuando se abrió el foro de Gesbit, hace bastante tiempo ya, y, seguro que recuerdas que se cerró tiempo después, ora por desesperación mía, porque odio los foros vacíos, ora por falta de paciencia también mía. Sea como sea, a raíz de ciertos comentarios positivos en PHP-Hispano, sobre todo a una persona en concreta, que veía bien contar con un foro, pues eso, que, me he decidido a ponerlo en marcha de nuevo. A ver qué tal se da en esta ocasión. Espero tener al menos la paciencia que en su momento pude no tener, y que fuera esto lo que faltó en su momento.

Por cierto, el foro puede visitarse en: www.forum.gesbit.com

Hace tiempo que decidí "serializar" las opciones de Gesbit, y también las que pueden establecerse desde los plugins "mediante Gesbit", de manera que se guardan así en la base de datos. Y hete aquí que me encuentro con este artículo en PHP-Hispano (donde por cierto he publicado Gesbit con un éxito que te cagas -es irónico) donde se desaconseja, razonablemente, hacer uso de este tipo de técnicas. La idea es que los datos se mantengan "accesibles" desde cualquier posible cliente de la base de datos, no sólo desde Gesbit.

La idea es razonable. Pero, claro, ¡yo tengo que tener algún motivo para hacer lo contrario! Y, en efecto, creo que los dejé claros en su momento. Otra cosa es que estuviera equivocado en mis conclusiones, pero, nadie me contradijo tampoco y uno no nace sabiendo, como suele decirse. Sea como sea, luego de leer el artículo que enlazo, a uno le entran ganas de deshacer los cambios correspondientes, y dejar de guardar "serializadas" las opciones de una bitácora.

La idea era que Gesbit, en lugar de requerir unas 20 filas de opciones de la base de datos, en cada petición, aunque fuera con una sola consulta, digo, en lugar de esto, que Gesbit requiera sólo una fila, que contiene todas las opciones de Gesbit serializadas. También, la serialización de las opciones para los plugins permite que Gesbit pueda gestionar varias opciones de un plugin ocupando una sola fila en la tabla de opciones.

Quisiera continuar de este modo, y, se me ocurre argumentar que las opciones de la bitácora, así como las opciones de los plugins, no son realmente datos, propiamente, de la bitácora. Todavía menos aún para un cliente distinto del propio Gesbit, puesto que, a dicho cliente le interesarían los datos acerca de las entradas, páginas, enlaces, usuarios, categorías, etiquetas, pero, ¿las opciones de la bitácora? Sin embargo, reconozco que este argumento es poco.

Y es poco porque no se sostiene. A un cliente podrían interesarle las opciones, en un momento dado, por el motivo que fuese. Y, lo cierto es que no podría acceder a ellas, a no ser que dicho cliente empleara una "deserialización" como la que puede conseguir en PHP, el lenguaje que se emplea en Gesbit y con el que se "serializan" las opciones en cuestión. Lo cierto es que ante algo así me siento un poco perdido. Algo me dice que sí, que debería volver atrás...

Pero eso implica trabajo. Y cambiar ciertas cosas que parecen funcionar bastante bien. Y que me queda la duda de si no pueden hacerse este tipo de excepciones. Es decir, al fin y al cabo no "serializo" las opciones sin motivo alguno, sino que existen razones que tal vez no estén del todo equivocadas, para el caso de Gesbit, concretamente o un sistema similar. Comprendo porqué no se debe hacer, y encuentro razonable que se evite o no se haga. Pero, no tengo tan claro rectificar en este caso.

Para conformar la documentación de Gesbit, como sabes, se utiliza PhpDocumentor. No sólo para la documentación del código fuente, que al cabo conforma la propia documentación (ya convertida en páginas HTML) sino también para los tutoriales relacionados con Gesbit, para todo esto se usa PhpDocumentor.

Pues bien, he salido de caza y he cazado todos los errores que se venían acumulando a la hora de generar la documentación. Más que errores, "advertencias", del tipo, "usted está declarando mal el uso de esta variable global y bla, bla, bla". En fin, sé que es una cosa sin mucha importancia, pero, me alegra poder presentar esta "lista de errores". A ver lo que dura. ¬¬

O sea, que, he pasado a usar más profusamente la clase "gbadminevents.class.js", para el poco Javascript que todavía se usaba en el panel de administración, directamente, en el HTML, usando los atributos "onclick" de algunos elementos, por ejemplo. Y estoy muy contento, porque, sin ir más lejos, una sola función Javascript controla ahora el cambio de propiedades (vía AJAX) de entradas, páginas, enlaces y comentarios.

Es sólo un ejemplo. También he aprovechado para hacer algunas mejoras en este sentido. Partes concretas "degradan" correctamente, vaya que funcionarían también si no se dispone de Javascript en el cliente. Lo cierto y verdad es que separar el Javascript del HTML (cosa que usando algo como jQuery es realmente sencillo) tiene no pocas ventajas, que, con Gesbit estoy empezando a experimentar por mí mismo. En fin, tenía que decirlo.

PS: Acaso ya has visto que he hecho algunos pequeños cambios en el sitio web de Gesbit, de modo que ""incluso"" puedes ver un vídeo de la instalación de Gesbit. En fin, tenía que decirlo.