Bitácora de Gesbit

Después de dos días de trabajo, estoy en condiciones de anunciar el plugin GbDefensio, si bien sigo haciendo algunas pruebas, y no lo publicaré hasta mañana, en el mejor de los casos. Si eres lector de esta bitácora, sabes que, además de las últimas entradas, venía hace tiempo dando vueltas a una posible gestión del SPAM en las bitácoras gestioandas con Gesbit. ¿Cómo es que anuncio el plugin GbDefensio si no está publicado?

En realidad se trata de lo de siempre: estoy más o menos contento con cómo se ha llevado a cabo, y ya no quiero esperar más para contarlo. El día de ayer lo perdí, es un decir, en construir un plugin que funcionaba, sí, pero, no como el servicio web Defensio se merecía. Resulta que llegué hasta el punto en que Defensio podía echar un vistazo al contenido de los nuevos comentarios (y "trackbacks"), de forma que Gesbit podía saber si según Defensio el comentario en cuestión podía ser o no SPAM.

Pero, las más de 14 horas que le he dedicado hoy a GbDefensio, reescribiéndolo por completo, no sólo sacan más partido del servicio que ofrece Defensio, sino que también le retorna algo de utilidad. En definitiva, se trata de que, actualmente, el plugin informa a Defensio cuando los usuarios actualizan los comentarios, concretamente, el plugin puede reportar "falsos positivos" y "falsos negativos" a Defensio.

Hay que decir que el servicio que ofrece Defensio es gratuito para bitácoras personales, y que, Defensio considera bitácoras personales aquellas que procesen menos de 50.000 comentarios al mes y/o que no obtengan beneficios que superen los 250 dólares al mes. Si una bitácora supera estas cifras, debería adquirirse una licencia de uso comercial, que cuesta unos 5 dólares al mes.

En todo caso, cabe decir que lo mejor para protegernos del SPAM es lo proactivo. Por ejemplo, de forma predeterminada, Gesbit no aprueba los comentarios entrantes, por un lado, y solicita al usuario que rellene un "CAPTCHA", una especie de sistema anti-robots. De esta forma, y sin más ni más, puedo asegurar que en mis bitácoras gestionadas con Gesbit no he recibido sino un par de comentarios SPAM, "Trackbacks", todos ellos.

No obstante, contar con un servicio como Defensio, es importante, puesto que, es de suponer que si algún día Gesbit se utiliza de una forma más o menos "masiva" (dios me libre), los "spammers" podrían buscarle las vueltas, y, no seré yo el tonto que diga que no podrán encontrarlas. Sobre todo en lo referente al SPAM procedente de "Trackbacks", puesto que estos no pasan por el muro del "CAPTCHA", por el que, de forma predeterminada, tiene que pasar los comentarios "normales".

De este modo, GbDefensio puede identificar los comentarios "SPAM", y marcarlos como tales, de forma que estos no sean mostrados en la bitácora. Por supuesto, en el supuesto caso de que comenzara a llegar SPAM, Gesbit proporciona ahora lo necesario para gestionarlo, desde el panel de administración y el formulario correspondiente. Es posible marcar comentarios como "SPAM", desmarcarlos, eliminar todos los comentarios "SPAM", básicamente.

Y, como creo que esta entrada me está quedando ya un poco larga, teniendo en cuenta que además anuncio algo que todavía no está disponible públicamente, lo voy a dejar aquí. Dejo además alguna que otra característica del plugin "GbDefensio", porque, además, es posible que para cuando hable sobre esta pueda hacerlo además de alguna otra más. Como suelo decir, parece que Gesbit es hoy un poquito mejor. Pero, sobre esto también hablaré en la siguiente entrada...

Siguiendo el hilo apuntado en esta y esta otra entradas, por fin me he decidido a implementar el nuevo tipo de "evento" ante el que los plugins que lo necesiten podrán "actuar". Gesbit ya cuenta con "printers" y "filters", que aprovechan varios de los plugins disponibles actualmente, pero, era preciso incorporar un nuevo tipo de "evento", que he dado en llamar "action", y, que, por supuesto tiene características que no ofrecen los "eventos" conque hasta ahora se podía contar.

