Codex

Interested in functions, hooks, classes, or methods? Check out the new WordPress Code Reference!

User:Guigui/DevPlug

Page d'accueil du Codex en français - Télécharger WordPress en français
Les utilisateurs francophones se retrouvent sur le site WordPress-Francophone, notamment sur son forum d'entraide.

This page is marked as incomplete. You can help Codex by expanding it.

Introduction

L'objectif principal de l'utilisation des plugins est de maintenir le noyau de Wordpress intact, dans un soucis de stabilité et de mise à jour des futures versions.

Définition

Un plugin WordPress est un programme, écrit en langage PHP, permettant d'ajouter des fonctionnalités personnalisés à Wordpress.

Ressources

  • Il existe une multitude d'articles et de ressources pour les développeurs de plugins dans la section Plugin Resources
  • Une bonne méthode pour comprendre le fonctionnement des plugins, est de regarder le code source du plugin suivant : Hello Dolly, installé par défaut sur wordpress
  • Faites la promotion de votre plugin sur le site Plugin Submission and Promotion

Créer un plugin

Le nom du plugin

Veillez à ce que le nom de votre plugin soit unique (voir la liste des plugins déposés Plugins ) La plupart des développeurs choisissent un nom en rapport avec la description du plugin, ce nom peut avoir plusieurs mots.

Les fichiers

Encore une fois, choisissez un nom unique (pour éviter les conflits de doublons) en utilisant la convention de nommage des variables: - 1ère lettre en minuscule. - Majuscule avec la première lettre de chaque mot. - ex: superPlugin.php

Votre plugin peut contenir plusieurs fichiers, dans ce cas il faut mettre ces fichiers dans un répertoire du même nom que votre fichier principal. ex: wp-content/plugins/superPlugin/superPlugin.php...

Fichier lisez moi

Si vous voulez diffuser votre plugin sur le site de wordpress http://wordpress.org/extend/plugins/, vous devez créer un fichier readme.txt dans un format standardisé, et l'inclure dans votre plugin. Voir http://wordpress.org/extend/plugins/about/readme.txt pour une description du format à respecter.

Informations en-tête

Votre fichier php principal doit contenir en en-tête, les informations concernant votre plugin. Celui-ci permettra à wordpress de localiser son existence, il pourra ainsi être activé dans l'administration des plugins. Sans cet en-tête, votre plugin ne pourra pas fonctionner

Exemple:

<?php
/*
Plugin Name: Nom du Plugin
Plugin URI: http://adresseContenantLesInfosSurVotrePlugin
Description: Courte description du plugin.
Version: La version du plugin.
Author: Nom de l'auteur
Author URI: http://siteWebAuteur
*/
?>

License

Faites suivre l'en-tête du fichier par les informations de licence. Dans la plupart des cas les plugins sont développés sous GPL GPL ou bien compatible with the GPL.

Pour cela utilisez la convention suivante:

<?php
/*  Copyright ANNEE  NOM_AUTEUR_DU_PLUGIN  (email : EMAIL_AUTEUR)

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
*/
?>

WordPress Plugin Hooks

Beaucoup de plugins accomplissent leurs tâches en se connectant à un ou plusieurs évènement de WordPress via les "hooks". La manière dont fonctionne les "hooks" est la suivante : chaque fois qu'un évènement ou qu'une action est réalisés, WordPress vérifie si une fonction a été enregistré par un plugin sur cette évènement et l'exécute le cas échéant. Ces fonctions modifie donc le fonctionnement de WordPress.

Par exemple, avant d'ajouter le titre d'un article dans le navigateur, WordPress va vérifier si un plugin a enregistré une fonction pour le "filtre" appelé "the_title". Si c'est le cas, le texte du titre est passé à chaque fonction enregistrés et le résultat final est affiché. Par conséquent, si votre plugin a besoin d'ajouter des information au titre affiché, il peut enregistre une fonction de filtrage sur "the_title".

Un autre exemple est "l'action" appelé "wp_footer". Juste avant de générer la fin d'une page HTML, WordPress vérifie si une fonction a été enregistré par un plugin sur l'action "wp_footer" et l'exécute le cas échéant.

