Feed aggregator

Este es un artículo que he traducido de Group 42 que me pareció muy interesante:

Views 2 ofrece un entorno de theming muy bien estructurado permitiendo el control de la presentación de cada elemento de una vista. Y en mi humilde opinión está genial!

Aquellos sin esperiencia con Views 1 encontrarán que Views 2 usa técnicas de theming estándares de PHPTemplate. Toda tu experiencia en theming con Drupal podrá ser usada con Views.

Los themers de Views 1 que empiecen con Views 2 podrán estar un poco confusos al principio. Yo lo estuve. El callback en template.php donde todo ocurría ya no está, conversionado en un consistente framework de ficheros de plantillas. Toda la libertad que existía en una función todavía existe pero con el añadido de la simplicidad de una bien definida estructura.

Resumen

Views permite hacer consultas a la base de datos y organizar la información para mostrarla. Crea un salida convirtiendo los datos recibidos en variables y pasándolas a una serie de plantillas. Cada plantilla maneja un diferente nivel de "creación de salida". El número de plantillas usadas para crear un código html de salida depende del tipo de Views y su estilo, además de los campos involucrados. Estas plantillas existen como ficheros (con extensión tpl.php), en el directorio del módulo o del theme, y siguen las convenciones de nombre de PHPTemplate.

Los niveles de las plantillas son:

• Campo (Field): Cuando se usan campos en una vista (Estilo de fila = Campos, Row Style = Fields), cada campos puede ser personalizado (themed) con una plantilla específica por campo. Si "row style = Node" entonces se usarán los ficheros de nodos tpl.php.
• Fila: Controla como cada campo individualmente será integrado en una fila. Esta plantilla no se usará para el estilo tabla.
• Estilo: Controla como las filas se integran con el código html de salida. Por ejemplo, en una vista tipo lista un bucle foreach pone cada fila (<li>) dentro de una lista desordenada (<ul>).
• Display: Controla la presentación de cosas como el título, la cabecera o el pié.

Cada nivel se convierte en variables de entrada para el nivel superior. La salida de las plantillas de campos son variables de entrada para las filas, la salida de las filas se convierte en variables de entrada para las plantillas de estilo, etc. También hay disponibles variables específicas según el nivel, como el el número de fila. Está disponible un diagrama en http://views-help.doc.logrus.com/help/views/analyze-theme.

Se usa una convención de nombres para conseguir tener una plantilla muy específica o muy general variando sólo su nombre. A través de un nombre apropiada, una plantilla puede aplicarse a todas las vistas, sólo a un tipo de vista o sólo para un "display" de una vista específica. Cuando múltiples ficheros se pueden aplicar a una vista aquel con el nombre más específico será el usado.

Las Plantillas

Cada nivel de theming tiene una plantilla por defecto. Las plantillas por defecto están en el mismo directorio de themes de módulo Views: por ejemplo., sites/all/modules/views/theme. Estos ficheros pueden proporcionar un punto para comenzar y un ejemplo de personalización, aunque si naturaleza generalista puede hacerlos algo complicados y no tan útiles cómo desearíamos.

Plantillas del módulo Views

El enlace de la información para personalizar el theme en la interfaz de Views 2 muestra información de los ficheros de theme de esa vista. Cada "display" tiene una información de theming diferente, por lo que asegurate que tienes seleccionado el "display" correcto.

Panel de información para personalizar las plantillas

Haciendo click en el enlace muestra un panel (ver la imagen de abajo). El panel muestra, en negrita, las plantillas usadas a cada nivel y muestra una lista de nombres de plantillas que reescribirán las plantillas por defecto.

Panel de Información de las Plantillas

Cuando estés preparado para personalizar tu vista, haz click en el enlace de Información del theme y decide el nombre apropiado para usar en tu template. generalmente personalizarás un "display" de una vista en concreto con lo que lo mejor es que selecciones uno de los nombres específicos o incluso el que más.

