Lancer un wiki de communauté pour rassembler les meilleures pratiques objectives pour le développement de plugins. Cette question a été inspirée par les commentaires de @ EAMann sur les wp-hackers .

L'idée est de collaborer sur ce que pourraient être les meilleures pratiques objectives afin que nous puissions éventuellement les utiliser dans le cadre d'un processus d'examen de la collaboration avec la communauté.

MISE À JOUR: Après avoir vu les premières réponses, il devient clair que nous n'avons besoin que d'une idée / suggestion / meilleure pratique par réponse et les personnes doivent consulter la liste pour s'assurer qu'il n'y a pas de doublons avant la publication.

Utiliser des actions et des filtres

Si vous pensez que les gens aimeraient ajouter ou modifier des données: fournissez apply_filters () avant de retourner .

PS Une chose que je trouve un peu décevante et que répond à votre question est le pourcentage de plugins conçus uniquement pour les utilisateurs finaux, c’est-à-dire qui ne possèdent pas de crochets propres. Imaginez si WordPress était conçu comme la plupart des plugins? Ce serait inflexible et une solution très niche.

Peut-être que les choses seraient différentes si WordPress était capable d'auto-installer des plugins sur lesquels d'autres plugins dépendaient? En général, je dois écrire de nombreuses fonctionnalités dont j'ai besoin, car les clients veulent certaines choses et que les plugins disponibles, même s'ils sont à 90%, ne me permettent pas de mettre à jour les 10% restants.

Je souhaite vraiment que ceux qui dirigent la communauté WordPress identifient un moyen de s'assurer que les plugins sont récompensés pour suivre les meilleures pratiques (telles que l'ajout de points d'ancrage pour les autres développeurs), tout comme les bonnes réponses sont récompensées sur un site StackExchange.

Prenons un exemple d' une autre question :

Exemple: je veux faire quelque chose dans mon plugin quand quelqu'un retweet un article. S'il existait un point d'ancrage personnalisé dans le plug-in Retweet populaire auquel je pouvais m'arranger, ce serait génial. Donc, je peux modifier leur plugin pour l'inclure, mais cela ne fonctionne que pour ma copie, et je ne veux pas essayer de le redistribuer.

Apparenté, relié, connexe

• Offrir des formulaires extensibles

Charger des scripts / CSS avec wp_enqueue_scriptetwp_enqueue_style

Les plug-in ne doivent pas charger / tenter de charger des versions en double de fichiers JS / CSS, en particulier jQuery et d'autres fichiers JS inclus dans WP Core.

Les plugins doivent toujours utiliser wp_enqueue_scriptet wp_enqueue_stylelors de la liaison de fichiers JS et CSS et jamais directement via des <script>balises.

Apparenté, relié, connexe

• Réutiliser les fonctions existantes

I18n soutien

Toutes les chaînes de sortie doivent être liées à un domaine de texte approprié pour permettre l’internationalisation par les parties intéressées, même si le développeur n’a aucun intérêt à traduire son propre plug-in.

Notez qu'il est très important de charger les fichiers de langue pendant l' initaction pour que l'utilisateur puisse s'y connecter.

Voir le Codex: I18n pour les développeurs WordPress

Et aussi cet article: Chargement des fichiers de langue WP correctement .

Depuis WordPress 4.6+

WP 4.6 a modifié l’ordre de chargement et les emplacements vérifiés, ce qui a grandement facilité la tâche des développeurs et des utilisateurs.

Considérant un plugin avec un textdomain 'my-plugin', WordPress va maintenant rechercher un fichier de traduction dans:
/wp-content/languages/plugins/my-plugin-en_US.mo

S'il ne parvient pas à en trouver un ici, il en recherchera un pour lequel le plug-in lui dit de regarder (habituellement dans le dossier 'language' des pluigns si vous suivez le codex):
/ wp-content / plugins / my-plugin / languages ​​/ my- plugin-en_US.mo

Enfin, si aucun fichier de langue n’est trouvé, il vérifiera l’emplacement par défaut de:
/wp-content/languages/my-plugin-en_US.mo

