Objectif Meilleures pratiques pour le développement de plugins?
Démarrer un wiki de communauté pour collecterobjectifles meilleures pratiques pour le développement de plugins. Cette question a été inspirée par les commentaires de @ EAMann sur 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é.
UPDATE: 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 que les personnes doivent consulter la liste pour s'assurer qu'il n'y a pas de doublons avant de poster.
Actions et filtres d'utilisation
Si vous pensez que les utilisateurs souhaiteraient ajouter ou modifier des données: fournissez apply_filters () avant de renvoyer .
P.S. Une chose que je trouve un peu décevante et que répond à votre question est le pourcentage de plug-ins conçus uniquement pour les utilisateurs finaux, c’est-à-dire qui n’ont 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 les plugins disponibles, même s'ils sont à 90%, ne me permettent pas de mettre à jour les 10% restants.
Je souhaite vraiment que les leaders de la communauté WordPress identifient un moyen de s'assurer que les plugins sont récompensés pour avoir suivi 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 de 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'attacher, 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.
En relation
Charger les scripts/CSS avec wp_enqueue_script et wp_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_script et wp_enqueue_style lors de la liaison de fichiers JS et CSS et jamais directement via les balises <script>.
En relation
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 au cours de l'action init afin que l'utilisateur puisse s'y connecter.
Voir le Codex: I18n pour les développeurs WordPress
Et aussi cet article: Le chargement de WP language file 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 pertinente depuis 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 plugin . 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_DEBUG activé et, idéalement, allumez-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 fichier wp-config.php de sorte que la constante WP_DEBUG 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 pouvez: utiliser les fonctions existantes incluses dans WordPress core au lieu d’écrire les vôtres. Ne développez des fonctions personnalisées PHP que lorsqu'il n'existe pas de fonction préexistante appropriée dans le noyau WordPress.
Un avantage est que vous pouvez utiliser "consigner les avis obsolètes" pour surveiller 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 expérimentés PHP.
En relation
La désinstallation devrait supprimer toutes les données d'un plugin
Lors de la suppression d'une installation WordPress, un plug-in doit supprimer tous les fichiers, dossiers, entrées de base de données et tableaux qu'il a créé ainsi que les valeurs d'option qu'il a créées.
Les plugins peuvent offrir une option pour exporter/importer les paramètres, de sorte que les paramètres puissent être enregistrés en dehors de WordPress avant la suppression.
En relation
Empêcher l'injection SQL avec les données d'entrée
Un plugin devrait nettoie toutes les entrées utilisateur récupérées directement ou indirectement (par exemple, via $_POST ou $_GET) avant d'utiliser des valeurs d'entrée pour interroger la base de données MySQL.
Voir: Formatage des instructions SQL .
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 pour qu'ils se terminent sans fin par_noms_fonctions_long_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 afin de 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
}
}
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(); au lieu de cela, nommez-le quelque chose comme jpb_init().
Sa commune devrait utiliser un préfixe de trois ou quatre lettres devant les noms ou utiliser le PHP Feature Names Feature . Comparez: Préfixe à une lettre pour PHP constantes de classe?
En relation
La désactivation ne doit pas provoquer la perte de données
Un plugin ne devrait passupprimer l'une de ses données lors de désactivation.
En relation
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
À la désinstallation un plugin devrait Inviter un utilisateur à supprimer ses données et recevoir une confirmation de son acceptation de la suppression des données avant de le faire, et un plugin devrait également donne la possibilité à l'utilisateur de conserver les données lors de la désinstallation. (Cette idée de @EAMann.)
En relation
Utiliser WordPress (intégré) Traitement des erreurs
Ne vous contentez pas de 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 pouvez 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 pouvez trouver plus d’informations sur this Q . Un ticket associé pour résoudre le "travail ensemble" de WP_Error et wp_die() est lié à partir de là et un autre ticket suivra. Les commentaires, critiques et autres sont appréciés.
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.
En relation:
plugins_url()pour un lien facile vers des ressources, incluses avec le plugin.
Réduire les noms ajoutés à l'espace de noms global
Un plugin devrait réduit son impact autant que possible en minimise le nombre de noms qu'il ajoute à l'espace de nom global .
Cela peut être fait en encapsulant les fonctions du plugin dans une classe ou en utilisant la fonction PHP des espaces de noms . Tout préfixer peut aussi aider mais n'est pas si flexible.
A côté des fonctions et des classes, un plugin ne devrait pas être utilisé introduit des variables globales. Utiliser des classes les obsolète normalement et cela simplifie la maintenance des plugins.
En relation
Commenter avec PhpDoc
La meilleure pratique est proche du style PhpDoc. Si vous n'utilisez pas un IDE comme "Eclipse", vous pouvez simplement jeter un coup d'oeil au manuel 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 Settings API qui s'occupe de tout pour vous.
Utiliser l'API de modification de thème avant add_option
L'API Modifications 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.
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 capacité codée en dur peut s'avérer insuffisante.
À tout le moins, effectuez des contrôles de capacité appropriés pour tous les types de procédures pour lesquels votre plug-in peut être utilisé.
Plugins hôtes sur WordPress.org
Utilisez le SVN repository 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.
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., puis les fonctions requises par le plugin/thème et enfin le constructeur (par exemple, l’écran d’admin, le contenu intégré au thème, 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 aplatisseurs 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.
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 fournit 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.
Un exemple de plug-in doté d'une telle fonctionnalité d'importation et d'exportation (ainsi que d'un mécanisme d'annulation) est Breadcrumb NavXT (Plugin Wordpress) (divulgation complète: quelques-uns de mes codes ici, la plupart ont été réalisés par mtekk) .
En relation
Mourir avec style
mourir de manière décente Toutes les fonctions d'un plugin (et même de thèmes) doivent utiliser 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_die peut donner à l'utilisateur un message stylé sur ce que le plugin (ou ceux-ci) ont mal fait. De plus, si l'utilisateur a désactivé le débogage, le plug-in sera interrompu.
L'utilisation de wp_die() aide également vos modules/thèmes à être compatibles avec la suite de tests wordpress .
Fournir des écrans d'aide aux utilisateurs
Il est préférable de répondre RTFM (cliquez sur Aide) plutôt 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 "submit" et/ou "reset", afin que les développeurs puissent facilement étendre le formulaire avec non seulement des champs, mais également des boutons.
Voir: Paramètres API
En relation
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 live: 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 de l'action: http://codex.wordpress.org/Plugin_API/Action_Reference Vous voyez également ici comment wP avec ce crochet: http://adambrown.info/p/wp_hooks/hook/plugins_loaded?version=2.1&file=wp-settings.php J'utilise cela très souvent et ce n'est pas si difficile et précoce, mieux qu'une nouvelle classe difficile ();
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.
Licence Plugins sous une licence compatible GPL
Les plug-ins et les thèmes devraient être sous 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.
(Ceci est un problème } et sérieux débat dans le passé et présent .)
Minimiser les effets secondaires des sources de données et des services Web distants
Un plugin should WebService Cache/Shield et/ou Requêtes XMLRPC/SOAP via une couche de mise en cache/fournisseur de données si vous les utilisez afin de ne pas faire de demandes frontales en attente ( lent) réponse 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 par exemple des publications sur ping.fm): Créez une table tampon, par exemple: ping_fm_buffer_post (date, heure, message, heure soumise, statut)
- Pour chaque fois que vous souhaitez soumettre une mise à jour à ping.fm, ajoutez-la à ce tableau.
- 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.
- 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 de 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
Utiliser des noms propres
Noms de crochets et filtres (classes, fonctions et vars), donc pour que les gens puissent les identifier même un an , quand ils ne se souviennent plus, où ce morceau de gâteau ou le code vient de. Peu importe si les noms de hook/filter deviennent longs. Ex. votreuniquename_hook/filter_whatitdoes.
- Si votre fichier contient une classe nommée "dbdbInit", le fichier contenant cette classe doit être nommé "
dbdbInit.class.php". - Si vous avez dans votre
dbdbInit- class une fonction qui enregistre ex. custom_post_types, puis appelez-leregister_custom_post_types(). - Si vous avez un tableau contenant les noms de custom_post_types, appelez la variable à laquelle le tableau est assigné
$custom_post_type_names. - Si vous avez une fonction qui gère un tableau, écrivez
function array_handler( $array ) { // handle the array}.. - Essayez simplement de nommer les choses de manière à ce que le panneau indique/à quoi il appartient par son nom.
Autre chose: si vous devez déboguer des éléments, alors, dans 99% des cas, vous recevez tous vos messages non seulement pour votre code, mais également pour wordpress. Donc, essayez d'utiliser le même préfixe ex. "dbdb" pour vos classes, fonctions publiques et variables/objets. De cette façon, vous pouvez les trouver facilement entre des centaines de fichiers. (Wordpress charge 64 fichiers avant votre thème et environ 1 550 fonctions, sans parler des crochets et des filtres.)
Attention aux futures versions de WordPress et de thèmes
Remarque: après avoir relu ce conseil, je m'éloigne maintenant de cette pratique, car la vérification de l'existence de chaque fonction peut ralentir votre site.
Vérifie si les fonctions sont déconseillées directement dans votre thème.
Ceci est un exemple "pourrait être comme ça".
if ( ! function_exists( 'wp_some_fn' ) )
{
$theme_data = wp_get_theme();
$error = new WP_Error( 'wp_some_fn', sprintf( __( 'The function %1$s is deprecated. Please inform the author', TEXTDOMAIN ), "Theme: {$theme_data->Name}: Version {$theme_data->Version}" );
// abort
if ( is_wp_error( $error ) )
return print $error->get_error_message();
}
// else if no error - the function works and exists
wp_some_fn();
Pour la gestion des erreurs de bonne pratique/meilleure pratique, voir cette réponse: link
Vous pouvez même laisser tomber la cause $ dans la fonction. Cela vous aidera, ainsi que vos utilisateurs, à suivre l'évolution des fonctions ou des classes de votre thème.
Utiliser les normes de codage de WordPress
http://codex.wordpress.org/WordPress_Coding_Standards
Vous savez à quel point il est facile de mettre à jour le code sur lequel vous avez travaillé par rapport au code que quelqu'un d'autre a mis en place? Les normes de codage permettent à tout développeur travaillant sur un projet d'entrer plus facilement et de voir ce qui se passe.
Nous savons que votre plugin ou votre thème vous appartient, et la façon dont vous cassez vos lignes et ajoutez vos accolades est l'expression de votre individualité. Chaque retrait est une déclaration minutieuse. Mais avec votre code personnalisé, vous contribuez à WordPress, même si votre code n'est pas dans l'application principale. Les normes de codage aident les développeurs à maîtriser rapidement votre code.
Découpler du code principal de WordPress
Un plugin devrait réduit l'impact de l'API WordPress au minimum nécessaire so pour séparer le code du plugin du code WordPress. Cela réduit l'impact des modifications au sein de la base de code WordPress sur le plugin. De plus, cela améliore la compatibilité inter-versions de votre code de plugin.
Cela ne signifie pas de ne pas utiliser les fonctions WordPress (utilisez-les, comme le suggère ré-utilisez les fonctions existantes ]), mais pas trop de mailler votre code avec les fonctions WordPress, mais de séparer la logique de votre plugin à partir de la fonctionnalité WordPress.
Utiliser les options wp pour les chaînes de sortie du plugin
Afin de rendre le plugin facilement utilisable et personnalisable, toutes les chaînes de sortie doivent être modifiables. La meilleure façon de faire consiste à utiliser les options de wp pour stocker les chaînes de sortie et à fournir un back-end pour modifier les valeurs par défaut. Le plugin ne doit pas utiliser de chaînes affichées qui ne peuvent pas être facilement modifiées à l’aide du backend du plugin.
Par exemple: Sociable - vous permet de modifier la phrase qui apparaît avant la partie icônes "partager et profiter:"
Utilisez désinstaller, activer et désactiver les hooks
Il y a trois crochets différents pour cela:
- Désinstallez
register_uninstall_hook(); - Désactivation
register_deactivation_hook(); - Activation
register_activation_hook();
Une instruction détaillée avec un exemple de travail peut être trouvé ici. .