Drupal 9

Cuando lees un artículo de una nueva API normalmente la gente se suele copiar en los ejemplos, o a lo sumo desarrolla uno de ellos un poquito más, es raro hablar de una Bundle Class o lo que se ha programado en ella ya que suele ser parte de la lógica de negocio.

Este texto son unas reflexiones de Statu en el Slack de Drupal-es en el que termina encontrando otra "aplicación" práctica para resolver una feature y obviamente implica implementar métodos en una Bundle Class.


El problema:
 

Ando escribiendo un módulo, el cual tiene varios formularios de configuración, y no se me ocurrió otra cosa que crear un formulario base que inyecta todas las dependencias necesarias (de todos los formularios), y a la vez tiene varios métodos además de los métodos estandar de los formularios de Drupal, de tal forma que el resto de formularios únicamente tendrían que extender este formulario para usar los métodos adicionales añadidos y sobreescribir los métodos comunes de los formularios con sus métodos propios.

Desde un punto de vista de DDD se puede justificar en que queda todo dentro del dominio que representa la funcionalidad concreta de ese módulo, pero no terminaba de gustarme la idea de tener un formulario sobrecargado de métodos para que luego el resto de formularios mediante la extensión pudiesen usar los métodos que implementa el formulario padre ya que yo creo que rompe el principio de responsabilidad única al ser sobrecargado con métodos que en algunos casos comparten el resto de formularios pero en otros casos no.

Es por eso que en un principio pensé en hacer una clase de tipo Helper y crear métodos estáticos pero en ese caso me pasaba un poco lo mismo esa clase era un poco como un cajón desastre donde meter todo aquello que no tenía claro donde poner, así se me ocurrió que en vez de eso podría usar Functors 

Así que vamos con el código.

Como se puede ver, de esta manera podemos tener múltiples Functors que al ser definidos como servicios no solo se pueden usar en el módulo sino que el día de mañana otro módulo podría llamar también a esos servicios, cada Functor únicamente se encargaría de su propia lógica (Principio de Responsabilidad Única), y simplemente se tienen que inyectar en los formularios.

Hux es módulo que permite escribir módulos de Drupal sin necesidad de usar el archivo *.module, me han comentado que únicamente para algunos hooks que hacen referencia al tema sería necesario usar el archivo *.module, me queda por comprobar eso.

Uno de los requisitos importantes de Hux es que es necesario usar PHP 8.x ya que usa anotaciones en los métodos de las clases que se crean, otro de los requisitos es que solo se puede usar a partir de la versión 9.4 de Drupal, o en su defecto la 9.3 con un parche que existe, ya que para hacer posible el funcionamiento del módulo hubo que modificar el core de Drupal.

¿Qué nos permite hacer Hux? Con Hux podemos mover los hooks del archivo *.module a clases dentro de la ruta /src/Hooks del módulo custom que se esta desarrollando, de esta forma en vez de tener un archivo *.module gigantesco lo separaremos en archivos mucho más pequeños y nos permite organizar mejor el código, con Hux podemos usar una o más clases para escribir nuestros hooks, tenerlo todo en una única clase que simule el viejo *.module es posible, pero también podemos tener varias clases el como o que tiene cada clase ya queda a decisión de cada uno, se puede ordanizar pensando en entidades de Drupal, se puede organizar el código pesando en DDD, o como queramos ya que ahora no estamos obligados a usar el archivo *.module (menos los hooks de temas).

Otra de funcionalidades que tenemos es que podemos invocar el mismo hook varias veces en la misma clase o en clases diferentes y gracias a esto mantener el principio de responsabilidad única cada vez que se invoca el hook; un ejemplo de esto sería un tipo de contenido que quiere definir varios pseudofields, en vez de tener todos los pseudofields en 2 hooks, se puede tener una clase por cada pseudofield y en esa clase declarar los hooks necesarios para cada uno de los pseudofields.

En este artículo se explica mejor que se puede hacer con el módulo, y el archivo Readme.md del módulo
 

Hux es un modulo que permite que dejemos de usar (parcialmente) los hooks en el archivo *.module de Drupal y usar en su defecto clases, en este artículo explican como funciona el módulo: https://www.previousnext.com.au/blog/hux-alternative-to-hooks

He jugado un rato para aclarar dudas:

 

Se pueden usar hooks genéricos que afecten a todas las entidades o filtrando por bundle (entre otras cosas).

se pueden usar hooks más específicos que afecte a una única entidad.

A la hora de organizar el código de nuestros proyectos es una gran ventaja, ya no tendremos todo el código en el archivo *.module, podemos tener múltiples clases dentro del directorio src/Hooks y cada una de esas clases que recoja un único hook, o tener varios hooks por clase, además puede ser un buen punto de partida a la hora de "agrupar" el código pensando en DDD o agruparlo por entidades, ya que a veces en proyectos custom no se visualiza el código agrupado de esta manera sino que simplemente se van creando módulos que resuelven una necesidad.

Normalmente trabajo con Wodby 4 Drupal como la base para levantar mis proyectos de Drupal en local, y en entornos de desarrollo, hasta ahora había usado Behat para hacer testing, es una herramienta que me gusta, y que considero que esta muy bien, pero había leído cosas buenas de Cypress, y quería probarlo, y cuando descubrí que además se podía integrar con Cucumber pues mucho mejor.

Cypress es una herramienta Javascript de end-to-end testing. En otras palabras, permite comprobar que el funcionamiento de un producto de software recién desarrollado sea buena y corresponda con los requerimientos iniciales.

Cucumber es una herramienta de software que apoya el desarrollo impulsado por el comportamiento. En el enfoque de Cucumber BDD es fundamental su analizador de lenguaje ordinario llamado Gherkin. Permite especificar los comportamientos esperados del software en un lenguaje lógico que los clientes puedan entender.

