Améliorer le code WordPress avec PHP moderne

En raison de la compatibilité en amont, WordPress n’a pas tiré parti des nouvelles fonctionnalités de PHP publiées après PHP 5.2.4. Heureusement, WordPress nécessitera bientôt PHP 5.6+ et même PHP 7.0+ peu de temps après. Cet article fait un tour des fonctionnalités PHP nouvellement disponibles pour WordPress, et tente de suggérer comment celles-ci peuvent être utilisées pour produire de meilleurs logiciels.

WordPress est né il y a quinze ans et, comme il conservait une compatibilité ascendante historique, les versions les plus récentes de son code ne pouvaient exploiter pleinement les toutes dernières fonctionnalités offertes par les versions les plus récentes de PHP. Bien que la dernière version de PHP soit la version 7.3.2, WordPress offre toujours une prise en charge jusqu’à PHP 5.2.4 .

Mais ces jours seront bientôt révolus! WordPress mettra à niveau sa version minimale prise en charge par PHP, passant à PHP 5.6 en avril 2019 et à PHP 7 en décembre 2019 (si tout se déroule comme prévu). Nous pouvons enfin enfin utiliser les capacités de programmation impératives de PHP sans craindre de casser les sites de nos clients.

Les quinze années de code fonctionnel de WordPress ayant influencé la manière dont les développeurs l'ont construit, nos sites, thèmes et plugins peuvent être encombrés de code médiocre qui peut recevoir une mise à niveau.

Cet article se compose de deux parties:

1. Nouvelles fonctionnalités les plus pertinentes
   D'autres fonctionnalités ont été ajoutées aux versions 5.3, 5.4, 5.5, 5.6 et 7.0 de PHP (remarquez que il n'y a pas de PHP 6 ). Je vais explorer les plus pertinentes.
2. Construire un meilleur logiciel
   Nous allons examiner de plus près ces fonctionnalités et voir comment elles peuvent nous aider à construire de meilleurs logiciels.

Commençons par explorer le «nouveau» PHP.

Classes, POO, SOLID et modèles de conception

Les classes et les objets ont été ajoutés à PHP 5, de sorte que WordPress utilise déjà ces fonctionnalités, mais pas de manière très complète ou exhaustive: Le paradigme du codage dans WordPress est principalement programmation fonctionnelle (effectuer des calculs en appelant des fonctions sans état d'application) au lieu de programmation orientée objet (OOP) (effectuer des calculs en manipulant l'état des objets). C’est pourquoi je décris également les classes et les objets et explique comment les utiliser dans le cadre de la programmation orientée objet.

La programmation orientée objet est idéale pour la production d’applications modulaires: les classes permettent de créer des composants, chacun pouvant implémenter une fonctionnalité spécifique et interagir avec d’autres personnalisation via ses propriétés encapsulées et encapsulées permettant un haut degré de réutilisation du code. Par conséquent, le test et la maintenance de l'application sont moins coûteux, car certaines fonctionnalités peuvent être isolées de l'application et traitées séparément; il y a aussi un gain de productivité puisque le développeur peut utiliser des composants déjà développés et éviter de réinventer la roue pour chaque application.

Une classe possède des propriétés et des fonctions qui peuvent être visionnées à l'aide de private ( accessible uniquement de l'intérieur de la classe de définition), protected (accessible de l'intérieur de la classe de définition et de ses ancêtres et classes héritières) et du public (accessible de partout). À partir d’une fonction, vous pouvez accéder aux propriétés de la classe en ajoutant leurs noms avec le préfixe $ this -> :

  protected $ name;
  
  fonction publique __construct ($ name) {
    $ this-> name = $ name;
  }

  fonction publique getIntroduction () {
    retour sprintf (
      __('Mon nom est s'),
      $ this-> nom
    )
  }
}

Une classe est instanciée en un objet à l'aide du mot clé new après quoi nous pouvons accéder à ses propriétés et fonctions via -> :

 $ person = new Person (' Pedro ');
echo $ person-> getIntroduction ();
// Ceci affiche "Mon nom est Pedro"

