Share
În primul post din această serie, am discutat motivele pentru care WordPress Plugins ar trebui tratate mai mult ca proiecte software mai mari (dar de multe ori nu sunt) și a făcut un caz pentru utilizarea unui cod bine organizat, în încercarea de a face programele plugin-ului mai sustenabile . Toate acestea s-au făcut în contextul dezvoltării unui widget WordPress.
Lucrul este că widget-urile nu sunt singurul tip de pluginuri care pot fi dezvoltate pentru WordPress. Aplicația suportă și pluginuri care extind funcționalitatea acesteia prin utilizarea de cârlige localizate pe toată aplicația. Ca atare, widget-urile nu sunt singurul tip de plugin care ar putea beneficia de o placă de boiler.
În acest tutorial, vom defini ce sunt exact cârligele WordPress, cum funcționează acestea și de ce sunt benefice. Apoi, vom examina WordPress Widget Boilerplate și modul în care o puteți utiliza în proiecte noi prin contextul unei aplicații de exemplu.
Înainte de a dezvolta pluginuri, este important să înțelegeți modelul WordPress pentru conectarea la aplicație și diferitele dintre acțiuni și filtre.
Destul de ușor, nu? În plus, WordPress are o documentație solidă pentru adăugarea de acțiuni [1] și adăugarea de filtre [2]. Puteți accesa mai multe despre pluginurile din API-ul Plugin [3] în Codul WordPress [4].
Dacă citiți articolul precedent, atunci sunteți deja familiarizat cu API-ul Widget. Este precis prin faptul că necesită un constructor și nu mai puțin de trei funcții pentru a obține ceva de lucru. Deoarece pluginurile au flexibilitatea de a intra într-o varietate de puncte din procesul WordPress, API Plugin-ul este puțin mai structurat. Din fericire, acest lucru nu înseamnă că nu putem să realizăm o formă de boilerplate de pe care să ne creăm pluginurile.
La urma urmei, acestea contin inca o functie comuna:
Similar cu Boilerplate-ul nostru Widget Widget, putem seta directorul nostru de șabloane să arate astfel:
Pare familiar, nu-i așa? Cel mai important aspect al pluginului Boilerplate nu este detaliile structurii directorului (deși vom examina un pic în viitor), dar organizarea codului plugin-ului principal.
Plugin-urile pot fi dezvoltate fie folosind o mulțime de funcții, fie prin împachetarea fiecărei funcții într-o clasă într-o abordare orientată pe obiecte. Sunt un fan al celor din urmă și boilerplate meu reprezintă asta. Iată definiția pluginului:
Accentsconagua
init_plugin_constants (); load_plugin_textdomain (PLUGIN_LOCALE, false, nume_dată (plugin_basename (__FILE__)). '/ lang'); / * * TODO: * Definiți funcționalitatea personalizată pentru pluginul dvs. Primul parametru al apelurilor * add_action / add_filter sunt cârligele în care trebuie să declanșezi codul. * * Al doilea parametru este numele funcției din cadrul acestei clase. Vedeți pumnii * mai târziu în fișier. * * Pentru mai multe informații: * http://codex.wordpress.org/Plugin_API#Hooks.2C_Actions_and_Filters * / add_action ('TODO', array ($ this, 'action_method_name')); add_filter ('TODO', array ($ this, 'nume_film_metodă')); // end if // constructor final / * -------------------------------------- ------ * * Funcții de bază * --------------------------------------- ------ * / / ** * Nota: Actiunile sunt puncte in executarea unei cicluri de viata a unei pagini sau a unui proces * pe care WordPress il incalzeste. * / function action_method_name () // TODO defini metoda ta de actiune aici // end action_method_name / ** * Notă: Filtrele sunt puncte de execuție în care WordPress modifică datele * înainte de a le salva sau de a le trimite în browser. * / function filter_method_name () // TODO defini metoda de filtrare aici // end filter_method_name / * ---------------------------- ---------------- * * Functii private * ----------------------------- ---------------- * / / ** * Inițializează constantele utilizate pentru comoditate pe parcursul * pluginului. * / funcția privată init_plugin_constants () / * TODO * * Acesta oferă identificatorul unic pentru plugin-ul folosit în * localizarea șirurilor folosite pe tot parcursul procesului. * * De exemplu: wordpress-widget-boilerplate-locale. * / if (definit ('PLUGIN_LOCALE')) define ('PLUGIN_LOCALE', 'plugin-name-locale'); // end if / * TODO * * Definiți acest lucru ca numele pluginului. Aceasta este ceea ce arată * în zona Widgets a WordPress. * * De exemplu: WordPress Widget Boilerplate. * / dacă (! definit ('PLUGIN_NAME')) define ('PLUGIN_NAME', 'Nume de plugin'); / / end dacă / * TODO * * acesta este sloganul plugin-ului folosit în inițializarea acestuia cu * API-ul WordPress. * Acesta ar trebui să fie, de asemenea, directorul * în care se află plugin-ul dvs. Folosiți cratime. * * De exemplu: wordpress-widget-boilerplate * / dacă (! Definit ('PLUGIN_SLUG')) define ('PLUGIN_SLUG', plugin-name-slug); // end if // end init_plugin_constants / ** * Funcția Helper pentru înregistrarea și încărcarea scripturilor și stilurilor. * * @name ID-ul care se înregistrează cu WordPress * @file_path Calea spre fișierul real * @is_script Argumentul opțional pentru cazul în care calea de intrare file_path este un fișier sursă JavaScript. * / funcția privată load_file ($ name, $ file_path, $ is_script = false) $ url = WP_PLUGIN_URL. $ Cale_fișier; $ file = WP_PLUGIN_DIR. $ Cale_fișier; dacă (file_exists ($ file)) dacă ($ is_script) wp_register_script ($ nume, $ url); wp_enqueue_script (nume $); altceva wp_register_style ($ name, $ url); wp_enqueue_style (nume $); // end if // end if // end _load_file // clasa de sfârșit // TODO: actualizați apelul de instanțiere al plugin-ului dvs. la numele dat la definiția clasei noi TODO (); ?> Cele mai multe IDE-uri au o funcție care listează toate TODO-urile remarcabile, așadar le pun în întregime în cod pentru a găsi cu ușurință ce trebuie făcut în timpul dezvoltării. Rețineți că există trei zone principale de cod:
Rețineți că dezvoltarea pluginurilor se abate de la dezvoltarea widgetului prin faptul că nu există multiple funcții care sunt așteptate. De fapt, ai nevoie doar de un constructor. De acolo, orice funcții definite în apelurile add_action sau add_filter și responsabilitatea dvs. de a implementa.
Are sens? Să aruncăm o privire asupra folosirii acestei plăci de cazan într-un exemplu simplu.
WordPress oferă cârlige pentru aproape punctul de execuție pe care le puteți imagina. În acest exemplu, vom intra în procesul de randare post pentru a introduce un mesaj personalizat. Chestia este că noi dorim doar să afișăm mesajul menționat în contextul unui cititor RSS.
În primul rând, cerințele:
Pe această bază, nu pare să fi nevoie să folosim JavaScript, CSS sau marcajele pentru a crea plugin-ul nostru, astfel încât să putem reduce boilerplate-ul plugin-ului nostru la codul plugin-ului principal și la fișierele de localizare:
În acest moment, putem începe să stubbing out boilerplate cu un nume și constante plugin:
/ ** * Inițializează constantele folosite pentru comoditate în * pluginul. * / funcția privată init_plugin_constants () if (! definit ('PLUGIN_LOCALE')) define ('PLUGIN_LOCALE', 'rss-note-locale'); // if if (! definit ('PLUGIN_NAME')) define ('PLUGIN_NAME', 'Notă RSS'); // sfârșit dacă dacă (! definit ('PLUGIN_SLUG')) define ('PLUGIN_SLUG', 'rss-note-slug'); // end if // end init_plugin_constants Apoi, trebuie să luăm în considerare ce tip de cârlig este necesar pentru manipularea conținutului. Amintiți-vă că încercăm să adăugăm ceva la conținutul conținutului pentru al redacta în browser, vom avea nevoie de un filtru. De aici, putem distruge constructorul:
/ ** * Inițializează pluginul prin setarea funcțiilor de localizare, filtre și administrare. * / funcția __construct () // Define constnats utilizată în pluginul $ this-> init_plugin_constants (); load_plugin_textdomain (PLUGIN_LOCALE, false, nume_dată (plugin_basename (__FILE__)). '/ lang'); // adăugați nota la fragmentul și la feed-ul principal add_filter ('the_content', array ($ this, 'display_rss_note')); add_filter ('the_excerpt_rss', array ($ this, 'display_rss_note')); // Constructor final Rețineți că funcția utilizează două filtre - unul pentru the_content [5] și unul pentru the_excerpt_rss [6]. Facem acest lucru deoarece unii utilizatori optează să publice doar un fragment al blogului lor, în loc de tot conținutul, și vrem să ne asigurăm că capturam ambele cazuri.
Apoi, să implementăm definiția funcției care va adăuga mesajul la restul postării:
/ ** * Adaugă un mesaj scurt la subsolul fiecărui post vizionat într-un cititor RSS * reamintind utilizatorilor să viziteze site-ul dvs. * / funcția publică display_rss_note ($ content) if (is_feed ()) $ content. = '„; $ content = '„; // se închide dacă returnează $ content; // end display_rss_note„; $ content = = __ ("Vă mulțumim pentru lectură! Asigurați-vă că vă atingeți restul postărilor mele de la", PLUGIN_LOCALE); $ conținut. = ''; $ content = get_bloginfo ("nume"); $ conținut. = '!'; $ content = '
„; $ content = '
Rețineți că funcția acceptă un parametru la care se referă variabila de conținut $. WordPress însăși transmite aceste date în funcție. Pentru aceste filtre particulare, avem de-a face cu conținutul unei postări pe blog, deci tot ceea ce adăugăm trebuie să fie concatenat, astfel încât să fie adăugat la sfârșitul acestuia.
Acest mesaj pe care îl adăugăm pur și simplu spune: "Vă mulțumim pentru lectură! Asigurați-vă că vă căutați din celelalte postări de la [Blog Name]!" prin utilizarea funcției get_bloginfo () [7]? Desigur, îl puteți actualiza pentru a citi ce vă place. În cele din urmă, rețineți că am împachetat acest lucru într-o condiție care verifică funcția is_feed () [8]. Acest lucru este important deoarece dorim ca acest cod să se declanșeze numai dacă conținutul este trimis printr-un feed RSS.
Asta e - nu prea rău, nu-i așa? Puteți descărca versiunea completă a codului sursă de lucru (inclusiv README asociat) pentru acest plugin pe GitHub sau chiar aici de la Wptuts. Boilerplate-ul este disponibil și pe GitHub.
Scopul acestei serii nu a fost doar de a contribui la furnizarea unui ghid introductiv pentru API-ul WordPress Plugin, ci și la furnizarea unui caz și a plăcilor de boiler pentru a face mult mai ușor pentru a trata și menține WordPress Plugins ca orice alt proiect software.