La première vérification a été ajoutée en 4.6 et donne aux utilisateurs un emplacement défini pour ajouter un fichier de langue, car ils devaient auparavant savoir où le développeur avait ajouté le fichier de langue. Désormais, l'utilisateur doit simplement connaître le domaine textuel du plugin: / wp-content / languages ​​/ plugins / TEXTDOMAIN-LOCAL.mo

Ci-dessous l'ancienne méthode (non pertinent depuis le WP 4.6+)

[...]
Enfin, je voudrais souligner qu'il est important de charger les fichiers de langue utilisateur personnalisés à partir de WP_LANG_DIR avant de charger les fichiers de langue fournis avec le plug-in . Lorsque plusieurs fichiers mo sont chargés pour le même domaine, la première traduction trouvée sera utilisée. De cette façon, les fichiers de langue fournis par le plugin serviront de solution de secours pour les chaînes non traduites par l'utilisateur.

public function load_plugin_textdomain()
{
    $domain = 'my-plugin';
    // The "plugin_locale" filter is also used in load_plugin_textdomain()
    $locale = apply_filters( 'plugin_locale', get_locale(), $domain );

    load_textdomain( 
            $domain, 
            WP_LANG_DIR . '/my-plugin/' . $domain . '-' . $locale . '.mo' 
    );
    load_plugin_textdomain( 
            $domain, 
            FALSE, 
            dirname( plugin_basename(__FILE__) ) . '/languages/' 
    );
}

Assurez-vous que les plugins ne génèrent aucune erreur avec WP_DEBUG

Testez toujours vos plugins avec WP_DEBUGactivé et idéalement, activez-le tout au long de votre processus de développement. Un plugin ne devrait lancer AUCUNE erreur avec WP_DEBUG. Cela inclut les avis obsolètes et les index non vérifiés.

Pour activer le débogage, modifiez votre wp-config.phpfichier de sorte que la WP_DEBUGconstante soit définie sur true. Voir le Codex sur le débogage pour plus de détails.

Première utilisation des fonctions existantes dans WordPress Core

Si vous le pouvez: utilisez les fonctions existantes incluses dans WordPress Core au lieu d’écrire les vôtres. Ne développez des fonctions PHP personnalisées que lorsqu'il n'existe pas de fonction préexistante appropriée dans le noyau WordPress.

Un des avantages est que vous pouvez utiliser des "avis obsolètes" pour contrôler facilement les fonctions à remplacer. Un autre avantage est que les utilisateurs peuvent consulter la documentation sur les fonctions dans le Codex et mieux comprendre ce que fait le plug-in, même s'ils ne sont pas des développeurs PHP expérimentés.

Apparenté, relié, connexe

• I18n soutien
• Charger des scripts / CSS avec wp_enqueue_script et wp_enqueue_style
• Offrir des formulaires extensibles

La désinstallation devrait supprimer toutes les données d'un plugin

Lorsqu'il est supprimé d'une installation WordPress, un plug-in doit supprimer tous les fichiers, dossiers, entrées de base de données et tables qu'il a créées, ainsi que les valeurs d'option créées.

Les plugins peuvent offrir une option pour exporter / importer les paramètres, afin que les paramètres puissent être enregistrés en dehors de WordPress avant la suppression.

Apparenté, relié, connexe

• La désactivation ne doit pas provoquer la perte de données

Empêcher l'injection SQL avec les données d'entrée

Un plugin doit supprimer toutes les entrées utilisateur récupérées directement ou indirectement (par exemple via $_POSTou$_GET ) avant d'utiliser des valeurs d'entrée pour interroger la base de données MySQL.

Voir: Formatage des instructions SQL .

Préfixer tous les éléments d'espace de noms globaux

Un plugin doit correctement préfixer TOUS les éléments d’espace de noms globaux (constantes, fonctions, classes, variables, voire des éléments tels que les taxonomies personnalisées, les types de publication, les widgets, etc.). Par exemple, ne créez pas une fonction appelée init(); nommez-le plutôt jpb_init().