Une classe héréditaire peut annuler les fonctions publiques et protégées de ses classes ancêtres et accéder aux fonctions ancêtres en les ajoutant au préalable avec le nom parent :: : [19659021] class WorkerPerson étend Person {

  occupation protégée;
  
  fonction publique __construct ($ name, $ occupation) {

    parent :: __ construct ($ name);
    $ this-> occupation = $ occupation;
  }

  fonction publique getIntroduction () {
    retour sprintf (
      __ ('% s et ma profession est% s'),
      parent :: getIntroduction (),
      $ this-> occupation
    )
  }
}

$ worker = new WorkerPerson ('Pedro', 'développement Web');
echo $ worker-> getIntroduction ();
// This imprime "Mon nom est Pedro et mon métier est le développement web"

Une méthode peut être faite abstract ce qui signifie qu'elle doit être implémentée par une classe héritante. Une classe contenant une méthode abstract abstraite doit être faite abstract elle-même, ce qui signifie qu'elle ne peut pas être instanciée; seule la classe implémentant la méthode abstraite peut être instanciée:

 classe abstraite Person {
  
  fonction publique abstraite getName ();

  fonction publique getIntroduction () {
    retour sprintf (
      __('Mon nom est s'),
      $ this-> getName ()
    )
  }
}
// personne ne peut pas être instanciée

La classe Manuel étend Person {
  
  fonction publique getName () {
    retournez 'Manuel';
  }
}

// Manuel peut être instancié
$ manuel = new Manuel ();

Les classes peuvent également définir les méthodes et propriétés statiques qui vivent sous la classe elle-même et non sous une instanciation de la classe en tant qu'objet. On y accède par self :: depuis la classe et par le nom de la classe + :: de l’extérieur:

 class Factory {

  protected $ $ instances = [];
  Fonction statique publique registerInstance ($ handle, $ instance) {
    self :: $ instances [$handle] = $ instance;
  }
  fonction statique publique getInstance ($ handle) {
    return self :: $ instances [$handle];
  }
}

$ engine = Factory :: getInstance ('Engine');

Pour tirer le meilleur parti de la programmation orientée objet, nous pouvons utiliser les principes SOLID pour établir une base solide mais facilement personnalisable pour l'application, ainsi que des modèles de conception pour résoudre des problèmes spécifiques dans une manière éprouvée. Les modèles de conception sont normalisés et bien documentés, ce qui permet aux développeurs de comprendre les relations entre les différents composants de l’application et permet de structurer l’application de manière ordonnée, évitant ainsi l’utilisation de variables globales (telles que global. $ wpdb ) qui polluent l’environnement mondial.

Espaces de nommage

Les espaces de nommage ont été ajoutés à PHP 5.3 et sont donc totalement absents du noyau WordPress.

Les espaces de nommage permettent d’organiser structurellement la base de code. éviter les conflits lorsque différents éléments portent le même nom – de la même manière que les répertoires du système d'exploitation, qui permettent d'avoir différents fichiers portant le même nom tant qu'ils sont stockés dans des répertoires différents. Les espaces de noms utilisent la même astuce d'encapsulation pour les éléments PHP (tels que les classes, les traits et les interfaces) en évitant les collisions lorsque différents éléments portent le même nom en les plaçant sur différents espaces de noms.

Les espaces de noms sont indispensables pour les interactions avec les bibliothèques tierces, car nous ne pouvons pas contrôler la façon dont leurs éléments seront nommés, ce qui peut entraîner des conflits lors de l'utilisation de noms standard tels que «Fichier», «Enregistreur» ou «Téléchargeur» pour nos éléments. De plus, même au sein d'un même projet, les espaces de noms empêchent les noms de classe de devenir extrêmement longs, de manière à éviter les conflits avec d'autres classes, ce qui pourrait donner lieu à des noms tels que «MyProject_Controller_FileUpload».

Les espaces de noms sont définis à l'aide du mot clé . ] (placé sur la ligne immédiatement après l'ouverture <? php ) et peut s'étendre sur plusieurs niveaux ou espaces de sous-noms (similaire au fait d'avoir plusieurs sous-répertoires dans lesquels placer un fichier), qui sont séparés par un :

 <? Php