Con las acciones he dudado más, y, me sorprende que, después de varias pruebas, terminase implementándolo (de momento) tal y como lo tenía pensado casi desde un principio. O bien no he sabido ni podido ir más allá, o bien lo que se me ocurrió al principio (y luego de darle algunas vueltas, como digo) podría servir perfectamente. El código que puedes ver a continuación es el encargado de ejecutar las acciones en los plugins que lo precisen, luego trataré de describirlo.

public function ApplyAction($actionID, $args = array()){
  $results = array();
  if(!empty($this->pluginObjects)){
    foreach($this->pluginObjects as $gbPlugin){
      $method = GBPLUGINS_PLUGIN_ACTIONCALLBACK_METHOD;
      if(method_exists($gbPlugin, $method)){
        $pluginID = strtolower(get_class($gbPlugin));
        $results[$pluginID] = $gbPlugin->$method($actionID, $args);
      }
    }
  }
  return $results;
}

Como puede verse las acciones se distinguen claramente de los "filters" y "printers", en que estas pueden recibir ciertos argumentos, y, además, el "resultado" de los plugins cuenta, se guarda, para poder ser utilizado por Gesbit en caso necesario. Aquí estriba la mayor dificultad de las acciones, y es que, a diferencia de los otros "eventos", estas tendrán características diferentes, aunque su implementación es generalista, por decirlo así.

Dicho de otro modo, un "filter" no cambia: los plugins obtienen el identificador de un "filter", y también el "contenido" a filtrar. Esto no cambia, siempre es así, y no hay dudas acerca de cómo trabajar. Lo mismo pasa también con los "printers". Los plugins son informados de que en un lugar determinado es posible "escribir" código, principalmente HTML, y tampoco hay vuelta de hoja aquí: los plugins escriben o no el código necesario atendiendo al "filtro" correspondiente.

Pero las acciones son algo distinto. Una acción, por ejemplo, puede no necesitar argumentos, y, de este modo, el plugin no recibirá argumento alguno. Una acción puede necesitar argumentos, pero, tal vez no haga uso del resultado de aplicar las acciones sobre los plugins. Por último, y en general, diferentes acciones pueden necesitar diferentes tipos de argumentos, y Gesbit podrá estar o no al tanto de los resultados de diferentes acciones, según sea o no necesario.

En realidad, pienso que no debería haber mayores problemas, siempre que las diferentes acciones que puedan llevarse a cabo, estén perfectamente documentadas. El desarrollador de un plugin no necesitará conocer todas las acciones, o, al menos, bastará con que conozca aquella o aquellas que necesite para su plugin. De momento he pensado en documentar las acciones en el mismo "script" en que se definen las constantes relacionadas, puesto que cada acción tendrá una constante (identificador) diferente.

También procuraré, si todo esto sigue adelante, documentar en la wiki de Gesbit todo este asunto. De hecho pienso que puedo aprovechar ya mismo parte del texto de esta entrada, aunque sea para dejar una pequeña referencia sobre la posibilidad de utilizar estas "acciones" en Gesbit. Si todo va bien, más pronto que tarde verás algún plugin que haga uso de las acciones de Gesbit. Mi intención es comenzar a usarlas para un posible plugin que utilizara el servicio de Defensio, para tratar de automatizar el reconocimiento de SPAM en las bitácoras.

Siguiendo la línea de añadir nuevas tareas para la gestión de entradas, esta vez le ha tocado a la gestión de comentarios, a la que he añadido tres nuevas tareas: que pueden usarse para marcar los comentarios como "SPAM", "Trackbacks" y/o "Normales". También tiene esto que ver con lo que he comentado en esta otra entrada, es decir, con la posible gestión de los comentarios "SPAM" en Gesbit.

He estado haciendo algunas pruebas con el servicio que ofrece Defensio, y, no parece ir mal, sino al contrario. Y, aunque ya existía la posibilidad de marcar como "SPAM" (o no) los distintos comentarios, individualmente, con las nuevas tareas, esto mismo puede aplicarse a varios comentarios al mismo tiempo. Sin embargo, me parece que no me ha quedado muy bien la implementación.