Una vez hayas identificado el nivel apropiado para personalizar, copia la plantilla por defecto de directorio modules/views/theme directory al directorio de tu theme y renombralo con el nombre que escogiste.

Identificando y copiando la plantilla

Aprentando al botón de "rescan" en la sección de Información refrescará la información cacheada y confirmará si el fichero que has copiado y renombrado ha sido detectado por Views

Ahora puedes modificar la plantilla para ajustarla a tus requisitos.

Además de reconocer el directorio de tu theme como sitio para colocar las plantillas, Views también reconoce las plantillas que pongas en el directorio views de tu theme. De esta manera todo estará mucho más organizado sobretodo si tienes muchas plantillas de Views.

Variables de las Plantillas

Mirando que se usa en el código de la plantilla por defecto es un buen punto de partida pero puede no darte una idea de todas las opciones. Las plantillas por defecto son muy generales, tal cómo debería ser, y a veces es complicado extraer información útil de las variables de los bucles foreach. Afortunadamente hay técnicas simples para mostrar las variables disponibles.

Lo primero que podemos pensar es poner algo cómo esto en nuestra plantilla:

<?php
  print print_r(get_defined_vars(), 1)
?>

Desafortunadamente, las variables disponibles incluyen el objeto de la vista, que contiene referencias a si mismo. Si lo mostramos todo hará mucho más complicado examinar las variables e incluso podría producir errores de memoria excedida. Algo mejor sería usar:

<?php
  print print_r(array_keys(get_defined_vars()), 1);

  // Or if you have the developer module installed
  dsm(array_keys(get_defined_vars()));
?>

Cada índice del array es el nombre de una variable. Por ejemplo, un índice del array llamado "field" se podrá usar en la plantilla como $field. Esto te dará un buen punto de partida para explorar las posibles variables.

Si tu plantilla de la vista tiene una variable $fields puedes repetir este truco para obtener la lista de los nombres de los campos:

<?php
  print print_r(array_keys($fields), 1);

  // Or if you have the developer module installed
  dsm(array_keys($fields));
?>

Dependiendo de como estés mostrando la información querrás usar en la salida un tag <pre> y usar la función htmlentities si la variable contiene HTML:

<?php
  print '<pre>' . htmlentities(print_r($rows, 1)) . '</pre>';
?>

Desde que Views 2 usa el theming estándar de PHPTemplate, puedes usar las funciones preprocessor en tu template.php. Para más información en preprocessors: http://drupal.org/node/223430. El nombre del hook es el nombre de la plantilla menos la extensión (tpl.php) y con los guiones convertidos en guiones bajos. Por ejemplo para una plantilla que se llame views-view-list--comments-recent--page.tpl.php la función preprocessor para ponerla en template.php será:

<?php
function phptemplate_preprocess_views_view_list__comments_recent__page(&$vars) {
  // code
}
?>

De Views 1 a Views 2

Algunas rápidas diferencias que los themes de Views 1 pueden encontrar útiles:

• El theming ahora es manejado usando ficheros y no funciones en template.php
• El theming de Views ahora es consecuente con la manera que los nodos se personalizan (por ejemplo PHPTemplate)
• Donde antes Views 1 proveía de un código y nombre de ejemplo vía del tab "Theme wizard", ahora Views 2 usa el botón de información y el directorio por defecto de los ficheros en views/theme.
• El fichero de template más parecido a la función de theme de Views 1 es el de "Row style output"

Sumario:

Pasos básicos en el theming de Views 2:

• Usa el enlace de información de theme para determinar con que plantilla empezar y para saber los posibles nombres
• Copia la plantilla por defecto desde modules/views/theme al directorio de tu theme
• Renómbrala con el nombre selecionado
• Dale al botón de "scan" para actualizar la cache y confirmar que has copiado/renombrado correctamente
• Lee los comentarios del fichero de la plantilla y usa:

  <?php
          print print_r(array_keys(get_defined_vars()), 1);
  
          // O si tienes el módulo "developer" instalado
          dsm(array_keys(get_defined_vars()));
        ?>
  para encontrar los nombres de las variables

