L'une des principales raisons de la popularité continue de WordPress est la facilité avec laquelle il peut être étendu et personnalisé avec des plug-ins.
Construire un plugin peut sembler être une tâche impossible, mais c'est plus simple que vous ne le pensez. Aujourd'hui, nous commençons notre série "Construire votre premier plugin WordPress" qui couvrira les principes les plus importants et les procédures du processus.
À la fin de la série, vous serez prêt à faire de nouvelles expériences, en vous appuyant sur les meilleures pratiques et conventions adoptées par la vaste communauté WordPress.
C'est un script PHP qui modifie ou étend la fonctionnalité native de WordPress.
En fournissant un outil très simple mais flexible API du plugin , WordPress fournit à chaque développeur les avantages suivants pour l’utilisation des plugins:
Quelle que soit votre expérience de codage PHP - vous avez vraiment écrit son premier plug-in juste après avoir terminé un livre "PHP for Dummies" - vous êtes à deux doigts de créer votre premier plug-in pour WordPress. Faisons ce pas ensemble.
La tâche principale que nous allons explorer aujourd'hui est de construire une base de plugin solide. Cette fondation doit répondre aux exigences de WordPress et rendre le plugin reconnaissable par le noyau. Dans le même temps, il convient de suivre les pratiques et les conventions communes, acceptées par la communauté, afin d’éviter les conflits éventuels avec d’autres plug-ins pouvant être installés sur un site.
Tout d'abord, vous devez vous assurer que le nom de votre plugin est unique. Même si vous n'allez pas faire de votre travail une version publique, vous devez au moins être sûr qu'il n'y a aucune possibilité que votre propre site utilise deux plug-ins portant le même nom. Le simple référentiel de plugins (et Google) est votre ami quand vous évitez le mauvais choix.
Pour augmenter la probabilité qu'un nom soit unique, de nombreux développeurs créent le préfixe de la marque, qui est l'abréviation du nom du développeur (ou du surnom). Ce préfixe avec une brève référence au nom du plug-in devrait ensuite être utilisé partout - dans les noms de fichiers, les fonctions, les classes, les variables, etc.
Commençons par un exemple. Nous adoptons le nom "Hello World Plugin" et pour augmenter les chances d'être unique, nous utilisons "My super prefix" converti en abréviation "MSP". Ce qui nous donne le nom vraiment unique "MSP Hello World Plugin"; La recherche dans le référentiel de plug-ins confirme que personne d'autre ne l'utilise.
Notre prochaine étape consiste à créer les fichiers du plugin. Il est fortement recommandé de les stocker dans un dossier séparé dans un dossier de plug-in dédié. Ce dossier doit être nommé conformément au plugin lui-même. Dans notre cas, il pourrait s'agir de 'msp-helloworld'. Le dossier doit inclure le fichier principal du plug-in portant le même nom: «msp-helloworld.php».
le WordPress Codex recommande également que vous incluez un fichier readme.txt. Ce fichier contient les informations sur votre plugin dans un format standardisé . Si vous envisagez de soumettre votre plug-in au référentiel WordPress, l'existence du fichier readme.txt est obligatoire. Mais n'y pensez pas comme un fardeau, il y a beaucoup d'avantages à le faire.
Si votre plugin est supposé avoir plusieurs fichiers ou charger des fichiers (images, fichiers css et js), ils doivent être organisés en sous-dossiers. Une organisation appropriée des fichiers est un signe de travail professionnel. Vous pouvez vous fier au modèle suivant:
Chaque plugin doit avoir l'obligation entête . Il aide WordPress à reconnaître le script en tant que plug-in valide et à afficher des informations correctes sur l'écran de gestion des plug-ins.
Cet en-tête est un bloc de commentaire PHP situé en haut du fichier du plugin principal:
/*Plugin Name: MSP Hello WorldDescription: Create hello world messageVersion: 1.0Author: Author's nameAuthor URI: http://authorsite.com/Plugin URI: http://authorsite.com/msp-helloworld*/
Les informations de l'en-tête seront présentées dans la ligne correspondante du plug-in sur l'écran de gestion.
L'ordre des lignes n'est pas important, mais le fichier doit être codé en UTF-8.
Notez qu'il est important d'être cohérent avec le modèle de numérotation de version que vous avez choisi (egxxx), pour que le mécanisme de mise à niveau de WordPress le détecte correctement.
Jusqu'à présent, nous avons créé différents fichiers pour notre plugin (dans des sous-dossiers appropriés), nous devons maintenant déterminer les chemins (ou URL) appropriés dans le code du plug-in. Compte tenu du fait que le dossier wp-content pourrait être déplacé de son emplacement par défaut, il devient clair que les chemins d'accès aux fichiers de plug-in ne doivent pas être codés en dur, mais doivent plutôt être détectés.
WordPress a deux fonctions, plugin_dir_path et plugin_dir_url pour résoudre le problème, mais nous pouvons aller plus loin en utilisant l'astuce suivante:
define('MSP_HELLOWORLD_DIR', plugin_dir_path(__FILE__));define('MSP_HELLOWORLD_URL', plugin_dir_url(__FILE__));
Avec ce petit extrait (inclus dans le fichier principal du plugin), nous détectons le chemin et l’URL du dossier de notre plugin dans l’installation de WordPress et nous les assignons aux constantes appropriées. Après cela, nous pouvons utiliser ces constantes en combinaison avec les chemins relatifs connus des sous-dossiers, par exemple MSP_HELLOWORLD_DIR.'assets/img/image.jpg'
.
En utilisant ces constantes, nous pouvons également facilement inclure des fichiers de plug-ins de sous-dossiers dans le fichier principal:
function msp_helloworld_load(){if(is_admin()) //load admin files only in adminrequire_once(MSP_HELLOWORLD_DIR.'includes/admin.php');require_once(MSP_HELLOWORLD_DIR.'includes/core.php');}msp_helloworld_load();
Après l'installation, notre plugin pourrait être actif ou inactif.
L'état actif signifie qu'il a été activé par l'utilisateur et que son code sera exécuté par WordPress chaque fois qu'une page est demandée.
Le plug-in peut également être désactivé par l'utilisateur, ce qui signifie que les fichiers sont conservés à leur place, mais que le code n'est pas exécuté.
(Le plugin pourrait également être complètement désinstallé par un utilisateur, ce qui signifie que les fichiers sont supprimés du dossier plugins.)
WordPress peut détecter les modifications apportées à ces états et exécuter du code planifié pour de telles modifications. Si un code est programmé pour l'activation ou la désactivation, il ne sera exécuté qu'à ce moment-là, pas à chaque chargement de page.
Par exemple, si le plug-in est censé manipuler avec des règles de réécriture, il doit les effacer lors de l'activation / désactivation. Si le plug-in crée des entrées dans une base de données, par exemple en stockant des options, il est recommandé de les supprimer lorsque le plug-in est désinstallé.
Comment ceci peut être fait?
Pour les actions d'activation et de désactivation, nous pouvons enregistrer un "crochet d'activation" et un "crochet de désactivation". Ils sont juste un morceau de code qui dit à WordPress d'exécuter une fonction particulière sur l'activation et une autre fonction particulière sur la désactivation. Voici un exemple d'un tel code:
register_activation_hook(__FILE__, 'msp_helloworld_activation');register_deactivation_hook(__FILE__, 'msp_helloworld_deactivation');function msp_helloworld_activation() {//actions to perform once on plugin activation go here}function msp_helloworld_deactivation() {// actions to perform once on plugin deactivation go here}
Pour les actions de désinstallation, nous avons deux alternatives.
Une option consiste à créer un fichier uninstall.php dans le dossier du plugin (avec le fichier principal du plugin et le fichier readme.txt) et à y inclure tous les codes requis. Si un uninstall.php existe, WordPress l'exécutera automatiquement lorsque le plug-in sera supprimé par l'utilisateur. Alternativement, nous pouvons enregistrer un hook de désinstallation de la même manière que nous l'avons fait avec les hooks d'activation et de désactivation. La partie la plus délicate consiste à l'appeler une seule fois, lors de l'activation. Voici un exemple:
register_activation_hook(__FILE__, 'msp_helloworld_activation');function msp_helloworld_activation() {//actions to perform once on plugin activation go here//register uninstallerregister_uninstall_hook(__FILE__, 'msp_helloworld_uninstall');}function msp_helloworld_uninstall(){//actions to perform once on plugin uninstall go here}
Il est important de savoir que seule l'une des alternatives décrites fonctionnera: si uninstall.php existe, il sera exécuté et aucun crochet de désinstallation ne sera déclenché.
Résumant tout ce qui précède, voici un aperçu de la création d'une base solide pour un plugin WordPress:
Après toutes ces étapes, vous êtes prêt à créer votre plug-in en créant son code. Nous allons nous familiariser avec certains concepts utiles qui rendent les plugins WordPress excitants et flexibles dans le prochain article de cette série. Mais certains aspects importants peuvent être mis en évidence dès maintenant:
J'espère que cette introduction vous incitera à commencer à développer avec WordPress. Recherchez la prochaine partie de la série dans un avenir proche.
Quels conseils ajouteriez-vous à cette introduction? Que voudriez-vous voir couvert dans le prochain article de la série? Faites le nous savoir dans les commentaires!