De hecho he tenido que rectificar, porque, no me he dado cuenta de que, cuando los comentarios se marcan como "SPAM", y, puesto que los comentarios "SPAM" no se muestran a los lectores de la bitácora, es preciso, digo, decrementar el número de comentarios de la entrada correspondiente, o este no se corresponderá con los que, efectivamente, se muestran al usuario.

Esto ya se hacía, por supuesto, cuando se editaban los comentarios individualmente, pero, no me he dado cuenta de que también había que hacerlo a la hora de actuar sobre varios comentarios: lo que implica que lo que se hacía en una sola consulta SQL, precisa ahora de más consultas, que además se incrementan según se incrementa el número de comentarios sobre los que actuar.

Pero, como digo, es necesario decrementar el número de comentarios de una entrada, cuando uno de sus comentarios se marca como "SPAM", y, por la misma razón, también es necesario incrementar el número de comentarios, en caso de que uno de ellos se marque como "normal" o "Trackback", si previamente estaba marcado como "SPAM", claro está. Hacer esto resulta inevitable.

En todo caso, en cuanto se lleve a cabo un plugin que controle los posibles comentarios "SPAM", será bien que el usuario de Gesbit cuente con dichas nuevas tareas, puesto que el plugin en cuestión marcará como "SPAM" los comentarios que crea menester, comentarios que luego el usuario puede considerar no como "SPAM", sino como legítimos, por decirlo así.

Y, precisamente, llegados a este punto, hay algo que me preocupa. Se trata de que Defensio, como otros servicios dedicados a luchar contra el "SPAM", necesitan la colaboración de las aplicaciones que hacen uso de ellos. ¿De qué manera? Pues haciéndoles llegar los datos de los comentarios que Defensio, por ejemplo, hubiera considerado como "SPAM", pero, que, el usuario, considera legítimo.

Consultar con Defensio, ya digo, por ejemplo, implica una comunicación HTTP, y tal vez resultarían demasiadas conexiones si queremos enviar a Defensio los datos de los comentarios que en un momento dado se marquen como "normales", si están marcados como "SPAM". Además se sumarían, me temo que inevitablemente, algunas consultas a la base de datos de Gesbit.

Entonces me planteo enviar a Defensio este tipo de información sólo cuando se editen comentarios individualmente. Pero, la verdad es que creo que estoy poniendo el carro antes que los bueyes, como suele decirse, y debería hacer pruebas (y las haré) antes de decidirme por una u otra solución. Además Gesbit necesita alguna cosa más para poder integrar un plugin que hiciera uso de un servicio como Defensio.

¿De qué estoy hablando? De las "acciones" de Gesbit. De la misma manera que los plugins pueden estar al tanto de "printers" y "printers", es menester introducir en el "sistema de plugins" una nueva categoría de "eventos", que tengo pensado llamar "acciones", y que, por supuesto, no serían ni "printers" ni "filters", sino todo lo contrario: acciones, ante las que los plugins podrían actuar. Aunque no tengo muy claro el asunto, lo cierto es que sobre esto sí que he hecho ya algunas pruebas.

He estado últimamente mirando cómo y de qué manera implementar un sistema para luchar contra el SPAM en Gesbit. Creo, y me parece que no me equivoco, que el mejor sistema pasa por utilizar las opciones de Gesbit predeterminadas: usar la moderación de comentarios y el CAPTCHA correspondiente en los formularios de envío de comentarios. De este modo, en mis bitácoras, no he recibido sino dos o tres (literalmente) mensajes SPAM.

Y, de esos dos o tres, al menos dos, que yo recuerde, fueron "Trackbacks", y no comentarios, directamente. Y es que el CAPTCHA de los formularios parece funcionar. Ayer mismo hice alguna mejora en este sistema, y, todavía me quedo con las ganas de implementarlo de otra forma, no utilizando una imagen, sino una "suma", por ejemplo, de modo que el CAPTCHA siga siendo efectivo (esto es lo complicado) pero también accesible.