• Usa el subdirectorio "views" en tu directorio del theme para mantener tus ficheros de las plantillas organizados

Añadir un bloque en nuestro blog o sitio en Drupal que incluya nuestros updates en Twitter es muy sencillo, siguiendo el mismo método que para añadir los elementos compartidos de Google Reader, podemos tenerlo activado en unos 3 minutos.
Os dejo el screencast que he realizado para mostrar cómo se hace:

Si bien es cierto que hay módulos que gestionan un interfaz entre Twitter y Drupal, puede que queramos solamente añadir un bloque con los updates, y no necesitar más funcionalidades, por lo que, cuanto más simple, mejor.
Una vez añadido el bloque, se puede formatear utilizando CSS, ya que crea un div con id twitter_div al que podemos cambiar las características para que se ajuste al estilo de nuestra web.

El video tarda un poco en cargar porque está subido a Youtube en HD, hablaré más sobre esto dentro de poco.
<!--break-->

Desde drupal.cat han organizado un nuevo taller sobre Drupal para el sábado 10 de Enero. El objeto del taller es profundizar sobre CCK, el taller se llama CCK o com fer arribar el teu Drupal a l'infinit i més enllà... (CCK o como hacer llegar tu Drupal hasta el infinito y más allá) y podéis encontrar el programa aquí.
Lo impartirán Jaume y Mark, y promete estar muy muy bien.
Si vais a asistir, recordad que deberéis llevar un portatil con Drupal instalado para agilizar la práctica.

Yo no podré asistir, ya que ese sábado no estaré en Barcelona, pero si queréis más detalles, pasaros por drupal.cat.

Esta es mi primera entrada en el blog. Antes de nada presentarme. Me llamo Aitor Ibañez, trabajo como informático freelance, gestionando y ayudando directamente en la realización de algunos de los procesos que se requieren a la hora de hacer una página web: diseño web, maquetación web accesible, programación (directamente) y posicionamiento orgánico en buscadores(directamente). Tengo 25 años y vivo en donostia-san sebastian,guipuzkoa.

leer más

Interesting Fact: this is the 210th time we've posted to this blog. Bittersweet Reality: it will be the last.

Our team has used Burning Questions to provide FeedBurner product announcements and stories about the publishers who use FeedBurner since February of 2004. We've laughed, we've cried, we've hackathoned. Above all, we've tried to give you a running play-by-play of the service's evolution from a green page with eight checkboxes to a central hub for publicizing, optimizing, analyzing, and, of course, monetizing all manner of blog, podcast, and commercial content in syndication. (We sheepishly admit a good number of you have spent more time than you'd like troubleshootizing, too. Feeds can be ornery.)

Today we're formally signing off Burning Questions, but not before we direct you to the new, official site for all future updates: the AdSense for Feeds blog. This blog will contain all future updates related to all FeedBurner services. We will soon redirect the Burning Questions feed itself to point to the new blog, so you don't need to update any existing feed (or email) subscriptions. Our first post discusses how you can start managing your feeds from a Google account, rather than from your old feedburner.com account. This is mondo important, as all future feed services, both AdSense-provided and otherwise, will eventually require use of a Google account.

FeedBurner would be just another digging construction guy graphic without your active use of, and involvement in, all aspects of it through the years. As we start tying more closely into other Google products that you may already use, we are eager to give you much more of the get-out-of-the-way, it-just-works joy, simplicity and reliability you deserve from web service like ours with all the benefits that Google's platform provides.

Finally, we must relent and reveal: here is the inspiration for a certain error page. With this last post, you finally have all of our secrets. Good luck, and avoid routines like "20 goto 10." That one required the air brakes.

Ayer se anunciaba la salida de las actualizaciones drupal 6.7 y 5.13 con un buen puñado de parches de seguridad y errores corregidos, unas versiones cuyas fechas están bastante planificadas y que aglutinan muchas issues que se agrupan para evitar la acumulación de releases o lo que podríamos llamar "efecto wordpress"