espace de noms CoolSoft  ImageResizer  Controllers;

class ImageUpload {

}

Pour accéder à la classe ci-dessus, nous devons qualifier pleinement son nom, y compris son espace de noms (et commençant par ):

 $ imageUpload = new  CoolSoft  ImageResizer  Controllers  ImageUpload ();

Nous pouvons également importer la classe dans le contexte actuel, après quoi nous pouvons directement référencer la classe par son nom:

utilisez CoolSoft  ImageResizer  Controllers  ImageUpload;
$ imageUpload = new ImageUpload ();

En nommant les espaces de noms conformément aux conventions établies, nous pouvons obtenir des avantages supplémentaires. Par exemple, en suivant la recommandation de normes PHP PSR-4 l’application peut utiliser le mécanisme de chargement automatique de Composer pour charger des fichiers, réduisant ainsi la complexité et ajoutant une interopérabilité sans friction entre dépendances. Cette convention établit l’inclusion du nom du fournisseur (par exemple, le nom de la société) en tant qu’espace de sous-nom supérieur, suivi éventuellement du nom du package, puis uniquement d’une structure interne dans laquelle chaque espace de sous-noms correspond à un répertoire portant le même nom. Le résultat mappe de 1 à 1 l'emplacement physique du fichier dans le lecteur avec l'espace de nom de l'élément défini dans le fichier.

Traits

Les caractères ont été ajoutés à PHP 5.4, ils sont donc totalement absents de le noyau WordPress.

PHP supporte l'héritage unique ainsi une sous-classe est dérivée d'une classe parente unique et non de plusieurs. Par conséquent, les classes qui ne s’étendent pas les unes des autres ne peuvent pas réutiliser du code par héritage de classe. Traits est un mécanisme qui permet une composition horizontale du comportement, ce qui permet de réutiliser du code parmi les classes qui vivent dans différentes hiérarchies de classes.

Un trait est similaire à une classe, mais il ne peut pas être instancié lui-même. Au lieu de cela, le code défini dans un trait peut être considéré comme «copié et collé» dans la classe de composition au moment de la compilation.

Un trait est défini à l'aide du mot-clé trait après quoi il peut être importés dans n'importe quelle classe par le biais du utilisez le mot-clé . Dans l'exemple ci-dessous, deux classes complètement indépendantes Person et Shop peuvent réutiliser le même code dans un trait Addressable :

 trait Addressable {

  protected $ address;
  
  fonction publique getAddress () {
    retourne $ this-> adresse;
  }
  
  fonction publique setAddress ($ address) {
    $ this-> address = $ address;
  }
}

classe Person {

  utiliser Addressable;
}

classe Shop {

  utiliser Addressable;
}

$ personne = nouvelle personne ('Juan Carlos');
$ person-> setAddress ('Obelisco, Buenos Aires');

Une classe peut également composer plus d'un trait:

 trait Exportable {
  
  Classe publique exportToCSV ($ filename) {
    // Itère toutes les propriétés et les exporte dans un fichier CSV
  }
}

classe Person {

  utiliser adressable, exportable;
}

Les traits peuvent aussi être composés d'autres traits définir des méthodes abstraites et offrir un mécanisme de résolution de conflit lorsque deux traits composés ou plus ont la même fonction nom, parmi autres fonctionnalités .

Les interfaces

Les interfaces ont été ajoutées à PHP 5, WordPress utilise donc déjà cette fonctionnalité avec une grande économie: le noyau inclut moins de dix interfaces. au total!

Les interfaces permettent de créer un code spécifiant les méthodes à implémenter, sans avoir à définir comment ces méthodes sont réellement implémentées. Ils sont utiles pour définir des contrats entre composants, ce qui conduit à une meilleure modularité et facilité de maintenance de l'application: une classe implémentant une interface peut être une boîte noire de code, et tant que les signatures des fonctions dans l'interface ne changent pas, le code peut être mis à jour à volonté sans produire de changements radicaux, ce qui peut aider à prévenir l’accumulation de dettes techniques. En outre, ils peuvent aider à réduire le verrouillage des fournisseurs en permettant d’échanger l’implémentation de certaines interfaces sur celles d’un autre fournisseur. En conséquence, il est impératif de coder l'application sur les interfaces plutôt que sur les implémentations (et définir quelles sont les implémentations réelles via l'injection de dépendance ).