Poder usar Cucumber por un lado para seguir la metodología BDD y por otro lado con Gherkin hacer partícipe al cliente de las pruebas que se escriben para el proyecto me parecía que era una doble victoria, así que me puse manos a la obra para hacerlo funcionar.

El éxito de todo esto se lo debo a este artículo y a los otros cuatro artículos escritos por Soraia Reis Fernandes que me ayudaron ha realizar una inmersión en Cypress primero y luego en Cucumber, y por último como integrarlo todo en Docker.
 

Lo cierto es que yo únicamente he trasteado un poco con las rutas para adecuarlo a Wodby 4 drupal, en un segundo artículo hablaré de otras cosas que he investigado, artículos sobre Cypress + Drupal que he leído y módulos que hay de Drupal para ejecutar test de Cypress.

He subido un proyecto aquí con todo lo que se necesita para empezar a trabajar con Cypress + Cucumber en Wodby 4 drupal.

La situación es la siguiente, en un proyecto es necesario subir archivos pdf, algunos de los cuales pueden llegar a subir hasta 700 megas, con ese peso tanto para subir como para servir el documento no es viable usar Apache/Nginx/PHP, se puede usar pero no es la opción más óptima, para solventar esto vamos a proponer usar un sistema de almacenamiento como es el caso de S3.

La wikipedia define S3 de la siguiente manera:
 

Amazon S3 o Amazon Simple Storage Service es un servicio ofrecido por Amazon Web Services que proporciona almacenamiento de objetos a través de una interfaz de servicio web.

En el caso de Drupal tenemos dos módulos que nos ayudarán con lo que queremos conseguir, por un lado esta el módulo S3 file system y por otro el módulo S3 file system Cors.

Configurar S3 file system

Tenemos que recordar que el sistema de Files de Drupal   por defecto nos permite configurar entre público o privado en /admin/config/media/file-system

Image

Para hacer nuestro truco tenemos que añadir la siguiente configuración del módulo S3 file system

Image

Ponemos a False s3fs.use_s3_for_public porque no queremos que Drupal delegue en el S3 todos los archivos que tenemos dentro de la carpeta files, sino que solo los archivos de los campos que nosotros queremos. 

Si volemos a cargar la página del módulo de file system veremos lo siguiente:

CodeSniffer es un script de PHP5 que analiza código PHP para detectar violaciones de un conjunto definido de normas de codificación. Analiza el código fuente para ver si cumple o no con un estándar, ya sea Zend, Pear o uno personalizado.

Junta de Andalucía

CodeSniffer es una herramienta muy sencilla de usar y con uan instalación muy simple que permitirá mantener los estándares de codificación de nuestros proyectos.
La inslatación es muy sencillo, lo primero comprobamos que tengamos instalado CodeSniffer 

phpcs -i

Tiene que devolver algo parecido a esta salidad, no exactamente la misma ya que yo ya tengo instalada los estándares de Drupal:

The installed coding standards are Zend, PSR1, PSR12, Squiz, PEAR, MySource, PSR2, Drupal, DrupalPractice and VariableAnalysis

Si no tenemos instalado CodeSniffer lo instalamos:

composer require --dev drupal/core-dev

Y comprobamos que ahora si tengamos instalado el CodeSniffer.

Una vez instalado tenemos que instalar los estándares de código de Drupal:

composer require --dev dealerdirect/phpcodesniffer-composer-installer

Y ya tendríamos instalado lo básico que usar esta herramienta.

Para usar el analizador de CodeSniffer lo ejecutamos de la siguiente manera:

phpcs --standard=Drupal --extensions=php,module web/modules/contrib/

Con esta orden o nos indica que esta todo bien o nos devolverá un informe como el siguiente:

Vamos a ver esta magnífica unión para tener una web estática (html, css, y js) de forma rápida y sencilla.

Gitlab es una saas que tiene varios servicios, entre ellos ofrece la posibilidad de alojar páginas estáticas de forma sencilla, para hacerlo nos tenemos que fijar en esta sección de la documentación de Gitlab: User and Group website examples, y también en esta otra sección de la documentación de Gitlab: Specific configuration options for Pages.

Por otro lado vamos a usar Tome, que es un módulo de Drupal 8||9 que permite exportar el contenido de nuestra página web a contenido estático, la documentación de Tome esta aquí.

Ahora vamos a la miga de todo esto (en realidad es muy sencillo), para casar Tome con Gitlab Pages, tenemos que entender una cosa, tenemos que definir en Drupal una carpeta donde Tome se encargará de guardar todo el contenido estático, por seguridad y organización en la carpeta donde tenemos los archivos devueltos por Tome no tenemos ni el directorio .git, ni los archivos .gitignore, ni .gitlab-ci.yml. Yo lo que he hecho es crear un directorio llamado public_tome, y dentro de él otro llamado html, es este segundo directorio el que guarda todos los archivos generados por Tome, mientras que dentro de public_tome guardamos todo,  el directorio html sería como el docment_root y el resto de elementos son los que queda fuera del document_root.

Image

Con esta estructura ya construida editamos el archivo de configuración (settings.php o settings.local.php) y añadimos lo siguiente:

$settings['tome_static_directory'] = '../public_tome/html';

Con esta configuración Tome despliega los archivos en la ruta que queremos.

El siguiente paso es configurar el archivo gitlab-ci.yml, este archivo es un archivo de configuración de pipeline que nos permite indicar (de forma sencilla) que queremos hacer durante el pipeline, lo importante para nosotros es la parte de script que es donde indicaremos que parte queremos copiar al servidor de estáticos de Gitlab.