Son point commun devrait utiliser un préfixe de trois ou quatre lettres devant les noms ou utiliser la fonctionnalité PHP Namespace . Comparez: Préfixe à une lettre pour les constantes de classe PHP?

Apparenté, relié, connexe

• L'espace de noms global est une ressource limitée

Utiliser un code PHP5 orienté objet et classe

Il n'y a aucune raison de ne pas écrire du code PHP5 propre et orienté objet. Le support de PHP4 disparaîtra après la prochaine version (WP 3.1). Bien sûr, vous pouvez préfixer tous les noms de fonctions de manière à ce qu'ils finissent par interminly_long_function_names_with_lots_of_underscores, mais il est beaucoup plus facile d'écrire une simple classe et de regrouper tout le contenu. En outre, placez votre classe dans un fichier séparé et nommez-la en conséquence pour pouvoir l'étendre et la maintenir facilement:

// in functions.php
require 'inc/class-my-cool-plugin.php';
new MyCoolPlugin();

// in inc/class-my-cool-plugin.php
class MyCoolPlugin {
    function __construct() {
        // add filter hooks, wp_enqueue_script, etc.

        // To assign a method from your class to a WP 
        // function do something like this
        add_action('admin_menu', array($this, "admin"));
    }

    public function admin() {
        // public methods, for use outside of the class
        // Note that methods used in other WP functions 
        // (such as add_action) should be public
    }

    private function somethingelse() {
        // methods you only use inside this class
    }
}

La désactivation ne doit pas provoquer la perte de données

Un plugin ne doit supprimer aucune de ses données lors de la désactivation .

Apparenté, relié, connexe

• La désinstallation devrait supprimer toutes les données du plugin

Incluez uniquement les fichiers dont vous avez besoin ...

Si vous êtes au début, n'incluez pas de code lié à la zone d'administration.

Annonce de Data-Loss lors de la désinstallation d'un plugin

Lors de la désinstallation, un plug-in doit inviter l'utilisateur à supprimer ses données et à recevoir une confirmation confirmant que l'utilisateur accepte de supprimer les données avant de le faire. Un plug-in doit également permettre à l'utilisateur de conserver les données lors de la désinstallation. (Cette idée de @EAMann.)

Apparenté, relié, connexe

• La désinstallation devrait supprimer toutes les données du plugin
• La désactivation ne doit pas provoquer la perte de données

Que le nom du dossier du plugin soit changé

/ plugins / pluginname / {divers}

Le "pluginname" utilisé pour le dossier devrait toujours être modifiable.

Ceci est normalement géré en définissant les constantes et en les utilisant systématiquement dans le plugin.

Inutile de dire que beaucoup de plugins populaires sont des pécheurs.

Apparenté, relié, connexe:

• plugins_url() pour un lien facile aux ressources, inclus avec le plugin.

Utiliser WordPress (intégré) Traitement des erreurs

Ne vous contentez pas return;si une entrée utilisateur était fausse. Livrez-leur des informations sur a été fait mal.

function some_example_fn( $args = array() ) 
{
    // If value was not set, build an error message
    if ( ! isset( $args['some_value'] ) )
        $error = new WP_Error( 'some_value', sprintf( __( 'You have forgotten to specify the %1$s for your function. %2$s Error triggered inside %3$s on line %4$s.', TEXTDOMAIN ), '$args[\'some_value\']', "\n", __FILE__, __LINE__ ) );

    // die & print error message & code - for admins only!
    if ( isset( $error ) && is_wp_error( $error ) && current_user_can( 'manage_options' ) ) 
        wp_die( $error->get_error_code(), 'Theme Error: Missing Argument' );

    // Elseif no error was triggered continue...
}

Une erreur (objet) pour tous

Vous pouvez configurer un objet d'erreur globale pour votre thème ou votre plugin pendant l'amorçage:

function bootstrap_the_theme()
{
    global $prefix_error, $prefix_theme_name;
    // Take the theme name as error ID:
    $theme_data = wp_get_theme();
    $prefix_theme_name = $theme_data->Name;
    $prefix_error = new WP_Error( $theme_data->Name );

    include // whatever, etc...
}
add_action( 'after_setup_theme', 'bootstrap_the_theme' );