Les interfaces sont définies à l'aide de l'interface . mot-clé, et doit répertorier uniquement la signature de ses méthodes (c'est-à-dire sans que leur contenu soit défini), qui doit avoir une visibilité publique (par défaut, l'ajout d'un mot-clé non-visibilité le rend également public):

 interface FileStorage {

  function save ($ nom du fichier, $ contenu);
  fonction readContents ($ filename);
}

Une classe définit qu'elle implémente l'interface par le biais du mot clé :

la classe LocalDriveFileStorage implémente FileStorage {

  fonction save ($ nomfichier, $ contenu) {
    // implémenter la logique
  }
  fonction readContents ($ filename) {
    // implémenter la logique
  }
}

Une classe peut mettre en oeuvre plusieurs interfaces en les séparant par :

 interface AWSService {
  fonction getRegion ();
}

La classe S3FileStorage implémente FileStorage, AWSService {

  fonction save ($ nomfichier, $ contenu) {
    // implémenter la logique
  }
  fonction readContents ($ filename) {
    // implémenter la logique
  }
  fonction getRegion () {
    retourne 'us-east-1';
  }
}

Puisqu'une interface déclare l'intention de ce qu'un composant est censé faire, il est extrêmement important de nommer correctement les interfaces .

Fermetures

Les fermetures ont été ajoutées à PHP 5.3, Par conséquent, elles sont actuellement totalement absentes du noyau WordPress.

Closures est un mécanisme permettant d'implémenter des fonctions anonymes qui permet de décombrer l'espace de noms global des fonctions à usage unique (ou rarement utilisées). Techniquement parlant, les fermetures sont des exemples de classe Closure . Cependant, dans la pratique, nous pouvons très probablement ne pas être conscients de ce fait sans subir de préjudice.

Avant les fermetures, chaque fois que nous transmettons une fonction en argument à un autre fonction, nous devions définir la fonction à l’avance et transmettre son nom en tant qu’argument:

 function duplicate ($ price) {
  retour $ prix * 2;
}
$ touristPrices = array_map ('duplicate', $ localPrices);

Avec les fermetures, une fonction anonyme (c'est-à-dire sans nom) peut déjà être passée directement en tant que paramètre:

 $ touristPrices = array_map (function ($ price) {
  retour $ prix * 2;
}, $ localPrices);

Les fermetures peuvent importer des variables dans son contexte via le mot clé :

 $ factor = 2;
$ touristPrices = array_map (function ($ price) utiliser ($ factor) {
  retour $ prix * $ facteur;
}, $ localPrices);

Les générateurs

Les générateurs ont été ajoutés à PHP 5.5 et sont donc totalement absents du noyau WordPress.

Les générateurs fournissent un moyen simple d'implémenter des itérateurs simples. Un générateur permet d'écrire du code qui utilise foreach pour parcourir un ensemble de données sans avoir à construire un tableau en mémoire. Une fonction de générateur est identique à une fonction normale, à la différence qu'au lieu de revenir une fois, elle peut générer autant de fois que nécessaire pour fournir les valeurs sur lesquelles on doit effectuer une itération.

 function xrange ($ start, $ limit, $ step = 1) {
    for ($ i = $ start; $ i 

Les déclarations de type d'argument et de retour

Différentes déclarations de type d'argument ont été introduites dans différentes versions de PHP: WordPress est déjà en mesure de déclarer des interfaces et des tableaux (qui ce n'est pas le cas: j'ai à peine trouvé une instance d'une fonction déclarant un tableau en tant que paramètre dans core, et aucune interface), et je serai bientôt en mesure de déclarer des callables (ajoutés en PHP 5.4) et des types scalaires: bool, float, int et string (ajouté dans PHP 7.0). Les déclarations de type de retour ont été ajoutées à PHP 7.0.

Les déclarations de type d'argument permettent aux fonctions de déclarer le type spécifique d'argument. La validation est exécutée au moment de l'appel. une exception si le type de l'argument n'est pas celui déclaré. Les déclarations de type de retour correspondent au même concept, mais elles spécifient le type de valeur qui sera renvoyé par la fonction. Les déclarations de type sont utiles pour simplifier l'intention de la fonction. comprendre et évite les erreurs d'exécution lors de la réception ou du renvoi d'un type inattendu.

Le type d'argument est déclaré avant le nom de variable d'argument et le type de retour est déclaré après les arguments, précédés de : :

 function foo (booléen $ bar): int {

}

Les déclarations de type d'argument scalaire ont deux options: coercitive et stricte. En mode coercitif, si le type incorrect est passé en tant que paramètre, il sera converti en un type correct. Par exemple, une fonction à laquelle un entier est attribué à un paramètre qui s'attend à une chaîne obtiendra une variable de type chaîne. En mode strict, seule une variable du type exact de déclaration sera acceptée.

Le mode coercitif est le mode par défaut. Pour activer le mode strict, nous devons ajouter une instruction declare utilisée avec la déclaration strict_types :

 declare (strict_types = 1);
fonction foo (booléen $ bar) {

}

Nouvelle syntaxe et opérateurs

WordPress peut déjà identifier des listes d’arguments de longueur variable par le biais de la fonction de func_num_args . À partir de PHP 5.6, nous pouvons utiliser le ... jeton indiquant que la fonction accepte un nombre variable d'arguments, qui seront ensuite transmis à la variable donnée sous forme de tableau:

 fonction sum (... $ numbers) {
  $ somme = 0;
  foreach ($ numbers sous forme de $ number) {
    $ somme + = nombre $;
  }
  retour $ somme;
}

À partir de à partir de PHP 5.6 les constantes peuvent impliquer des expressions scalaires impliquant des littéraux numériques et des chaînes de caractères au lieu de simples valeurs statiques, ainsi que des tableaux:

 const SUM = 37 + 2; // une expression scalaire
const LETTERS = ['a', 'b', 'c']; // Un tableau

À partir de à partir de PHP 7.0 les tableaux peuvent également être définis avec définissez :

: définissez ('LETTERS', ['a', 'b', 'c']);

PHP 7.0 a ajouté quelques nouveaux opérateurs: l'opérateur Null coalescing ( ?? ) et l'opérateur Vaisseau spatial () . [19659005] L'opérateur de coalescence Null est un sucre syntaxique pour le cas habituel d'utilisation d'un ternaire avec isset (). Il retourne son premier opérande s'il existe et n'est pas NULL; sinon, il retourne son deuxième opérande.

 $ username = $ _GET ['user'] ?? 'personne';
// Ceci est équivalent à:
// $ username = isset ($ _GET ['user'])? $ _GET ['user']: 'personne';

L'opérateur Spaceship est utilisé pour comparer deux expressions, renvoyant -1, 0 ou 1 lorsque le premier opérande est respectivement inférieur, égal ou supérieur au deuxième opérande.

 echo 1 2; // retourne -1
echo 1 1; // renvoie 0
echo 2 1; // retourne 1

Ce sont les nouvelles fonctionnalités les plus importantes ajoutées aux versions 5.3 à 7.0 de PHP. La liste des nouvelles fonctionnalités supplémentaires, non répertoriées dans cet article, peut être obtenue en consultant la documentation de sur la migration de version en version .

Nous analysons ensuite comment tirer le meilleur parti de toutes les fonctionnalités. ces nouvelles fonctionnalités et les tendances récentes du développement Web pour produire de meilleurs logiciels.

Recommandations relatives aux normes PHP

Les Recommandations relatives aux normes PHP ont été créées par un groupe de développeurs PHP issus de frameworks et de bibliothèques populaires, essayer d'établir des conventions afin que différents projets puissent être intégrés de manière plus transparente et que différentes équipes puissent mieux travailler les unes avec les autres. Les recommandations ne sont pas statiques: les recommandations existantes peuvent être obsolètes et de nouvelles peuvent être remplacées, et de nouvelles sont publiées en permanence.

Les recommandations actuelles sont les suivantes:

Penser et coder dans les composants

Les composants permettent d'utiliser les meilleures fonctionnalités d'un framework sans être verrouillés- dans le cadre lui-même. Par exemple, Symfony a été publié sous la forme d'un ensemble de composants PHP réutilisables pouvant être installés indépendamment du cadre Symfony ; Laravel un autre framework PHP, utilise plusieurs composants Symfony et a publié son propre ensemble de composants réutilisables utilisables par tout projet PHP.

] Tous ces composants sont publiés dans Packagist un référentiel de paquets PHP publics, et peuvent facilement être ajoutés à tout projet PHP via Composer un très populaire gestionnaire de dépendances pour PHP. 19659005] WordPress devrait faire partie d'un cycle de développement aussi vertueux. Malheureusement, le noyau WordPress lui-même n'est pas construit à l'aide de composants (comme en témoigne l'absence presque totale d'interfaces) et, de plus, il n'a même pas le fichier composer.json requis pour permettre l'installation de WordPress via Composer . Ceci est dû au fait que la communauté WordPress n'a pas convenu si WordPress est une dépendance d'un site (dans ce cas, son installation via Composer serait justifiée) ou s'il s'agit du site lui-même (dans ce cas, Composer n'est pas le

À mon avis, si nous devons nous attendre à ce que WordPress reste pertinent pour les quinze prochaines années (au moins WordPress en tant que CMS backend), alors WordPress doit être reconnu comme une dépendance du site. et mis à disposition pour installation via Composer . La raison est très simple: avec à peine une seule commande dans le terminal, Composer permet de déclarer et d'installer les dépendances d'un projet parmi les milliers de paquets publiés dans Packagist, ce qui permet de créer rapidement des applications PHP extrêmement puissantes, ce que les développeurs adorent travailler de cette façon. Si WordPress ne s'adapte pas à ce modèle, il risque de perdre le soutien de la communauté de développement et de sombrer dans l'oubli, tout comme FTP n'est pas devenu populaire après l'introduction des déploiements basés sur Git.

Je dirais que la publication de Gutenberg démontre déjà que WordPress est une dépendance de site et non pas le site lui-même: Gutenberg considère WordPress comme un CMS sans tête, et peut également fonctionner avec d'autres systèmes dorsaux, comme le montre l'exemple de Drupal Gutenberg . Par conséquent, Gutenberg indique clairement que le système de gestion de contenu (CMS) alimentant un site peut être échangé et qu'il doit donc être traité comme une dépendance. De plus, Gutenberg lui-même est destiné à être basé sur des composants JavaScript publiés via npm (comme l'explique l'exploitant principal Adam Silverstein ), de sorte que le client WordPress doit gérer ses packages JavaScript via le gestionnaire de paquets npm, alors pourquoi ne pas étendre cette logique au backend afin de gérer les dépendances de PHP via Composer?

Maintenant la bonne nouvelle: il n'est pas nécessaire d'attendre que ce problème soit résolu, car il est déjà possible de le traiter. WordPress en tant que dépendance d'un site et installez-le via Composer. John P. Bloch a mis en miroir le noyau WordPress dans Git ajouté un fichier composer.json, et l'a publié dans Packagist et de Roots 'Bedrock fournit un paquet contenant Installez WordPress avec une structure de dossiers personnalisée prenant en charge les outils de développement modernes et une sécurité renforcée. Et les thèmes et les plugins sont également couverts; tant qu'ils ont été répertoriés dans les répertoires de plug-in du thème et de WordPress ils sont disponibles sous WordPress Packagist . En conséquence, il s'agit d'un option judicieuse pour créer du code WordPress ne pensant pas en termes de thèmes et de plugins, mais en termes de composants, les rendant disponibles par le biais de Packagist pour être utilisés par tout projet PHP, et également packagés et publiés en tant que thèmes et plugins pour une utilisation spécifique de WordPress . Si le composant doit interagir avec les API WordPress, alors ces API peuvent être abstraites derrière une interface qui, le cas échéant, peut également être implémentée pour d'autres CMS.

Ajout d'un moteur de modèle pour améliorer le View Layer

Si nous suivons la recommandation de penser et de coder des composants et si nous considérons WordPress comme une dépendance de site autre que le site lui-même, nos projets peuvent alors s'affranchir des limites imposées par WordPress et importer des idées et des outils extraits de d'autres frameworks.

Le rendu de contenu HTML côté serveur est un exemple typique, réalisé à l'aide de modèles PHP simples. Cette couche d'affichage peut être améliorée grâce aux moteurs de modèles Twig (de Symfony) et Blade (de Laravel), qui fournissent une syntaxe très concise et des fonctionnalités puissantes qui lui confèrent un avantage par rapport à PHP. modèles. En particulier, les blocs dynamiques de [Gutenberg] peuvent facilement tirer parti de ces moteurs de gabarit, car leur processus de restitution du code HTML du bloc côté serveur est découplé de l'architecture de hiérarchie des gabarits de WordPress.

Architecte L'application pour le Utilisation générale

Le codage par rapport aux interfaces, et la pensée en termes de composants, nous permettent d’archiver une application pour une utilisation générale et de la personnaliser pour l’utilisation spécifique que nous devons fournir, au lieu de coder uniquement pour l’utilisation spécifique de chaque projet. avoir. Même si cette approche est plus coûteuse à court terme (elle nécessite un travail supplémentaire), elle est payante à long terme lorsque des projets supplémentaires peuvent être réalisés avec un effort moindre en personnalisant simplement une application à usage général.

Pour être efficace, les considérations suivantes doivent être prises en compte:

Évitez les dépendances fixes (autant que possible)

jQuery et Bootstrap (ou Foundation, ou ) auraient pu être considérées comme indispensables quelques années Cependant, il y a bien longtemps, ils ont constamment perdu du terrain face à JS vanilla et aux nouvelles fonctionnalités CSS natives. Par conséquent, un projet d'usage général codé il y a cinq ans et dépendant de ces bibliothèques risque de ne plus convenir de nos jours. Par conséquent, en règle générale, plus le nombre de dépendances fixes sur des bibliothèques tierces est faible, plus elles seront à jour à long terme.

Amélioration progressive des fonctionnalités

WordPress est un système de gestion de contenu complet qui inclut la gestion des utilisateurs; par conséquent, le support pour la gestion des utilisateurs est inclus. Cependant, tous les sites WordPress ne nécessitent pas une gestion des utilisateurs. Par conséquent, notre application doit en tenir compte et fonctionner de manière optimale sur chaque scénario: prenez en charge la gestion des utilisateurs chaque fois que nécessaire, mais ne chargez pas les actifs correspondants lorsque ce n'est pas le cas. Cette approche peut également fonctionner progressivement: disons qu'un client doit implémenter un formulaire Contactez-nous mais qu'il n'a pas de budget; nous le codons donc à l'aide d'un plugin gratuit doté de fonctionnalités limitées, et un autre client dispose du budget nécessaire pour acheter la licence à partir d'une offre de plugins commerciaux. de meilleures fonctionnalités. Ensuite, nous pouvons coder nos fonctionnalités pour adopter une fonctionnalité très basique, et utiliser de plus en plus les fonctionnalités du plug-in le plus performant disponible dans le système.

Revue continue du code et de la documentation

En passant en revue nos versions précédentes. code écrit et sa documentation, nous pouvons valider s’il est à jour en ce qui concerne les nouvelles conventions et technologies et, si ce n’est pas le cas, prendre des mesures pour le mettre à niveau avant que la dette technique ne devienne trop coûteuse et que nous devions la coder. tout recommence à zéro.

Lectures recommandées : Soyez vigilant: Fonctions PHP et WordPress pouvant nuire à la sécurité de votre site

Essayez de minimiser les problèmes mais soyez préparé quand ils se produisent

Aucun logiciel n'est jamais parfait à 100%: les bugs sont toujours présents, nous ne les avons pas encore trouvés. En tant que tel, nous devons nous assurer que, une fois que les problèmes surviennent, ils sont faciles à résoudre.

Make It Simple

Les logiciels complexes ne peuvent pas être conservés à long terme: pas seulement parce que d'autres membres de l'équipe ne le comprennent pas. , mais aussi parce que la personne qui l’a codé peut ne pas comprendre son propre code complexe dans quelques années. Donc, produire un logiciel simple doit être une priorité, plus que seul un logiciel simple peut être correct et rapide .

Echec de la compilation est meilleur que l'exécution

Si un élément de code peut être validé erreurs lors de la compilation ou de l'exécution, nous devons alors hiérarchiser la solution de compilation, afin que l'erreur puisse survenir et être traitée au stade du développement et avant que l'application n'atteigne la production. Par exemple, const et définir sont tous deux utilisés pour définir les constantes, alors que const est validée au moment de la compilation, define est validée à l'exécution. So, whenever possible, using const is preferable over define.

Following this recommendation, hooking WordPress functions contained in classes can be enhanced by passing the actual class as a parameter instead of a string with the class name. In the example below, if class Foo is renamed, whereas the second hook will produce a compilation error, the first hook will fail on runtime, hence the second hook is better:

class Foo {
  public static function bar()

  }
}

