Nota: Quiero hacer una serie de posts dedicados a las vistas con argumentos en Drupal, pero para hacer esto, me parece mejor explicar antes el modulo de Views, y para darle contexto, el de CCK.

¿qué es CCK?

El Content Construction Kit es uno de los módulos contribuidos, es decir, que no forman parte del núcleo, básicos de Drupal para implementar sitios webs complejos de forma fácil e intuitiva. A través de este módulo, podemos crear tipos de contenido personalizados que nos permitirán tener la información de nuestras páginas más organizada y acesible.

me parece estupendo, pero .... ¿que es un tipo de contenido?

Un tipo de contenido (content type) es parte de esta terminología (o casi podríamos llamarlo idioma) que utiliza Drupal, se refiere a un elemento (de tipo nodo) con características y atributos propios. Es decir, que, gracias a CCK, podemos construir nuestros propias entidades de información a través de una interfaz de usuario.

las cosas se entienden mejor con ejemplos...

Se pueden buscar centenares de ejemplos, en el caso de una aplicación de organización de restaurantes, podríamos crear un tipo de contenido restaurante, con información personalizada, como la localizacíón, una valoración, la carta / menú, etc etc.
Buenos ejemplos de otros módulos que crean tipos de contenido propios son el Simplenews, que crea un tipo de contenido para los boletines de noticias, el Image que lo crea para gestionar las imagenes, o el Poll (parte del core), que crea nodos de tipo encuesta con un campo personalizado para las votaciones.

¿encontraré todos los tipos de campos que necesito utilizar?

En uno de los blogs de Drupal Planet, he leido sobre un curioso proyecto llamado Drupy, una versión de Drupal, pero desarrollada integramente desde la perspectiva de programación basada en objetos, con Python, en lugar de PHP.

Lejos de ser una simple idea, o un proyecto abandonado, parece que la gente de Drupy está muy activa y están cerca de sacar una versión beta del sistema. En su web puedes consultar el estado actual del proyecto, y a través de su página de sourceforge se pueden seguir las correcciones y avances de desarrollo.

Creo que es bueno para la comunidad que se hagan versiones de Drupal en otras plataformas, aunque me gustará saber cómo va encarar la gente de Drupy el problema de portar todos los módulos (o al menos los más relevantes) de PHP a Python, ¿veremos algún día módulos en Drupy siendo portados a la versión de Drupal en PHP?.
También será interesante conocer los detalles del web server que van a utilizar, porque tengo entendido que la combinación de Apache + Python está un poco verde.

¿Qué opináis del tema? ¿Os parece que aportará algo al proyecto de Drupal? ¿O al software libre en general?

Hoy me he peleado con un formulario que tenía que generar "al vuelo" y me he encontrado con dos variantes de este error:

"warning: implode() [function.implode]: Bad arguments. in /includes/form.inc on line 622."
"warning: implode() [function.implode]: Invalid arguments. in /includes/form.inc on line 622."

El problema parece residir en que, cuando generas el formulario que tiene campos de tipo select o checkbox con drupal_render , no inserta todas las propiedades que requiere el modulo form y produce uno de los errores que podéis ver más arriba.

Buscando en drupal.org, he visto una solución a este problema, insertandole estas propiedades, en este caso al select, con la función _element_info .

$form['select']+= _element_info('select');

Donde $form['select'] es el elemento select del formulario que queremos completar.
Es importante que se le añada esta sentencia antes de establecer las propiedades específicas de nuestro form, ya que sino, sobreescribirá varias de ellas y perderemos información.

De todas formas, la forma recomendable de generar un formulario en drupal, que nos evita este tipo de problemas es usar drupal_get_form() en la llamada a la función que genera el formulario, en lugar de drupal_render en la propia función.

A través de este post de Lullabot me he enterado de cómo comprobar si una página web está construida en Drupal o no a través de las cabeceras de http.

Se ve que casi todos los sitios Drupal emiten una cabecera de Expires a fecha de 19 de Noviembre de 1978, que parece ser es el cumpleaños de este señor.

Podéis comprobar vuestras webs aquí:
http://cambrico.net/check-drupal-site

Por lo visto, no se puede utilizar la propiedad #required para hacer que los campos de tipo file en los formularios de Drupal sean obligatorios. El problema es que el campo que contiene la ruta del fichero se vacía al realizar la carga, ya que ésta se realiza a nivel de sesión.
Para poder validar si los usuarios rellenan o no un campo obligatorio de tipo file, podemos optar por parchear el core, en el form.inc como sugieren en algunos posts del foro de Drupal.org o podemos validarlo utilizando la variable global $_FILES en el hook validate del propio formulario.
Os dejo un ejemplo:

function member_payment_import_csv_validate($form_id, $form_values) {
	foreach($_FILES as $file) { // Se recorre el array $_FILES	
		if (empty($file['name']['file'])) { 
			// Y si el nombre del fichero está vacío, devolvemos un error
			form_set_error('file',t('Cannot import an empty file'));
		}
	}
	return TRUE;
}

Hace un tiempo que me pregunté por qué Drupal no es el sistema de gestión de contenidos líder para webs sociales en PHP, y uno de los factores que más saltan a la vista es el desconocimiento, bien porque no se conoce la existencia del sistema (cada vez menos), o porque los programadores, diseñadores, webmasters... no conocen en profundidad las ventajas de utilizar Drupal para acelerar el proceso de desarrollo de una página web.
Recientemente Elvis McNeeely ha decidido dedicar 10 minutos, 3 días por semana durante 1 mes para ayudar y responder preguntas en los foros de Drupal.org con el objetivo de aumentar este conocimiento. Ha llegado a la conclusión, pienso que muy acertada, de que el primer lugar donde los no-iniciados van a realizar preguntas son los foros. Y parece que no será el único que va a empezar a dedicarle más tiempo a este soporte.
Llevo dos o tres semanas ya colaborando intentando echar una mano en los foros de Drupal Hispano, y creo que es una de las mejores formas de ayudar y apoyar a la propagación de Drupal, podéis encontrar otras 24 formas en 5 líneas.
Así que, aunque solamente hayas tenido un breve contacto con Drupal, pásate por los foros o por el canal #drupal-es en IRC, seguro que hay alguien que puede necesitar tu ayuda.