Vous pouvez en apprendre plus sur les "actions" et les "filtrer" dans Plugin API. Si vous trouver un endroit dans le code de WordPress où vous voudriez voir une action ou un filtre mais que WordPress ne les fournit pas vous pouvez également suggérer un nouvel "hook" (les suggestion sont généralement prisent en compte); voyez Reporting Bugs pour ça.

Template Tags

Un autre moyen pour un plugin d'ajouter une fonctionnalité à WordPress consiste à créer un Template Tags. Celui qui voudra alors utiliser votre plugin pourra ajouter ce "tag" dans son thème, dans la sidebar, la section de contenue des articles, ou n'importe où cela est approprié. Par exemple, un plugin qui ajouterai des tags géographique aux articles devra définir une fonction de template tag appelée geotag_list_states() pour la sidebar, qui liste tout les états qui sont taggé avec l'article, avec des liens sur la page archive des états que le plugin active.

Pour définir un template tag, il suffit d'écrire et de documenter une fonction PHP dans la page principal de votre plugin. Il est également bon en plus de la documentation d'une fonction de donner un exemple de ce qu'il est réellement nécessaire d'ajouter au fichier du thème pour utiliser la fonction en incluant <?php et ?>.

Sauvegarder les données dans la base

Beaucoup de plugins auront besoin de récupérer des données et de les sauver entre deux sessions, pour les utiliser avec des fonction de filtrage, d'actions ou encore de template. Ces information devront être sauvegardé dans la base de données de WordPress. Il existe deux méthodes basiques pour la sauvegarde des données :

  1. Utiliser le mécanisme "d'option" de WordPress (décrit ci-dessous). Cette méthode est approprié pour sauvegardé des petites quantités de données statique -- le type de données utilisé ici est généralement saisie à l'initialisation du plugin et rarement modifiées par la suite.
  2. Créer un nouvelle table. Cette méthode est approprié pour des données associé à un article, à des pages, attachements ou encore commentaires -- les données vont augmenter avec la vie du site et n'auront pas forcément des noms uniques. Voyez Creating Tables with Plugins pour savoir comment faire ceic..

WordPress Options Mechanism

Voyez Creating Options Pages pour savoir comment créer une page qui sauvegardera automatiquement vos options pour vous.

WordPress possède un mécanisme de sauvegarde, de mise à jour et de récupération des options dans la base de données. Les valeurs des options peuvent être des chaines, des tableaux ou des objets PHP (qui seront sérialisé ou convertie en chaine avant la sauvegarde et désérialisé pour la récupération). Le nom des options sont des chaine et doivent être unique afin d'éviter tout confit avec WordPress ou d'autre plugins.

Le code suivant est un exemple de fonction principale que votre plugin pourrait utiliser pour accéder aux options de WordPress.

add_option($name, $value, $description, $autoload);
Créé une nouvelle option; ne fait rien si l'option existe déjà.
$name
Obligatoire (string). Nom de l'option qui sera ajoutée.
$value
Obligatoire (string), vide par défaut. La valeur de l'option à stocker.
$description
Optionnel (string), vide par défaut. Description de l'option, placée dans la base de données de WordPress au cas où quelqu'un parcourrerait la base pour savoir à quoi servent les options qui y sont stockéees.
$autoload
Optionnel, 'yes' par défaut (enum: 'yes' or 'no'). Si la valeur d'autoload est 'yes' la valeur de l'option est automatiquement renvoyée par la fonction get_alloptions.
get_option($option);
Renvoit la valeur d'une option stockée en base.
$option
Obligatoire (string). Nom de l'option dont vous souhaitez récuperer la valeur. Vous pouvez trouver la liste des options par défaut qui sont installées avec WordPress sur la page Option Reference.
update_option($option_name, $newvalue);
Met à jour ou créé une option dans la base de données (note that add_option does not have to be called if you do not want to use the $description or $autoload parameters).
$option_name
Obligatoire (string). Nom de l'option à mettre à jour.
$newvalue
Obligatoire. La nouvelle valeur de l'option.

Panneaux d'administration

Si votre plugin stock des données dans la base de WordPress (voir section précédente), il sera probablement nécessaire d'avoir un panneau d'administration afin de voir et d'éditer ces options. Les méthodes pour faire ceci sont décrite dans Adding Administration Menus.

