Una de las cosas que parece avanzar muy lentamente es el desarrollo de los temas en Drupal. Cabe aclarar que un tema es lo que en otros CMS llamarían una plantilla.
Con Avanzar lentamente me refiero a que existen ahora maneras de desarrollar el frontend en muchas plataformas que no se usan o no parecen usarse en Drupal, para cambiar esto en parte se impulso durante un tiempo la idea de sitios desacoplados (o headless) donde el contenido y parte de la configuración esta en Drupal y la parte visual estaba en otra cosa como puede ser Gastby o algún otra cosa en react o javascript que se use actualmente.
Como parte del desarrollo de Drupal integrándolo a Symfony (cuando salió la versión De Drupal 8) se decidió usar twig , crear subthemas y se acabo. Mucho del desarrollo de themas o de maneras de manejarlo se ha dejado a ser creado por cada empresa o grupo de programadores que deseen hacerlo como un proyecto en Drupal.org
En parte es correcto en cuanto a no tomar una decisión grande como podría ser tomar un camino, por ejemplo mover todo el frontend a algún framework de javascript. El problema esta en que no se incorporan nuevas practicas a los themas.
Existe una iniciativa que se llama UI Suite Initiative - Design Systems with Drupal qué esta desarrollando themas y módulos para permitir que se usen diferentes sistemas de diseño que ya existen como son el ya conocido Boostrap o USWDS o Material Design o hasta el sistema de Firefox (que desconocía!). En palabras del los creadores: La iniciativa proporciona un conjunto coherente de módulos para implementar sistemas de diseño completos al tiempo que preserva y mejora la experiencia de creación de sitios Drupal.
Como parte de esta iniciativa tienen hasta su propio manifiesto (lo traducimos):
Manifiesto
Es necesario reducir la brecha entre los themers y los site builders. Se producen en cada proyecto demasiado código PHP (custom plugins, events, hooks preprocess, hooks alter...) por parte de los desarrolladores backend, para llenar este vacío.Además, si este código PHP no se proporciona en su totalidad, es posible que el tema deba compensar en exceso, adaptando su trabajo para proporcionar un markup peculiar o abusando de los mecanismos de sugerencia y override de plantillas.
Si era un problema cuando implementábamos maquetas sencillas y aburridas. Este es aún más el caso hoy en día con nuevas metodologías como los Sistemas de Diseño.
Por es por esto que estamos buscando y creando módulos Drupal para cubrir todas las partes (components, styles helpers/utilities, layout systems, examples pages...) de un sistema de diseño, mientras:
- permitimos que el tema posea e impulse la implementación, declarando fácilmente archivos YAML desde la carpeta del tema
- exponer esta implementación directamente a la construcción del sitio, en la administración de Drupal (layout builder, manage display, views, blocks, flags...), como complementos configurables.
- para casos comerciales específicos, exponer esta implementación al desarrollador backend como una API agradable y sólida.
El segundo punto es muy importante. La posibilidad de modificar desde la administración el acomodo de los elementos o hasta como se ve (colores, tamaños de letra, etc), es algo que ya se impulsaba desde que apareció el módulo de layout builder, que para la gente de wordpress seria una especie de Elementor o Gutenberg.
De esta manera un themer podría aplicar un sistema de diseño a un tema o a un módulo y dejar a los usuarios del sitio el poder aplicar estas reglas.
Vale pues mucho la pena darse una vuelta por esta iniciativa y ver todo el trabajo que apenas están haciendo y guardar los diferentes temas que están implementando.
Añadir nuevo comentario