Drutácora

En Drupal , los bloques suelen tener id numéricos, lo que dificulta el mantenimiento de los estilos que se les aplica (el id numérico de un block puede cambiar si se lo elimina y vuelve a crear, por ejemplo). Puede ser más conveniente usar id descriptivos. Para eso, se puede aplicar algo como: template.php ... /** * Devuelve un id textual para el block * http://www.bluepiccadilly.com/2011/12/give-your-drupal-blocks-more-descriptive-html-id-attribute */ function block_id (&$block) { $info = module_invoke($block->module, 'block', 'list'); if ($info[$block->delta]['info']) { $block_id = 'block-' . $block->module . '-' . $info[$block->delta]['info']; $block_id = str_replace(array(' ', '_'), '-', strtolower($block_id)); return preg_replace('/[^\-a-z0-9]/', '', $block_id); } else { return 'block-' . $block->module . '-' . $block->delta; ...

Al elaborar un site, a veces me pregunto por qué usar un framework como Drupal. Para hacer algo, primero veo si puedo hacerlo con los módulos que tengo, si no, veo si hay módulos que me acerquen a lo que se necesita, si no, programo lo que se necesita. Otros desarrolladores prefieren usar un framework que les permita programar con soltura lo que se necesita. También pueden revisar antes si ya tienen algo similar o si alguien más lo tiene. ¿Cuál es la diferencia? La forma en que Drupal tiene las soluciones. Quizás no sea perfecta, ni simple, ni elegante, ni eficiente, pero es algo como un estándar. Hay una cierta forma de reutilizar soluciones previas. Puedes ponerles un nombre y publicarlas de modo que otros también puedan usarlas. Hay algo en la forma Drupal que tiene su encanto. Podría ser mejor, pero algo es algo :-)

Me parece que: Drupal tiene una idea brillante en su forma de proveer extensibilidad. Con el tiempo: los desarrolladores que notaron eso formaron una comunidad. la fama de Drupal fue aumentando. el desarrollo con Drupal se volvió una oportunidad de negocio. Cuando se hizo notorio el negocio, se hizo notorio el comité que guía la evolución de Drupal. La evolución de Drupal no es directamente controlada por la comunidad. Es hecha por la comunidad, pero no necesariamente para la comunidad. El comité motivó a la comunidad para que hiciera algunos saltos evolutivos. Quizás la versión más exitosa ha sido Drupal 6. Drupal 7 parecía un salto evolutivo natural, sin embargo quizás estuvo más inspirado en el desarrollo de la iniciativa Acquia. Saltar de Drupal 6 a Drupal 7 no ha resultado algo fácil. Drupal 8 buscaría volver a Drupal algo más genérico. ¿Vale la pena gastar energía en saltar de Drupal 6 a Drupal 7, o es mejor guardarla para saltar a Drupal 8 cuando llegue el mo...

Lea el artículo original en Puroguramu .

artículo de Matt Buttcher (2010/10/13), traducción libre de Antonio Kobashikawa Nota de traductor : Aunque Drupal se ha convertido en un movimiento poderoso, parece que, en el interés por capitalizar algunos negocios asociados, se han tomado decisiones que están distanciando al producto de sus objetivos primarios para la comunidad. Algunas personas han estado notando eso desde hace algún tiempo y me parece interesante el tema. He conducido o contribuido a docenas de proyectos Open Source. Y todo mi código ha sido siempre Orientado a Objetos, con una excepción. Esa excepción es Drupal. Java, Python, PHP, y aún OO Perl... soy un desarrollador que teje con la lana del OO. Así que esto puede sonar chocante para cualquiera que me conoce, pero mi argumento es que la OO es mala para Drupal. Créame que decirlo no es algo notable en mi vida de desarrollador. Me siento como si le dijera a mi niño que debe faltar al colegio, sólo porque tal nivel de sofisticación no es necesaria en su vida...

Una forma simple de hacer esto, es a través de Drupal.settings , que es un objeto siempre disponible. Para agregar el nodo a Drupal.settings , lo hago en alguna función adecuada, por ejemplo en la implementación del hook_form_alter() , ya que allí se hacen las alteraciones de los formularios de edición de nodos. Por ejemplo: function mymodule_form_alter(&$form, &$form_state, $form_id) {   switch ($form_id) {     case 'my_node_form':       ...       $node = node_load($form['nid']['#value']);       // port to javascript       if ($node) {         drupal_add_js(array('node' => $node), 'setting');       }       ...       break;     ...   } } Luego, en algún javascript que se invoque para el tipo my_node , se puede usar algo como:   var node = Drupal.settings.node;   var nid = Drupal.settings.node...

Views Custom Field  es un módulo que permite colocar PHP como contenido de un campo de una vista. Normalmente, uno usa la variable $data para acceder a los valores de los campos que se hayan definido. Por ejemplo, $data->nid permite obtener el valor de nodo y haciendo print_r($data) uno puede explorar otros valores que usar. Pero hay un problema con los valores de los campos CCK. El nombre de los campos que contienen sus valores en $data corresponden a aliases que no son constantes. Por ejemplo, cuando usa filtros expuestos, podrá encontrar que ese nombre de campo en $data cambia según qué filtro esté aplicando. Una forma de solucionar esto es usar $this->view , también disponible, para obtener el alias adecuado en cada caso. Es decir, en lugar de usar $data->some_field_alias usar $data->{$this->view->field['field_id']->field_alias} Este es un ejemplo real: <?php $cliente_nid = $data->{$this->view->field['field_client_nid'...