Tengo que seguir dándole vueltas a ese asunto, y creo que se las daré, pero, en esta entrada quería hablar de los posibles sistemas contra el SPAM que pueden implementarse en Gesbit. Estos sistemas serían usados para luchar contra el SPAM más allá del CAPTCHA de los formularios, de modo que incluso los "Trackbacks" pudieran ser "filtrados" convenientemente. Existen varios servicios en Internet, como puedan ser Akismet, Defensio y TipePad AntiSpam.

Estos servicios ofrecen APIs, incluso hay alguna que otra "clase" para PHP, de forma que su implementación no debería ser extremadamente compleja, sino todo lo contrario. Y, probablemente, al contrario que con el sistema de caché de contenido, en este caso me parece que sería factible la utilización de plugins, de modo que podría llevarse a cabo un plugin para cada servicio "antispam" disponible, si es que no se ve menester usar varios de ellos al mismo tiempo.

Veremos en qué queda todo esto. Por un lado no me gusta mucho utilizar servicios de terceros en Gesbit, empero, pueden estar justificados en este caso concreto, puesto que, precisamente, un servicio "antispam" necesita de la colaboración de muchas fuentes, informando de qué es SPAM y qué no lo es, de modo que los propios sistemas "aprenden", y, se supone, van mejorando con el tiempo sus predicciones. Por otro lado sería un asunto no integrado en Gesbit.

No integrado, puesto que se utilizaría un plugin para ello, y cada quien sería libre, a partir de ahí, de elegir qué servicio utilizar, de modo que el propio Gesbit no utilizara ninguno en concreto. En definitiva, creo que es hora de que me plantee utilizar un nuevo tipo de "callback" en los plugins, que no será para "filters", ni para "printers", sino que serían "actions", acciones, ante las que los plugins podrían actuar en un momento dado. Pero con calma, todo esto despacio.

En la anterior entrada, mostré las veinte líneas de que se compone el plugin GbMarkdown para Gesbit. En esta entrada me propongo explicar o describir línea por línea el código fuente susomentado, por si a alguien le resulta de interés. Vamos allá, pues.

Primero, vamos a refrescar la memoria, mostrando completo el código fuente del plugin:

function gbmarkdown($pluginData){
  return new GbMarkdown($pluginData);
}
 
class GbMarkdown extends GbPlugin
{
  const MARKDOWN_SCRIPT='markdown.php';
 
  public function OnActivatePlugin(){}
  public function OnDeactivatePlugin(){}
 
  public function FilterCallback($filterID, $content){
    if(($filterID == GBPLUGINS_FILTER_POST_CONTENT) 
     && is_readable($this->GetDirPath().self::MARKDOWN_SCRIPT)){
       require_once($this->GetDirPath().self::MARKDOWN_SCRIPT);
       return Markdown(html_entity_decode($content));
    }
    return $content;
  }
}

Ahora vamos a echar un vistazo pormenorizado, línea por línea, si te parece bien.

Pienso que el plugin GbMarkdown, de que he hablado recientemente aquí mismo, puede resultar un típico ejemplo de plugin "filtro" para Gesbit. En este caso, se trata de filtrar el contenido de las entradas de una bitácora, de modo que se pueda trabajar con dicho contenido, retornando el mismo "modificado" por el plugin. Este es el código fuente del plugin GbMarkdown:

function gbmarkdown($pluginData){
  return new GbMarkdown($pluginData);
}
 
class GbMarkdown extends GbPlugin
{
  const MARKDOWN_SCRIPT='markdown.php';
 
  public function OnActivatePlugin(){}
  public function OnDeactivatePlugin(){}
 
  public function FilterCallback($filterID, $content){
    if(($filterID == GBPLUGINS_FILTER_POST_CONTENT) 
     && is_readable($this->GetDirPath().self::MARKDOWN_SCRIPT)){
       require_once($this->GetDirPath().self::MARKDOWN_SCRIPT);
       return Markdown(html_entity_decode($content));
    }
    return $content;
  }
}

Como puede verse, únicamente veinte líneas son necesarias para que el plugin pueda llevar a cabo su trabajo. Por supuesto, un plugin puede complicarse todo lo que se quiera, pero, como se aprecia, no quita que, con relativamente poco esfuerzo, puedan conseguirse plugins realmente prácticos.

