Share
Lorsque vous aurez bientôt terminé votre plugin WordPress, il est temps de penser à le diffuser au grand public. Se préparer à la publication d'un plugin nécessite beaucoup de polissage, de test et de réglage, et il est facile d'oublier certaines étapes du processus. Ce tutoriel vous guidera dans la publication du plugin dans le répertoire du plugin WordPress et fonctionnera comme une liste de contrôle pour vous aider à vous assurer que votre plugin sera prêt pour le prime time au moment où vous cliquez sur Publier..
Certaines des étapes, telles que la configuration du projet, sont effectuées une fois dans la vie de chaque plugin, alors que d'autres sont importantes chaque fois que vous publiez une nouvelle version de votre plugin. C'est pourquoi il peut être judicieux de créer un signet pour ce didacticiel et d'y revenir au moment de la prochaine mise à jour..
Le répertoire des plugins sur WordPress.org est pour WordPress ce que l’AppStore est pour l’iPhone: le moyen le plus simple et le plus rapide de rechercher des plugins pour WordPress. Même s'il est possible de publier votre plugin sous forme de fichier zip téléchargé à partir de votre propre site Web, l'intégration de WordPress à celle de son répertoire de plugins se resserre.
En publiant votre plugin via le répertoire plugin, vous permettez à vos utilisateurs potentiels de trouver votre plugin et de le maintenir à jour lorsque vous créez de nouvelles versions. Ils pourront installer le plugin sans avoir à quitter le tableau de bord d'administrateur WordPress et, naturellement, la plupart des utilisateurs de WordPress connaissent déjà le répertoire du plugin et le parcourront lorsqu'ils rechercheront des plugins correspondant à leurs besoins. D'autre part, vous obtiendrez des statistiques de téléchargement, les réactions des utilisateurs via la page du plugin dans le répertoire du plugin, ainsi qu'un référentiel gratuit de subversion permettant de stocker les fichiers de votre plugin et l'historique de ses versions..
Y a-t-il une raison pour ne pas héberger votre plugin dans le répertoire du plugin? Si votre plugin est commercial, vous pouvez l'héberger ailleurs (sur votre propre site ou sur un marché, tel que Codecanyon d'Envato), car le répertoire du plugin est ouvert et ne permet pas de gagner de l'argent avec vos plugins. Tout ce qui est posté dans le répertoire des plugins WordPress est téléchargeable gratuitement par tous..
Voici les règles pour les plugins hébergés dans le répertoire, extraites des instructions du répertoire de plugins:
Il n'y a que quelques restrictions:
Une fois que vous avez décidé d’héberger votre plugin dans le répertoire du plugin WordPress, la première étape consiste à créer un compte utilisateur WordPress.org. Pour en obtenir un, visitez le répertoire des plugins et cliquez sur le bouton "Registre" lien en haut à droite de la page, juste à côté de l'invite de connexion.
Après avoir enregistré votre compte d'utilisateur, vous pouvez demander à WordPress d'ajouter votre plugin en suivant ce lien qui mène à une page ressemblant à la capture d'écran ci-dessous..
Remplissez le formulaire et expliquez brièvement en quoi consiste votre plugin. Soyez aussi précis que possible tout en restant dans une longueur raisonnable. Si votre plugin a déjà un site web, entrez l'URL dans le champ "Plugin URL".
Avant la création de votre projet, un membre du personnel de WordPress lira votre demande et l’approuvera. Alors que WordPress ne fait aucune promesse quant au temps que cela pourrait prendre, en disant qu'ils vous répondront dans "un laps de temps vaguement défini", le temps est calculé en heures ou en jours plutôt qu'en semaines - le plus souvent, vous aurez votre plugin mis en place dans les 24 heures suivant le dépôt de la demande.
Une fois votre plugin approuvé, vous recevrez un email avec le site Web de votre nouveau projet et l'URL SVN qu'il contient. Notez l'URL du référentiel, car nous l'utiliserons beaucoup dans les prochaines étapes..
Dans les étapes suivantes, je supposerai que vous connaissez au moins assez SVN. Par conséquent, si vous ne savez pas ce qu'est SVN, parcourez un tutoriel avant de passer à l'étape suivante..
Sur Mac et la plupart des versions (sinon toutes) de Linux, un client SVN en ligne de commande est fourni avec le système d'exploitation. Dans Windows, vous pouvez installer le client de ligne de commande vous-même ou utiliser un client graphique tel que Tortoise SVN. Sur Mac, Versions est un très beau client graphique..
Pour tirer le meilleur parti du référentiel SVN fourni par WordPress, nous allons le configurer de sorte que la version de développement du plug-in soit enregistrée dans
Le répertoire plugin lit la balise à partir de laquelle votre version stable actuelle doit être distribuée en consultant le fichier readme.txt dans tronc. Je vais couvrir cela plus en détail dans la prochaine étape que nous allons parcourir le contenu de la readme.txt fichier qui devrait être inclus avec le plugin.
Voyons d’abord les commandes SVN que vous utiliserez la plupart du temps. Ne vous inquiétez pas si vous n'aimez pas écrire de commandes dans le terminal, utilisez plutôt votre client SVN graphique préféré..
Commençons par vérifier le projet de SVN. À l'heure actuelle, le projet est toujours vide, de sorte qu'un seul répertoire vide est ajouté à votre ordinateur..
$ svn co http: //[email protected]/your-plugin/trunk chemin local
Copiez ou déplacez votre code de plugin dans ce répertoire (chemin local) créé par la commande svn, puis ajoutez les fichiers à SVN. Dans le répertoire, tapez:
$ svn add chemin-fichier
chemin du fichier peut être un chemin d'accès à un fichier spécifique ou un caractère générique tel que * .php. Ceci marquera les fichiers à ajouter au référentiel SVN dans votre prochain svn commit - rien n’est encore validé. Si vous n'êtes pas sûr des fichiers que vous avez déjà ajoutés, vous pouvez vérifier le statut SVN de chaque fichier du répertoire de travail actuel:
$ svn status
Enfin, lorsque tout est prêt à être envoyé au référentiel SVN, validez les fichiers. N'ayez pas peur de commettre souvent: tant que la "balise stable" pointe vers un autre répertoire que le coffre, vos commits n'auront aucun effet sur la version déjà publiée. En faisant cela, vous êtes en sécurité au cas où vous perdriez votre copie locale du code pour une raison quelconque..
$ svn commit -m "Une brève explication de ce qui a été changé"
Avant que votre projet puisse être affiché dans le répertoire des plugins, vous devrez toujours ajouter le fichier readme.txt. Mais avant d'entrer dans cela, il est temps de tester votre plugin.
Même si vos utilisateurs ne paient pas pour utiliser votre plugin, la publication d'un plugin sans le tester au préalable n'est jamais une bonne idée. En open source, les utilisateurs tolèrent quelques versions de buggy de temps en temps si vous corrigez vos bugs rapidement et si vous êtes rapide à répondre à leurs rapports de bogues, mais si chaque version sort avec des bugs sérieux, tôt ou tard, vos utilisateurs passera à d'autres plugins similaires.
Dans le même temps, nous devons garder à l’esprit que, en tant que développeurs uniques ou petites équipes, nos ressources de test sont limitées. Si vous avez de la chance, vous pouvez faire tester votre plug-in par une personne extérieure à l'équipe, mais très souvent, c'est vous seul qui faites les tests. C’est pourquoi il est important de créer un plan de test clair, simple et applicable.
Pour en créer un, suivez les conseils suivants, choisissez les astuces qui vous conviennent et personnalisez-les en fonction de votre propre expérience et des spécificités du plug-in que vous êtes sur le point de publier..
Je suis le premier à admettre que je ne suis pas un développeur parfait. Même si je connais mes points faibles, j'ai tendance à répéter mes erreurs. C'est pourquoi, dans ma procédure de test, j'essaie de garder une liste à jour des types de bogues qui apparaissent le plus souvent dans mon code et des tests que je dois faire avant chaque publication afin de détecter les erreurs les plus courantes..
C'est appelé les tests de régression, et c’est l’une des formes les plus importantes de test: habituellement, les nouvelles fonctionnalités sont assez bien testées au fur et à mesure que vous les développez, mais en même temps, vous pouvez introduire des bogues dans d’autres parties du code que vous avez déjà considérées comme complètes..
Pour attraper ces bugs, créez une liste de tests pour vérifier les fonctionnalités de base de votre plugin, et parcourez la liste avant chaque publication, même si vos modifications n'auraient pas dû les toucher.
Certains des bogues n'apparaissent que pour les nouveaux utilisateurs qui installent le plug-in pour la première fois, tandis que d'autres ne dérangent que les utilisateurs qui effectuent une mise à niveau à partir d'une version précédente. Certains bogues n'apparaissent que dans un environnement multi-utilisateur, etc..
Pour vous assurer de détecter le plus grand nombre de problèmes possible, il est judicieux de créer différents environnements de test, au moins l'un avec une version existante de votre plugin et l'autre avec une nouvelle installation de WordPress..
Lorsque vous savez que votre prochaine version crée de nouvelles tables de la base de données ou modifie celles existantes, testez-la avec soin pour vous assurer que les modifications que vous attendez se produisent effectivement et que la base de données parvient à l'état final correct. Ma procédure de test dit à propos de la structure de la base de données:
Si la structure de la base de données a changé:
- Tester la mise à niveau de la base de données sans désactiver le plugin
- Tester la mise à niveau de la base de données avec désactivation / réactivation
Ce sont des états que vous ne remarquerez pas si vous exécutez le plug-in comme prévu, et cela peut prendre un certain temps avant que vous ne remarquiez les erreurs, sauf si vous les testez intentionnellement..
Ce n'est pas quelque chose que vous voulez voir dans un code de gestion d'erreur destiné à gérer le cas d'erreur avec élégance:
Pour vous assurer que votre plugin fonctionne avec les modifications introduites dans la dernière version de WordPress, il est bon de toujours mettre à jour votre environnement de test avec la dernière version avant de procéder à la dernière série de tests..
Consultez les commentaires des utilisateurs pour voir s’il existe des bogues que vous n’avez pas encore abordés. Ignorez les demandes de fonctionnalités pour le moment (mais notez-les pour pouvoir les utiliser comme entrées lors de la planification de votre prochaine version), car vous ne pouvez pas tout faire dans une version. Croyez toujours vos utilisateurs quand ils disent avoir trouvé un bogue, mais n'ayez pas peur de demander plus d'informations pour le résoudre..
Si votre plugin écrit du code HTML ou CSS, choisissez un ensemble de navigateurs que vous prenez en charge et testez votre plugin sur ces navigateurs avant chaque version..
Certains problèmes potentiels sont plus faciles à détecter en consultant le code qu'en effectuant des tests. Par conséquent, comme dans les tests, il est judicieux de garder une trace de vos points faibles et de rédiger une liste d'éléments à vérifier avant de publier le plugin. À mesure que vous publiez plus de versions, vous acquérez plus de connaissances sur ce qui est important de tester dans ce projet même. Continuez donc à mettre à jour la liste à mesure que vous apprenez, en extrayant et en ajoutant d'autres éléments..
Voici quelques idées à vérifier, recueillies à partir de ma propre expérience:
Lorsque vous manipulez des formulaires postés par l'utilisateur, assurez-vous de valider les attributs correctement, dans sa forme la plus simple, à l'aide de la touche esc_attr méthode.
$ user_name = esc_attr ($ _ POST ["nomutilisateur"]);
si votre plugin n'est pas écrit à l'aide d'objets, chacune de vos fonctions est dans le même espace de noms avec le reste du code dans WordPress et les plugins installés. Pour éviter que vos noms de fonctions entrent en collision avec ceux de WordPress ou d’autres plug-ins, ajoutez-leur un nom abrégé..
function pluginname_print_error ($ message) ? // est plus sûr que: function print_error ($ message) ?
Passez en revue tous vos commentaires TODO ou FIXME pour voir que vous n’avez rien oublié de ce sur quoi vous avez prévu de travailler plus tard..
Si votre plugin prend en charge la localisation, avant chaque publication, parcourez toutes les chaînes du plugin pour vous assurer qu'elles sont toutes correctement marquées pour la localisation. Il est facile de l'oublier en ajoutant de nouvelles chaînes à un plugin.
Accentsconagua
// utilise $ text = __ ("Hello, world", "my_plugin"); // au lieu de seulement $ text = "Hello, world" // et _e ("Hello!", "my_plugin"); // au lieu de echo "Hello!"; Dans le Codex WordPress, vous pouvez trouver un document décrivant le style de codage à suivre lors du développement de plugins pour la plate-forme WordPress. Bien que le suivi de ce document ne soit pas obligatoire, cela facilitera le travail des autres développeurs pour vous aider avec le plugin..
Vérifiez que chaque fichier de votre plug-in contient l'en-tête GPL et que le fichier license.txt de la licence GPL est inclus dans le dossier principal de votre plug-in..
/ * Copyright (c) 2011, Votre nom. Ce programme est un logiciel libre. vous pouvez le redistribuer et / ou le modifier selon les termes de la licence publique générale GNU telle que publiée par la Free Software Foundation; soit la version 2 de la licence, soit (à votre choix) toute version ultérieure. Ce programme est distribué dans l'espoir qu'il sera utile, mais SANS AUCUNE GARANTIE; sans même la garantie implicite de QUALITÉ MARCHANDE ou d'ADÉQUATION À UN USAGE PARTICULIER. Voir la licence publique générale GNU pour plus de détails. Vous devriez avoir reçu une copie de la licence publique générale GNU avec ce programme; sinon, écrivez à la Free Software Foundation, Inc., 51 Franklin Street, cinquième étage, Boston, MA 02110-1301, USA. * /
Chaque plugin engagé dans le répertoire du plugin WordPress doit avoir un readme.txt fichier formaté selon les règles définies par ce modèle. Il est important de suivre la mise en forme telle que définie lorsque, lorsque vous validez votre plugin dans le répertoire du plugin, ce fichier est automatiquement converti en description du plugin que vous voyez lorsque vous parcourez les plugins dans le répertoire du plugin..
Par exemple, voyez comment cet extrait du début du modèle readme.txt est converti en informations présentées à l'utilisateur du répertoire du plugin:
=== Nom du plugin === Contributeurs: markjaquith, mdawaffe (il devrait s'agir d'une liste d'identifiants d'utilisateur wordpress.org) Lien de don: http://example.com/ Tags: commentaires, spam Nécessite au moins: 2.8 Testé jusqu'à: 3.1.3 Balise stable: 1_5_4
Copiez le modèle dans votre répertoire de plugin et commencez à le modifier avec les informations spécifiques à votre plugin. Une fois que vous êtes satisfait de votre readme.txt, testez-le à l'aide du validateur readme.txt fourni par WordPress avant de le valider pour SVN..
Lorsque vous voyez ceci en haut de la page du validateur, vous êtes prêt à valider:
J'ai mentionné le tag stable à l'étape où nous avons parlé de la bonne façon d'utiliser SVN dans le développement de plugins. Maintenant, il est temps de commencer à l'utiliser: vous avez testé votre plugin, vous avez inspecté votre code et vous avez rédigé la documentation. Il n'y a plus rien à part relâcher le plugin:
Recherchez le fichier PHP principal de votre plugin et mettez à jour le commentaire en entrant votre numéro de version dans le répertoire. "Version:" champ:
/ * Nom du plugin: A Plugin Version: 1.0 URI du plugin: http://wp.tutsplus.com Description: My great plugin Auteur: Jarkko Laine URI de l'auteur: http://jarkkolaine.com * /
Dans le fichier readme.txt, deux sections sont consacrées à la documentation de vos modifications de version: "Changelog" et "Avis de mise à niveau."Ajoute une section de votre nouvelle version à Changelog, fournissant des informations détaillées sur les modifications et corrections de bogues incluses dans cette version. La notification de mise à niveau est un résumé plus court (au plus 300 caractères) expliquant pourquoi il est utile de mettre à jour cette version du plugin..
Voici un exemple de ligne de journal des modifications de mon plugin de donation:
= 1.5.2 = * Correction du bug: Correction d'un bug de mise à niveau de la base de données introduite dans la version précédente * Correction du bug: Correction d'un bug lié à la transmission de la devise sélectionnée à PayPal
Toujours dedans readme.txt, Regardez la ligne (presque en haut du fichier) qui dit "Étiquette stable:"et mettez à jour la ligne avec le nom de la balise que vous utiliserez pour votre prochaine version. Ma convention a été de nommer la balise de la même manière que le numéro de version avec des points remplacés par des traits de soulignement (par exemple, la balise de la version 1.0 serait 1_0) Cela fonctionne plutôt bien, mais le mieux est simplement de lui donner le même numéro de version:
Étiquette stable: 1.0
Ainsi, lorsque quelqu'un cherchera une ancienne version de votre plugin sur la page "Autres versions", elle déterminera facilement quelle balise appartient à quelle version, comme dans cet exemple du plugin le plus populaire dans le répertoire du plugin:
Validez vos modifications dans le fichier PHP principal du plug-in et dans le fichier readme.txt. Créez ensuite la balise que vous avez choisie pour votre prochaine "balise stable":
$ svn copy http: //[email protected]/your-plugin/trunk http: //[email protected]/your-plugin/tags/1.0 -m "Marquage d'une nouvelle version "
C'est ça: le readme.txt dans tronc pointe sur la bonne balise et tout ce que vous avez à faire est d’attendre que le logiciel automatique dans le répertoire du plugin remarque vos modifications et mette à jour le répertoire. Il faudra environ une demi-heure pour que la nouvelle version soit téléchargeable à partir du répertoire du plugin et quelques heures de plus avant que votre blog WordPress ne sache qu'une mise à jour est disponible pour le plugin (s'il s'agissait d'une mise à jour au lieu du premier commit)..
Une fois que vous avez remarqué la mise à jour dans le répertoire du plugin, téléchargez-la et testez une nouvelle fois pour vous assurer que chaque modification et correction a été correctement incluse dans la version. Parlez de ce plugin à vos amis et à vos abonnés, puis attendez le retour de vos commentaires et observez l'évolution de vos statistiques de téléchargement..
Une fois que vous avez commencé à recevoir des commentaires, ou si vous avez vos propres idées pour améliorer le plugin, il est bon de continuer à déployer de nouvelles versions toutes les quelques semaines environ. Cela montrera à vos utilisateurs que votre plugin est toujours en vie et en développement actif et les incitera davantage à y investir leur temps..
