Depuis la première version stable sortie en décembre 2013, le framework Joomla n'a cessé de se développer pour toujours mieux répondre aux besoins de l'écosystème Joomla, fournissant ainsi une épine dorsale des installations Joomla dans le monde entier. Le travail qui a été fait sur cette petite partie du code de base de Joomla a été extraordinaire et jette les bases d'une version encore plus puissante qu’est Joomla 4.0. Nous allons aujourd’hui aborder l'état actuel du framework Joomla et ce que vous pouvez en attendre à l’avenir.
Retour en arrière
Il ne serait pas approprié de discuter de l'avenir sans d'abord comprendre le passé et ce qui a amené Joomla à être ce qu’il est aujourd'hui. Le framework a évolué comme un fork de la plate-forme Joomla précédente, un ensemble de bibliothèques de base qui ont alimenté Joomla depuis 2005. Bien que cela ait été considéré comme un mouvement controversé à l'époque, cela s'est avéré intéressant car cela a permis aux développeurs de compenser une grande partie de la dette technique accumulée dans les bibliothèques de base sans perturber la distribution du CMS, tout en permettant le développement et le test de nouvelles fonctionnalités dans des applications réelles avant d’être introduites dans le CMS. L'inconvénient de cette séparation est qu'une grande partie du code a été dupliquée et maintenue séparément, entraînant des corrections de bogues et des améliorations apportées uniquement sur une source. Grâce à cette séparation, les membres de la communauté ont pu introduire plusieurs améliorations architecturales majeures dans les API principales, modifications qui sont ajoutées à la version 4.0 de Joomla.
En 2016, le package de base de données a été mis à jour pour prendre en charge l'intégration des instructions préparées pour chaque pilote de base de données pris en charge, une amélioration majeure de la sécurité par rapport à l'API existante et une fonctionnalité standard pour toute couche d'abstraction de base de données. Cet effort n'avait pas été tenté précédemment en raison de la prise en charge par l'API de l'extension PHP mysql, désormais obsolète. Ce support a été introduit dans l'API lorsque des pilotes basés sur PDO ont été ajoutés à la plateforme et au framework. Cependant, la version initiale de cette implémentation complète comportait plusieurs oublis qui n'ont pas été pris en compte et qui ont nécessité des modifications architecturales supplémentaires et des améliorations dans l'API de base de données pour résoudre les problèmes liés à l'implémentation sous-jacente de chaque pilote.
Depuis que le travail a commencé en 2015 sur les packages du Framework 2.0, beaucoup d'efforts ont été consacrés à l'amélioration du code et du Framework (à la fois comme un ensemble autonome de package et comme une API qui serait le fondement de Joomla 4.0). En plus du travail sur l'API de la base de données, nous avons introduit un nouveau package de console qui s’appuie sur Symfony et qui permet aux développeurs de Joomla de développer des utilitaires en ligne de commande bien intégrés dans leurs extensions et applications. De plus, le Framework offre un conteneur d'injection de dépendance permettant la gestion centralisée des dépendances applicatives et est maintenant utilisé pour réduire le couplage entre les différents éléments de l'API Joomla, permettant des intégrations avancées où les composants principaux peuvent être remplacés par une implémentation personnalisée. Notre package de session a été révisé pour adresser plusieurs soucis architecturaux dans les conceptions de classe ayant pour résultat une API qui peut être entièrement testée.
État actuel
Au cours du mois de mars 2018, les 45 packages du framework ont franchi une étape importante : un million de téléchargements cumulés. Plusieurs de ces packages ont reçu la ferveur du public, représentant plus de 90 000 téléchargements chacun, tandis que d'autres packages n’ont pas eu cette chance avec moins de 2 500 téléchargements. Cela indique qu'il y a certaines choses que nous avons bien faites alors qu'il y a d'autres n'ont pas fonctionné, et nous n'avons pas peur d'admettre que toutes les idées ne sont pas bonnes. De même, certains de nos packages ont été correctement maintenus (dans certains cas en partie grâce à leur utilisation dans le CMS), et d'autres packages ont reçu peu ou pas d'attention.
Une grande partie du développement s'est concentrée sur les branches 2.0 de nos packages afin d'optimiser notre code pour les exigences minimales de PHP 7 ou d'expérimenter (et implémenter) des changements architecturaux améliorant l'utilité de nos packages. Comme nous l'avons souligné précédemment, cela a entraîné plusieurs améliorations dont la communauté Joomla aura grandement besoin au cours des années à venir, et nous sommes fiers que nos efforts permettent une amélioration continue. Cependant, nous avons également suffisamment progressé pour constater que le framework a perdu de son intérêt et qu'il est nécessaire de ré-analyser nos efforts actuels et futurs.
Pour aller plus loin
Après avoir analysé l'état actuel du Framework, compte tenu des ressources disponibles dans l'écosystème PHP et des ressources disponibles au sein de la communauté Joomla pour maintenir le Framework, nous avons pris la décision de retirer plusieurs packages (en plus de la suppression des packages Compat, Form et Log).
- Toutes les bibliothèques de connecteurs d'API à l'exception du connecteur GitHub - Ces bibliothèques ont essentiellement été abandonnées depuis la version stable initiale du Framework, recevant peu de téléchargements au cours des années ou un minimum de maintenance. Le connecteur GitHub est exclu car nous maintenons activement ce package et l'utilisons de manière assez constante dans nos outils.
- Le package DateTime - Une grande partie de la fonctionnalité de ce package est maintenant incluse dans la bibliothèque Carbon
- Le package Date - Cette sous-classe de DateTime de PHP est très utile dans l'environnement CMS où les chaînes date / heure sont généralement localisées et traduites. Mais ces fonctionnalités ont été supprimées du Framework et encore une fois la bibliothèque de Carbon est devenue un remplacement viable.
- Le package Cache - Bien qu'il s'agisse d'un package actif supportant à la fois le PSR-6 et le PSR-16, nous avons trouvé qu'il n'était pas raisonnable d'intégrer un package de cache compatible PSR dans le CMS car il repose sur des fonctionnalités n’étant pas supportée par PSR et nécessite essentiellement que nous maintenions deux API de mise en cache. Nous préférons nous concentrer sur le support d'une seule API, surtout étant donné le nombre de packages supportés dans l'écosystème PHP.
- Le package LDAP - Il s'agit d'un package dont le support et la maintenance ont été minimes et dont la conception de l’API interne rappelle celle de PHP 4. Nous recommandons le composant LDAP de Symfony en remplacement.
Un autre point que nous nous sommes efforcés d'améliorer est la documentation des packages du Framework et la mise à disposition de ressources pour aider les utilisateurs à créer des applications sur le Framework. Nous avons établi une structure de documentation standard pour chaque package (jusqu'à présent cela concernait principalement la documentation de la mise à jour 2.0 et les aperçus des packages) et à mesure que la version Framework 2.0 se rapproche, ce travail est intégré dans le site Web de Joomla.
Articles qui devraient vous intéresser
Phoca Gallery 3.2.4 : une galerie Joomla pour vos photos
Réussir votre entreprise sur Internet grâce à Joomla
