http://virtualizada.com/tags/m_dulos La vista de la taxonomía con una profondidad de 0. es http://virtualizada.com/blog/por_qu%C3%A9_no_me_gusta_el_m%C3%B3dulo_content_templates <p> Hace poco tiempo descubrí el módulo <a href="http://drupal.org/project/contemplate">Content Templates</a> , aunque ya se llevaba mucho tiempo trabajando en él (desde 2006). </p> <p> Contemplate (nombre reducido) permite la modificación del avance y cuerpo de un nodo en Drupal desde la administración. Viene a solucionar una necesidad que sucede cuando se usan campos CCK para extender el formato básico de los nodos. Parte del problema es que Drupal considera que todos estos campos forman parte del <em>body </em>y cuando se muestran avances se muestran todos estos campos. Por otra parte, no existe una forma cómoda de ocultar, por ejemplo, algunos campos (perdón, úsese <a href="http://drupal.org/project/cck_field_privacy">CCK Field Privacy</a>) o etiquetas de campos (con técnicas CSS!). </p> <p> El caso es que es engorroso y Contemplate lo pone, en principio, un poco más fácil. Tanto que sólo tienes que elegir crear una nueva plantilla para un tipo de nodo, decidir qué parte se modifica (teaser, body, rss) y voilà! dónde está mi contenido? </p> <p> Lo primero que no me gusta de este módulo, y que no sirva como una crítica destructiva si no como una manera de valorar su uso según qué casos, es que se requieren tantos conocimiento de HTML/PHP que si tuvieras que customizarte tu propia forma de visualizar un nodo. </p> <p> En segundo lugar, no sé por qué (quizá es que no he sabido usarlo correctamente) desaparece automáticamente lo que guardamos en el campo body y esto hace que tengamos que estar prevenidos y no se nos pase crearnos un cck tipo texto para poder guardar el cuerpo. </p> <p> En tercer lugar, parece ofrecer una forma nueva con la que referenciar los campos cck de la que desconozco la potencia o lo nuevo que ofrece (si alguien la sabe, por favor que me informe que estoy pez). El caso es que, en mi opinión, usando el campo <a href="http://drupal.org/project/devel">Devel</a> (si no lo usas normalmente te lo recomiendo para todas tus instalaciones) es más que suficiente para saber cómo hacer referencia con PHP a las variables que lo muestran. </p> <p> Entiendo que es duro tener que pensar que hay que saber programar para poder manejar el sistema de plantillas de Drupal, ya que esto hace el trabajo de maquetador mucho más pesado. Existen alternativas como Smarty (todavía no lo he probado aquí, pero me gustaría verlo en funcionamiento), el caso es que es una realidad. Contemplate resuelve de forma rápida una serie de limitaciones que tiene el CMS y me gustaría decir que es la mejor opción para quien no quiere oír de programación. Pero no es así. </p> <p> En cuarto y último lugar, este módulo como muchos otros se interponen de una manera indirecta en una clara separación, y en mi opinión necesaria, de las tareas de maquetación y administración. Es más un problema de metodología de trabajo: ¿quién tiene que preocuparse de cómo se muestra un tipo de contenido, de qué etiquetas HTML deben usarse, de cuándo o cómo poder modificarlo? </p> <p> En este sentido creo que siempre será más fácil trabajar en un proyecto en el que se separen al máximo estas tareas, que un maquetador no necesite nada más que su cuenta FTP directa al directorio de themes para poder hacer lo que quiera sobre el aspecto del sitio... claro que este argumento destrozaría la utilidad del sistema de bloques!! ups... bueno, quizá no tenga razones reales para no usarlo, una vez más, es cuestión de costumbres. </p> <p> &nbsp; </p> <p> pd: estoy totalmente a favor del sistema de bloques y de que exista gente que trabaje tan duro como se ha hecho con el proyecto Contemplate. </p> http://virtualizada.com/blog/por_qu%C3%A9_no_me_gusta_el_m%C3%B3dulo_content_templates#comments contenido drupal módulos reflexiones Mon, 13 Oct 2008 17:42:29 +0200 karmel 189 at http://virtualizada.com http://virtualizada.com/blog/tags/drupal/m_dulos_destacados_para <p>Interesante selección de módulos para Drupal la que podemos encontrar en <a href="http://5lineas.com/archivo/desarrollo-web/que-pueden-hacer-los-usuarios-en-un-sitio-web-soluciones-drupal/">5lineas.com</a>, muy a tener en cuenta junto con el <a href="http://www.lullabot.com/audiocast/drupal_podcast_no_40_top_40_projects">top 40 de Lullabot</a> para los que quieran ofrecer algo más de documentación a lo más usado de este cms.</p> <p>&nbsp;</p> http://virtualizada.com/blog/tags/drupal/m_dulos_destacados_para#comments drupal módulos Wed, 23 May 2007 20:20:57 +0200 karmel 89 at http://virtualizada.com http://virtualizada.com/blog/diccionario_de_m%C3%B3dulos_drupal_en_espa%C3%B1ol <p> Llevo muchos meses ya navegando por los submundos <a href="http://drupal.org/project/Modules" title="¿respositorio de qué?">del repositorio de módulos de Drupal</a> (porque me interesa principalmente) y lo cierto es que he debido probar e instalar al menos el 40% de ellos. </p> <p> El caso es que mi compañero <a href="http://canaltrabajo.com/" title="Ver su canal de trabajo">Oliveros</a> me sugirió que podría ser una buena idea aprovechar el tirón y comenzar a publicar algún diccionario de módulos con documentación en español comentando aspectos interesantes de ciertos módulos, cómo pueden combinarse y dónde pueden resultar útiles. </p> <p> Así que espero en breve comenzar con la primera tirada y que sirva de utilidad a la comunidad hispana que creo que es algo que nos hace falta a todos. </p> <p> Por supuesto, se aceptan colaboradores. </p> <p> <u><strong>ACTUALIZACIÓN:</strong></u> </p> <h3>ya están disponibles las primeras entradas en el directorio de la web:  <a href="/inicio/modulos">Módulos imprescindibles para Drupal</a> </h3> http://virtualizada.com/blog/diccionario_de_m%C3%B3dulos_drupal_en_espa%C3%B1ol#comments diccionario drupal módulos Sat, 05 May 2007 13:10:30 +0200 karmel 80 at http://virtualizada.com