Share
WordPress a rendu pratique le déploiement des plugins auprès du public. Il suffit de mettre votre plugin dans le référentiel de plugins WordPress et il peut être facilement trouvé par des personnes à partir de leur tableau de bord..
L'une des meilleures caractéristiques du référentiel est probablement qu'il facilite la mise à jour des plugins à partir du tableau de bord. Les notifications de mise à jour sont affichées dans le tableau de bord. Effectuer une mise à jour est aussi simple que de cliquer sur le bouton Mettre à jour maintenant bouton.
Mais que diriez-vous si vous vouliez héberger le plugin vous-même? La fonctionnalité de mise à jour ne sera pas disponible si vous hébergez votre plugin en dehors du dépôt de plugin WordPress. Vos utilisateurs ne seraient pas non plus informés de la disponibilité d'une mise à jour.
Cet article vous apprendra qu'avec un peu de code créatif, vous pouvez héberger vos propres plugins WordPress dans GitHub tout en conservant la fonctionnalité de mise à jour automatique..
Vous voudrez peut-être héberger votre plug-in en dehors du référentiel de plug-ins WordPress pour un certain nombre de raisons. L’une des principales restrictions du référentiel est qu’il vous faut attribuer une licence à votre plugin en tant que GPLv2. Je ne m'attarderai pas sur les détails des licences, mais en un mot cela signifie que tout le monde peut partager votre travail. Donc, si vous voulez vendre votre plugin, son hébergement dans un référentiel privé GitHub est désormais une option que vous pouvez envisager..
Cependant, en raison de la construction de WordPress, héberger votre plugin dans GitHub aurait désactiver les mises à jour automatiques pour notre plugin. Pour comprendre pourquoi c'est le cas, nous devons comprendre comment WordPress gère les mises à jour des plugins..
Vous pouvez en apprendre plus sur le référentiel de plugins WordPress en lisant leurs instructions détaillées sur les plugins..Premièrement, examinons comment WordPress effectue les mises à jour de plug-in afin de mieux comprendre pourquoi les plug-ins auto-hébergés ne peuvent pas avoir de mises à jour automatiques.
WordPress vérifie périodiquement dans le référentiel WordPress les mises à jour de vos plugins installés. Il reçoit un tas d'informations sur chaque plugin, telles que sa dernière version et l'URL du paquet du plugin. Voici ce que nous voyons habituellement dans la page d'administration du plugin lorsque nous sommes informés d'une mise à jour:
Quand on clique sur le Voir les détails de la version x.x lien, WordPress effectue une autre recherche dans le dépôt du plugin. Cette fois, il obtient des informations plus détaillées sur le plugin, telles que sa description, son journal des modifications, la version de WordPress testée, et bien d’autres choses encore. Ces informations nous sont montrées dans une lightbox:
Enfin, lorsque le Mettre à jour maintenant le lien est cliqué, le package du plugin mis à jour est téléchargé et installé.
Alors pourquoi les mises à jour automatiques ne fonctionnent-elles pas pour les plug-ins auto-hébergés?? C'est parce que WordPress essaie de le trouver dans le référentiel du plugin WordPress et ne le trouve pas là!
Notre plan est d'activer les mises à jour automatiques avec notre plugin hébergé par GitHub.
Voici une liste de ce que nous devons faire pour que cela fonctionne:
Nous allons utiliser des filtres WordPress afin de mettre en œuvre notre plan de jeu. Ceux-ci sont:
Accentsconagua
pre_set_site_transient_update_plugins. Ce filtre est appelé lorsque WordPress tente de rechercher des mises à jour de plug-ins..plugins_api. Celui-ci est utilisé lorsque WordPress affiche les détails de la mise à jour du plugin.upgrader_post_install. Enfin, ceci est appelé après l'installation d'un plugin..Nous allons nous accrocher à ces filtres, puis insérer nos données dans les résultats pour créer WordPress pense que notre plugin est dans le référentiel de plugins WordPress. Les données que nous mettrons proviendront de notre référentiel GitHub et devraient imiter les données fournies par le référentiel de plug-ins..
Avant de procéder au codage, parlons d’abord de GitHub et de la façon dont nous allons l’utiliser pour diffuser les données dont nous avons besoin pour alimenter WordPress..
Vous aurez besoin d'un référentiel GitHub privé ou public. Votre rapport devrait contenir tous vos fichiers de plugin, et non une copie compressée de votre plugin.
Nous allons utiliser une fonctionnalité intéressante de GitHub appelée Communiqués.
La bonne chose à propos des versions est qu’elles récupèrent la base de code actuelle dans le référentiel et créent un fichier zip téléchargeable pour chaque version spécifique. Nous pouvons dire à WordPress de télécharger ce fichier zip lors de la mise à jour de notre plugin.
Une autre bonne chose à propos de Releases est que nous pouvons inclure les détails de la mise à jour de notre plugin dans les notes de publication. Nous pouvons ensuite analyser cela et l’afficher dans la lightbox montre WordPress pour les détails de la mise à jour du plugin. Nous pouvons aller plus loin et même permettre le démarquage de GitHub pour notre changelog.
Quand il est temps de déployer une mise à jour de notre plugin, suivez la mise en forme de l'image ci-dessus lorsque vous créez une nouvelle version:
Il est maintenant temps de coder notre plugin!
Tout d'abord, nous créons le point de départ de notre classe:
classe BFIGitHubPluginUpdater private $ slug; // plugin slug private $ pluginData; // plugin data private $ username; // nom d'utilisateur GitHub private $ repo; // nom du dépôt GitHub private $ pluginFile; // __FILE__ de notre plugin private $ githubAPIResult; // contient les données de GitHub private $ accessToken; // fonction de jeton de dépôt privé GitHub __construct ($ pluginFile, $ gitHubUsername, $ gitHubProjectName, $ accessToken = ") add_filter (" pre_set_site_transient_update_plugins ", array ($ this," setTransitent "); add_falter, this, "setPluginInfo"), 10, 3); add_filter ("upgrader_post_install", array ($ this, "postInstall"), 10, 3); $ this-> pluginFile = $ pluginFile; $ this-> username = $ gitHubUsername ; $ this-> repo = $ gitHubProjectName; $ this-> accessToken = $ accessToken; // Obtenir des informations sur notre plugin à partir de la fonction privée WordPress initPluginData () // code ici // Obtenir des informations sur notre plugin à partir de GitHub private function getRepoReleaseInfo () // code ici // Envoie les informations de version du plugin pour obtenir la fonction publique de notification de mise à jour setTransitent ($ transitoire) // code ici return $ transient; // Envoie les informations de version du plugin à afficher dans le détails lightbox public function setPluginInfo ($ false, $ action, $ response) // code eh re return $ response; // Effectuer des actions supplémentaires pour installer avec succès notre fonction publique plugin postInstall ($ true, $ hook_extra, $ result) // code here return $ result; C'est la structure de classe que nous allons utiliser. Nous avons principalement défini toutes les fonctions que nous allons utiliser et créé nos crochets de filtre. Cette classe ne fait rien pour l'instant, si ce n'est assigner des valeurs aux propriétés de la classe.
Pour que notre classe puisse s'exécuter, nous aurons besoin de quelques arguments:
$ pluginFile: Nous appellerons cette classe à partir de notre script de plugin principal, cela devrait avoir la valeur __FICHIER__. Nous aurons plus tard des détails sur notre plugin.$ gitHubUsername: Votre nom d'utilisateur GitHub$ gitHubProjectName: Votre nom de référentiel GitHub$ accessToken: Un jeton d’accès qui nous permettra d’afficher les détails d’un dépôt GitHub privé. Si votre projet est hébergé dans un dépôt GitHub public, laissez ce champ vide..Maintenant remplissons les fonctions de notre classe avec du code.
Vous pouvez en savoir plus sur la création de jetons d'accès à l'aide de l'aide GitHub. Vous pouvez également lire le fonctionnement de l'API GitHub..initPluginData Une fonctionC'est la fonction la plus simple de notre classe. Nous aurons besoin du slug de notre plugin et d'autres informations dans le reste du script, nous mettons donc les appels nécessaires dans une fonction pour plus de commodité..
$ this-> slug = plugin_basename ($ this-> pluginFile); $ this-> pluginData = get_plugin_data ($ this-> pluginFile);
getRepoReleaseInfo Une fonctionCette fonction concerne la communication avec GitHub pour obtenir nos informations de publication. Nous allons utiliser l'API GitHub pour obtenir des détails sur notre dernière version. Puis rangez tout ce que nous avons dans notre githubAPIResult propriété pour traitement futur.
le pre_set_site_transient_update_plugins Le filtre est appelé deux fois par WordPress, une fois lorsqu'il recherche les mises à jour du plug-in, puis un autre après l'obtention des résultats. Comme nous allons utiliser cette fonction dans ce filtre, nous interrogerons l'API GitHub à deux reprises. Nous avons juste besoin d'obtenir des informations de GitHub une fois:
// Ne le fait qu'une fois si (! Empty ($ this-> githubAPIResult)) retour;
Ensuite, nous utiliserons l'API GitHub pour obtenir des informations sur nos versions:
// Interroge l'API GitHub $ url = "https://api.github.com/repos/$this->usernameName/$this->repo/releases"; // Nous avons besoin du jeton d'accès pour les pensions privées if (! Empty ($ this-> accessToken)) $ url = add_query_arg (array ("access_token" => $ this-> accessToken), $ url); // Récupère les résultats $ this-> githubAPIResult = wp_remote_retrieve_body (wp_remote_get ($ url)); if (! empty ($ this-> githubAPIResult)) $ this-> githubAPIResult = @json_decode ($ this-> githubAPIResult); Enfin, nous ne conserverons que les données de la dernière version du plug-in:
// N'utilise que la dernière version if (is_array ($ this-> githubAPIResult)) $ this-> githubAPIResult = $ this-> githubAPIResult [0];
Nous pouvons maintenant obtenir les données de notre plugin auprès de GitHub. Nous allons analyser ces données dans les fonctions suivantes.
setTransitent Une fonctionCette fonction est appelée lorsque WordPress recherche les mises à jour du plugin. Notre travail ici consiste à utiliser les données de notre version de GitHub pour fournir des informations sur la mise à jour de notre plugin..
La première chose à faire est de vérifier si WordPress a déjà vérifié les mises à jour de plug-ins auparavant. Si c'est le cas, il n'est pas nécessaire d'exécuter à nouveau le reste de la fonction.
// Si nous avons déjà vérifié les données du plugin, ne revérifiez pas si (vide ($ transitoire-> coché)) return $ transitoire;
Ensuite, nous obtiendrons les informations de plug-in que nous allons utiliser:
// Obtenir les informations sur la version du plugin & GitHub $ this-> initPluginData (); $ this-> getRepoReleaseInfo ();
Après avoir appelé ces deux fonctions, nous pouvons vérifier la version de notre plugin local à partir de la version (le nom de la balise) trouvée dans GitHub. Nous pouvons utiliser la commodité de PHP version_compare fonction pour comparer les deux valeurs:
// Vérifie les versions si nous devons faire une mise à jour $ doUpdate = version_compare ($ this-> githubAPIResult-> tag_name, $ transient-> vérifié [$ this-> slug]);
Enfin, une mise à jour de plugin est disponible, nous devons demander à l'administrateur d'afficher une notification de mise à jour. Nous faisons cela en remplissant le $ transitoire variable avec nos informations de plugin mises à jour.
// Mise à jour du transitoire pour inclure nos données de plug-in mises à jour if ($ doUpdate == 1) $ package = $ this-> githubAPIResult-> zipball_url; // Inclut le jeton d'accès pour les dépôts GitHub privés if (! Empty ($ this-> accessToken)) $ package = add_query_arg (array ("access_token" => $ this-> accessToken), $ package); $ obj = new stdClass (); $ obj-> slug = $ this-> slug; $ obj-> new_version = $ this-> githubAPIResult-> tag_name; $ obj-> url = $ this-> pluginData ["PluginURI"]; $ obj-> package = $ package; $ transitoire-> réponse [$ this-> slug] = $ obj; return $ transitoire; Une fois que cette fonction aura traité nos informations GitHub, notre administrateur pourra afficher les notifications sur la page d’administration du plug-in:
setPluginInfo Une fonctionLe but de cette fonction est de rassembler des détails concernant le plugin mis à jour à partir des notes de publication. Toutes ces informations seront affichées dans une boîte à lumière lorsque le Voir les détails de la version x.x le lien est cliqué.
Premièrement, obtenons nos informations de plugin:
// Obtenir les informations sur la version du plugin & GitHub $ this-> initPluginData (); $ this-> getRepoReleaseInfo ();
Ensuite, nous vérifions s'il est temps d'afficher quoi que ce soit. Nous pouvons vérifier si nous essayons de charger les informations de notre plugin actuel en vérifiant la limace:
// Si rien n'est trouvé, ne fait rien si (vide ($ response-> slug) || $ response-> slug! = $ This-> slug) return false;
Pour afficher les détails de notre plugin, nous devons ajouter nos informations de plugin manuellement à la $ réponse variable, normalement cette variable serait renseignée avec les résultats du référentiel du plugin WordPress:
// Ajouter nos informations de plugin $ response-> last_updated = $ this-> githubAPIResult-> published_at; $ réponse-> slug = $ this-> slug; $ response-> plugin_name = $ this-> pluginData ["Name"]; $ response-> version = $ this-> githubAPIResult-> tag_name; $ response-> author = $ this-> pluginData ["AuthorName"]; $ response-> homepage = $ this-> pluginData ["PluginURI"]; // Ceci est notre version du fichier zip de téléchargement $ downloadLink = $ this-> githubAPIResult-> zipball_url; // Inclut le jeton d'accès pour les dépôts privés GitHub si (! Empty ($ this-> accessToken)) $ downloadLink = add_query_arg (array ("access_token" => $ this-> accessToken), $ downloadLink); $ response-> download_link = $ downloadLink; Jusqu'à présent, nous avons ajouté les détails de notre plugin, mais nous n'avons pas encore analysé nos notes de publication de notre version de GitHub. Voyons ce que nous avons dans nos notes de publication:
Dans les notes de publication, nous avons spécifié trois détails concernant notre version: notre journal des modifications, suivi de la version minimale requise de WordPress, puis de la dernière version de WordPress dans laquelle le plugin a été testé. Nous allons analyser ce texte et extraire ces valeurs.
Puisque nous hébergeons notre plugin dans GitHub, il serait intéressant de pouvoir utiliser GitHub Markdown dans nos notes de publication. Je vais utiliser une classe PHP appelée ParseDown convertir le texte de démarque en HTML:
// Nous allons analyser les notes de publication du balisage GitHub et inclure l'analyseur require_once (plugin_dir_path (__FILE__). "Parsedown.php");
Nous allons également créer des onglets dans la lightbox pour la rendre conforme à la manière dont les plugins hébergés dans le référentiel WordPress affichent leurs informations. L'un sera pour la description du plugin et l'autre pour notre journal des modifications:
// Créer des onglets dans la boîte à lumière $ response-> sections = array ('description' => $ this-> pluginData ["Description"], 'changelog' => class_exists ("Parsedown")? Parsedown :: instance () - > parse ($ this-> githubAPIResult-> body): $ this-> githubAPIResult-> body); Enfin, nous allons extraire les valeurs pour le a besoin et testé:
// Obtient la version requise de WP si disponible $ matches = null; preg_match ("/requires:\s([\d\.]+)/i", $ this-> githubAPIResult-> body, $ correspond à); if (! empty ($ correspond à)) if (is_array ($ correspond à)) if (nombre (correspond à))> 1) $ réponse-> requiert = $ correspondance [1]; // Obtient la version testée de WP si disponible $ matches = null; preg_match ("/tested:\s([\d\.]+)/i", $ this-> githubAPIResult-> body, $ correspond à); if (! empty ($ correspond à)) if (is_array ($ correspond à)) if (nombre (correspond à))> 1) $ réponse-> testé = $ correspond à [1]; return $ response; post-installation Une fonctionCette dernière fonction traitera de l'exécution de processus supplémentaires dont nous avons besoin pour installer complètement notre plugin après son téléchargement..
Lors de la création d'une version pour notre dépôt GitHub, un fichier zip est automatiquement créé pour cette version. Le nom de fichier du fichier zip est généré par GitHub au format reponame-tagname.zip. Cela contient également un répertoire où se trouvent nos fichiers de plugins. De même, le nom du répertoire correspondant suit également le format nom-prénom.
Normalement, lorsque WordPress télécharge et décompresse une archive de plug-in, le nom du répertoire du plug-in ne change pas. Si vous êtes le répertoire du plugin est mon-génial-plugin, après avoir supprimé les anciens fichiers du plugin et décompressé le fichier mis à jour, votre répertoire serait toujours nommé mon-génial-plugin. Mais comme GitHub change le nom du répertoire de notre plugin chaque fois que nous déployons une version, WordPress ne pourra pas trouver notre plugin. Il serait toujours capable de l'installer, mais il ne pourrait pas le réactiver. Nous pouvons résoudre ce problème en renommant le nouveau répertoire afin qu'il corresponde à l'ancien..
La première chose est la première:
// Récupère les informations du plugin $ this-> initPluginData ();
Ensuite, nous devons vérifier si notre plugin est actuellement activé pour pouvoir le réactiver ensuite:
// Rappelez-vous si notre plugin avait déjà été activé $ wasActivated = is_plugin_active ($ this-> slug);
Maintenant, nous renommons notre répertoire de plugins mis à jour pour correspondre à l'ancien. Nous utilisons la fonction bouge toi ici, mais puisque nous spécifions le même répertoire, ce serait comme le renommer:
// Étant donné que nous sommes hébergés dans GitHub, notre dossier de plugins aurait un nom de répertoire de // nomfichier_référentiel le changer pour le nom d'origine: global $ wp_filesystem; $ pluginFolder = WP_PLUGIN_DIR. DIRECTORY_SEPARATOR. dirname ($ this-> slug); $ wp_filesystem-> move ($ result ['destination'], $ pluginFolder); $ result ['destination'] = $ pluginFolder;
La dernière étape serait de réactiver le plugin:
// Réactiver le plugin si nécessaire si ($ wasActivated) $ activate = activate_plugin ($ this-> slug); return $ result;
Maintenant que le cours est terminé, il ne reste plus qu'à l'appeler dans notre fichier de plugin principal:
require_once ('BFIGitHubPluginUploader.php'); if (is_admin ()) new BFIGitHubPluginUpdater (__FILE__, 'myGitHubUsername', "Nom du stock"); C'est tout! Incluez simplement cette classe et appelez-la dans votre plugin, et il devrait commencer à vérifier les mises à jour automatiquement.
Pour vérifier si cela fonctionne, créez une nouvelle version pour votre dépôt GitHub et suivez les instructions données précédemment:
Une fois que vous avez créé votre version, vous pouvez forcer WordPress à rechercher les mises à jour en cliquant sur le bouton d'actualisation situé dans la barre d'administration..
J'espère que vous avez appris quelque chose sur le fonctionnement de WordPress et sur le processus de mise à jour des plugins. Vous pouvez télécharger le script complet à partir des liens de téléchargement en haut de cet article..
J'espère que vous avez apprécié cet article. J'apprécie hautement vos commentaires, commentaires et suggestions. Partagez vos pensées ci-dessous!
