Abstraction WordPress : Meilleures pratiques et plugins WordPress d’abstraction

WordPress est un CMS ancien, mais c’est aussi le plus utilisé.  En raison de son support continu des versions PHP obsolètes et du code hérité, WordPress a du retard dans l’adoption des pratiques de codage modernes, l’un des meilleurs exemple est l’abstraction de WordPress.

I. Problèmes d’intégration de WordPress et des outils PHP

L’intégration de WordPress avec des outils de base de code PHP tels que PHPStan, PHPUnit et PHP-Scoper peut parfois poser des problèmes en raison de l’ancienne architecture de WordPress. Même si le code WordPress ne représente qu’une partie du projet, il peut entraîner des difficultés d’intégration avec ces outils. Pour résoudre ce problème, il peut être judicieux de diviser le projet en paquets distincts, certains contenant uniquement du code WordPress et d’autres contenant du code commercial indépendant du CMS. Ainsi, les paquets sans code WordPress ne seront pas affectés par les problèmes d’intégration et pourront être pleinement compatibles avec les outils de base de code PHP.

II. L’abstraction de code et comment coder contre les interfaces

L’abstraction de code consiste à réduire les dépendances directes entre les différents éléments du code en utilisant des contrats. Au lieu de coder directement en fonction des implémentations spécifiques, on programme en fonction des interfaces fournies. Cela permet de créer des paquets de code indépendants les uns des autres, qui peuvent être utilisés dans différentes applications avec différentes configurations. L’utilisation de l’outil Composer facilite la distribution de ces paquets de code. Enfin, l’injection de dépendances est utilisée pour assembler toutes les parties du code ensemble de manière flexible et modulaire. Ainsi, l’abstraction de code conduit à une base de code propre et bien structurée, favorisant la réutilisabilité et la flexibilité.

Le codage contre les interfaces est une pratique qui consiste à utiliser des contrats, sous la forme d’interfaces en PHP ou d’autres langages, pour permettre l’interaction entre différentes parties du code. Une interface définit les fonctions disponibles et leurs signatures, c’est-à-dire les types d’entrées qu’elles acceptent et les sorties qu’elles fournissent.

En programmant en utilisant des interfaces, on déclare l’intention de la fonctionnalité sans se soucier de sa mise en œuvre concrète. Ainsi, notre application peut utiliser des morceaux de code autonomes qui remplissent des objectifs spécifiques, sans avoir à connaître les détails de leur fonctionnement interne. Cela rend l’application indépendante des détails de mise en œuvre et facilite la substitution d’une implémentation par une autre qui atteint le même objectif, sans nécessiter de modifications importantes de l’application elle-même.

III. Les paquets

Composer est un gestionnaire de paquets pour PHP qui facilite l’installation et la gestion des dépendances d’une application. Pour rendre notre application PHP indépendante de WordPress, nous devons distribuer son code sous forme de paquets distincts, de deux types différents : ceux contenant le code spécifique à WordPress et ceux ne contenant que la logique métier, sans aucun code WordPress.

Ensuite, nous ajoutons ces paquets en tant que dépendances de notre application et les installons à l’aide de Composer. Pour assurer une intégration fluide avec les outils et les pratiques de développement, nous veillons à ce que les paquets contenant la logique métier représentent la majorité du code de l’application. Un objectif raisonnable serait qu’ils gèrent environ 90% du code global de l’application.

• Utiliser l’injection de dépendances

L’injection de dépendances est un modèle de conception qui permet d’assembler les différentes parties d’une application de manière souple. Dans ce modèle, l’application accède aux services à travers des contrats, et les implémentations de ces contrats sont « injectées » dans l’application via une configuration.

En modifiant simplement la configuration, il est possible de passer facilement d’un fournisseur de contrat à un autre. Il existe plusieurs bibliothèques d’injection de dépendances parmi lesquelles choisir. Il est recommandé de choisir une bibliothèque qui respecte les recommandations standard de PHP (généralement appelées « PSR »), afin de pouvoir facilement remplacer la bibliothèque par une autre si nécessaire. Pour l’injection de dépendances, la conformité à la PSR-11 est importante, car elle spécifie une « interface de conteneur ». Parmi les bibliothèques conformes à la PSR-11, on peut citer, entre autres :

• Symfony’s DependencyInjection
• PHP-DI
• Aura.Di
• Container (Dependency Injection)
• Yii Dependency Injection

IV. Quand faire l’abstraction

L’abstraction de code est une tâche qui peut demander beaucoup de temps et d’efforts, c’est pourquoi il est important de peser les avantages par rapport aux coûts avant de se lancer. Voici quelques indications pour déterminer quand il peut être intéressant d’abstraire du code. Vous pouvez utiliser les extraits de code fournis dans cet article ou les extensions WordPress d’abstraction suggérées ci-dessous comme point de départ.

