Bienvenue dans la dernière partie de cette série. Si vous venez d'arriver, consultez nos deux articles précédents. Nous avons couvert jusqu'à présent les sujets suivants:
Conseils pour les meilleures pratiques de développement WordPress
Plus de conseils sur les meilleures pratiques de développement WordPress
Dans ce dernier article, je vais parler de trois choses importantes qui, bien qu’elles n’affectent pas le fonctionnement du plug-in, sont essentielles si vous souhaitez fournir un plug-in de qualité..
La première chose à faire lors du codage d’un plugin est d’activer le mode débogage.comme le recommande WordPress. De cette façon, vous verrez toutes les erreurs, les avertissements et les problèmes.
Pour activer le mode débogage, placez simplement votre wp-config.php
define ('WP_DEBUG', true);
Une fois le site rechargé, vous verrez tous les avertissements et problèmes, ainsi que d’autres messages tels que les notices de fonctions obsolètes de WordPress. Si vous souhaitez fournir un produit de qualité, assurez-vous que l'utilisation de votre plug-in avec l'activation ou la désactivation du mode débogage donne le même résultat (aucune erreur, aucun avertissement ni aucune notification)..
Si vous souhaitez plutôt enregistrer les erreurs dans un fichier et ne pas les afficher au format HTML, vous pouvez le faire en ajoutant avec WP_DEBUG
les lignes suivantes.
// toutes les erreurs seront enregistrées dans un fichier journal debug.log dans le répertoire / wp-content / define ('WP_DEBUG_LOG', true); // ne pas afficher les erreurs en HTML define ('WP_DEBUG_DISPLAY', false);
Un autre paramètre de débogage que j'utilise beaucoup et qui enregistre toutes les requêtes de base de données dans un tableau est le suivant:
define ('SAVEQUERIES', vrai);
D'habitude, j'utilise tout cela (spécialement le dernier) avec le plugin Debug Bar et la console Debug Bar. Si vous ne les connaissez pas, allez chercher une copie et commencez à déboguer vos plugins et vos thèmes. Vous verrez comme c'est facile à faire.
Vous pouvez également consulter les listes de plug-ins que j'utilise pour le développement dans Wp Favs.
La documentation de chaque aspect de votre plugin ou de votre thème facilitera grandement la vie de vos utilisateurs et de votre vie. Ils pourront faire fonctionner le plugin ou le thème en suivant un guide, une vidéo ou une combinaison des deux et vous feront gagner beaucoup de temps avec des tickets d'assistance et des e-mails sans fin..
Je recommande de diviser toute la documentation en catégories ou en sections étant le plus important:
Ensuite, en fonction de votre thème ou de votre plug-in, vous pouvez ajouter le reste de sections ou de catégories. Si vous consultez la page de documentation de WordPress Social Invitations, vous verrez ce que je veux dire..
Si vous avez ajouté des filtres et des points d'ancrage, comme je l'ai mentionné dans l'article précédent, il serait judicieux de créer une page de référence Filtre / Actions expliquant ce qu'ils font..
Les onglets d'aide sont un autre moyen de fournir de l'aide à vos utilisateurs directement sur votre plug-in, au lieu de les rediriger vers votre site Web. Ils sont normalement utilisés pour fournir des informations sur l'écran utilisé à ce moment-là.
Par exemple, sur l’un de mes plugins appelé Social PopUP, j’utilise un onglet d’aide pour expliquer les codes courts disponibles..
Si vous utilisez une classe dans votre plugin et que vous souhaitez ajouter l'onglet d'aide à un type de publication personnalisé, vous pouvez effectuer les opérations suivantes:
/ ** * Initialisez le plugin en chargeant les scripts et les styles d’administrateur et en ajoutant une page de paramètres et un menu. * * @since 1.0.0 * / function __construct () […] // Onglet Aide add_action ('load-post.php', array ($ this, 'mon_admin_add_help_tab')); / ** * Ajouter un onglet d'aide au type d'article traité * *since 1.0 * @return void * / function my_admin_add_help_tab () $ screen = get_current_screen (); if ('spucpt'! = $ screen-> id) return; // Ajouter mon_tabulaire_tableau si le type de publication est spucpt $ screen-> add_help_tab (array ('id' => 'mon_tabulaire_tableau', 'title' => __ ('Codes abrégés'), 'content' => 'Bonjour le contenu va ici' ,));
Il est très important de vérifier que l'ID d'écran actuel correspond à votre type de publication personnalisée, sans quoi l'onglet d'aide apparaîtra partout..
Si, au lieu de cela, vous avez ajouté une page d’options, vous pouvez utiliser le code utilisé comme exemple dans le Codex..
add_help_tab (array ('id' => 'my_help_tab', 'title' => __ ('Mon onglet Aide'), 'content' => ''. __ ('Le contenu descriptif qui apparaîtra dans Mon onglet Aide-corps va ici.'). '
',)); ?>
À mon avis, les aides ne sont pas très visibles pour les utilisateurs, et la plupart d’entre eux ne savent même pas qu’elles existent, mais il est recommandé d’inclure des lignes d’aide dans le plugin lui-même..
Internationalisation également connu sous le nom i18n (il y a 18 lettres entre le i et le n) c'est la cerise sur le gâteau d'un plugin ou d'un thème. Comme vous le savez déjà, WordPress est utilisé par des personnes de partout dans le monde. Par conséquent, au moment de proposer un plugin ou un thème, nous devons nous assurer qu'ils peuvent facilement le traduire dans leur langue maternelle.
Premièrement, nous devrions apprendre le sens de ces deux mots, également appelés i18n et i10n. L'internationalisation fait référence au processus de création d'un plugin ou d'un thème à traduire, alors que la localisation est l'acte de le faire..
WordPress utilise la célèbre bibliothèque gettext qui explique en quelques mots, on peut dire que cela fonctionne comme ceci:
La première chose à faire est de décider text-domain cela sera utilisé pour envelopper toutes vos traductions de plugins ou de thèmes. Le text-domain doit correspondre à votre plugin.
Il existe plusieurs façons de créer les chaînes à traduire, selon que vous créez des variables, répercutez quelque chose, etc. Les fonctions les plus courantes sont: __ ()
et _e ()
. Voyons quelques exemples ci-dessous:
// création d'une variable $ hello = __ ('Hello, Im une chaîne traduisible', 'my-text-domain'); écho ''. __ ('Bonjour, je suis une chaîne traduisible', 'my-text-domain'). '
'; // pour faire un echo, vous pouvez utiliser _e ('Hello, Im une chaîne traduisible', 'my-text-domain'); // Lorsque vous avez des variables dans la chaîne, vous avez: printf (__ ('Nous avons supprimé% d posts.', 'My-text-domain'), $ count); // Ou plusieurs variables printf (__ ('Votre nom est% 1 $ s et votre nom de famille est% 2 $ s.', 'Mon-text-domain'), $ name, $ lastname);
Une autre fonction intéressante que vous pouvez utiliser est _n ()
qui est utilisé pour les pluriels. Cette fonction prend 4 arguments:
Pour revenir à notre exemple précédent, avec les pluriels, cela ressemblera à:
printf (_n ('Nous avons supprimé un message.', 'Nous avons supprimé% d messages.', $ count, 'my-text-domain'), $ count);
Si, par hasard, vous avez besoin de traduire des chaînes dans votre JavaScript, vous pouvez les transmettre en utilisant le wp_localize_script ()
fonction que nous avons discuté sur le deuxième article de cette série.
wp_enqueue_script ('script-handle',…); wp_localize_script ('script-handle', 'objectL10n', array ('alert' => __ ('Ceci est un message d'alerte', 'my-text-domain'), 'submit' => __ ('Submit', ' my-text-domain '),));
Nous avons déjà ajouté toute la chaîne traduisible autour de notre plugin et il est maintenant temps de l'activer. Pour ce faire vous faites simplement:
fonction myplugin_init () $ plugin_dir = nom_base (nom_répertoire (__FILE__)); load_plugin_textdomain ('my-text-domain', false, $ plugin_dir); add_action ('plugins_loaded', 'myplugin_init');
Ce morceau de code va essayer de charger depuis la racine de votre plugin un fichier MO appelé my-text-domain-
lieu
.mo
. Selon vos paramètres de langue dans wp-config.php, la partie locale sera remplacée par votre code de langue. Par exemple si mon wp-config.php
est configuré comme:
define ('WPLANG', 'es_ES');
Le fichier qui va être chargé est my-text-domain-es_ES.mo
. Pour les thèmes est assez similaire, il vous suffit d'inclure dans votre functions.php
le suivant:
load_theme_textdomain ('my_theme_textdomain');
le différence principale est-ce que cette fonction cherchera locale .mo
au lieu de my_theme_textdomain- locale .mo
comme nous l'avons vu sur l'exemple précédent.
Vous pouvez en savoir plus sur l18n dans le Codex WordPress.
Nous sommes à la fin de cette série et j'espère que vous avez aimé la lire autant que je l'ai écrite. Comme je l'ai dit plus tôt, j'ai écrit cette série en pensant à mes débuts en tant que développeur. J'ai essayé de rassembler toutes les informations que j'estimais importantes pour créer un bon plugin, en résumant à grande échelle tout ce qui a déjà été expliqué dans le Codex. Même si j’en ai probablement laissé beaucoup, je pense qu’il suffit d’avoir des bases solides.
J'aimerais beaucoup que vous partagiez vos réflexions, conseils et idées pour un développement solide dans les commentaires..