Internationaliser votre plugin

Once you have the programming for your plugin done, another consideration (assuming you are planning on distributing your plugin) is internationalization. Internationalization is the process of setting up software so that it can be localized; localization is the process of translating text displayed by the software into different languages. WordPress is used all around the world, so it has internationalization and localization built into its structure, including localization of plugins. For background on WordPress's use of GNU gettext for localization, see Translating WordPress.

It is highly recommended that you internationalize your plugin, so that users from different countries can localize it. The process is fairly straightforward:

  • Choose a translation "text domain" name for your plugin. This is generally the same as your plugin file name (without the .php), and must be unique among plugins the user has installed.
  • Wherever your plugin uses literal text strings that will be displayed to the user (known as "messages"), wrap them in one of the two WordPress gettext functions. Note that in a plugin, you need to use the second argument, passing in the translation text domain name you chose, unlike in the core of WordPress (which leaves the $domain argument blank).
__($message, $domain) 
Translates $message using the current locale for $domain. Wrap text strings that you are going to use in calculations with this function.
_e($message, $domain) 
Translates $message using the current locale for $domain, and then prints it on the screen. Wrap text strings that you are directly printed with this function.
  • Create a POT file (translation catalog listing all the translatable messages) for your plugin, and distribute it with your plugin. Users will need to put their translated MO file in the same directory as your plugin's PHP file, and name it domain-ll_CC.mo, where ll_CC is the name of their locale. See Translating WordPress for information on POT files, MO files, and locales.
  • Load the translations for the current locale and your text domain by calling load_plugin_textdomain before either of the gettext functions is called, but as late as possible in the session (because some multi-lingual plugins change the locale when they load). One possible implementation is to define an initialization function that is called at the top of all of your plugin functions. For instance, assuming your text domain is "fabfunc":
$fabfunc_domain = 'fabfunc';
$fabfunc_is_setup = 0;

function fabfunc_setup()
{
   global $fabfunc_domain, $fabfunc_is_setup;

   if($fabfunc_is_setup) {
      return;
   } 

   load_plugin_textdomain($fabfunc_domain, 'wp-content/plugins');
}

If your plugin is in its own subdirectory, append that to the second argument of load_plugin_textdomain.

If you are reading this section because you want to internationalize a Theme, you can basically follow the steps above, except:

  • The MO file goes into the theme directory (same place as style.css).
  • The MO file is named ll_CC.mo, where ll_CC is the name of the locale (i.e. the domain is NOT part of the file name).
  • To load the text domain, put the following (inside a PHP escape if necessary) in your theme's functions.php file:
load_theme_textdomain('your_domain');

Plugin Development Suggestions

This last section contains some random suggestions regarding plugin development.

  • The code of a plugin should follow the WordPress Coding Standards. Please consider the Inline Documentation Standards as well.
  • All the functions in your plugin need to have unique names that are different from functions in the WordPress core, other plugins, and themes. For that reason, it is a good idea to use a unique function name prefix on all of your plugin's functions. Another possibility is to define your plugin functions inside a class (which also needs to have a unique name).
  • Do not hardcode the WordPress database table prefix (usually "wp_") into your plugins. Be sure to use the $wpdb->prefix variable instead.
  • Database reading is cheap, but writing is expensive. Databases are exceptionally good at fetching data and giving it to you, and these operations are (usually) lightning quick. Making changes to the database, though, is a more complex process, and computationally more expensive. As a result, try to minimize the amount of writing you do to the database. Get everything prepared in your code first, so that you can make only those write operations that you need.
  • SELECT only what you need. Even though databases fetch data blindingly fast, you should still try to reduce the load on the database by only selecting that data which you need to use. If you need to count the number of rows in a table don't SELECT * FROM, because all the data in all the rows will be pulled, wasting memory. Likewise, if you only need the post_id and the post_author in your plugin, then just SELECT those specific fields, to minimize database load. Remember: hundreds of other processes may be hitting the database at the same time. The database and server each have only so many resources to spread around amongst all those processes. Learning how to minimize your plugin's hit against the database will ensure that your plugin isn't the one that is blamed for abuse of resources.


External Resources