• Accéder à l’outillage : En séparant le code de WordPress en paquets distincts, il devient possible d’évaluer directement une extension WordPress de manière isolée.
• Réduire le temps et le coût d’outillage : Les tests PHPUnit prennent plus de temps à s’exécuter lorsqu’ils doivent initialiser et exécuter WordPress par rapport à lorsqu’ils ne le font pas. Réduire le temps d’exécution des tests peut également entraîner des économies financières.
• Un remaniement lourd mais pas nécessaire : Introduire l’architecture nécessaire (injection de dépendances, division du code en paquets, etc.) dans un projet existant peut nécessiter une refonte majeure, ce qui peut rendre le processus complexe et difficile à gérer. En revanche, abstraire le code dès le début d’un nouveau projet facilite considérablement sa gestion.
• Produire du code pour plusieurs plateformes : En isolant 90% du code dans un paquet indépendant du CMS, nous pouvons créer une version de la bibliothèque qui peut être utilisée avec un CMS ou un framework différent en ne modifiant que 10% du code global.
• Migrer vers une plateforme différente : Lorsque nous devons migrer un projet de Drupal à WordPress, de WordPress à Laravel, ou toute autre combinaison, seule une réécriture de 10% du code est nécessaire, ce qui représente une économie significative.

V. Meilleures pratiques 

5.1. Adhérer au PSR-12

Adhérer à la spécification PSR-12 lors de la définition de l’interface pour accéder aux méthodes de WordPress vise à réduire les difficultés cognitives lors de l’analyse du code provenant de différents auteurs. Cela nécessite de renommer les fonctions de WordPress pour être en conformité avec la spécification.

5.2. Diviser les méthodes 

Les méthodes de l’interface ne sont pas tenues d’être une réplique exacte de celles de WordPress. Nous avons la liberté de les adapter lorsque cela est pertinent. Par exemple, la fonction get_user_by($field, $value) de WordPress est capable de récupérer un utilisateur dans la base de données en utilisant le paramètre $field, qui peut prendre les valeurs « id », « ID », « slug », « email » ou « login ». Cette conception présente quelques problèmes :

• Elle ne générera pas d’erreur à la compilation si nous passons une chaîne de caractères incorrecte.
• Le paramètre $value doit accepter différents types de données pour toutes les options, même si en passant « ID » il attend un entier, tandis qu’en passant « email » il ne peut recevoir qu’une chaîne de caractères.

5.3. Supprimer les détails d’implémentation de la signature de la fonction

Lors de l’évaluation d’une fonction WordPress d’un point de vue abstrait, les informations spécifiques à son implémentation peuvent être omises de sa signature.

5.4. Effacer la dette technique

La fonction get_posts de WordPress renvoie différentes entités telles que les articles, les pages et les publications personnalisées, mais ces entités ne sont pas interchangeables. Cependant, cette divergence conceptuelle n’a jamais été corrigée dans le code principal de WordPress. Ce problème est courant dans les logiciels à longue durée de vie et est souvent appelé « dette technique » – des problèmes de code qui ne sont pas corrigés pour éviter les changements cassants.

VI. Les différents avantage de l’abstraction du code

L’abstraction du code dans une application offre plusieurs avantages significatifs :

• La configuration et l’utilisation d’outils pour des paquets contenant uniquement du code commercial sont plus simples, plus rapides et moins coûteuses.
• Il devient possible d’utiliser des outils qui ne sont pas compatibles avec WordPress, comme le scoping d’une extension avec PHP-Scoper.
• Les paquets produits peuvent être autonomes et facilement intégrés dans d’autres applications.
• La migration de l’application vers d’autres plateformes devient plus facile.
• Il est possible de changer de perspective, passant d’une mentalité centrée sur WordPress à une approche axée sur la logique commerciale.
• Les contrats décrivent l’intention de l’application, améliorant sa compréhensibilité.
• L’application est organisée en paquets, ce qui permet de créer une application légère et de l’enrichir progressivement en fonction des besoins.
• La dette technique peut être éliminée, résolvant ainsi les problèmes de code non corrigés.

VII. Problèmes liés à l’abstraction du code

L’abstraction du code dans une application présente certains inconvénients :

• Elle nécessite un investissement initial important en termes de travail et d’efforts.
• Le code devient plus verbeux, ce qui signifie qu’il y a une superposition de couches de code supplémentaires pour obtenir le même résultat.
• La création de nombreux paquets peut conduire à la gestion et à la maintenance complexe de ces derniers.
• Il peut être nécessaire d’utiliser un mono-repo pour gérer tous les paquets de manière cohérente.
• L’utilisation excessive de l’injection de dépendances peut être contre-productive pour les applications simples, avec des rendements décroissants en termes de bénéfices.
• Il est important de noter que l’abstraction du code ne pourra jamais être complètement réalisée, car il existe généralement une préférence implicite pour l’architecture du CMS sous-jacent.

Conclusion sur l’abstraction WordPress : 

Si vous lisez ces lignes, c’est que vous avez appris ce qu’était l’abstraction WordPress. Pour résumer cela à séparer le code de WordPress de manière à le rendre plus indépendant et réutilisable. Cela permet de le rendre portable et modulaire, facilitant ainsi sa migration vers d’autres systèmes et sa réutilisation dans d’autres projets. 

Meta description :  En lisant cet article vous comprendrez l’abstraction WordPress. C’est très important de connaître cela aujourd’hui.