En principio me mostraba reacio a los editores "Wysiwyg", que luego he acabado utilizando. Yo me mostraba a favor del texto plano, del HTML puro y duro, puesto que uno ha cogido cierta práctica en escribirlo, casi sin pensar, si se me permite decirlo así, estoy seguro de que no soy yo sólo el que expirementa algo parecido.

Tal vez si hubiera sabido antes de John Gruber y su Markdown, o de Alex Shiels y su Textile, hubiera seguido prefiriendo el texto plano al "enriquecido", pero, todavía mejor, evitándome tener que escribir HTML tal cual, sino usando las sintaxis que proponen Markdown o Textile, cuyos ejemplos puedes ver aquí y aquí.

El caso es que, como me consta que hay gente enamorada de Markdown, y supongo que también de Textile, he añadido sendos plugins al repertorio de plugins para Gesbit, uno, que reconoce y procesa la sintaxis de Markdown, y, otro, la de Textile, en el cuerpo de las entradas de una bitácora.

Los plugins son realmente sencillos, el trabajo duro lo hace Textile, por un lado, y por otro Markdown, concretamente, una implementación de esta para PHP, PHP Markdown de Michel Fortin. Únicamente hay que tener en cuenta lo siguiente: si se usa alguno de estos plugins, no puede usarse el editor "Wysiwyg" de Gesbit. *

Esto significa que el usuario que quiera usar alguno de estos plugins, necesita editar su perfil, de modo que la opción correspondiente esté desactivada. De forma predeterminada viene así, desactivada. Por otro lado, todavía cabría añadir algo más: si se usa GbMarkdown, no puede usarse GbTextile, y viceversa.

No es que vaya a causarse ningún desastre, pero, en cuando un plugin "filtre" el contenido de las entradas, estas ya se presentarán en el correspondiente HTML, de modo que el "siguiente" plugin no tendrá nada que hacer, por decirlo así. Recuerda que ambos plugins realizan un trabajo muy similar.

En ambos casos se trata de escribir texto plano, con unas determinadas marcas (la sintaxis de cada Markdown y Textile), de forma que estas se conviertan automáticamente al HTML correspondiente. Cuando uno de los plugins realice este trabajo, el otro no podrá hacer nada, de modo que ambos plugins se excluyen.

Quizá se podría lograr una implementación más depurada. Por ejemplo, tal vez se podría dar a cada usuario la posibilidad de elegir el formato (Markdown o Textile, incluso otros) que quiere "aplicar" a una determinada entrada. Sin embargo, estos plugins no llegan tan lejos, primando la sencillez, o, si se quiere, lo simple.

* Tú puedes escribir HTML dentro del editor de texto plano (además de la sintaxis de Markdown, por ejemplo), pero, no es posible usar el editor "Wysiwyg", porque, este trabaja con HTML, y, por decirlo así, rompería la sintaxis de Markdown.

Acabo de añadir a Gesbit dos nuevas "tareas" en sendos formularios para gestionar entradas y páginas de una bitácora. Ya es posible cambiar el "estado de publicación" y el "estado de privacidad" de una o más entradas y páginas, de forma simultánea. Como se puede ver en la imagen de más abajo, ya existían otras tareas relacionadas disponibles.

Estas "tareas" son útiles para cambiar el estado de alguna de las propiedades de una entrada o página, pero, sobre todo cuando se trata de cambiar el estado de varias entradas o páginas al mismo tiempo. Además, he implementado algo mejor mejor el asunto, si se me permite decirlo. No es un añadido espectacular, pero, tampoco es desdeñable, ¿no te parece?

Ya sabes que estás invitado a probar Gesbit, no dejes de hacerlo.

Me gustaría escribir sobre los cambios recientes llevados a cabo en Gesbit. Algunos más o menos menores, como, el uso de "instanceof" en lugar de la función "is_a()", para comprobar si un objeto es la instancia de una determinada clase o no. También he sustituido el uso de "readdir()", allí donde se usaba, por la clase "DirectoryIterator".

