Un sitio en Drupal paso a paso. Parte 113 Comentarios

Fecha: 

07 de Febrero de 2009

Bienvenidos a Cuenco Digital. En este primer artículo y en los siguientes se explicará como se construyó este sitio de

la manera más ilustrativa posible.

Es muy difícil describir la construcción de cualquier pieza de software. El proceso generalmente no es lineal sino que

consiste en una serie de iteraciones, idas y vueltas, correcciones y ajustes.

La construcción de Cuenco Digital no escapó a esto. Sin embargo una vez terminado todo, es posible describir en

líneas generales los pasos necesarios para diseñar un sitio como este como si se tratara de un trabajo sin marchas

atrás.

Hace un poco más de un año me propuse crear un sitio personal en donde volcar en forma de artículos mis

aprendizajes relacionados con el administrador de contenidos Drupal.

Por aquel entonces la versión estable para descargar era la 5.2, Drupal 6 estaba en pañales y muchos desarrollares aún

no habían comenzado a migrar sus sitios a las versiones más nuevas.

Estudio, trabajo, y otras cuestiones, hicieron que el proyecto se retrase. Y se retrasó mucho. Había escrito cuatro

artículos que explicaban como crear un sitio paso a paso utilizando Drupal 5. De eso, ya pasaron cinco meses y en

esta nueva versión de Cuenco Digital utilicé Drupal 6.

Este artículo es entonces una adaptación de aquel que escribí hace varios meses. Espero que funcione :-)

La visión:

Todo proyecto “debería” tener una visión, un porque. Generalmente esta visión en proyectos chicos o personales no

se escribe. Sin embargo con el tiempo esta visión termina siendo indispensable para que el proyecto no fracase o no

se desvirtúe completamente.

La visión de Cuenco Digital en pocas líneas podría describirse como:

Cuenco Digital es un sitio web en donde los diseñadores y programadores web que utilizan Drupal para sus

desarrollos, puedan encontrar material y compartir sus conocimientos con la comunidad de habla hispana.

Está orientado en gran medida a aquellas personas que ya han trabajado con Drupal y conocen sus fundamentos

básicos, dando lugar a la trata de temas más complejos e interesantes.

¿Por qué?

Porque otro sitio sobre estas temáticas. ¿No existen suficientes ya?.

Lamentablemente no, de hecho la mayor parte de este tipo de sitios está en inglés. Esto puede que no sea un factor

limitante para muchos, pero para otros sí lo es.

De todas formas nunca será demasiada toda la documentación que pueda ayudar a un desarrollador para que logre su

cometido.

Además, mi aprendizaje personal sobre todo lo referido a Drupal se basa en este tipo de sitios. Y a través de este

medio busco seguir aportando material a una comunidad que tanta información brindó desinteresadamente.

¿Qué?

Bien, ya está definido porque un sitio así y a que apunta. Ahora, ¿Qué recursos brindará Cuenco Digital? ¿Qué se

puede encontrar aquí?

Cuenco Digital pretende sumarse a otros sitios donde la documentación, los foros y los artículos están escritos en

español.

Para ello será necesario una infraestructura para la creación de artículos y donde la comunidad pueda comentar y

expresar sus opiniones.

Otro servicio que se brindará es el de los videos. Algunos temas son demasiado tediosos de explicar con palabras.

Usualmente un video es mucho más efectivo y permite explicar el concepto en pocos minutos.

Los hooks de Drupal son uno de los aspectos de mayor interés para los desarrolladores de módulos. Aquí se irán

recopilando los más utilizados con su documentación traducida en español y ejemplos más completos que los que

provee el API de Drupal.

En un futuro no muy lejano tal vez sea conveniente montar un foro sobre temas específicos, existen muchos foros

sobre Drupal por lo que esta cuestión estará sujeta a la forma en que participen los visitantes del sitio.

¿Cómo?

¿Como hacer todo esto? Un sistema web que soporte contenidos, comentarios y usuarios es candidato a ser

implementado con algún gestor de contenidos. Para este caso como no podía ser de otra forma se optó por Drupal.

Los detalles de esta sección serán el tema de siguientes artículos.

Resumiendo:

Un paso fundamental antes de empezar a construir es tener claro que se quiere construir. En la medida que se destine

un poco más de tiempo en esto, se ahorrarán mucho más en evitar complicaciones futuras en otras etapas del

desarrollo.

Una especie de plan de trabajo:

Hacer un sitio con Drupal puede dividirse en una serie de tareas idealmente podrían ser llevadas adelante por equipos

de trabajo diferentes.

Entre estas tareas se encuentran:

Diseño del aspecto visual (Theme)

Instalación y configuración de módulos (Funcionalidad)

Programación de módulos inexistentes y parches (Opcional)

Puesta a punto y pruebas

Lamentablemente no conté con un equipo de trabajo para diseñar esto, lo armé solo, en mis momentos libres entre el

trabajo y el estudio. Por eso el desarrollo fue una mezcla de todos esos aspectos a medida que iban necesitándose.

No obstante los siguientes artículos se organizan respetando estas divisiones para que cada uno pueda ser

aprovechado por quien lo desee.

En la sección artículos relacionados, se encuentran los enlaces a los demás artículos de esta explicación.

y... ¿Drupal para cuando?

Es realmente extraño que un sitio dedicado a hablar sobre Drupal no trate nada de Drupal en su primer artículo.

Para todos aquellos que piensen que aquí debería haber algo de eso por lo menos, voy a comentar algunas cuestiones

referidas a la elección de la versión de drupal para este sitio.

La primera versión de este sito, allá por fines del año 2007 estaba pensada para Drupal 5. La versión de Drupal a

utilizar no sólo depende de cual sea la "estable" y "recomendada" por los desarrolladores principales. Sino que se

debe tener en cuenta el estado de los módulos compatibles con esa versión.

Durante la primera mitad del 2008, Drupal 5 era mi elección a la hora de comenzar algún proyecto web. Pero desde

mediados de 2008 decidí elegir Drupal 6 pues los módulos views, y cck (casi irremplazables) ya tienen versiones

