Pasé los últimos dos años en un nuevo trabajo con dos sitios de WordPress bajo mi supervisión. Revisé un poco las tuberías, eliminé un tema horrible de Tailwind y trabajé en la construcción de nuevos módulos y bloques. Estoy usando Timber/Twig y hackeé el compositor de manera relativamente sencilla usando el complemento imprescindible en el directorio y eligiendo el nombre de archivo “00_autoload.php” para forzar al compositor a cargar antes que nada. Hace muchos años trabajé probando la integración del compositor en Drupal 8.
He pasado algún tiempo con complementos y bloques tal como se encuentran actualmente en el ecosistema y tratando de descubrir la mejor manera de integrar Composer como una opción para aquellos complementos que quieran usarlos. El mayor obstáculo es que el compositor no tiene forma de manejar el control de versiones de la biblioteca de modo que se carguen dos versiones de una biblioteca simultáneamente. Esto puede llevar a una situación en la que dos complementos quieran dos versiones diferentes e incompatibles de la misma biblioteca. La solución de Drupal ha sido obligar a todos a actualizar las cosas y ser más tacaños con las subvenciones de compatibilidad con versiones anteriores. Eso va en contra de lo que he observado en el ecosistema de WordPress.
Aparte, aquí no estoy defendiendo ninguno de los dos enfoques, sólo señalo las diferencias. Cada enfoque tiene ventajas e inconvenientes que pueden debatirse infinitamente, pero que en última instancia están fuera de tema.
A los bloques se les ha actualizado su sistema de carga en algún momento entre el 5 y el 6 (Antes de mi trabajo actual no había trabajado con PHP, y mucho menos con WordPress, durante 6 años). El sistema recomendado actualmente, con el archivo block.json, es muy potente y he disfrutado usándolo. Creo que tiene sentido pasar a una declaración de archivo json para los complementos que desean optar por Composer porque dichos complementos deberán tener un archivo Composer.json. La especificación está aquí: https://getcomposer.org/doc/04-schema.md
Podría tener sentido utilizar el nombre plugin.json para archivos que utilicen este dialecto. Además de las directivas del compositor, se usarían directivas de enlace similares a las del archivo block.json. Fuera de mi cabeza algo como esto
{
"hooks": [
{ "name": "class/function invoked" },
{ "init": { "MyPlugin\\Hooks", "init" }}
]
}Los complementos también podrían especificar su prioridad. Existen complementos que existen para que otros complementos se basen en ellos sin exponer sus propias características; estos son más adecuados para las bibliotecas de compositores.
Finalmente, los temas y bloques también podrían invocar bibliotecas de compositores.
La razón para manejar esto desde el principio es evitar la carga redundante de bibliotecas. En cuanto al código central en sí, esto podría usarse para separar lo antiguo de lo nuevo y tal vez trabajar hacia una refactorización que está enormemente atrasada y hacerlo posible dividiendo las cosas en fragmentos que se pueden razonar poco a poco durante un par de años (porque llevará años)
¿Pensamientos?