Plus tard, vous pourrez ajouter un nombre illimité d’erreurs à la demande:

function some_theme_fn( $args )
{
    global $prefix_error, $prefix_theme_name;
    $theme_data = wp_get_theme();
    if ( ! $args['whatever'] && current_user_can( 'manage_options' ) ) // some required value not set
        $prefix_error->add( $prefix_theme_name, sprintf( 'The function %1$s needs the argument %2$s set.', __FUNCTION__, '$args[\'whatever\']' ) );

    // continue function...
}

Ensuite, vous pouvez tous les récupérer à la fin de votre thème. De cette façon, vous n'interrompez pas le rendu de la page et pouvez toujours afficher toutes vos erreurs pour le développement.

function dump_theme_errors()
{
    global $prefix_error, $prefix_theme_name;

    // Not an admin? OR: No error(s)?
    if ( ! current_user_can( 'manage_options' ) ! is_wp_error( $prefix_error ) )
        return;

    $theme_errors = $prefix_error->get_error_messages( $prefix_theme_name );
    echo '<h3>Theme Errors</h3>';
    foreach ( $theme_errors as $error )
        echo "{$error}\n";
}
add_action( 'shutdown', 'dump_theme_errors' );

Vous trouverez de plus amples informations à ce Q . Un ticket associé pour résoudre le "travail ensemble" de WP_Erroret wp_die()est lié à partir de là et un autre ticket suivra. Les commentaires, critiques et autres sont appréciés.

Réduire les noms ajoutés à l'espace de noms global

Un plugin devrait réduire son impact autant que possible en minimisant le nombre de noms qu'il ajoute à l'espace de noms global .

Cela peut être fait en encapsulant les fonctions du plugin dans une classe ou en utilisant la fonction d'espaces de nommage PHP . Tout préfixer peut aussi aider mais n'est pas si flexible.

A côté des fonctions et des classes, un plugin ne doit pas introduire de variables globales. Utiliser des classes les obsolète normalement et cela simplifie la maintenance des plugins.

Apparenté, relié, connexe

• Préfixe correctement

Commenter avec PhpDoc

La meilleure pratique est proche du style PhpDoc. Si vous n'utilisez pas d'IDE comme "Eclipse", vous pouvez simplement consulter le manuel de PhpDoc .

Vous n'avez pas besoin de savoir exactement comment cela fonctionne. Les développeurs professionnels peuvent quand même lire le code et en ont besoin comme résumé. Les codeurs amateurs et les utilisateurs peuvent apprécier la façon dont vous l'expliquez au même niveau de connaissance.

Utiliser l'API Settings avant add_option

Au lieu d'ajouter des options à la base de données via la fonction add_option, vous devez les stocker sous forme de tableau avec l'aide de l' API de configuration qui s'occupe de tout pour vous.

Utiliser l'API de modification de thème avant add_option

L' API de modification est une construction assez simple et un moyen sûr qui permet d'ajouter et de récupérer des options. Tout est enregistré en tant que valeur sérialisée dans votre base de données. Facile, sûr et simple.

Protéger la confidentialité des utilisateurs du plugin

