Un nuevo tipo de extensión llegará pronto a Drupal para sumarse a módulos, temas gráficos y perfiles de instalación. Presentados inicialmente como starter templates, las recipes (traducido como recetas) proveen funcionalidades completas que pueden incorporarse en sitios ya existentes.
Para entender mejor la necesidad que da lugar a tan importante novedad, hay que adentrarse en el modelo de reutilización de Drupal y cómo la tipología actual de extensiones no acaba de dar cobertura a todos los escenarios.
Durante la construcción de un sitio web Drupal se acometen tareas en diferentes áreas. Realizando un recorrido desde la cara más visible hasta los aspectos más internos, encontramos en primer lugar el interfaz de usuario, del que se encarga fundamentalmente el tema gráfico. Técnicamente, los temas pueden intercambiarse de un sitio a otro, sin embargo, suelen depender de otros muchos elementos que se han de tener en cuenta para hacerlos plenamente reutilizables. Las nuevas recetas no tienen un papel particularmente relevante en este sentido, ya que están orientadas a facilitar la reutilización de funcionalidades. Otras características, como la reciente incorporación de Single Directory Component, tienen un impacto mucho más directo en la reutilización de temas gráficos.
Adentrándonos en la mecánica interna de una web Drupal, encontramos un núcleo base y un conjunto de módulos adicionales. Los módulos extienden las prestaciones de éste CMS proporcionando nuevas funcionalidades o enriqueciendo alguna de las existentes. La mayoría de los módulos ofrecen piezas adicionales para construir sitios web, pero rara vez aportan funcionalidades que sólo con instalarse estén listas para ser usadas directamente por los usuarios. Esta es la necesidad que vienen a cubrir las recipes.
No nos olvidamos de los perfiles de instalación. Este último tipo de extensión fue incorporado en Drupal 5 para permitir la instalación desde cero de soluciones llave en mano, en este caso sí, explotables directamente tras instalarse. Los perfiles, también conocidos como distribuciones, suelen ofrecer un producto completo listo para su uso, luego son ideales para responder a necesidades específicas que no requieran trabajo adicional más allá de una personalización básica.
Los perfiles también se han entendido tradicionalmente como un punto de partida para construir sitios más complejos. Sin embargo, por su orientación y diseño, han demostrado muchas limitaciones en este sentido. Para empezar, sólo puede haber un perfil de instalación en un sitio Drupal y éste debe elegirse bien al iniciar el trabajo ya que luego no es tarea nada simple cambiar a otro diferente. Por otro lado, los perfiles son de por sí difíciles de mantener y los sitios donde se utilizan como base más aún, ya que los cambios o añadidos que se apoyan en el perfil suelen tener que revisarse para adaptarse a cada nueva versión del perfil. Y actualizar una web Drupal no es tarea opcional. Como sucede con cualquier producto software, utilizar versiones recientes es obligado para contar con soporte de seguridad entre otras razones.
Aunque las recipes pueden utilizarse para realizar cambios de perfil técnico en un sitio Drupal, la nueva herramienta está ideada para permitir la instalación de funcionalidades bien definidas que puedan usarse de manera directa. Un ejemplo podría ser añadir un catálogo de productos a una web corporativa ya existente o permitir la compra online de esos mismos productos con una receta que instale todo lo requerido por un comercio electrónico.
Lo de empaquetar funcionalidades complejas no es algo nuevo en Drupal. En 2009 vio la luz el módulo contribuido Features con el objetivo de facilitar el despliegue en entornos productivos de nuevas funcionalidades implementadas por el equipo de desarrollo en sus entornos de trabajo. Por entonces era Drupal 6 la versión estable.
Hasta Drupal 8, configuración y contenido convivían más o menos entremezclados en base de datos. Así pues, sin ninguna otra herramienta o técnica en particular, trasladar un cambio de configuración de un entorno de desarrollo a producción implicaba repetir los pasos uno a uno en el entorno de destino. Uno de los grandes hitos alcanzados con Drupal 8 fue separar ambos conceptos, de tal manera que la configuración pasó a considerarse parte del código, quedando bajo el sistema de control de versiones y viajando a través de éste de unos entornos a otros. En ese momento el papel de Features quedó en entredicho, sin embargo, sigue existiendo como una opción para empaquetar y mantener funcionalidades dentro de un site Drupal.
Su utilización en el diseño de las nuevas recipes fue descartado por varias razones:
Los módulos quedan permanentemente activos en el sistema a pesar de que con frecuencia sólo aportan configuración, las recipes no debían dejar huella.
Y por tanto de compartir, una característica fundamental demandada a las recetas es que pudieran aplicarse en diferentes sitios con características dispares
Lo que dificultaría su integración en el núcleo de Drupal, donde se requieren soportes simples y versátiles.
Las recetas comparten algunas características con los módulos. Ambos son instalables bajo demanda, es decir, se pueden instalar en cualquier momento en una web ya en funcionamiento para extenderla. También se pueden combinar diferentes recipes en un mismo sitio Drupal, aportando cada una de ellas una funcionalidad determinada. Además, unas pueden depender de otras, por ejemplo, la anteriormente mencionada recipe de comercio electrónico dependería de la que aporta el catálogo de productos.
Pero lo que realmente hace únicas a las recetas es que…:
Actúan a modo de script, sin dejar huella ni permanecer activas durante la vida del sitio. De esta manera no tienen ningún impacto en rendimiento, ni un papel activo en el funcionamiento del aplicativo. Además, se espera que sean revertibles.
Mediante dependencias las recipes pueden llegar a instalar código, esto es, módulos y temas gráficos, pero ellas como tal no contienen archivos PHP. Por tanto, si una funcionalidad requiere, por ejemplo, implementar un hook, tiene que llevarse a cabo dentro de un módulo del que la receta dependa.
Además de aportar nueva configuración, mediante un nuevo soporte llamado config actions las recetas pueden realizar modificaciones sobre la configuración existente sin necesidad de escribir líneas de programación.
Hasta ahora, crear contenido programáticamente ha sido una labor resuelta de diferentes formas. Default Content o Structure Sync son algunas de las más conocidas en el ámbito de módulos contribuidos. Umami, el perfil de instalación de demostración, tiene su propia implementación. Con la llegada de las recipes se incorporará al núcleo de Drupal un soporte que normalice la creación de contenido durante la instalación o despliegue.
Antes de adentrarnos en cómo son las Drupal recipes, es necesario recordar que hoy por hoy es un proyecto en fase de desarrollo, luego su forma final posiblemente variará respecto a la que tiene actualmente, aunque no se esperan cambios en sus elementos básicos.
En la carpeta que contiene una receta encontraremos al menos un archivo recipe.yml con esta estructura:
recipe.yml
# Nombre visible de la receta, tal y como se listará.
name: 'Example recipe'
# Descripción opcional de la funcionalidad que aporta.
description: "An example Drupal recipe."
# En las recetas, el tipo es similar al paquete (package) en los
# módulos, agrupa recetas según criterio de utilidad. El tipo
# 'Site' significa que la receta será listada como una opción
# en el instalador.
type: 'Content type'
recipes:
# Si la receta depende de otras, se listarán aquí. Todas se
# aplicarán antes que ella misma.
- editorial_ui_for_publishers
- another_recipe
install:
# Dependencias generales (módulos o temas gráficos) de la receta.
- easy_breadcrumb
- node
- text
config:
# La receta puede controlar qué entidades de configuración instalar o
# no de las provistas por los módulos listados en sus dependencias.
# Estos ejemplos son ficticios.
import:
easy_breadcrumb:
- views.view.easy_breadcrumbs
node:
- node.type.article
text: *
# Aquí se relacionan las "config actions" o acciones a realizar
# sobre configuración existente. Se declara el nombre de la
# configuración a tratar, la acción concreta a realizar (esto lo
# hace un plugin) y posibles argumentos.
#
# En el ejemplo, el rol de usuario 'Editor' será creado si no
# existe y luego obtendrá varios permisos para trabajar sobre
# el tipo de contenido Artículo.
actions:
user.role.editor:
ensure_exists:
label: 'Editor'
grantPermissions:
- 'delete any article content'
- 'edit any article content'
content:
# Se puede proveer un directorio con contenido a crear una vez
# la configuración de la receta se haya instalado.
Si la receta debe instalar nueva configuración, existirá una carpeta llamada config conteniéndola. Como es habitual, cada entrada de configuración se almacenará en un archivo YAML (extensión .yml) cuyo nombre coincidirá con el del elemento que defina. Por ejemplo, si la receta provee un tipo de contenido para noticias con identificador news, ésta estaría definida en el archivo config/node.type.news.yml.
A diferencia de los módulos, toda la configuración que provee una receta se instala incondicionalmente, de ahí que no existan las clásicas subcarpetas config/install o config/optional.
A fecha de publicación de este artículo, no está decidido el formato en el que las recetas almacenarán entidades de contenido a crear cuando se apliquen. La conversación gira en torno al modelo que establece el módulo Default Content por considerarse el más extendido. Si finalmente se adoptase una solución basada en esta línea, cabría esperar una carpeta content con el contenido agrupado en subcarpetas según su tipo, tal y como hace el conocido módulo contribuido.
Estos son los tres elementos que provee una receta Drupal. Adicionalmente, cuando se trate de una receta contribuida, encontraremos como es habitual un archivo composer.json con la información de empaquetado, declaración de dependencias, etc. y otros archivos de uso común, como documentación básica en un README.md.
Las recetas vienen con un nuevo API debajo del brazo que permitirá realizar modificaciones sobre configuración existente utilizando una sintaxis declarativa, como la que se presenta en el archivo recipe.yml ilustrativo. Este API es independiente de las recipes y podrá ser utilizado desde otros ámbitos. Por ejemplo, los módulos tradicionales podrán hacer uso de Config Actions para realizar cambios en configuración sin programación.
Esencialmente, este API define un nuevo tipo de plugin, cuyas instancias aplican un cambio sobre el elemento de configuración dado según la información que reciban. Es interesante señalar que la implementación actual provee un mecanismo basado en atributos PHP que crea una instancia por cada método dentro de una entidad de configuración que venga marcado con el atributo ActionMethod. El plugin grantPermissions que aparece en el archivo recipe.yml ilustrativo realmente llama al método del mismo nombre (en singular) de la clase \Drupal\user\Entity\Role, que ahora viene declarado así:
/**
* {@inheritdoc}
*/
#[ActionMethod(adminLabel: new TranslatableMarkup('Add permission to role'))]
public function grantPermission($permission) {
// …
}
Si el nombre del método es singular, la implementación, con el soporte de Synfony, crea otra instancia del mismo nombre en plural que llama al método original tantas veces como valores se definan en la acción.
A pesar de que esta nueva capacidad de Drupal está aún en fase activa de desarrollo, el equipo que participa en su construcción invita hacer uso de ella por el bajo riesgo que implica. Según explican, el nuevo soporte no tiene por qué instalarse en entornos productivos, ya que las recetas se aplican en entornos de desarrollo y las acciones que realizan se propagan como cualquier otro cambio. Además, no se esperan cambios importantes en la estructura ya implementada, por lo que es poco probable que deban revisarse aquellas recetas que se construyan ahora.
Para hacer uso de las recipes, en el proyecto que está sirviendo para articular su implementación se pueden encontrar parches para aplicar sobre cualquiera de las versiones mantenidas de Drupal 10. El parche es extenso, pero en su mayoría define añadidos, luego la probabilidad de colisión con otros parches o errores por diferencias en el código base es baja.
Quien desee practicar con ellas en casa tiene a su disposición un libro de cocina con algunas recetas Drupal para degustar y al que los máster chefs de Drupal pueden realizar aportaciones si así lo desean.
No se barajan fechas concretas para que las Drupal recipes lleguen a una versión estable, pero tienen detrás un equipo trabajando activamente que hará posible su incorporación a medio plazo. Considerando la experiencia de otras iniciativas con un calado similar, es probable que lleguen como parte de una actualización menor de Drupal 10 o, como tarde, con Drupal 11, sobre todo teniendo en cuenta que también se requiere adaptar alguna infraestructura para darles cobertura, por ejemplo, crear el nuevo tipo de extensión y su buscador correspondiente en drupal.org.
Las recipes no son un producto terminado y por tanto quedan puntos por abordar. Entre los que encontramos con mayor peso estaría que, por el momento, no hay previsto dotar a las recetas de un sistema que permita trasladar actualizaciones de una recipe una vez aplicada a un sitio. Esta carencia, unido a que no existe un registro de las recetas aplicadas, dificulta establecer un ciclo de vida para ellas y, por tanto, hoy por hoy se aplican una única vez y cualquier cambio que se desee trasladar a posteriori deberá gestionarse por alguna otra vía.
Quizá el nombre inicial de starter templates o plantillas de inicio describía mejor su propósito principal: proveer un punto de partida para nuevos proyectos o funcionalidades. Y es que su funcionamiento resulta análogo al de un script o una macro que aglutina un conjunto de pasos y los aplica sobre un sitio en particular.
Por otra parte, las recetas apuntan a ser el reemplazo natural de los perfiles de instalación, algo así como una evolución de éstos, aunque el debate sobre ello está aún abierto. De hecho, se pretende que los perfiles incluidos en el núcleo de Drupal como Standard o Umami se reemplacen con recetas. En cualquier caso, será la experiencia de uso la que determine cómo explotar mejor esta nueva capacidad de Drupal.
ifgeekthen.nttdata.com es un blog del grupo NTT DATA. Un proyecto que busca compartir con profesionales del mundo digital temas relacionados con la tecnología y el universo geek.
