El blog de Maikel

Este tema parece sencillo, pero personalmente me complicó la vida. Todos sabemos que la url taxonomy/term/tid en Drupal provee un listado de todos los contenidos categorizados en el término tid. La forma en que muestra esa lista de contenidos responde al theme que estos tengan aplicado. Pero un requerimiento de diseño puede implicar que se desee mostrar esa lista, que por defecto nos provee el módulo taxonomy de otra forma. Mi primer impulso fue buscar un tpl para tal fin. En Drupal 7 template suggestion ( http://drupal.org/node/1089656 )encontré que existe un taxonomy-term--tid.tpl.php . Realemente no se si es un error personal (pero encontré en muchos foros muchas personas con el mismo problema), pero aunque tomaba los cambios que uno aplicara en el tpl, al final siempre imprimía el valor de $content , aunque este no se imprimiera en el fichero, es decir hay alguien (supongo que sea taxonomy) que después de mostrar lo que se definió en el tpl pues muestra el comportamiento natu...

El módulo Views es sin dudas uno de los componentes principales de Drupal. Si bien aún en la versión 7 no se incluyó en el core, nadie duda de que es casi imprescindible para incorporar funcionalidades de todos los días en nuestros sitios. Una de las múltiples funcionalidades de Views es el uso de AJAX. Esto incorpora este comportamiento en los paginados y en lo filtros dándole al resultado final un alto nivel de usabilidad. Realmente funciona a las mil maravillas. Como siempre queremos más, muchas veces tenemos que incorporar otros comportamientos en una vista que requieren que incluyamos código java script propio. Si la vista usa AJAX esto puede ser problemático, porque al ejecutarse un paginado o un filtro se reconstruye toda la vista y con ello el DOM vuelve al estado original y nuestro JS es muy probable que no se ejecute. Para solucionar este detalle y seguir usando AJAX en nuestras vistas la respuestas es no poner nuestro js en el típico jQuery(document).ready , en este caso...

Hace un tiempo necesitaba crear un efecto de esos tan comunes en estos tiempos donde tienes un conjunto de imágenes en un bloque que van saliendo una tras otra, con cierto efecto. Drupal da muchas posibilidades para eso, incluso pluging para views para manejar la presentación de esta forma. Pero la verdad prefería en ese momento hacerlo, para así aprender. Lo primero que hice fue implementar un módulo que generara un bloque donde colocaría el slide de imágenes. Para eso simplemente busqué un ejemplo en internet y tomé su código y lo adapté a un módulo de Drupal. La verdad funcionó perfectamente. Pero usando ese mismo módulo en otros proyectos entró en conflicto en una salida de una vista. El problema estaba en que ese ejemplo usaba una versión de JQuery diferente a la que trae consigo Drupal 7. Por ello para evitar entrar en estos conflictos lo mejor es si se va a implementar apoyarse en herramientas que brinda Drupal. Les presento estas solución: Para D6 y D7 existe un módul...

Hoy retomo el blog, con el firme propósito de poner un post semanal, porque las cosas se van dejando y luego quedan como abandonadas. Revisando post anteriores me percato del tiempo que he dejado de escribir. Ese tiempo se traduce en que ya Drupal está estable en su versión 7 desde casi un año y los últimos post se referían en todo momento a la versión 6. Mucho ha llovido desde entonces. La versión 7 de Drupal trajo consigo muchos cambios. Nos haremos una comparación entre Drupal 6 y 7 porque ya hay cientos de ellas y seguramente no llegaríamos al nivel que muchas de estas alcanzan. Centraremos este Post en algunos detalles que suelen afectar. Importar y exportar tipos de contenidos Cuando se instalaba CCK en Drupal 6 aparecía dentro del grupo CCK el módulo Content Copy que permitía exportar e importar estructuras de tipos de contenidos. Para la versión 7, como sabemos el core trae consigo el módulo Field y dependiente de este algunos otros que permiten crear campos con sus respectiva...

Craking Drupal es un libro que leí hace poco tiempo, pero que me enseñó muchas cosas y que hoy quiero compartir en este blog. El autor del libro, Greg James Knaddison , hace una reflexión bastante amplia de lo que es la seguridad en Drupal, de cómo se manifiestan los principales problemas y de las buenas prácticas para evitarlos. Aunque es imposible en un post resumir un libro tan amplio, trataré de hacer un resumen lo más concreto posible. El primer punto es olvidarnos de la estúpida idea que existe en muchas personas que plantean “….no uso un CMS porque estos tienen problemas de seguridad….” Para mi esta es la expresión de un neófito que no tiene nada que decir. Los problemas de seguridad existen, se use un CMS o no, incluso es más probable que una persona cometa errores que repercutan en la seguridad de una aplicación Web si hace todo el trabajo desde cero que si usa una herramienta respaldada por una comunidad e incluso por importantes empresas del sector de las TIC. Drupal por de...

Me puse a probar una serie de comentarios y post de los grupos de drupal.org sobre el tema de los perfiles. Sobre todo en el grupo de argentina, gracias a los siempre excelentes post de victorkane. Este tema no es nada del otro mundo, es una cosa bastante sencilla, pero que nos puede ser útil. Pregúntense ¿qué proyecto hacen en Drupal en el que no activen el módulo path y php filter?, ¿qué proyecto hacen donde no incluyan CCK y VIEWS?, ¿quién no usa Administration menu para la administración? Bueno, entonces porque siempre pasar el trabajo de estar instalando estos módulos. Para resolver eso lo mejor es crear un perfil de instalación donde una vez instalado Drupal ya todos estos módulos estén instalados por defecto. Pero esto es solo una de las ventajas de tener un perfil. Hay miles de proyectos que son similares, ¿por qué no crear un perfil para esos casos? donde no solo los módulos salgan instalados, sino, que también se creen estructuras como puede ser un menú, un bloque, una taxon...

En el artículo anterior decía que no habíamos encontrado un módulo para Drupal que hiciera las veces de proveedor de servicios OAI. Se mencionaban un conjunto de herramientas que Drupal incluía y que habíamos probado, pero desgraciadamente no encontramos un proveedor de servicios, aunque si un proyecto llamado eXtensible Catalog Drupal Toolkit , que al parecer implementa toda la filosofía del protocolo OAI-PMH (Open Access Initiative Protocol Metadata Harvesting), pero personalmente no lo he probado. Seguramente es una excelente solución, como todo lo que implementa esta comunidad. Nuestra solución no fue usar ese módulo, principalmente por descubrirlo un poco tarde, esto nos llevó a desarrollar un módulo que llamamos Service Provider. Antes de hablar del módulo en cuestión me tomaré dos o tres párrafos para explicar el protocolo OAI-PMH, para que se entienda mejor en que consistió el trabajo. El protocolo OAI-PMH sirve para regir el intercambio de información Open Access entre reposit...