WordPress est un dinosaure. Si vous êtes un programmeur PHP et que vous avez possibilité de travailler en dehors de WordPress au cours des 10 dernières années, il y a probablement une ou deux ou quelques dizaines de choses qui vous frustrent lorsque vous replongez dans la base de code du projet vieille de 16 ans. À une époque où WordPress offre aux programmeurs JavaScript les dernières nouveautés, ceux qui font du travail PHP peuvent se sentir laissés pour compte.

Il y a une bonne raison pour le code hérité dans WordPress: il est rétrocompatible avec plus d’une décennie d’extensions tierces. Plus, vieux le code ne correspond pas nécessairement à mal code. Si ce n’est pas cassé – tu sais comment ça se passe.

L’année dernière, WordPress dépassé l’exigence minimale pour exécuter le logiciel en PHP 5.6 ou plus récent. De nombreux développeurs ont applaudi les fonctionnalités telles que la syntaxe de tableau court, l’espace de noms et l’opérateur de propagation. D’autres voulaient passer à PHP 7+, mais PHP 5.6 était un bon tremplin vers un code PHP plus moderne.

Ce changement a ouvert de nouvelles questions. Quand WordPress de base commencera-t-il à utiliser de nouvelles fonctionnalités? Quelles normes de codage le projet devrait-il suivre?

WordPress 5.3 a utilisé la nouvelle opérateur de diffusion, qui a nettoyé et simplifié plusieurs fonctions. Cela a montré une volonté des principaux conducteurs de mettre à jour du code obsolète tout en évitant les problèmes de compatibilité descendante.

Un ensemble de normes mis à jour

Pour commencer à utiliser les fonctionnalités PHP modernes dans WordPress, les normes de codage de la plate-forme doivent évoluer. Le 20 mars, Juliette Reinders Folmer a proposé un ensemble complet de lignes directrices. La proposition est un projet et devra être affinée en fonction des commentaires des développeurs et des principaux contributeurs.

«Bien qu’il puisse s’écouler un certain temps avant que certaines de ces fonctionnalités ne soient réellement adoptées pour être utilisées dans WordPress Core», a écrit Folmer, «définir les normes de codage à l’avance permettra une base de code cohérente lorsqu’elles seront adoptées et permettra des plugins et des thèmes, qui ne sont pas nécessairement liés au minimum PHP 5.6, pour préserver la cohérence de leur code lorsqu’ils commencent déjà à utiliser un PHP plus moderne. »

Les normes proposées sont réparties selon les thèmes suivants:

  • Déclarations d’espace de noms
  • Importation use déclarations
  • Traits et interfaces
  • Déclarations de type
  • Déclarer les déclarations / typage strict
  • le ::class constant
  • Les opérateurs
  • Nouvelles règles supplémentaires couvrant divers articles

Tout code qui va directement dans WordPress doit suivre les normes de codage du projet. Il est fortement recommandé que les développeurs de plugins et de thèmes adoptent les mêmes normes, mais il n’est pas obligatoire de les inclure dans les répertoires officiels de plugins et de thèmes. Les normes de codage à travers un écosystème permettent à un développeur de récupérer plus facilement le code d’autres développeurs sans avoir à apprendre des styles uniques entre les extensions.

Dans l’ensemble, la mise à jour semble solide. Il y a beaucoup à aimer dans cette proposition, et ce serait un ajout bienvenu à un ensemble de directives qui avait cruellement besoin d’un rafraîchissement.

L’un de mes plus gros reproches concerne la dénomination des fichiers. Le projet WordPress devrait abandonner l’utilisation de class-, interface-, et trait- préfixes des noms de fichiers PHP. Au lieu de cela, nous devons saisir cette occasion pour adopter le Norme de chargement automatique du PSR-4 convention de dénomination. Dans cette norme, le nom de fichier correspond exactement au nom de la classe, de l’interface ou du trait. À tout le moins, les noms de fichiers préfixés ne devraient pas être une recommandation qui va aux développeurs WordPress partout. Conservez-le pour le cœur si nécessaire pour la tradition, mais ne recommandez pas l’utilisation généralisée d’un système qui est des années déconnecté du PHP moderne.

J’aimerais également que WordPress adopte l’utilisation du cas Pascal (c’est-à-dire, ExampleProject) sur des casquettes de chameau (c.-à-d. Example_Project) pour les espaces de noms. Cependant, étant donné la tradition des casquettes de chameau pour les noms de classe, je ne vois pas cela changer. C’est un peu difficile, mais cela semble hors de propos par rapport à d’autres projets PHP plus modernes.

La plus grande chose que la communauté des développeurs WordPress puisse faire en ce moment est de discuter de la proposition et de faire part de ses commentaires. La plupart du travail est fait. C’est à la communauté de l’aider à aller de l’avant.


Source link