Me he percatado de que la clase "Themes" estaba incluyendo antes los archivos JavaScript y después los archivos CSS. Igual ocurría en el panel de administración de Gesbit, y, aunque no se trata de un error, sí que las páginas se ve de otro modo mientras carga: puesto que ya cuentan con su "estilo" mientras cargan los "scripts" necesarios.

Pero, esta entrada se titula como se titula por algo, evidentemente, y es que ahora en Gesbit queda más claro y diferenciado lo relativo a la internacionalización (i18n) y a la localización (l10n). En Gesbit venía usando una clase "Localize", que había llevado a cabo para algún proyecto anterior. Y también existía una clase "DateUtils", que estaba mezclando cosas.

Han sido necesarios varios cambios "a nivel interno", pero, no ha sido complicado, porque todo estaba más o menos claro. He creado una nueva clase "L10n", que contiene parte de los métodos que contenía, erróneamente, la clase "DateUtils". Ahora la clase "DateUtils" contiene sólo lo que se espera: utilidades relacionadas con fechas.

La clase "DateUtils" queda en clase estática, y, la clase "L10n" contiene lo relativo a la poca o mucha "localización" que puede llevarse a cabo en Gesbit: Nombres de meses, días, abreviaturas, todas correspondientemente traducidas, localizadas. Esta clase se instancia ahora en una variable "global", tal como se hacía antes con "DateUtils".

Y, por último, pero, no menos importante, la clase "Localize" pasa a llamarse "I18n", porque, efectivamente, más que para la localización de Gesbit, sirve para su "internacionalización", o para la posible "traducción" de textos y cadenas de caracteres. Todo esto para llamar a las cosas por su nombre, que es lo mismo que intentar no confundir.

¿Qué te parece? A mí me hacen especial ilusión estos cambios, porque, efectivamente, ahora queda más claro lo que se dedica a la localización y a la internacionalización, aunque a veces se entremezclan. Pero, lo que estaba claro es que la clase "DateUtils" estaba errada, y que la clase "Localize" existía porque no existían "I18n" y "L10n", como ahora.

¿Cómo? ¿Cambios en un plugin que se publicó ayer mismo? Así es, pero, todo tiene una explicación. Lo que ocurre es que existen al menos tres plugins "Lightbox" distintos de la biblioteca jQuery para JavaScript. Todos son buenos, todos funcionan, todos cumplen, pero, el que utilicé en primer lugar tiene algún que otro problema no resuelto, cuenta con funcionalidades que no iban a usarse nunca en Gesbit y ocupa el doble de tamaño que el plugin que ahora mismo ya usa el plugin Lightbox para Gesbit.

Son motivos suficientes como para plantearme el cambio que he llevado a cabo, y ahora se utiliza este LightBox para jQuery. El motivo principal que me ha llevado a cambiar de plugin de jQuery, ha sido la forma de inicializar el mismo: el que usé ayer se inicializaba sólo, lo que conllevaba ventajas, pero, también problemas, sin ir más lejos, uno con las opciones del plugin, que hacían necesario editar el código fuente del propio plugin para jQuery: alqo nada recomendable para futuras actualizaciones del mismo.

El plugin de jQuery que ahora uso permite su inicialización a placer, no se inicializa solo, por un lado, pero, cuenta con las suficientes opciones, funciona en los mismos navegadores que el anterior plugin, ocupa menos, en fin. Se da un cambio, sin embargo, de cara al usuario de Gesbit. Ahora, para mostrar una imagen mediante el plugin, es preciso que un enlace a esta cuente con el atributo "class=lightbox". Si se quiere mostrar una o más galerías de imágenes, hay que añadir un atributo "rel=nombre-album", donde "nombre-album" puede variar.

En todo caso, los cambios han sido más o menos sencillos, luego de algunas pruebas, y no sólo he actualizado el plugin, sino que también estoy usándolo en mi bitácora personal, como sabes, y una prueba es esta entrada de mi bitácora, donde puede verse la última versión del plugin LightBox para Gesbit en acción. En general, como he dicho, de cara al lector de la bitácora, apenas hay diferencia entre un plugin para jQuery y otro, así que los cambios prácticamente no se notan. En este aspecto ambos plugins se comportan de forma similar.