Tan solo un día despues salen dos nuevas versiones, la 6.8 y 5.14, y coincido con undomain en que es bastante extraño y no da mucha confianza, y por eso me he revisado las notas de la release con más detalle que habitualmente.

Parece ser que uno de los parches incluidos en las releases 6.7 y 5.13 hacía que las últimas versiones estables no fueran compatibles con PHP 4 (la incompatibilidad se puede ver en este comentario). Es decir, que si un sitio está ejecutándose en PHP 5 y ya ha actualizado a drupal 6.7 / 5.13, no hay una prisa real en aplicar el parche para la 6.8 / 5.14.

Esto me hace pensar dos cosas:
- ¿Por qué la gente sigue utilizando PHP 4? Go PHP5!! (curiosamente gophp5 está hecho en drupal)
- Y lo más importante, este parche "apresurado" por cuestiones de compatibilidad, daña la imágen de Drupal como sistema haciendo que parezca menos estable de lo que en realidad es. Quizás deberían publicitar mucho más las "betas" de las releases planificadas (¿sin la parte de seguridad, para no dar pistas sobre vulnerabilidades antes de tiempo?) para que hubiera más gente probándolas y se redujera la posibilidad de este tipo de fallos. ¿Qué opináis al respecto?

Esta semana ha sido de lo más intensa e interesante, no tengo costumbre de hacer resúmenes pero en este caso creo que corresponde.

leer más

Now that drupal is global and that the language "official" is the English, some of our post the write in this language.

As it is not our language will be small flash of news that may be more interesting.

leer más

Así es, hemos ganado el concurso Webactiva 2008 en la categoría de mejor Portal Web con www.economiasolidaria.org. Estos premios son organizados anualmente por CEIN premiando las mejores webs en diferentes categorías.

leer más

Esta mañana me ha llegado un mensaje del grupo de seguridad de Drupal en el buzón de correo, eso significa que han sacado nuevas sub-versiones de seguridad y toca actualizar.
¡Justo cuando acababa de pasarme a Drupal 6!
El método de actualización de una sub-versión a otra (por ejemplo, de drupal 6.6 a drupal 6.7) es bastante simple, primero hacemos copia de seguridad de base de datos y ficheros, sobreescribimos los ficheros de nuestra aplicación con los de la nueva, que nos descargamos de drupal.org (sin sobreescribir el /sites!!), ponemos el sitio en mantenimiento (opcional) y accedemos a update.php, seguimos el proceso del interfaz, y voilà! ya estamos actualizados ;)

Aquí podéis ver el listado de parches incluidos en la versión 6.7 y 5.13.

Al ser una actualización de seguridad, la recomendación es hacerla lo antes posible, en caso de que no tengamos tiempo para aplicarla inmediatamente, es muy aconsejable aplicar los parches de seguridad hasta que podamos actualizar completamente. El parche de seguridad para drupal 6 es este y para drupal 5 este.

Si tenéis dudas de cómo se aplican estos parches, en drupal.org hay un paso a paso.

Para que os lleguen este tipo de avisos de seguridad, pasaos por la página del grupo de seguridad en drupal.org y desde allí podréis subscribiros.

Hace unos días nos leíamos un artículo en A List Apart muy interesante, reflexionando acerca de cómo mejorar el error 404 en un servidor. A grandes rasgos, proporcionaba un script en Perl para averiguar por qué se había producido el error 404 y así ofrecer una informacion un poquito más útil a los usuarios que se encontraban con esta página.

Drupal no es tan versátil en este caso, pero mejorar la usabilidad de los sitios web es un poco más fácil gracias a que permite la configuración de las páginas de Acceso Denegado y Página No Encontrada.

• Acceso denegado

Es un error que transmite Drupal desde el servidor, con código 403, cuando se está intentando hacer una petición a una página para la que no se tiene acceso.

• Página no encontrada

Este mensaje es enviado también por el servidor web, con código 404, que informa de que la dirección http que se ha introducido no existe.

En el caso de Drupal, ambas páginas pueden configurarse para que sean un poco más amigables, ¿cómo?

