Voici quelques bonnes pratiques pour vous aider à organiser votre code afin qu’il fonctionne bien avec le noyau WordPress et d’autres plugins WordPress

1- Éviter les collisions de noms

Une collision de noms se produit lorsque votre plugin utilise le même nom pour une variable, une fonction ou une classe qu’un autre plugin. Heureusement, vous pouvez éviter les collisions de noms en utilisant les méthodes ci-dessous.

a- Méthode de codage procédural

Par défaut, toutes les variables, fonctions et classes sont définies dans l’ espace de noms global , ce qui signifie qu’il est possible pour votre plugin de remplacer les variables, fonctions et classes définies par un autre plugin et vice-versa. Les variables définies à l’intérieur des fonctions ou des classes ne sont pas affectées par cela.

b- Préfixer tout

Toutes les variables, fonctions et classes doivent être précédées d’un identifiant unique. Les préfixes empêchent d’autres plugins d’écraser vos variables et d’appeler accidentellement vos fonctions et classes. Cela vous empêchera également de faire la même chose.

c- Vérifier les implémentations existantes

PHP fournit un certain nombre de fonctions pour vérifier l’existence de variables, de fonctions, de classes et de constantes. Tous ces éléments renvoient true si l’entité existe.

• Variables : isset() (comprend des tableaux, des objets, etc.)
• Fonctions : function_exists()
• Classes : class_exists()
• Constantes : définies()

Exemple :

2-Méthode de programmation orientée objet

Un moyen plus simple de résoudre le problème de collision de noms consiste à utiliser une classe pour le code de votre plugin. Vous devrez tout de même vous occuper de vérifier si le nom de la classe que vous voulez est déjà pris mais le reste sera pris en charge par PHP.

Exemple :

3- Organisation des fichiers

Le niveau racine de votre répertoire de plugin doit contenir votre fichier plugin-name.php et, éventuellement, votre fichier uninstall.php . Tous les autres fichiers doivent être organisés en sous-dossiers dans la mesure du possible.

4- Structure des dossiers

Une structure de dossiers claire vous aide, ainsi que les autres personnes travaillant sur votre plugin, à conserver ensemble des fichiers similaires. Voici un exemple de structure de dossiers pour référence :

/nom-du-
plugin nom-du-plugin.php
uninstall.php
/languages
/includes
/admin
/js
/css
/images
/public
/js
/css
/images

a- Architecture des plugins

L’architecture, ou l’organisation du code, que vous choisissez pour votre plugin dépendra probablement de la taille de votre plugin.
Pour les petits plugins à usage unique qui ont une interaction limitée avec le noyau WordPress, les thèmes ou d’autres plugins, il y a peu d’avantages à concevoir des classes complexes ; à moins que vous ne sachiez que le plugin va se développer considérablement plus tard.
Pour les gros plugins avec beaucoup de code, commencez par les classes à l’esprit. Séparez les fichiers de style et de scripts, et même les fichiers liés à la construction. Cela aidera à l’organisation du code et à la maintenance à long terme du plugin.

b- Chargement conditionnel

Il est utile de séparer votre code administrateur du code public. Utilisez la condition is_admin() . Vous devez toujours effectuer des vérifications de capacité car cela n’indique pas que l’utilisateur est authentifié ou dispose d’un accès de niveau administrateur. Voir Vérification des capacités de l’utilisateur .

Exemple :

5-Modèles architecturaux

Bien qu’il existe un certain nombre de modèles d’architecture possibles, ils peuvent être regroupés en trois variantes :

• Fichier de plugin unique, contenant des fonctions
• Fichier de plugin unique, contenant une classe, un objet instancié etéventuellement des fonctions
• Fichier de plugin principal, puis un ou plusieurs fichiers de classe

6- Modèles d’architecture expliqués

Des implémentations spécifiques des organisations de code les plus complexes ci-dessus ont déjà été rédigées sous forme de didacticiels et de diapositives :

• Slash – Singletons, chargeurs, actions, écrans, gestionnaires

• Implémentation du modèle MVC dans les plugins WordPress

7- Points de départ standard

Au lieu de repartir de zéro pour chaque nouveau plugin que vous écrivez, vous voudrez peut-être commencer par un passe- partout . L’un des avantages de l’utilisation d’un passe-partout est d’avoir une cohérence entre vos propres plugins. Les plaques passe-partout permettent également à d’autres personnes de contribuer plus facilement à votre code si vous utilisez une plaque passe-partout avec laquelle elles sont déjà familières.
Ceux-ci servent également d’autres exemples d’architectures différentes mais comparables.

• WordPress Plugin Boilerplate : Une base pour le développement de plugins WordPress qui vise à fournir un guide clair et cohérent pour la construction de vos plugins.
• WordPress Plugin Bootstrap : Bootstrap de base pour développer des plugins WordPress en utilisant Grunt, Compass, GIT et SVN.
• WP Skeleton Plugin : Plugin squelette qui se concentre sur les tests unitaires et l’utilisation de composer pour le développement.
• WP CLI Scaffold : La commande Scaffold de WP CLI créer un plugin squelette avec des options telles que les fichiers de configuration CI

Bien sûr, vous pouvez prendre différents aspects de ceux-ci et d’autres pour créer votre propre passe-partout personnalisé.

CONCLUSION

Pour conclure, pour créer un site Web, vous devez être à la fois développeur et concepteur. Ce n’est qu’après avoir compris les deux que vous pourrez travailler à l’amélioration de l’expérience utilisateur, ce qui est l’objectif ultime. Assurez-vous de respecter les normes de codage, de suivre les tendances et d’assurer la lisibilité de vos codes ainsi que du contenu Web pour être sur la bonne voie lors du développement de vos compétences.

Source: https://developer.wordpress.org/plugins/plugin-basics/best-practices/