estables y funcionales para Drupal 6.

De hecho, hace unos dias, Drupal.org actualizó su sitio principal a la versión 6.x de Drupal. Ya no hay escusas.

Con esta elección también tome otra decisión importante. en este sitio, no voy a escribir artículos referidos a

Drupal 5. ¿Porque? Bueno, primero elección personal. Pero además porque después de 6 meses de usar Drupal 6

estoy convencido que son muy escasas las cosas que solo se pueden hacer con Drupal 5 y no la versión 6.

A pesar de mi decisión de no escribir sobre Drupal 5, es probable que algunos artículos lo mencionen. Principalmente

cuando se traten temas como "nuevas características" o mejoras entre las distintas versiones.

Bien. Esto es todo por hoy. Nuevamente gracias por visitar este sitio y espero que lo disfruten.

Un sitio en Drupal paso a paso. Parte 22 Comentarios

Fecha: 

08 de Febrero de 2009

En el artículo anterior comenté acerca de las ideas generales que guiarán el desarrollo del sitio.

En este artículo se tratan las cuestiones tal vez más interesantes para todos aquellos que nunca hayan usado Drupal.

Las herramientas:

Para empezar a construir un sitio se necesita un servidor. Un servidor es una computadora que aloja las páginas y las

“sirve” a todos aquellos que se las soliciten.

En donde construí este sitio tengo instalado un servidor casero. Una modesta Pentium III con un poco más de 300 Mb

de memoria RAM. El servidor corre con Debian Linux 4.0 tiene instalado PHP 5 y Mysql 5.

Con ese software Drupal funciona perfectamente y puede iniciarse la construcción del sitio.

Eligiendo, descargando e instalando Drupal:

Al momento de escribir este artículo existen dos versiones estables de Drupal. La versión 6 es la más moderna, la

versión 5 ya lleva varios años entre nosotros.

Meses atrás habría recomendado seguir trabajando con Drupal 5. Esto se debía principalmente a que los módulos

compatibles con Drupal 6 aún no estaban listos. Hoy en día, prefiero utilizar Drupal 6 como comenté en el articulo

anterior. La mayoría de los módulos para esta versión funcionan bastante bien.

Instalar Drupal es bastante simple, se requiere de una base de datos en Mysql, o PostgreSql y un poco de espacio en

disco.

Existen muchísimos tutoriales sobre como instalar Drupal. Por lo que no voy a detenerme demasiado en este paso.

Básicamente con comandos en una consola de linux sería algo asi:

#Ingresamos al directorio de trabajo de apache

cd /var/www/apache2-default/

# Descargamos drupal 6

wget http://ftp.drupal.org/files/projects/drupal-6.9.tar.gz

# Descomprimimos el archivo

tar xzvf drupal-6.9.tar.gz

# Creamos un nuevo directorio que alojará las configuraciones para el

sitio

cd drupal-6.9/sites/

mkdir localhost.nuevositio

# Copiamos el archivo default.settings.php al directorio anterior con

el nombre settings.php

cp default/default.settings.php localhost.nuevositio/settings.php

# Cambiamos los permisos de escritura del archivo

cd  localhost.nuevositio

chmod 777 settings.php

#Creamos la base de datos

mysql -u usuario_db -p

#introducimos el password de usuario_db

CREATE DATABASE drupal6_db;

quit;

#Crear un enlace dinámico para acceder al sitio desde el navegador

cd /var/www/apache2-default/

ln -s drupal-6.9 nuevositio

#Acceder a la url indicada: Por ejemplo http://localhost/nuevositio

(en un navegador web)

#Ingresar los datos solicitados por el asistente.

# Volver a cambiar los permisos de settings.php

cd /var/www/apache2-default/drupal-6.9/sites/localhost.nuevositio/

chmod 644 settings.php

#crear el directorio files y darle permisos de escritura

mkdir files

chmod -R 775 files

La configuración anterior no es excelente. De hecho recomiendo ver el siguiente video destinado específicamente a

como instalar drupal de una forma "segura" y apropiada. Por lo tanto, lo anterior es solo una forma de mostrar como

se puede instalar Drupal rápidamente.

Una de las ventajas que se introdujeron en Drupal 6 es la posibilidad de instalar Drupal en un idioma diferente al

inglés. Para lograr esto es necesario descargar el paquete de internacionalización para el lenguaje en español. El link

de descarga es http://drupal.org/project/es

El archivo debe descomprimirse en el directorio raiz de Drupal, si todo se hizo correctamente, al instalar drupal

aparecerá la opción de "Instalar en Español" como indica la siguiente figura.

Configuraciones iniciales:

Los sitios creados con Drupal poseen una serie de datos importantes por ejemplo: nombre del sitio, eslogan, dirección

de email, política de creación de nuevas cuentas de usuario, permisos, etc.

Comenzando con los datos del sitio. El nombre, el eslogan y la dirección de correo electrónico se configuran en el

menú Administrar -> Configuración del sitio -> Información del sitio

Los permisos de usuario se configurarán más adelante, cuando haya cosas que configurar.

Activando los primeros módulos:

El paquete de Drupal trae con su instalación base una serie de módulos requeridos, sin ellos Drupal no puede

funcionar.

Pero además contiene una serie de módulos opcionales. Entre los que necesité para este sitio se encuentran:

Upload: Permite adjuntar archivos al contenido creado.

Search: Permite buscar contenido en el sitio.

Path: Permite definir un alias para las páginas.

Contact: Crea formularios de contacto para enviar emails desde el sitio.

Locale: Para traducir la interfaz de Drupal al idioma español.

Statistics: Brinda estadísticas como cantidad de lecturas por nodo.

Profile: Agrega nuevos campos a un perfil de usuario. Útil para definir el país de origen u otros datos personales.

Forum: Para generar un foro en el sitio.

Taxonomy: Para categorizar los artículos del sitio.

Por supuesto que se utilizaron muchos módulos más pero la ventaja de estos es que no hay que descargarlos desde

www.drupal.org solo se activan desde Administrar -> Construcción del sitio -> Módulos

