Share
WordPress a făcut convenabil ca pluginurile să fie distribuite publicului. Doar puneți plugin-ul în depozitul de plugin-uri WordPress și poate fi ușor găsit de către oameni din interiorul tabloului de bord.
Probabil una dintre cele mai bune caracteristici ale repozitorului este aceea că ușurează actualizarea pluginurilor din interiorul tabloului de bord. Actualizările de notificări sunt afișate în interiorul tabloului de bord, iar efectuarea unei actualizări este la fel de ușoară ca și efectuarea unui clic Actualizează acum buton.
Dar ce zici dacă ați fi vrut să găzduiți plugin-ul singur? Funcția de actualizare convenabilă nu va fi disponibilă dacă găzduiți plugin-ul în afara repo-ului plugin-ului WordPress. Nici utilizatorii dvs. nu ar fi notificați despre o actualizare disponibilă.
Acest articol vă va învăța că, cu puțină codificare creativă, puteți găzdui propriile pluginuri WordPress în GitHub, păstrând în același timp funcția de actualizare automată.
S-ar putea să existe o serie de motive pentru care doriți să găzduiți pluginul în afara depozitului de plugin-uri WordPress. Una dintre principalele restricții pe care le oferă depozitul este că trebuie să licențiați pluginul ca GPLv2. Nu mă voi concentra asupra detaliilor licențierii, dar pe scurt, înseamnă că oricine poate să-ți împărtășească munca. Deci, dacă doriți să vă vindeți pluginul, atunci găzduirea acestuia într-un depozit privat GitHub este acum o opțiune pe care o puteți lua.
Cu toate acestea, datorită modului în care WordPress a fost construit, gazduirea plugin-ului dvs. în GitHub ar fi dezactivați actualizările automate pentru pluginul nostru. Pentru a înțelege de ce este cazul, trebuie să înțelegem modul în care WordPress gestionează actualizările pluginului.
Puteți afla mai multe despre depozitul de plugin-uri WordPress citind Liniile directoare detaliate ale pluginurilor.În primul rând, să investigăm modul în care WordPress efectuează actualizări de pluginuri pentru a înțelege mai bine de ce pluginurile găzduite automat nu pot avea actualizări automate
WordPress verifică periodic depozitul WordPress pentru actualizările pluginurilor instalate. Acesta primește o grămadă de informații despre fiecare plugin, cum ar fi cea mai recentă versiune și adresa URL a pachetului de plugin-uri. Aceasta este ceea ce vedem de obicei în pagina de administrare a plugin-urilor atunci când suntem notificați despre o actualizare:
Când faceți clic pe Vedeți detaliile versiunii x.x link-ul, WordPress efectuează o altă căutare în plugin-ul repo. De data aceasta devine mai multe informații detaliate despre plugin, cum ar fi descrierea, changelog-ul, versiunea WordPress testată și multe altele. Aceste informații ne sunt afișate într-o casetă lightbox:
În cele din urmă, atunci când Actualizează acum se face clic pe linkul, pachetul actualizat de plugin-uri este descărcat și instalat.
Deci, de ce actualizările automate nu funcționează pentru pluginurile găzduite automat? Este pentru că WordPress încearcă să o găsească în depozitul de plugin-uri WordPress și nu o poate găsi acolo!
Planul nostru este să permiteți actualizările automate cu pluginul găzduit de GitHub.
Iată o listă a ceea ce trebuie să facem pentru a funcționa:
Vom folosi câteva filtre WordPress pentru a implementa planul nostru de joc. Acestea sunt:
Accentsconagua
pre_set_site_transient_update_plugins. Acest filtru este apelat când WordPress încearcă să verifice actualizările pluginului.plugins_api. Acesta este folosit când WordPress prezintă detaliile de actualizare a pluginului.upgrader_post_install. În cele din urmă, acest lucru se numește după ce un plugin este instalat cu succes.Vom creea în aceste filtre, apoi împingeți datele noastre în rezultate pentru a face WordPress gândi că plugin-ul nostru este în depozitul de plugin-uri WordPress. Datele pe care le vom pune vor proveni de la repo GitHub și ar trebui să imite datele furnizate de depozitul de plugin-uri.
Înainte de a începe codarea, hai să vorbim mai întâi despre GitHub și cum o vom folosi pentru a da datele de care avem nevoie pentru a alimenta WordPress.
Veți avea nevoie de un depozit GitHub privat sau public. Repo-ul dvs. ar trebui să conțină toate fișierele pluginului dvs. și nu o copie comprimată a pluginului.
Vom folosi o caracteristică rece a numelui GitHub Lansări.
Cel mai bun lucru despre lansări este faptul că primește codul curent în depozit și creează un fișier zip descărcabil pentru fiecare versiune specifică. Putem spune WordPress să descarce acest fișier zip atunci când actualizează plugin-ul nostru.
Un alt lucru bun despre lansări este că putem pune în detaliu plugin-ul nostru în notele de lansare. Putem apoi să analizăm acest lucru și să îl afișeze în caseta de lumină WordPress arată pentru detaliile actualizării pluginului. Putem să mergem mai departe și chiar să permitem marcarea GitHub pentru changelog-ul nostru.
Când este momentul să implementați o actualizare în pluginul nostru, urmați formatul din imaginea de mai sus atunci când creați o nouă versiune:
Acum este momentul să codificați pluginul nostru!
În primul rând, vom crea punctul de plecare pentru clasa noastră:
clasa BFIGitHubPluginUpdater privat $ slug; / / plugin plugin privat $ pluginData; // plugin date private $ username; // numele de utilizator GitHub privat $ repo; // GitHub nume de repo nume privat $ pluginFile; // __FILE__ din pluginul nostru privat $ githubAPIResult; // deține datele din GitHub private $ accessToken; // Funcția GitHub privată a funcției de repo __construct ($ pluginFile, $ gitHubUsername, $ gitHubProjectName, $ accessToken = ") add_filter (" pre_set_site_transient_update_plugins ", array ($ this," setTransitent ")) add_filter (" plugins_api " acest lucru, "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; // Obțineți informații despre plugin-ul nostru din funcția privată WordPress initPluginData () // code here // Obțineți informații despre plugin-ul nostru de la GitHub privat functie getRepoReleaseInfo () // cod aici // Apasati in versiunea pluginului pentru a obtine functia publica de notificare update setTransitent ($ tranzitoriu) // cod aici return $ tranzitor; // Apasati in versiunea versiunii pluginului pentru a fi afisat in detalii lightbox funcția publică setPluginInfo ($ false, $ action, $ answer) // code eh retur răspuns $; // Efectuați acțiuni suplimentare pentru a instala cu succes pluginul public postInstall ($ true, $ hook_extra, $ result) // cod aici return $ result; Aceasta este structura de clasă pe care o vom folosi. Am definit în principal toate funcțiile pe care le vom folosi și am creat cârligele de filtrare. Această clasă nu face nimic din moment, exceptând atribuirea de valori proprietăților clasei.
Pentru ca clasa noastră să fie executată, vom avea nevoie de câteva argumente:
$ pluginFile: Vom numi această clasă din script-ul nostru principal de plugin-uri, aceasta ar trebui să aibă valoarea __FIŞIER__. Vom primi detalii despre plugin-ul nostru mai târziu.$ gitHubUsername: Numele de utilizator GitHub$ gitHubProjectName: Numele GitHub repository$ accessToken: Un jeton de acces care ne va permite să vizualizăm detaliile unui repo GitHub privat. Dacă proiectul dvs. este găzduit într-un repo GitHub public, lăsați-l complet.Acum să umplem funcțiile clasei noastre cu un anumit cod.
Puteți afla mai multe despre crearea jetoanelor de acces din ajutorul GitHub. Puteți citi, de asemenea, cum funcționează API-ul GitHub.initPluginData FuncţieAceasta este cea mai simplă funcție din clasa noastră. Vom avea nevoie de plugin-ul nostru de slug și alte informații pe parcursul restului script-ului, așa că punem apelurile necesare într-o funcție pentru comoditate.
$ this-> slug = plugin_basename ($ this-> pluginFile); $ this-> pluginData = get_plugin_data ($ this-> pluginFile);
getRepoReleaseInfo FuncţieAceastă funcție are legătură cu comunicarea cu GitHub pentru a obține informațiile despre lansare. Vom folosi API-ul GitHub pentru a obține detalii cu privire la cea mai recentă versiune. Apoi, stoca tot ce avem în noi githubAPIResult proprietate pentru prelucrare ulterioară.
pre_set_site_transient_update_plugins filtrul este chemat de două ori de WordPress, o dată când verifică actualizările plug-in-ului, apoi un alt după ce a obținut rezultate. Deoarece vom folosi această funcție în filtrul respectiv, vom interoga API-ul GitHub de două ori. Trebuie doar să obținem informații de la GitHub odată:
// Faceți acest lucru o singură dată dacă (! Empty ($ this-> githubAPIResult)) return;
Apoi, vom folosi API-ul GitHub pentru a obține informații despre lansările noastre:
// Solicitați API-ul GitHub $ url = "https://api.github.com/repos/$this->username/$this->repo/releases"; // Avem nevoie de tokenul de acces pentru repo-urile private dacă (! Empty ($ this-> accessToken)) $ url = add_query_arg (array ("access_token" => $ this-> accessToken), $ url); // Obțineți rezultatele $ this-> githubAPIResult = wp_remote_retrieve_body (wp_remote_get ($ url)); dacă (! gol ($ this-> githubAPIResult)) $ acest-> githubAPIResult = @json_decode ($ this-> githubAPIResult); În cele din urmă, vom păstra numai datele pentru cea mai recentă versiune a pluginului:
// Utilizați numai cea mai recentă versiune dacă (is_array ($ this-> githubAPIResult)) $ this-> githubAPIResult = $ this-> githubAPIResult [0];
Acum putem obține datele pluginului nostru de la GitHub. Vom analiza aceste date în funcțiile următoare.
setTransitent FuncţieAceastă funcție se numește când WordPress verifică actualizările pluginului. Misiunea noastră aici este să folosim datele noastre de lansare GitHub pentru a furniza informații pentru actualizarea pluginului nostru.
Primul lucru pe care îl facem este să verificăm dacă WordPress a verificat deja actualizările de pluginuri. Dacă are, atunci nu mai trebuie să executăm din nou restul funcției.
// Dacă am verificat datele plugin-ului înainte, nu verificați dacă (gol ($ tranzitor-> verificat)) return $ transitory;
Apoi, vom primi informațiile plugin-ului pe care le vom folosi:
// Obțineți informații de lansare pentru plugin și GitHub $ this-> initPluginData (); $ This-> getRepoReleaseInfo ();
După apelarea acestor două funcții, putem verifica versiunea pluginului nostru local din versiunea (numele etichetei) găsită în GitHub. Putem folosi PHP convenabil version_compare pentru a compara cele două valori:
// Verificați versiunile dacă trebuie să facem o actualizare $ doUpdate = version_compare ($ this-> githubAPIResult-> tag_name, $ tranient-> checked [$ this-> slug]);
În cele din urmă, există o actualizare a plugin-ului disponibil, trebuie să solicităm administratorului să afișeze o notificare de actualizare. Facem asta prin completarea $ tranzitorie variabilă cu informațiile noastre despre plugin-ul actualizat.
// Actualizați intervalul temporar pentru a include datele pluginului actualizat dacă ($ doUpdate == 1) $ package = $ this-> githubAPIResult-> zipball_url; // Includeți tokenul de acces pentru replici GitHub privat dacă (! Empty ($ this-> accessToken)) $ package = add_query_arg (array ("access_token" => $ this-> accessToken), $ package); $ obj = noua stdClass (); $ obj-> slug = $ this-> slug; $ obj-> new_version = $ this-> githubAPIResult-> nume_timp; $ obj-> url = $ this-> pluginData ["PluginURI"]; $ obj-> pachet = $ pachet; $ tranzitor-> răspuns [$ this-> slug] = $ obj; return $ $ tranzitorii; După ce această funcție procesează informațiile GitHub, administratorul nostru va putea afișa notificări în pagina de administrare a pluginurilor:
setPluginInfo FuncţieScopul acestei funcții este de a aduna detalii despre plugin-ul actualizat din notele de lansare. Toate aceste informații vor fi afișate în interiorul unei casete lightbox atunci când Vedeți detaliile versiunii x.x se face clic pe linkul.
În primul rând, să luăm informațiile despre pluginul nostru:
// Obțineți informații de lansare pentru plugin și GitHub $ this-> initPluginData (); $ This-> getRepoReleaseInfo ();
Apoi verificăm dacă este sau nu timpul să afișați ceva. Putem verifica dacă încercăm să încărcăm informații despre plugin-ul nostru curent, verificând melc:
// Dacă nimic nu este găsit, nu face nimic dacă (gol ($ răspuns-> slug) || $ răspuns-> slug! = $ This-> slug) return false;
Pentru a afișa detaliile pluginului, trebuie să adăugăm manual informațiile despre pluginul nostru răspuns $ variabilă, în mod normal, această variabilă ar fi populată cu rezultatele din depozitul de plugin-uri WordPress:
// Adăugați informațiile despre plugin-ul nostru $ answer-> last_updated = $ this-> githubAPIResult-> published_at; $ răspuns-> slug = $ this-> slug; $ răspuns-> plugin_name = $ this-> pluginData ["Nume"]; $ răspuns-> versiune = $ acest-> githubAPIResult-> nume_tag; $ răspuns-> author = $ this-> pluginData ["AutorName"]; $ răspuns-> homepage = $ this-> pluginData ["PluginURI"]; // Aceasta este versiunea noastră descărcare zip fișier $ downloadLink = $ this-> githubAPIResult-> zipball_url; // Includeți tokenul de acces pentru GitHub repos privat dacă (! Empty ($ this-> accessToken)) $ downloadLink = add_query_arg (array ("access_token" => $ this-> accessToken), $ downloadLink); $ răspuns-> download_link = $ downloadLink; Până acum am adăugat detaliile pluginului, dar nu am analizat încă notele noastre de lansare din versiunea GitHub. Să verificăm ce avem în notele noastre de lansare:
În notele de lansare am specificat trei detalii privind versiunea noastră: versiunea noastră de modificări, urmată de versiunea minimă necesară pentru WordPress, ultima versiune WordPress în care a fost testat pluginul. Vom analiza acest text și vom extrage aceste valori.
Din moment ce găzduim plugin-ul nostru în GitHub, ar fi bine dacă putem avea capacitatea de a utiliza markdown GitHub în notele noastre de lansare. Voi folosi o clasă PHP numită ParseDown pentru a converti textul în marcaj în HTML:
// Vom analiza notele de lansare a marcajului GitHub, include parserul requ_once (plugin_dir_path (__FILE__). "Parsedown.php");
Vom crea, de asemenea, file în caseta lightbox pentru a se conforma cu modul în care depozitele WordPress găzduite de plugin-uri își afișează informațiile. Unul va fi pentru descrierea plugin-ului, iar celălalt va fi pentru changelog-ul nostru:
// Crearea filelor în caseta lightbox $ response-> sections = array ('description' => $ this-> pluginData ["Descriere"], 'changelog' => class_exists ("Parsedown" > parse ($ this-> githubAPIResult-> corp): $ this-> githubAPIResult-> body); În cele din urmă, vom extrage valorile pentru necesită și testat:
// Obține versiunea necesară a WP dacă este disponibilă $ matches = null; preg_match ("/requires:\s([\d\.++)/i", $ this-> githubAPIResult-> corp, $ meciuri); dacă este gol ($ matches)) if (is_array ($ matches)) if (count ($ matches)> 1) $ response-> requires = $ matches [1]; // Obține versiunea testată de WP dacă este disponibil $ matches = null; preg_match ("/tested:\s([\d\.++)/i", $ this-> githubAPIResult-> corp, $ meciuri); dacă este gol ($ matches)) if (is_array ($ matches)) if (count ($ matches)> 1) $ response-> tested = $ matches [1]; returna răspunsul $; postInstall FuncţieAceastă ultimă funcție se va ocupa de efectuarea unor procese suplimentare pe care trebuie să le instalăm pe deplin după ce este descărcat.
Când creați o versiune pentru repo GitHub, acesta creează automat un fișier zip pentru acea versiune specifică. Numele de fișier pentru fișierul zip este generat de GitHub cu formatul reponame-tagname.zip. Acesta conține, de asemenea, un director în care sunt localizate fișierele noastre de pluginuri. În mod similar, numele directorului pentru acest lucru urmează formatul reponame-tagname.
În mod normal, când WordPress descarcă și dezarhivează o arhivă a pluginului, numele directorului plugin-ului nu se schimbă. Dacă sunteți directorul plugin-ului este mi-minunat-plugin, după ștergerea vechilor fișiere de plugin și dezarhivarea celei actualizate, sunteți directorul va fi numit în continuare mi-minunat-plugin. Dar, deoarece GitHub schimbă numele directorului plugin-ului de fiecare dată când implementăm o versiune, WordPress nu va putea găsi plugin-ul nostru. Încă ar fi în stare să o instaleze, dar nu o va putea reactiva. Putem rezolva această problemă prin redenumirea noului director pentru a se potrivi cu cel vechi.
Să începem cu începutul:
// Obțineți informații de plugin $ this-> initPluginData ();
Apoi trebuie să verificăm dacă pluginul nostru este activat în prezent, astfel încât să îl putem reactiva după aceea:
// Amintiți-vă dacă pluginul nostru a fost activat anterior $ wasActivated = is_plugin_active ($ this-> slug);
Acum redenumim directorul plugin actualizat pentru a se potrivi cu cel vechi. Folosim funcția mișcare aici, dar din moment ce specificăm același director, ar fi la fel ca redenumirea acestuia:
// Deoarece suntem găzduiți în GitHub, dosarul plugin-ului nostru ar avea o dirname de // reponame-tagname care îl schimbă în originalul nostru: global $ wp_filesystem; $ pluginFolder = WP_PLUGIN_DIR. DIRECTORY_SEPARATOR. dirname ($ this-> slug); $ wp_filesystem-> mutați ($ result ['destination'], $ pluginFolder); $ result ['destinație'] = $ pluginFolder;
Ultimul pas ar fi reactivarea pluginului:
// Reactivarea plugin-ului dacă este necesar dacă ($ wasActivated) $ activate = activate_plugin ($ this-> slug); retur $ rezultat;
Acum, că clasa este terminată, tot ce trebuie să faceți este să o numiți în fișierul nostru principal de plugin:
require_once ('BFIGitHubPluginUploader.php'); dacă (is_admin ()) nou BFIGitHubPluginUpdater (__FILE__, 'myGitHubUsername', 'Repo-Name'); Asta e! Doar includeți această clasă și apelați-o în plugin-ul dvs. și ar trebui să înceapă automat verificarea actualizărilor.
Pentru a testa dacă funcționează, creați o nouă versiune pentru replica dvs. GitHub și urmați liniile directoare specificate mai devreme:
După ce ați creat versiunea, puteți să forțați WordPress să verifice actualizările făcând clic pe butonul de reîmprospătare găsit în bara de administrare.
Sper că ați învățat un lucru sau două despre cum funcționează WordPress și cum se realizează întregul proces de actualizare a pluginurilor. Puteți descărca scriptul complet din linkurile de descărcare din partea de sus a acestui articol.
Sper că ți-a plăcut acest articol. Apreciez foarte mult orice feedback, comentarii și sugestii. Împărtășește-ți gândurile de mai jos!