(Auparavant: Communication anonyme avec l'API)

Si un plug-in communique avec un système externe ou une API (par exemple, un Webservice), il doit le faire de manière anonyme ou fournir à l'utilisateur une option anonyme garantissant qu'aucune donnée liée à l'utilisateur du plug-in ne fuit à une deuxième partie sans contrôle.

Plugins hôtes sur WordPress.org

Utilisez le référentiel SVN fourni sur WordPress.org pour héberger des plugins. Cela facilite la mise à jour de l'expérience utilisateur et, si vous n'avez jamais utilisé SVN auparavant, vous comprendrez vraiment en l'utilisant dans un contexte qui le justifie.

Fournir un contrôle d'accès à l'aide d'autorisations

Dans de nombreux cas, les utilisateurs ne souhaitent peut-être pas que tout le monde ait accès aux zones créées par votre plug-in, en particulier dans le cas de plug-ins effectuant plusieurs opérations complexes. Une vérification de la fonctionnalité codée en dur peut s'avérer insuffisante.

Ayez au minimum des contrôles de capacité appropriés pour tous les types de procédures pour lesquels votre plugin peut être utilisé.

Paramètres du plug-in d'importation / exportation

Ce n'est pas si commun entre les plugins, mais si votre plugin a (certains) paramètres, il devrait fournir Import / Export de données telles que la configuration et l'entrée utilisateur .

Import / Export améliore la facilité d'utilisation d'un plugin.

Breadcrumb NavXT (plugin Wordpress ) est un exemple de plug-in doté d'une telle fonctionnalité d'importation et d'exportation (ainsi que d'un mécanisme d'annulation ).

Apparenté, relié, connexe

• La désinstallation devrait supprimer toutes les données du plugin
• La désactivation ne doit pas provoquer la perte de données

Organiser votre code

Il est toujours difficile de lire du code qui n'est pas écrit dans l'ordre dans lequel il est exécuté. Commencez par inclure / require, define, wp_enqueue_style & _script etc.

Essayez de séparer les éléments tels que css et js dans leurs propres dossiers. Essayez également de le faire avec des fonctions qui ne sont que des aides, comme les aplatissements de tableaux et similaires. Garder le fichier "principal" aussi propre et lisible que possible est un moyen d'aider les utilisateurs, les développeurs et vous-même lorsque vous essayez de mettre à jour votre logiciel dans l'année et que vous n'avez pas vu le code depuis plus longtemps.

Il est également bon d'avoir une structure que vous répétez souvent afin de toujours trouver votre chemin. Développer dans une structure connue sur différents projets vous donnera le temps de l'améliorer et même si votre client passe chez un autre développeur, vous n'entendrez jamais "il a laissé un chaos". Cela renforce votre réputation et devrait être un objectif à long terme.

Mourir avec style

mourir de manière décente Toutes les fonctions d'un plugin (et même d'un thème) doivent être utilisées wp_die()dans des endroits critiques pour offrir à l'utilisateur un peu d'informations sur ce qui s'est passé. Les erreurs php sont ennuyeuses et wp_diepeuvent donner à l’utilisateur un joli message stylé sur ce que le plugin (ou eux) a mal fait. De plus, si l'utilisateur a désactivé le débogage, le plug-in sera simplement interrompu.

En utilisant wp_die()également, vos plugins / thèmes sont compatibles avec la suite de tests wordpress .

• Utiliser la gestion des erreurs WP

Fournir des écrans d'aide aux utilisateurs

Il est plus agréable de dire RTFM (cliquez sur aide) comme une réponse que de devoir répondre à la question à maintes reprises.

/**
  * Add contextual help for this screen
  * 
  * @param $rtfm
  * @uses get_current_screen
  */ 
  function ContextualHelp( /*string*/ $rtfm) 
  { 
     $current_screen = get_current_screen();
     if ($current_screen->id == $this->_pageid) 
     {
        $rtfm .= '<h3>The WordPress Plugin - Screen A</h3>';
        $rtfm .= '<p>Here are some tips: donate to me ' .
     }
     return $rtfm; 
  }
add_action('contextual_help', array($this,'ContextualHelp'),1,1);

update / note: (voir les commentaires de kaiser): l'exemple ci-dessus doit être utilisé dans une classe

Offrir des formulaires extensibles

Lorsqu'un plugin offre la possibilité de saisir des données, il doit toujours avoir un point d'accroche à la fin, juste avant le bouton "soumettre" et / ou "réinitialiser", afin que les développeurs puissent facilement étendre le formulaire avec non seulement des champs, mais également des boutons.

Voir: API de paramètres

Apparenté, relié, connexe

• Utiliser des actions et des filtres
• Réutiliser les fonctions existantes
• I18n soutien

inclure la fonction toujours par crochet, pas directement.

Exemple:

• Ne pas utiliser pour inclure la classe du plugin via new sans hook

• Utilisez le crochet plugins_loaded

  // add the class to WP                                   
  function my_plugin_start() {                                                               
      new my_plugin();   
  }                                                        
  add_action( 'plugins_loaded', 'my_plugin_start' );

Mise à jour: un petit exemple en direct: Plugin-svn-trunk-page et un pseudo exemple

//avoid direct calls to this file where wp core files not present
if (!function_exists ('add_action')) {
        header('Status: 403 Forbidden');
        header('HTTP/1.1 403 Forbidden');
        exit();
}

if ( !class_exists( 'plugin_class' ) ) {
    class plugin_class {

        function __construct() {
        }

    } // end class

    function plugin_start() {

        new plugin_class();
    }

    add_action( 'plugins_loaded', 'plugin_start' );
} // end class_exists

Vous pouvez également charger via mu_plugins_loaded sur multisite-install, voir le codex pour la référence d’action: http://codex.wordpress.org/Plugin_API/Action_Reference . Ici aussi, vous voyez comment wLcude wP avec ce hook: http: // adambrown. info / p / wp_hooks / hook / plugins_loaded? version = 2.1 & fichier = wp-settings.php J'utilise cela très souvent et ce n'est pas si difficile et précoce, mieux comme une nouvelle classe difficile ();

Licence Plugins sous une licence compatible GPL

Les plug-ins et les thèmes doivent être concédés sous une licence compatible WordPress. Cela leur permet d'être redistribués avec WordPress en tant que "programme". Une licence recommandée est la GPL . Veillez à ce que toutes les bibliothèques de codes fournies avec le plug-in soient compatibles avec la même licence.

(Cela a été un problème et un sujet de débat sérieux dans le passé et le présent .)

La description de votre plugin doit détailler avec précision les fonctions de votre plugin. Il y a 10 plugins postaux en vedette. Tous affichent les articles en vedette, mais beaucoup ont des caractéristiques différentes. Il devrait être facile de comparer votre plugin à des plugins similaires en lisant la description.

Vous devriez éviter de vous vanter de la simplicité de votre plugin, à moins que ce ne soit vraiment très basique. Vous devez inclure des liens utiles dans la description, comme le lien vers les paramètres.

Minimiser les effets secondaires des sources de données et des services Web distants

Un plugin doit mettre en cache / bouclier le service Web et / ou les requêtes XMLRPC / SOAP via une couche de mise en cache / fournisseur de données si vous les utilisez afin de ne pas créer de demandes frontales en attente d'une réponse (lente) du service Web.

Cela inclut le téléchargement de flux RSS et d'autres pages. Concevez vos plugins pour qu’ils demandent des données en arrière-plan.

Une étape possible est la suivante (prenez un message sur ping.fm par exemple): Créez une table tampon, par exemple: ping_fm_buffer_post (date, heure, message, heure soumise, statut)

1. Pour chaque fois que vous souhaitez soumettre une mise à jour à ping.fm, ajoutez-la à ce tableau.
2. Maintenant, nous devons créer un plugin pour gérer ces données. Ce plugin sera exécuté via crontab pour vérifier chaque mise à jour non encore soumise.
3. Comme nous avons ce tableau, nous pouvons également répertorier tous les messages soumis à ping.fm et vérifier le statut de chaque message. Juste au cas où il y aurait un problème du côté de ping.fm, nous pouvons le soumettre à nouveau.

Testez votre plugin

Nous devrions définitivement avoir des outils de test sur notre environnement de développement de plugins.

Sur la base de cette réponse d’ Ethan Seifert à une question test, voici les bonnes pratiques à suivre:

• Votre test unitaire doit tester le plus petit comportement qu'une classe puisse effectuer.
• Lorsque vous atteignez le niveau de test fonctionnel, vous pouvez tester votre code avec des dépendances Wordpress.
• En fonction de ce que votre plugin fait - envisagez d'utiliser des tests basés sur Selenium qui testent la présence de données dans le DOM à l'aide d'identifiants