add_action('init', ['Foo', 'bar']); // Not so good
add_action('init', [Foo::class, 'bar']); // Much better

For the same reason as above, we should avoid using global variables (such as global $wpdb): these not only pollute the global context and are not easy to track where they originate from, but also, if they get renamed, the error will be produced on runtime. As a solution, we can use a Dependency Injection Container to obtain an instance of the required object.

Dealing With Errors/Exceptions

We can create an architecture of Exception objectsso that the application can react appropriately according to each particular problem, to either recover from it whenever possible or show a helpful error message to the user whenever not, and in general to log the error for the admin to fix the problem. And always protect your users from the white screen of death: All uncaught Errors and Exceptions can be intercepted through function set_exception_handler to print a non-scary error message on screen.

Adopt Build Tools

Build tools can save a lot of time by automating tasks which are very tedious to execute manually. WordPress doesn’t offer integration with any specific build tool, so the task of incorporating these to the project will fall entirely on the developer.

There are different tools for accomplishing different purposes. For instance, there are build tools to execute tasks for compressing and resizing images, minifying JS and CSS files, and copying files to a directory for producing a release, such as WebpackGrunt and Gulp; other tools help create the scaffolding of a project, which is helpful for producing the folder structure for our themes or plugins, such as Yeoman. Indeed, with so many tools around, browsing articles comparing the different available tools will help find the most suitable one for our needs.