Puede ser que necesitemos construir una tabla formateada para alguna de nuestras páginas o módulos de Drupal, para ello, el sistema de theming nos permite mostrar tablas configurables a través del theme_table.

Para ello, necesitamos una consulta, en el ejemplo muestro todos los usuarios de la aplicación , y sus fechas de creación y último ingreso.
Para mostrar la cabecera y habilitar la ordenación en las columnas, cargamos el array $header, al que le pasamos data, que será el texto de cabecera de la columna, field, que será el nombre de la columna recuperada en la consulta (se requiere si se necesita realizar una ordenación), y opcionalmente sort, que será asc o desc, según necesitemos que esté ordenada la tabla por defecto. También le podremos pasar los atributos HTML que queramos, como colspan o clases CSS.
El array $rows es el que tiene los datos, y se puede rellenar de forma simple, pasándole los datos cargados de la base de datos, como en el ejemplo, o de forma compleja, pasándole data para los datos y los atributos CSS o HTML como segundo parámetro.
También se le puede pasar un array $attributes, para controlar los estilos CSS y HTML desde este array, en lugar de desde $header y $rows.
Para poder activar la ordenación, es necesario añadirle la función tablesort_sql a la hora de ejecutar la consulta con db_query.

Si estamos desarrollando un sitio en Drupal que utilice Tokens, que son pequeños trozos de texto a modo de comodín que son reemplazados por sus valores definitivos sobre una plantilla definida, puede que queramos añadir algún Token más aparte de los que vienen por defecto con la instalación de Drupal o alguno de sus módulos.

Existen diversos módulos que utilizan Token para funcionar, el ejemplo más claro es el de pathauto que realiza una substitución automática de los títulos de los nodos según los patrones que le indiquemos, o el sistema de comercio electrónico Ubercart.

Por ejemplo, la lista de tokens globales es esta:
Global tokens
[user-name] Nombre del usuario identificado.
[user-id] Id del usuario identificado.
[user-mail] Correo electrónico del usuario identificado.
[site-url] Url del sitio Drupal.
[site-name] Nombre del sitio Drupal.
[site-slogan] Slogan del sitio Drupal.
[site-mail] E-mail de contacto del sitio Drupal.
[site-date] Fecha actual del servidor.

Si quisieramos añadir nuevos comodines, deberemos utilizar las funciones del API del módulo Token; que son los hooks hook_token_list y hook_token_value.

• hook_token_list sirve para mostrar un listado de los tokens disponibles en el texto a modo informativo.

• hook_token_value es llamada al realizar las substituciones de los comodines y se encarga de reemplazarlos por sus valores reales.

Una de las múltiples diferencias o novedades entre Drupal 5 y Drupal 6 es la forma de calcular el último registro insertado en una tabla de base de datos. Podemos resumirlo diciendo que en Drupal 5 no se hace de forma totalmente correcta, pero en Drupal 6 está corregido.

Drupal 5

Drupal 5 utiliza una tabla auxiliar llamada sequences para almacenar los últimos valores de los campos auto numéricos, y, en lugar de omitir el campo autonumérico para que el gestor de bases de datos se encargue de la secuencia automáticamente, se utiliza la función db_next_id, que accede a sequences y calcula y modifica el siguiente valor para la tabla.

<?php
function db_next_id($name) {
$name = db_prefix_tables($name);
db_query('LOCK TABLES {sequences} WRITE');
$id = db_result(db_query("SELECT id FROM {sequences} 
WHERE name = '%s'", $name)) + 1;
db_query("REPLACE INTO {sequences} VALUES ('%s', %d)", $name, $id);
db_query('UNLOCK TABLES');
return $id;
}
?>

Por lo que, si en algún momento necesitamos resetear o alterar la secuencia de una determinada tabla en Drupal 5, deberemos tener en cuenta que la configuración de AUTO_INCREMENT para generar autonuméricos puede que no se utilice y deberemos actualizar la tabla sequences para establecer el número que necesitemos.

Si creamos un nuevo módulo para Drupal 5, o modificamos uno que requiera añadir alguna tabla con autonuméricos, utilizando como base de datos Mysql, es mejor utilizar el campo AUTO_INCREMENT y no db_next_id.

Para insertar en una tabla con un campo AUTO_INCREMENT, deberemos no informar el campo y dejar que el gestor calcule cuál es el siguiente número.

En workhabits han publicado hace un par de semanas un ejemplo a modo de taller de cómo validar que el nombre de usuario que elegimos esté disponible en el momento del registro.

He realizado un par de modificaciones y lo he empaquetado en el módulo adjunto que podéis instalar para probar o utilizar en vuestros sitios. Está preparado y probado en Drupal 5.7.

Instrucciones para instalación y demo

Descomprimir el fichero adjunto en nuestro sitio Drupal, en el directorio sites/all/modules/demo_user, después se accede a la página de activación de módulos (www.nuestrositio.com/admin/build/modules) y se activa el módulo Demo User. Aquí dejo una demo de cómo instalar el módulo y de cómo se comporta.