1º Creamos dos nuevas páginas (node/add/page), un texto que puede servir es:

No hemos encontrado la página

La dirección que nos indica no corresponde con ninguna página en esta web. Asegúrese de que la URL está bien escrita o use nuestro buscador.

Atentamente, El Equipo del sitio.

No puede acceder a esta sección

Lo sentimos, pero no podemos darle acceso a esta sección. Si es usted usuario de nuestra web puede intentarlo de nuevo autentificándose. Si el problema persiste y necesita del acceso, consulte con un administrador de la web.

Atentamente, El Equipo del sitio.

 

2º Desde la dirección (relativa) admin/settings/error-reporting de nuestro sitio podremos indicar los nodos correspondientes

Los mensajes son sólo una sugerencia, se trata siempre de informar y dar alguna opción al usuario, ya que ha llegado a la web, aunque sea a través de un enlace roto que no pierda la esperanza. En el caso de acceso denegado es incluso más importante, cuántas veces habremos olvidado conceder los permisos suficientes a un usuario. Tampoco viene mal advertir que efectivamente, existen áreas que son restringidas sin que la privacidad resulte excluyente.

Al hilo del artículo, en Drupal falta aún dar un poquito más de información a los desarrolladores, para conocer las causas exactas del error y tratar de evitarlo, aunque para eso aún podemos acudir a espiar los registros (logs) de las diversas herramientas.

Desde que intenté sobreescribir un perfil de usuario creando una vista y enviando argumentos (no lo intentéis, no funciona!) me he topado siempre con el mismo problema: el de poder elegir libremente la manera en que se muestran los datos en un nodo.

Entonces se publicó Panels 2 , la segunda versión de un módulo que en principio sólo servía para crear un nuevo layout dentro de la zona de contenido principal. Los panels permitían entonces mostrar bloques o páginas creadas con vistas y enviar argumentos hacia la página (si existía) de la vista completa.

Esto, suponía ya de por sí una revolución, ya que facilitaba en cierto modo a los no maquetadores, crear de una forma ágil nuevas distribuciones y además más complejas con la ayuda de las vistas.

Ahora, Panels 2 le da una vuelta de tuerca a todo esto y permite redefinir páginas que ya existen como las de tipo node/<id> o user/<id>/edit, por ejemplo.

¿Qué nos permite esto?

1. Recolocar los elementos (como hasta ahora) y definir sobre ellos permisos de visualización, órdenes y condiciones...y todo eso que hacen las vistas.
2. No tocar el código, ni el del template ni el de contemplate.
3. Decidir cómo debe mostrarse un nodo al editarlo, visualizarlo y crearlo (sea del tipo que sea)

Todas estas segundas versiones, en principio complejas para la gente que nos revolucionamos cuando salió el proyecto Flexinode, siguen una tendencia marcada por las versiones 6 y 7 de Drupal, la de mejorar la usabilidad en la administración y con ella potenciar las posibilidades.

 

Reflexión personal

Aveces me pregunto si el hecho de intentar hacer las cosas bien, usables, inteligibles, simples, eficaces... no es precisamente lo que capacita a las herramientas para que por fin sean útiles.

Quizá haya ignorado durante mucho tiempo que ésto se podía hacer ya con algún truco de experto y con las anteriores versiones, pero ahora desde luego me queda claro que es posible.

En cuanto pruebe la segunda versión del Views seguro que descubro alguna nueva maravilla... o quizá no

 

De vez en cuando miro el listado de módulos de drupal.org ordenados por fecha y así veo los nuevos y las actualizaciones de los otros. Y aquí os dejo algunos que me han parecido interesantes:

• Profile Complete Percent: Te muestra el porcentaje del perfil que ha completado el usuario.
• Timeline: Para crear timelines
• jQuery Impromptu: Bonito reemplazo para alert, prompt y confirm.
• RSVP: Permite invitar a gente a un evento.
• Hide Submit: Oculta el submit una vez pulsado para evitar que se pulse más de un vez.
• Invitation Voucher: Permite gestionar invitaciones para poder registrarse. Ideal para tener una beta privada.
• Floating Windows: Para mostrar ventanas arrastrables para mostrar mensajes, formularios, etc. Sólo en el CVS.
• Draft: Permite crear borradores y además mediante javascript va guardando el formulario de forma automática por si pasa algo. Imprescindible (yo ya me lo he puesto y lo he añadido a la lista de módulos imprescindibles para un blog)
• Node Edit Protection: Te avisa si te has dejado a medias el formulario de un nodo.

Hasta ahora no me había encontrado con un proyecto en el que, por requisitos técnicos, tuviera que conectar necesariamente con una base de datos Postgres. La razón era que necesitaba hacer conexiones con dos bases de datos diferentes con el CMS Drupal y esto sólo puede hacerse si el sistema de gestión de BD es el mismo.

Resulta un poco decepcionante, después de pasar largo tiempo defendiendo y presumiendo de abstracción en la gestión de consultas de Drupal y del soporte multiplataforma, encontrarte con que la mitad de los módulos no han preparado su .install para que puedan crearse las tabalas, índices y secuencias necesarias para su funcionamiento sobre Postgres.

Suerte, que leyendo un poco más descubro el nuevo API (Schema API) que viene preparado en la versión 6, en el que no sólo se abstraen consultas, actualizaciones y demás, sino que además permite la creación de tablas de forma "unificada".

Una de cal y otra de arena. Mi recomendación es que no merece la pena pelearse con una base de datos y que si tienes que enfrentarte a un Postgres con Drupal valora el tiempo de crear índices y tablas a mano.

A continuación voy a explicar en qué consiste en fichero .install y cuáles son los geniales cambios que se han implementado en la v6 y posteriores.

El gestor de contenidos Drupal funciona, grosso modo, con ficheros llamados módulos (extensiones). Cada módulo es una funcionalidad en sí misma, uno que gestiona los usuarios, otros que gestiona los blogs, etc.

Los módulos que no vienen incorporados en el paquete básico funcionan exactamente igual que el resto y consisten. Todos consisten en al menos 3 ficheros:

• Un .module, con el código de la funcionalidad en sí
• Un .info, con información de su descripción, versión, nombre, paquete, etc.
• Un .install, con el código necesario para su instalación, actualización y desinstalación

Fichero .install

Cuando el módulo se activa por primera vez, Drupal consulta si existe un fichero de este tipo y ejecuta la función que en él existe:

nombreDelModulo_install()

El código que contiene esta función suele ser de la forma:

switch ($GLOBALS['db_type']) { case 'mysql': case 'mysqli': //... break; case 'pgsql': //.. break; default: drupal_set_message(t('Unsupported database.')); }

Donde se mira el tipo de base de datos que se ha indicado en la configuración y se ejecuta el código sql apropiado para ese sistema de gestión.

El problema es que los desarrolladores del módulo se olvidan de proporcionar el código para los dos casos (actualmente son las bases de datos que, se dice, tiene soporte). Un problema que los usuarios tampoco resolvemos porque no reportamos la necesidad cuando se encuentra.

La solución dada con el nuevo API me parece, sin embargo, acertadísima.

Schema API

El Schema Api proporciona, como he comentado, la facilidad para defininir estructuras abstractas de base de datos para, porteriormente, convertirlas según el lenguaje específico de cada sistema de gestión de contenidos.

Ahora, nuestro código se simplifica (incluso se queda en la mitad), ya que sólo tendremos llamar dentro de la función nombreDelModulo_install(), al hook_schema, es decir a nombreDelModulo_schema('tabla').

Esta función debe estar definida dentro del módulo, será un hook más y se parecerá a:

function nombreDelModulo_schema(){ $schema['tabla'] = array(     'fields' = array(         'vid' = array(             'type' = 'int',             'not null' = TRUE, ...         ),     ), ); return $schema; }

Más información http://api.drupal.org/api/group/schemaapi/6