Blog de Carlos Rincón - drupal 6

Cómo quitar el confirmar password en Drupal 6 al registrarte?

Carlos — Tue, 13 Sep 2011 15:58:01 +0000

Si quieres simplificar al máximo el registro de usuario una de las cosas que se puede hacer es quitar el campo de confirmar password del formulario de registro.

Para hacer esto en Drupal 6 lo puedes hacer cambiando el tipo de campo del password de "password_confirm" a "password". Tan simple como eso. (yo he necesitado un rato para darme cuenta :P)

Esto lo ponemos dentro de un hook_form_alter, por ejemplo:
function mimodulo_form_alter(&$form, &$form_state, $form_id) { if($form_id == 'user_register' && !(arg(0) == 'user' && is_numeric(arg(1)))) { $form['account']['pass']['#type'] = 'password'; $form['account']['pass']['#title'] = 'Tu clave secreta'; } }

Has de sustituir el nombre de "mimodulo" por el nombre real de tu módulo dónde pongas esto.

Theming Views 2

Carlos — Mon, 05 Jan 2009 10:33:54 +0000

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 '

' . htmlentities(print_r($rows, 1)) . '

';
?>

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

Form Builder

Carlos — Thu, 04 Dec 2008 08:30:00 +0000

Los chicos de lullabot han publicado algo que hace tiempo que el mundo de Drupal estaba esperando: Un Form Builder (constructor de formularios) con una interfaz drag & drop. De momento todavía está en el CVS y no hay ni versión de desarrollo publicada pero ya es funcional aunque no está recomendada para entornos de producción. Todavía no tengo muy claro si será necesario una actualización de CCK para aprovechar todas las funcionalidades (y de los módulos que modifiquen formularios), si alguien lo prueba que lo comente (yo lo intentaré probar cuando tenga un momento)

Form Builder Project: http://drupal.org/project/form_builder
Form Builder Demo: http://quicksketch.org/demos/form-builder-example

Ya se hizo algo parecido para el Google Summer of Code pero no siguió adelante.

Vía Pedro

Añadir una traducción después de instalar Drupal 6

Carlos — Tue, 25 Nov 2008 16:53:59 +0000

Con Drupal 6 los .po de las traducciones van cada uno con su módulo y al hacer una nueva instalación Drupal se encarga de añadirlos todos.

¿Pero que pasa si queremos añadir un idioma después de instalar Drupal 6? Se puede igualmente pero tener que añadir 20 0 30 .po es muy tedioso. Para solucionar esto he encontrado en Drupal.org un post del usuario wed muy interesante. Sólo hay que hacer lo siguiente:

curl -s h ttp://ftp.drupal.org/files/projects/es-6.x-1.2.tar.gz | tar xzOf - --wildcards modules/* profiles/* themes/* > es.po

(esto en el caso de añadirlo es español, si es en otro idioma hay que sustituir la dirección del archivo y he puesto un espacio en el h ttp para que no le pusiera un enlace)

Esto lo que hace es juntar todos los ficheros con lo que ya podemos ir al panel de control de importación de lenguajes (admin/build/translate/import) y añadir el .po en un sólo paso.

Publicado CCK 2 para Drupal 6

Carlos — Thu, 06 Nov 2008 08:42:16 +0000

Ya han publicado la versión final de CCK 2. En la noticia de drupal.org podéis ver las novedades o podéis miraros el post que hice con las novedades de Views, CCK y Organic groups.

Ahora todavía falta que publiquen las versiones finales de algunos campos CCK (por ejemplo imagefield) para que ya no tengamos escusa de desarrollar con Drupal 6.

Actualización de Drupal 5 y Drupal 6

Carlos — Wed, 22 Oct 2008 21:34:40 +0000

Jooooooer. A actualizarse toca a Drupal 5.12 o Drupal 6.6. Cada vez que pasa algo así hecho de menos un sistema automático para poder hacerlo.

Views 2: publicada la versión final

Carlos — Sat, 18 Oct 2008 15:53:02 +0000

Ya ha salido la versión final de Views 2 (ver funcionalidades de Views 2).

Biiiieeeeeeeeeeeeeeen, braaaavoooooooo, viiivaaaaaaaaaaaaa.

Ahora sólo falta que salga la versión final de CCK y ya casi podremos empezar a desarrollar todo con Drupal 6.

Cómo no se entiende mucho el sitio que he usado para crear esta animación es http://www.xtranormal.com

Actualización de seguridad para Drupal 5 y Drupal 6

Carlos — Fri, 10 Oct 2008 08:03:57 +0000

Ayer mismo salió una actualización de seguridad de Drupal 6, la 6.5 y de Drupal 5, la 5.11 Recomendado totalmente actualizar ya que hay varios fallos críticos

Publicada la beta de Rules

Carlos — Thu, 28 Aug 2008 08:46:43 +0000

El sucesor de workflow-ng para Drupal 6 se llama Rules y acaban de publicar la primera beta. Es un módulo del que dependen bastantes otros módulos además de ser realmente muy potente.

Es un pequeño paso para Rules pero un gran paso para Drupal 6.

De momento Mollom no

Carlos — Thu, 01 May 2008 12:20:14 +0000

Controlar el spam es muy importante en cualquier página web en la que los usuarios puedan aportar algo cómo por ejemplo un blog. Para eso instalé y recomendé usar Mollom para controlar ese spam pero tiene algunos fallos que hace que me replantee controlar el spam de otra manera.

El principal problema es que cuando Mollom cree que un comentario puede ser spam, muestra un captcha para asegurarse que no es un spambot. Pero en lugar de poder enviar el comentario una vez rellenado el captcha se ha de previsualizar con lo que al final en lugar de tener que hacer un sólo paso para enviar un comentario se han de hacer tres lo que molesta bastante. Y no es bueno molestar a los visitantes de una página y menos a los que quieren comentar. Es similar a las protecciones en los CD's, para evitar que unos se los copien (que lo harán de todas formas) molestan a los verdaderos clientes, los que compran el CD.

Ahora para evitar que entre spam, además del bad Behaviour, pondré un simple captcha para los usuarios anónimos. Así, sólo será necesario un paso para poder enviar un comentario.

Creo que Mollom debería mejorar para no dar esos falsos positivos que, aunque se pueden superar con la técnica del captcha, si son tantos como ahora llegan a molestar. También me pasó que haciendo pruebas puse como spamer a Jordi y luego aunque fuese un usuario registrado siempre le mostraba un captcha. No le iría mal a Mollom tener una manera de poder decirle que un usuario es confiable (uno en concreto me refiero, no todos los usuarios registrados). Y lo mismo para los usuarios no registrados.