In some cases, though, there are no build tools that can achieve exactly what our project needs, so we may need to code our own build tool as an extension to the project itself. For instance, I have done this to generate the service-worker.js file to add support for Service Workers in WordPress.

Conclusion

Due to its strong emphasis on keeping backwards compatibility, extended even up to PHP 5.2.4, WordPress has not been able to benefit from the latest features added to PHP, and this fact has made WordPress become a not-very-exciting platform to code for among many developers.

Fortunately, these gloomy days may soon be over, and WordPress may become a shiny and exciting platform to code for once again: The requirement of PHP 7.0+ starting in December 2019 will make plenty of PHP features available, enabling developers to produce more powerful and more performant software. In this article, we reviewed the most important newly-available PHP features and how to make the most out of them.

The recent release of Gutenberg could be a sign of the good times to come: even if Gutenberg itself has not been fully accepted by the community, at least it demonstrates a willingness to incorporate the latest technologies (such as React and Webpack) into the core. This turn of events makes me wonder: If the frontend can get such a makeover, why not extend it to the backend? Once WordPress requires at least PHP 7.0, the upgrade to modern tools and methodologies can accelerate: As much as npm became the JavaScript package manager of choice, why not making Composer become the official PHP dependency manager? If blocks are the new unit for building sites in the frontend, why not use PHP components as the unit for incorporating functionalities into the backend? And finally, if Gutenberg treats WordPress as a swappable backend CMS, why not already recognize that WordPress is a site dependency and not the site itself? I’ll leave these open questions for you to reflect upon and ponder about.

(rb, ra, il)