La mayoría de estos módulos una vez instalados crean un nuevo menú dentro de Administrar -> Configuración del

sitio

Y pueden configurarse desde allí.

URL limpias:

Las url limpias son un mecanismo que provee drupal para que enlaces con la forma

www.cuencodigital.com/?q=node/add

se lean como

www.cuencodigital.com/node/add

En Administrar -> Configuración del sitio -> URL limpias se puede activar esta opción si el servidor lo permite.

Recordemos que el servidor de utilizado para el desarrollo de este sitio funciona con Debian 4 y en drupal.org dan la

explicación de cómo hacer para que las URL limpias puedan utilizarse para este sistema operativo.

(http://drupal.org/node/43783)

El siguiente artículo profundizará aún más en la instalación y configuración de otros módulos esenciales en este sitio.

Un sitio en Drupal paso a paso. Parte 315 Comentarios

Fecha: 

09 de Febrero de 2009

En el artículo anterior mostré los pasos iniciales para instalar y configurar Drupal de forma básica.

En este artículo voy a basarme en la instalación y configuración de los módulos que le darán la mayor parte de la

funcionalidad a Cuenco Digital.

Los esenciales:

CCK y Views son dos módulos muy populares entre los que trabajan con Drupal frecuentemente.

CCK es el Kit Constructor de Contenidos, básicamente su función es crear tipos de contenido. Un tipo de contenido

puede interpretarse como un conjunto de información que se distingue por la forma en que organiza la misma.

Por ejemplo, en este sitio, un artículo es un tipo de contenido, las novedades son otro tipo de contenido y una página

estática otro. No son lo mismo pues un artículo contiene una fecha, un autor, un resumen, un listado de artículos

relacionados, y una novedad no contiene ninguno de los dos campos nombrados, etc. De hecho el tipo de contenido

está intimamente relacionado al significado que tenga para el diseñador la información. Claramente el concepto de

"novedad", "artículo" y "video" representan grupos de información distintos, y por lo tanto se representan como tipos

de contenido distintos.

CCK permite además definir que campos contendrá un tipo de contenido. Un campo es como un casillero a rellenar

con información. Puede ser un número, o una dirección de correo, o un enlace a una pagina web, pasando por videos,

códigos postales y muchísimas otras cosas más.

Views, es un módulo para hacer listados. Listados de información en este sitio se utilizan views para hace el listado

de artículos, de videos, de novedades y cualquier otro listado de contenidos que se necesite.

Descargando un módulo:

Los módulos se descargan del sitio oficial de Drupal. www.drupal.org/project/Modules

Una vez descargado un modulo se puede descomprimir en tres posibles lugares

drupal/sites/all/modules

drupal/sites/www.example.com/modules

drupal/modules

En cualquiera de los tres directorios el modulo será reconocido por el sitio en Drupal. Sin embargo la tercera opción

no es recomendable, hay quienes opinan lo mismo, pues dificulta los procesos de actualización futuros.

Entre las dos primeras formas se suele utilizar la primera si el módulo va a ser compartido entre varias instalaciones

de Drupal en un mismo servidor, o la segunda si el módulo será utilizado sólo por el sitio actual.

Todos los módulos se instalan de la misma forma. Se descargan desde Drupal, se descomprimen en el directorio

modules indicado y se activan desde Administrar -> Construcción del sitio -> Módulos

Configurando CCK:

CCK, como se dijo antes, permite crear tipos de contenido. Para empezar se crearán tres tipos de contenidos nuevos.

artículos, novedades y videos.

Si observan bien en la lista anterior, hay dos tipos de contenidos más. Página, es creado por drupal en su instalación

original, y Tema del Foro es creado automáticamente por el módulo forum.

Cada tipo de contenido tiene una serie de campos que lo identifican. Poniendo como ejemplo al tipo de contenidos

artículo, los campos son Resumen, Fecha de publicación, además de los comunes para todos los tipos de contenido, el

título y el cuerpo.

Pequeña aclaración:

Para que un tipo de contenido se diferencie de otro no es necesario que posean distintos campos. De hecho podrian

existir los tipos de contenido, pagina e historia y ambos utilizar un título y un cuerpo.

Lo que diferencia a un tipo de contenido de otro es lo que el desarrollador quiera expresar con ellos.

De todas formas, creo que es más fácil de entender para los recién iniciados en cck este tipo de diferencias.

Cada campo generalmente es controlado por un módulo específico. Por poner un ejemplo, el módulo date provee toda

una serie de funcionalidades para trabajar con campos del tipo fecha. Las validaciones, los calendarios desplegables,

las formas de mostrar la fecha, etc, son controladas por este modulo date.

Los módulos que interactuan con CCK se ubican generalmente en el paquete llamado CCK, la siguiente figura ilustra

los módulos instalados en este sitio.

Cada tipo de contenido permite configurar los campos que mostrará. El tipo de contenido Artículo posee, un título, un

cuerpo, un campo de tipo texto y un campo de tipo fecha. Drupal 6 introduce un sistema de ordenamiento dinámico

de las filas de las tablas, esto significa que para ordenar el formulario de creación de un Artículo solo hace falta

arrastrar y soltar las filas de la tabla siguiente en el orden deseado.

La forma de agregar y configurar campos para cada tipo de contenido es bastante intuitiva por lo que no voy a

detenerme en explicar paso a paso como configurar cada campo de cada tipo de contenido.

Configurar Views

El sitio debe proveer una forma simple de acceder a todos los artículos disponibles. Idealmente debería mostrar el

nombre del artículo y su resumen. Para lograr este objetivo utilizaré Views.

Views es un módulo que permite generar listados de información de una forma muy flexible. Puede compararse como

una herramienta para hacer consultas SQL a la base de datos a través de una interfaz gráfica.

Lo primero que haremos es crear una vista nueva. En Administrar -> Construcción del sitio -> Views, se observa la

pestaña 'Add view'

Para aquellas personas que recién comienzan con Drupal, la interfaz de views puede parecer intimidante. (Lo admito,

para mi también lo fue cuando la vi por primera vez). No explicaré aquí que significa cada sección, eso será parte de

otro artículo. Lo que si haré en cambio es describir como se configuró la vista utilizada en los artículos.

Antes de continuar la explicación quisiera hacer un pequeño comentario sobre las versiones de Views disponibles

para Drupal. Hace unos meses, cuando escribí este mismo artículo para Drupal 5, explicar la configuración de una

vista, me llevó cerca de tres páginas tamaño A4. Múltiples capturas de pantalla explicando las diferentes

configuraciones y aún así el proceso era bastante difícil de entender. Con la nueva versión de Views para Drupal 6,

Earl Miles y los desarrolladores de views han hecho realmente un trabajo estupendo. Toda la interfaz se reduce a una

sola página que se recarga con AJAX y facilita la creación de views en un modo realmente notable.

Al crear una nueva vista se nos solicitarán una serie de datos. En la primera sección, el nombre de identificación y la

descripción. También es necesario indicar el tipo principal de objetos que manipulará la vista. En este caso se elige

nodos pues son vistas sobre contenido.

En Views 1.x (para drupal 5) habría sido necesario crear una vista para los artículos y otra para los videos. Views 2.x

permite crear una vista general y hacer vistas personalizadas sobre esa general. Compartiendo aspectos y

personalizando otros. De esta manera el mantenimiento de los listados se simplifica enormemente y bien usado,

facilita las tareas de theming que veremos luego.

La configuración general del listado

La siguiente imagen ilustra como está configurada la sección default de la vista. Esta sección es como la vista

"madre" y los usuarios no pueden verla directamente. Sin embargo funciona como matriz para las demás vistas que se

generen heredando su configuración.

Basic settings: Aquí se definen los aspectos generales de la vista. Cuantas filas mostrará, el título general de la

página, la forma en que se mostrarán los campos (Tabla, Grilla, Nodos completos, etc), si se utilizará AJAX para

cambiar entre página y página. El encabezado, el footer y el texto a mostrar si no hay contenido disponible para la

vista.

Relationships: Las relaciones no son utilizadas en este sitio. Y serán motivo de otro artículo (Ya está disponible un

video sobre este tema). Básicamente permiten conectar distintos tipos de objetos por un campo en común. Por

ejemplo, se podría relacionar el nodo, con un usuario, utilizando una referencia a un usuario (CCK User reference). Y

automáticamente, los datos de ese usuario estarían disponibles para su uso en esta vista, como un columna más para

la tabla.

Arguments: Los argumentos tampoco son utilizados en esta vista. Los argumentos permiten pasarle parámetros al

view, generalmente a través de la URL.

Campos: Todo listado contiene información. Los campos representan parte de esa información. Para este listado se

desea mostrar: El título, el resumen, la fecha y la cantidad de comentarios de cada nodo.

Sort criteria: El criterio para ordenar la lista. En este caso, la fecha ingresada en el campo field_fecha ordenado de

mayor a menor (o sea los más nuevos, primero).

Filtros: Los filtros definen condiciones que los objetos (en este caso, los nodos) deben cumplir para figurar en el

listado. Para esta vista, el nodo debe estar publicado y debe poseer un tipo en especial (aunque no se define cual en la

vista por defecto).

Por supuesto surge una pregunta. ¿Como sabe Views que tiene que mostrar solo los videos en la página de videos y

los artículos en la página de artículos? Bueno, la respuesta es, sobreescribiendo.

Sobreescribiendo valores por defecto:

En la esquina superior de la imagen anterior se pueden ver 3 rectángulos.

Cada uno de los dos rectángulos inferiores representa una instancia de la vista. Prefiero llamarle instancia porque son

palpables para el usuario final. Recordemos que la vista Default no puede ser accedida. Las instancias pueden ser de

diferentes tipos. En este caso son páginas html. Pero tambien pueden ser bloques, o feeds Rss, cada una con

propiedades diferentes.

Una vez que se agregan las dos visualizaciones (Displays) views solicita que indiquemos los paths para esos displays.

Aquí ya se está indicando el primer factor que las diferencia. Un display tendra como path articulos, la otra video.

Luego, por cada display se puede elegir modificar o no algún parámetro de la views original. El caso más claro es el

del valor "Tipo de Nodo" en la sección filtros. El display para artículos filtrará por nodos con el tipo artículos y el de

videos por tipo de nodo video.

Los filtros se diferencian de los asignados por defecto presionando el boton "Override" (sobreescribir) que aparece en

la parte superior derecha de cada configuración de algun parámetro.

Con este concepto, es posible crear varios listados que mantengan aspectos en común y personalizando otros

dependiendo de cada caso.

Resumiendo un poco el tema de las vistas:

Hasta Drupal 5, no había forma de compartir aspectos entre listados. Existía el clonado de vistas, pero esto implicaba

actualizar cada vista por separado si se modificaba algun aspecto en común.

Con Drupal 6 y la version 2.x de Views, es posible generar una vista por defecto. Luego cada display, o sea la forma

en que el usuario percibirá el listado (como un bloque, una página u otra forma) permite definir aspectos únicos y

otros compartidos.

Los filtros, los campos, la forma de ordenamiento, el encabezado o hasta el título del listado pueden compartirse o

Sobreescribirse haciendo que el manetenimiento de las vistas, se simplifique mucho si se organizan correctamente.

Unos últimos detalles de configuración de los listados incluyeron la creación de dos menús en la sección, Primary

Links que aparecen listados automáticamente en la parte superior del sitio.

Con esto concluye este artículo. Es fácil de ver la potencia y las múltiples ramificaciones que tienen estos dos

módulos, no en vano son los dos más utilizados y descargados por los desarrolladores de sitios con Drupal.

Un sitio en Drupal paso a paso. Parte 45 Comentarios

Fecha: 

23 de Febrero de 2009

Un sitio en Drupal paso a paso (Parte 4 de 6)

Una de los temas más interesantes a la hora de aprender Drupal es como modificar lo que el usuario final ve en el

sitio terminado.

El Theme es un conjunto de archivos que definen como será el aspecto final del sitio. Para muchos diseñadores webs

acostumbrados a maquetar con HTML y CSS no será una dificultad aprender a hacer un Theme para Drupal.

Sin embargo existen una serie de detalles y formas de trabajar que deben conocerse para entender como empezar a

desarrollar un Theme.

Desde cero o …

Drupal.org provee una serie de themes listos para utilizarse. Al igual que un módulo estos pueden descargarse e

instalarse y automáticamente se podrá observar el cambio visual en todo el sitio.

Para desarrollos profesionales no siempre se puede optar por un diseño prefabricado. Generalmente existe un layout

predefinido que hay que seguir, lo que el cliente quiere para su sitio.

Entonces surgen dos posibilidades. La primera es adaptar un theme existente modificando el CSS y algunos archivos

más para obtener el nuevo diseño. La segunda opción es construir un theme desde cero.

Por extraño que parezca, es más simple y habitual recurrir a modificaciones de themes existentes que a crear uno

nuevo desde cero. Y existe una razón muy fuerte para esto, hacer un theme desde cero puede ser una tarea realmente

difícil.

Debido a esto último un grupo de desarrolladores han diseñado una serie de Themes especialmente creados para ser

modificados fácilmente y adaptados a las necesidades de cada uno. Se destacan Zen, Clean y Artists C01 entre otros.

Aunque últimamente esta lista ha crecido mucho y se agregan a la lista Stark, Basic, Foundation, y todo tema que a

simple vista parezca demasiado "blanco".

Un subtheme de Zen

Para darle el aspecto visual al sitio se creó un subtheme de Zen. Para quienes no lo conozcan Zen es un Theme de

Drupal que tiene como características principales su buena documentación, y su gran cantidad de selectores de CSS

listos para usar. Además permite crear sub temas en base a uno más general. De esta forma se pueden reutilizar

diseños existentes o definir hojas de estilos comunes para todos.

Para crear un subtheme de Zen se debe descargar el paquete desde la página principal del proyecto

http://drupal.org/project/zen y descomprimir el archivo tar.gz en la carpeta /sites/all/themes del directorio donde esta

instalado Drupal.

Una vez hecho esto, se debe crear una nueva carpeta con el nombre del tema, en este caso el nombre elegido fue

cuenco.

Usando comandos de Linux:

#crear el directorio themes en sites/all si no existe

cd /var/www/apache2-default/drupal6/sites/all

mkdir themes

#Descargamos zen en este directorio (Puede que no sea la versión 1.1

la actual)

cd themes

wget http://ftp.drupal.org/files/projects/zen-6.x-1.0.tar.gz

#descomprimimos zen

tar xzvf zen-6.x-1.0.tar.gz

#creamos un nuevo directorio en su interior con el nombre del sub tema

cd zen

mkdir cuenco

#copiamos los archivos de la carpeta STARTERKIT al nuevo directorio

creado

cp -R STARTERKIT/* cuenco

STARTERKIT es una base para que el diseñador pueda crear su propio subtema. Aún faltan dos pasos para que zen

reconozca el nuevo theme. Por un lado la documentación oficial indica que hay que reemplazar todas las

STARTERKIT por el nombre de nuestro theme, en este caso cuenco.

Por lo tanto, donde diga por ejemplo:

<?php

function STARTERKIT_preprocess_page(&$vars) {

  $vars['sample_variable'] = t('Lorem ipsum.');

}

?>

Deberá quedar:

<?php

function cuenco_preprocess_page(&$vars) {

  $vars['sample_variable'] = t('Lorem ipsum.');

}

?>

Los reemplazos deben hacerse en los archivos .php que se encuentren en el directorio del nuevo Theme creado.

El último paso consiste en la elección del layout del sitio. Zen provee dos opciones de trabajo. Un diseño Liquido, y

uno Estático. Si se opta por un layout líquido, se deberá copiar el archivo layout-liquid.css al directorio cuenco. En

caso de elegir un diseño estático se copiará layout-fixed.css.

En cualquiera de los dos casos se deberá renombrar el archivo con el nombre layout.css

#copiamos el archivo

cd /var/www/apache2-default/drupal6/sites/all/themes/zen

cp layout-fixed.css cuenco

#y lo renombramos

cd cuenco

mv layout-fixed.css layout.css

Un poco de CSS:

Explicar paso a paso como se creó el aspecto visual de cada elemento del sitio seria un desperdicio de tiempo.

De hecho esto es algo muy particular de cada diseñador. No me considero un experto en css y por lo tanto muchas

cosas probablemente se puedan resolver de otro forma. Lo que sigue es el archivo cuenco.css, aquí alojé todos los

estilos propios del tema. En verdad no es una forma muy profesional de trabajar. Hay quienes separan los archivos

css según el tema o las secciones que modifiquen. Pero en este caso la utilidad se encuentra en que puedo mostrar en

un solo lugar, las diferencias que se aplican con respecto al diseño original de Zen.

El archivo de css personalizado puede verse aquí.

Como se dijo antes, Zen trae dos layouts definidos. Uno líquido, en donde se las diferentes secciones se estiran o

comprimen a medida que la ventana del navegador cambia de tamaño. Y otro estático en donde todas las secciones

mantienen sus dimensiones.

Para que el Theme reconozca el archivo CSS es necesario agregarlo en el archivo cuenco.info. Esto es nuevo para

todos los themes de Drupal 6.

stylesheets[all][]   = layout.css

;stylesheets[all][]   = html-elements.css

; stylesheets[all][] = tabs.css

; stylesheets[all][] = messages.css

; stylesheets[all][] = block-editing.css

; stylesheets[all][] = wireframes.css

stylesheets[all][]   = cuenco.css

stylesheets[all][]   = garland.css

stylesheets[print][] = print.css

Todas las hojas de estilo comentadas con un punto y coma seran cargadas desde el theme Zen, he aquí una de las

ventajas de usar Zen. Algunos habrán notado la presencia del archivo garland.css. No es un error, personalmente me

gusta como garland trata las tablas y los fieldsets colapsables. Por eso copie esa parte del css de garland y la incluí en

mi propio tema.

Una de las cosas que pude lograr en este tema, que no había podido lograr antes, es no modificar el template de zen

para colocar los menús primarios en

el header. Existe un método a través de Css que permite mover el navbar dentro del div header. Esto permite hacer

temas con los menus organizados como en drupal.org y en muchisimos otros sitios que usan estos diseños.

Las plantillas tpl en Drupal

Sin embargo conocer las plantillas y su funcionamiento puede hacer que el tema a crear sea verdadermente flexible.

Sin entrar en demasiados detalles, Drupal utiliza los archivos con extensión tpl.php para generar el HTML final del

sitio. Podría entenderse como una matriz para hacer HTML en base a ciertos datos que Drupal le envia a la plantilla.

La plantilla page.tpl.php es la encargada de realizar el render general del sitio. Es como el esqueleto general. Dentro

de este se ubicaran los menús, los bloques, los contenidos, etc.

Para modificar la plantilla de zen se pueden hacer dos cosas. Una es modificarla directamente desde el directorio zen/

y la otra es copiar esa plantilla dentro del subtema. Esta ultima opción hace que el subtema utilice la plantilla

modificada en vez de la que provee Zen por defecto y así se evita alterar la plantilla page.tpl.php para todos los

subtemas existentes.

Mi recomendación personal. Modificar lo menos posible las plantillas. Esto permite que las actualizaciones del theme

de drupal sea lo menos dolorosa posible en un futuro.

La principal razón para modificar una plantilla es para agregarle nuevas regiones. Existen otros métodos que se verán

más adelante en este artículo para modificar algunos componentes dentro de la plantilla.

Otras regiones.

Una de las novedades que incluyen los temas en Drupal 6 es que se pueden indicar las regiones de los temas

directamente desde el archivo .info. De esta forma, lo que en drupal 5 se habría hecho asi:

Dentro del archivo template.php escribir:

<?php

function cuenco_regions() {

  return array(

    'left' => t('left sidebar'),

    'right' => t('right sidebar'),

    'navbar' => t('navigation bar'),

    'content_top' => t('content top'),

    'content_bottom' => t('content bottom'),

    'header' => t('header'),

    'pre_footer' => t('pre footer'), //nueva región

    'footer' => t('footer'),

    'closure_region' => t('closure'),

  );

}

?>

En Drupal 6 se hace de esta forma:

Dentro del archivo cuenco.info

regions[left]           = left sidebar

regions[right]          = right sidebar

regions[navbar]         = navigation bar

regions[content_top]    = content top

regions[content_bottom] = content bottom

regions[header]         = header

regions[pre_footer]     = pre_footer

regions[footer]         = footer

regions[closure_region] = closure

Sin embargo, tanto en Drupal 5, como en Drupal 6 es necesario agregar una modificación al template page.tpl.php

    <div id = "pre_footer">

      <div id ="pre_footer-inner">

        <?php print $pre_footer;?>

      </div>

    </div>

Este código le indica al tema donde imprimir el contenido de los bloques alojados en la región. Dicho de otra forma,

$pre_footer será reemplazado por todos aquellos bloques que esten activos en la región "Pre footer".

Widgets para los comentarios.

Cuando un artículo posee comentarios se puede observar en el extremo superior derecho un dibujo con el número de

comentarios del nodo. Para realizar esto es necesario modificar otra plantilla. La plantilla de los nodos.

Así como page.tpl.php el la plantilla genérica para todo el esqueleto del sitio, existe node.tpl.php que es la plantilla

genérica para imprimir el contenido de un nodo.

Si se modifica esta plantilla se cambiará el aspecto de cómo se imprime cada nodo del sitio. En caso de solo querer

cambiar el estilo de un tipo de contenido se puede usar por ejemplo node-articulo.tpl.php que cambiaría el estilo solo

para el tipo de contenido artículo.

El cambio en la plantilla fue simple. Solo se agregó el siguiente código sobre el div con clase “content”

<?php

print $comment_widget;

?>

Ahora, $comment_widget no existe. Esto es una construcción propia de este sitio. Para definir el valor de la variable

$comment_widget se debe modificar el archivo template.php de la siguiente forma.

<?php

function cuenco_preprocess_node(&$vars) {

  if($vars['comment_count']) {

    $vars['comment_widget'] = '<a href = "#comments"><div class =

"comment_widget">'. format_plural($vars['comment_count'], '1 Comment',

'@count Comments') .'</div></a>';

  }

}

?>

Esta función es la encargada de crear las variables “personalizadas” para la plantilla del nodo. Por suerte zen ya da la

estructura de la función para que solo tengamos que agregar el código en su interior.

Más variables:

El widget para los comentarios es solo un ejemplo de la potencia de las variables. Para este theme definí algunas

variables que sobreescriben el contenido de otras ya existentes.

Por ejemplo, en este tema visual, tanto el logo, como el nombre del sitio, son imágenes. En el template page.tpl.php

este codigo está definido como:

<?php if ($logo): ?>

    <div id="logo"><a href="<?php print $front_page; ?>" title="<?php

print t('Home'); ?>" rel="home">

      <img src="<?php print $logo; ?>" alt="<?php print t('Home'); ?>"

id="logo-image" /></a>

    </div>

  <?php endif; ?>

  <?php if ($site_name): ?>

    <?php if ($title): ?>

      <div id="site-name"><strong>

        <a href="<?php print $front_page; ?>" title="<?php print

t('Home'); ?>" rel="home">

        <?php print $site_name; ?>

        </a>

      </strong></div>

    <?php else: ?>

      <h1 id="site-name">

        <a href="<?php print $front_page; ?>" title="<?php print

t('Home'); ?>" rel="home">

        <?php print $site_name; ?>

        </a>

      </h1>

    <?php endif; ?>

  <?php endif; ?>

Ahora bien, ¿Cómo hacer que $site_name sea una imagen? Nuevamente las variables permiten modificar este valor.

Con esta simple función, la variable site_name (cuyo valor es el nombre del sitio) es reemplazada por una imágen:

<?php

function cuenco_preprocess(&$vars, $hook) {

  $site_name = $vars['site_name'];

  $vars['site_name'] = theme_image(path_to_theme() .

'/images/logo_text.png', $site_name, t('Home'));

}

?>

Comentarios finales:

A simple vista puede parecer que hacer un theme en drupal es algo complicado. Bien, no es muy fácil al principio.

Pero con un poco de práctica se pueden lograr diseños muy vistosos, no como este :), que respondan a detalles y

configuraciones del sitio. Y cuyas modificaciones futuras se basen solo en cambios en el CSS.

Muchas personas, entre las que me incluyo, recomiendan no utilizar un único archivo de Css para todo el theme. Esto

simplifica el mantenimiento futuro. Sin embargo en este caso opte por centralizar todo para simplificar las

explicaciones.

Lo que queda es puro css. Explicar cada detalle no tiene sentido, y cualquier diseñador web conociendo el

funcionamiento de las plantillas en drupal debe estar en condiciones de crear su propio theme.

Para aquellos interesados en profundizar más sobre la creación de themes en Drupal existen algunos libros (en inglés)

como Drupal 5 Themes o su versión para Drupal 6.

La documentación de Zen, o los videos de la documentación del theme Genesis también son de gran ayuda. Aunque

ambos están también en inglés.

Por último, les recomiendo este artículo en español: http://investic.net/blog/miren/desarrollo_theme_definicion en el

se explica muy bien un caso real. Especialmente en lo que refiere al diseño inicial y la metodología a utilizar.

Un sitio en Drupal paso a paso. Parte 610 Comentarios

Fecha: 

05 de Abril de 2009

Un sitio en Drupal paso a paso. (Parte 6 de 6)

En los cinco artículos anteriores se describió el proceso de instalación de Drupal. Instalación y configuración de los

módulos esenciales. Configuración de CCK y Views. Creación del theme y por último, la configuración de los

módulos que complementan la funcionalidad.

Sin embargo, quedan una serie de detalles quedan en el tintero para que el sitio este listo para su puesta en

producción.

Traducciones

En la parte dos de esta serie de artículos se indicó como instalar el sitio en idioma en español.

La traducción de Drupal en el idioma nativo de cada país depende, como la mayoría en el software libre, de la

comunidad que lo utiliza. De esta forma, los encargados de traducir Drupal al español son tanto usted como yo. Y

debido a esto, hay algunas partes de Drupal que aún no están traducidas.

El principal efecto de esto es que se observa el sitio casi completamente en español, pero algunas cadenas aún están

en inglés.

Drupal trae entre sus opciones una interfaz para traducir las cadenas no traducidas. En mi opinión esta interfaz podría

ser mucho mejor. La buena noticia es que en Drupal 7 esto cambia, la mala, es que aún estoy con Drupal 6.

Por esa razón, muy acertadamente un desarrollador programó un módulo para mejorar el proceso de traducción de las

cadenas no traducidas.

Localization Client agrega una barra en la parte inferior del sitio en donde se ven las cadenas no traducidas y las

traducidas en dos columnas. Bastante intuitivo, y no es necesario ir recargando la página para traducir muchas

cadenas.

Aún tiene algunos errores, pero utilizándola conjuntamente con la interfaz de traducción de Drupal se pueden lograr

excelentes resultados.

Parches, esto no anda...

Para todos aquellos desarrolladores que vienen utilizando Drupal desde hace tiempo, sabrán que no todo siempre

funciona como debería. Por poner un ejemplo real y bastante crítico por cierto, indico que me sucedió en este sitio.

Drupal 6 introduce como nueva funcionalidad la posibilidad de traducir las cadenas de los archivos de javascript.

Esto significa que si usted esta creando un calendario tipo popup, y quiere que los meses estén en el idioma

apropiado, con Drupal 6 ahora es posible (Drupal 5 y anteriores no contemplaban esta opción).

El problema es que esta opción no esta funcionando bien cuando se utiliza el cache para javascript. Eso significa que

toda cadena, aunque esté traducida, se verá en inglés en el sitio.

Por suerte, existe un parche que corrige este error. Aún no se encuentra en el núcleo de Drupal 6 aún, se puede

aplicar el parche sin problemas.

El proceso de aplicación de parches es igual para cualquier parche.

# Descargar el parche en el directorio indicado

cd Drupal6/includes

wget http://drupal.org/files/issues/locale-338630-30.D6.patch

# aplicar parche

patch locale.inc < locale-338630-30.D6.patch

De forma similar, un parche para el módulo Data soluciona el bug indicado en este issue. Actualización: El parche

esta incluido en las nuevas versiones de Date, ya no es necesario aplicarlo.

Bloque personalizado

Tarde o temprano cualquier desarrollador que utilice drupal va a necesitar programar algo que no exista.

En mi caso, necesitaba un bloque para mostrar el siguiente artículo a publicar.

Sin entrar en demasiados detalles sobre la programación, Drupal 6 requiere que se active el módulo PHP Filter

incluido en el núcleo para poder escribir snippets en php.

Una vez activado este módulo creé un bloque con el siguiente código.

<?php

  $sql = "SELECT n.title titulo, c.field_fecha_value fecha,

c.field_resumen_value resumen

             FROM content_field_fecha c

             INNER JOIN  {node} n ON n.vid = c.vid

             WHERE n.status = 0 AND n.type IN ('articulo', 'video')

             LIMIT 1";

 

  $res = db_query($sql);

  $articulo = NULL;

   while($ob = db_fetch_object($res)) {

     $articulo['titulo'] = check_plain($ob->titulo);

     $articulo['fecha'] = format_interval(strtotime($ob->fecha) -

time());

     $articulo['resumen'] = check_markup($ob->resumen);

   }

   print '<h3 class = "title">Próximamente...</h3>';

   if (is_array($articulo)) {

     print '<div class = "date">Dentro de <strong>'.

$articulo['fecha'] .' </strong>se publicará:</div>';

     print '<p><a title = "leer más" href = "/proximamente">'.

$articulo['titulo'] .'</a></p>';

   }

   else {

     print t('No hay artículos por publicarse próximamente');

   }

?>

La idea es que busque en la base de datos todos aquellos videos y artículos que no hayan sido publicados aún, y

muestre su titulo en un bloque.

Bueno eso de ahí arriba es en realidad un ejemplo. Para este sitio utilicé views para generar ese bloque. Pero para la

versión con Drupal 5 de este mismo sitio realmente habia utilizado un código como el anterior y me pareció

apropiado dejarlo como ejemplo.

Automatizando

A todos les debe pasar en algún momento de sus vidas, el tiempo no les alcanza para hacer todo lo que quisieran. De

alguna manera esto afecta al sitio en el sentido de que tal vez durante un mes no publico nada y otro mes puedo

publicar varios artículos y videos juntos. Para evitar esos períodos de inactividad prolongada en el sitio decidí

implementar un sistema de publicación automatizada de artículos y videos.

Si bien el módulo scheduler podría ser el apropiado para eso, no me convence el hecho de que tenga que definir una

fecha y que no sea visible en el artículo como fecha de publicación. Por lo tanto opte por utilizar el módulo rules.

Rules es, a mi criterio, uno de los módulos más importantes que tiene Drupal. Permite ejecutar acciones en base a

eventos que se presentan en el sitio. Añadiendo también la opción de exigir que ciertas condiciones se cumplan para

ejecutar la acción. Las posibilidades que brinda este módulo son realmente muchísimas.

Para que se publiquen los artículos utilizo el mismo query que usé en el bloque, de esta forma, cuando corre cron,

controlo que la fecha de publicación del primer artículo o video no publicado sea menor a la del día de hoy. Si eso se

cumple, publico el contenido.

Todo listo, a publicar el sitio entonces

Como comenté en el primer artículo, el desarrollo de este sitio se hizo con un servidor local. Para que todos puedan

leer los artículos, es necesario mover el sitio a un servidor en producción.

Este proceso consiste en, copiar los archivos de la instalación de Drupal (todo lo que esté incluido en el directorio

Drupal6) y copiar la base de datos.

Dependiendo de las dimensiones del sitio tal vez sea conveniente comprimir todo el sitio, y descomprimirlo en el

servidor de producción:

El siguiente código requiere conexión a ssh con el servidor

#Comprimir el directorio padre de todo el sitio

tar czf cuenco.tar.gz drupal6

mysqldump -u usuario -p nombre_base_de_datos > respaldo.sql

tar czf respando.tar.gz respaldo.sql

Mover estos archivos al servidor con FTP o sFTP

y luego, hacer el proceso inverso, ahora en el servidor de producción

#Comprimir el directorio padre de todo el sitio

tar xzf cuenco.tar.gz drupal6

tar xzf respando.tar.gz respaldo.sql

#Restaurar la base de datos

mysql -u usuario -p base_de_datos < respaldo.sql

Últimos ajustes

En el directorio raiz de Drupal hay un archivo llamado .htaccess, para aquellos que utilicen apache como servidor

probablemente deban modificar algo en su interior.

www.CuencoDigital.com y CuencoDigital.com son en realidad el mismo sitio. Algunas personas encuentran más

cómo acceder al sitio con www. otras sin la www. En el archivo .htaccess se puede crear una regla para que

contemple a ambos sitios como uno solo:

  RewriteCond %{HTTP_HOST} ^cuencodigital\.com$ [NC]

  RewriteRule ^(.*)$ http://www.cuencodigital.com/$1 [L,R=301]

Agregando esas dos lineas, cada vez que alguien escriba www.cuencodigital.com será automáticamente

redireccionado a cuencodigital.com.

¿Ya esta?

Ojala fuera tan simple. La esta sección deberia llamarse testing, testing, testing!. Para asegurarme de que todo esté en

orden tuve que revisar y configurar las opciones de comentarios, configurar la forma de registrarse en el sitio, revisar

muchas cadenas que no aparecen traducidas a simple vista. (Ejemplo, pruebe de indicar un resultado erroneo para la

pregunta matemática.)

RSS, la opción por defecto que trae drupal no sirve para este sitio. Configurar los bloques en la barra lateral. Testing

de nuevo. Desactivar la reconstrucción del cache de páginas. Configurar cron. Configurar google analytics. Probar

comentarios al azar. Hacer el theme sobre los comentarios. Revisar las opciones de rutas automáticas para los tipos de

contenidos nuevos.

Testing!. Probar cron, buscar contenidos. Crear cuentas de usuario al azar con menos privilegios. Probar posteo de

comentarios con esos usuarios. En fin. La parte fea de todo esto.

Es necesario y determina la calidad final de cualquier pieza de software que el tiempo dedicado al testing sea más de

unos minutos. Las pruebas son algo serio, en serio!

Conclusiones

Largo ¿no?. Creo que no voy a escribir tanto la próxima vez pero espero haber dado una idea general de lo que

significa un desarrollo en Drupal.

Soy conciente de que estoy obviando muchos detalles. Escribirlos aquí podría haber reflejado realmente como hacer

un sitio en Drupal paso a paso. Pero, como indiqué en el primer artículo de la serie. Es imposible describir todos los

detalles. Ademas leer tanto nivel de detalle es aburrido (y ni que decir de escribirlos!). Es más fructífero que se anime

usted mismo a crear y solucionar sus propios problemas. Despues me cuenta como le fue.

Como comentarios finales me gustaría hablar un poco de las herramientas que utilicé para el desarrollo.

Editores gráficos: Inkscape, gimp, gthumb

Editor de html: gedit

Editor de php: gPhpEdit

Servidor: Apache 2

Navegadores: Firefox 3, Opera 9

Motor de sql: Mysql 5

Sistemas operativos: Ubuntu Linux y Debian Linux

Con esto quiero indicar que es posible un desarrollo íntegro utilizando herramientas de software libre. Tal vez sea

hora de que se empiecen a tomar un poco más en serio en las instituciones educativas.

Muchas gracias por haber leído este último artículo sobre como hacer un sitio en Drupal paso a paso. Espero sus

comentarios.