Share
Când vine vorba de scrierea pluginurilor WordPress, există în general două moduri de a face acest lucru: programarea orientată pe obiecte și programarea funcțională (cu excepția Widget-urilor - vom acoperi mai târziu în articol).
Deși, în general, oamenii au cerut un stil de programare peste celălalt, fiecare prezintă propriul set de avantaje și dezavantaje.
În această serie cu două părți, Stephen Harris și cu mine vom descompune cele două căi pe care le puteți scrie despre pluginurile WordPress. Mai precis, o să vorbesc despre programarea orientată pe obiecte și el va acoperi programarea funcțională.
Deoarece nivelul de experiență al cititorilor variază, vom vorbi despre programarea la nivel înalt, deci dacă sunteți începător, atunci nu ar trebui să aveți nicio problemă în urma. Dacă totuși sunteți un dezvoltator mai experimentat, puteți găsi mai multe informații mai utile mai târziu în articol.
Cu acest lucru, să începem să ne uităm la o abordare orientată pe obiecte pentru dezvoltarea pluginurilor WordPress.
După cum se menționează în introducere, pluginurile pot fi dezvoltate pentru WordPress în două moduri:
Cel de-al doilea articol din seria va cuprinde Programarea funcțională, dar să oferim o definiție de lucru a programării orientate pe obiecte, astfel încât să ne aflăm la același nivel pe tot parcursul acestui articol.
Wikipedia afirmă:
Programarea orientată pe obiecte (OOP) este o paradigmă de programare care utilizează "obiecte" - de obicei instanțe ale unei clase - constând din câmpuri și metode de date împreună cu interacțiunile lor - pentru a proiecta aplicații și programe de calculator.
Cei care au mai multă experiență în programarea pe calculator, mai ales cei care folosesc tehnici de programare orientate pe obiecte, vor dori probabil această definiție.
Dar hai să o simpităm în scopurile acestui articol:
Programarea orientată pe obiecte este o tehnică de programare care folosește o colecție de metode asociate pentru a defini un program de calculator sau o parte a unui program de calculator.
Destul de simplu, nu? În cazul nostru, pluginurile noastre sunt cu siguranță parte de un program de calculator, deoarece acestea se hrănește în WordPress.
Deși vom examina codul în restul acestui articol, rețineți că programele orientate pe obiecte sunt identificate prin gruparea metodelor asociate acestora și acea se face în contextul a ceea ce se numește o clasă - pe care o vom acoperi momentan.
Deși este adevărat că pluginurile WordPress pot fi dezvoltate folosind OOP sau programare funcțională, există o excepție atunci când vine vorba de dezvoltarea Widgets.
Conform articolului Codex privind dezvoltarea de widgeturi, următoarea structură va fi utilizată pentru scrierea unui widget:
clasa My_Widget extinde WP_Widget funcția publică __construct () // widget real processes formularul funcției publice ($ instance) // ieșeste formularul de opțiuni pe admin actualizarea funcției publice ($ new_instance, $ old_instance) // procesează opțiunile widgetului pentru a fi salvat widget-ul funcției publice ($ args, $ instance) // expune conținutul widgetului
Aceasta înseamnă că toate Widget-urile ar trebui să fie scrise folosind OOP. Dacă nu ați văzut coduri ca cele de mai sus, vom acoperi acest lucru în secțiunea următoare și ar trebui să ofere tot ce trebuie să știți pentru a înțelege ce se întâmplă.
Înainte de a începe să ne uităm la construirea pluginurilor bazate pe OOP pentru WordPress, să examinăm mai atent noțiunile de bază ale OOP pentru a ne asigura că suntem clari în ceea ce privește terminologia și cum funcționează paradigma.
După cum am definit mai devreme, OOP utilizează "o colecție de metode conexe". Dar nu ne putem opri aici. La urma urmei, programarea funcțională face același lucru.
În PLO, aceste "metode conexe" sunt toate legate în contextul a ceea ce se numește a clasă. În exemplul Widget de mai sus, veți vedea clasă cuvânt cheie ca primul cuvânt din cod.
Începe pe o linie care se termină cu un consola de deschidere (la fel ca și funcțiile) și apoi încapsulează sau împachetează toate funcțiile sale înrudite înainte de a termina cu suportul de închidere (pentru moment ignorați extinde cuvânt cheie în exemplul Widget - vom atinge asta într-un moment).
Dacă tocmai începeți cu orele de scriere și vă întrebați dacă o funcție aparține unei clase date, întrebați-vă dacă funcția pare a fi ceva pe care o anumită clasă ar face-o.
De exemplu, în exemplul Widget de mai sus, Actualizați metoda este, evident, ceva ce ar face un widget. Dar să zicem că scrieți o clasă care va fi responsabilă pentru citirea unei postări de blog în baza de date WordPress. Ar fi logic ca acea clasă să aibă o funcție numită citit sau read_by_id, dar ar trebui să aibă o funcție numită scrie? Ce ziceti șterge?
În funcție de modul în care ți-ai proiectat clasa, posibil. Dar dacă unic scopul clasei este de a citi datele, probabil că nu.
Și asta este OOP: în mod logic vă grupați funcțiile într-o clasă, dar gruparea logică depinde de responsabilitatea pe care o acordați clasei.
OOP este o paradigmă puternică care este utilizată în întreaga aplicație WordPress. OOP permite operații avansate, cum ar fi moștenirea (care este reprezentată de extinde cuvânt cheie din clasa Widget), modele de design care sunt în esență soluții existente la problemele comune.
Acest articol nu încearcă să fie o scufundare adâncă în programarea orientată pe obiecte. Este pur și simplu încercarea de a oferi o bază de pe care putem explora cele două moduri de a scrie plugin-uri WordPress, dar le menționez aici ar trebui să vă interesează în scufundări în continuare în programare orientată obiect.
Acum că am definit programarea orientată pe obiecte și am explorat suficient pentru a pune o fundație, este timpul să începem să vorbim despre componentele dezvoltării bazate pe OOP în contextul pluginurilor WordPress.
În restul acestui articol, vom aborda elementele de bază ale ceea ce este necesar pentru scrierea pluginurilor OOP și a avantajelor pe care le aduce.
Înainte de a face orice în dezvoltarea orientată pe obiecte, trebuie să definiți clasa. Presupunând că aveți deja o idee despre ceea ce va face clasa voastră, aceasta este în general o chestiune de a veni cu ceea ce doriți să vă numiți clasa.
În cea mai mare parte, cred că exemplul de vizualizare a codului este întotdeauna avantajos atunci când de fapt, de predare cod, așa că vom fi aruncați o privire la WordPress Plugin Boilerplate.
Rețineți că boilerplate-ul Plugin-ului este un proiect pe care l-am creat inițial pentru a ajuta la lansarea plug-in-urilor bazate pe OOP. De atunci a fost contribuit de un număr de oameni diferiți. Îl folosesc în acest articol, deoarece demonstrează subiectul la îndemână.
Acestea fiind spuse, observați că definiția clasei pentru Boilerplate Plugin-ului arată astfel:
clasa PluginName // Mai mult să vină ...
Deoarece Boilerplate Plug-in-ului este un loc de pornire pentru dezvoltare, vom redenumi, evident, clasa. Pentru acest articol, să o numim DemoPlugin.
class DemoPlugin // Mai mult să vină ...
În acest moment, suntem gata să începem să definim funcții care trăiesc în cadrul clasei.
În OOP, prima funcție pe care o puteți vedea într-o clasă este o funcție numită "constructor", iar PHP nu este diferită.
O definiție simplă, de lucru a constructorului este următoarea:
Constructorul este locul unde inițializați datele care vor fi utilizate în întreaga clasă.
Cum funcționează aceasta variază de la proiect la proiect, dar există două lucruri primare pe care le putem face în contextul unui plugin WordPress:
În a noastră DemoPlugin, o să facem doar asta. Vom seta o fereastră de text Demo-plugin și vom înregistra acțiuni pentru înregistrarea și înscrierea unui exemplu de foaie de stil și a unui exemplu de fișier JavaScript.
Pentru a fi completă în exemplul nostru, vom înregistra, de asemenea, un cârlig pentru adăugarea unui text la sfârșitul conținutului afișat într-o postare.
Mai întâi, să definim constructorul:
class DemoPlugin funcția publică __construct ()
Rețineți că în PHP un constructor este definit de o funcție publică numită construi care este precedată de două sublinieri.
În continuare, să definim textul nostru:
Accentsconagua
class DemoPlugin funcția publică __construct () load_plugin_textdomain ('demo-plugin', fals, nume_dată (plugin_basename (__FILE__)). '/ lang'); În linia de mai sus a codului, rețineți că am definit cheia pentru textul nostru Demo-plugin iar linia se așteaptă să găsească fișierele de localizare dintr-un subdirector numit lang în directorul plugin-ului.
Deoarece localizarea este în afara domeniului de aplicare pentru acest articol, nu voi mai face scufundări, dar puteți examina codul sursă pentru Boilerplate Plug-in pentru a vedea cum se configurează acest lucru.
Apoi, definim acțiunile de înregistrare a foilor de stil și a JavaScript, precum și filtrul care va adăuga un text la sfârșitul conținutului nostru:
class DemoPlugin funcția publică __construct () load_plugin_textdomain ('demo-plugin', fals, nume_dată (plugin_basename (__FILE__)). '/ lang'); add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_styles')); add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_scripts')); add_filter ('the_content', array ($ this, 'append_post_notification')); Dacă nu sunteți familiarizat cu acțiunile și filtrele, asigurați-vă că ați citit unul dintre articolele mele recente de aici despre Wptuts +, deoarece explică diferența.
Acum, dacă sunteți familiarizați cu dezvoltarea temelor WordPress sau cu programarea funcțională, probabil că ați fost obișnuiți să vedeți ceva de genul:
add_action ('wp_enqueue_scripts', 'register_plugin_styles'); Decat:
add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_styles')); Observați că diferența dintre cele două apeluri de mai sus este în al doilea parametru. În mod specific, în plugin-ul nostru trecem printr-o matrice, în timp ce prima linie de cod este pur și simplu să treacă un șir.
Pentru că dezvoltăm acest plugin folosind OOP, WordPress trebuie să știe unde să apeleze register_plugin_styles metodă. Din moment ce trăiește în cadrul clasei noastre, trebuie să-i spunem lui WordPress să numească metoda pe un exemplu al clasei noastre.
Are sens?
În esență, spunem WordPress: Am primit această metodă register_plugin_styles, dar trebuie să o numiți pe o instanță a acestei clase (de aici acest cuvinte cheie).
Dacă sunteți nou în WordPress, dar veniți dintr-un program de fundal, atunci vă puteți imagina că îi spuneți WordPress să facă acest lucru:
$ demo = nou DemoPlugin (); $ Demonstrativă> register_plugin_styles ();
Oricum, linia de jos este că dacă vă dezvoltați pluginurile folosind OOP, atunci tu trebuie sa înregistrați cârligele folosind un matrice cu doi indici: prima fiind $ this iar al doilea este numele funcției.
Dezvoltatorii avansați vor fi familiarizați cu abilitatea PHP de a trece-prin-referene și pass-by-value. În WordPress Development, nu este atât de neobișnuit să vedeți următoarele:
add_action ('wp_enqueue_scripts', array (& $ this, 'register_plugin_styles')); Unde acest este trecut prin referință; cu toate acestea, din PHP 5.4, abilitatea de a trece variabilele prin referință la timpul de apel a fost eliminată. Acesta este motivul pentru care tutorialul optează să treacă prin valoare.
În programare, funcțiile sunt unitățile de cod care sunt esențialmente responsabile de "a face ceva". În programarea orientată pe obiecte, este util să vă gândiți la ele puțin diferit.
În PLO, clasele sunt de obicei reprezentate de substantive. În cazul nostru, avem a DemoPlugin. În mod similar, funcțiile sunt adesea verbe. Asta este, ele sunt acțiuni pe care substantivul nostru le poate lua. În acest moment, am optat deja să definim următoarele funcții:
register_plugin_stylesregister_plugin_scriptsappend_post_notificationObservați cum fiecare nume de funcție reprezintă o acțiune care poate fi luată. Aceasta este o regulă bună pe care o puteți folosi atunci când scrieți funcții.
În programarea funcțională există într-adevăr doar ideea funcțiilor; cu toate acestea, în PLO, există mai multe tipuri diferite de funcții, dintre care două sunt funcții "publice" și "private".
Funcțiile publice sunt funcții care sunt accesibile în afara clasei. Aceasta înseamnă că puteți să apelați aceste metode odată ce ați instanțiat clasa.
Acesta este exact ceea ce am făcut mai devreme în următorul cod:
$ demo = nou DemoPlugin (); $ Demonstrativă> register_plugin_styles ();
Practic, aceste funcții sunt accesibile publicului (unde publicul poate fi un programator sau alt obiect).
Funcțiile pe care le scriem pentru înregistrarea foile de stil, JavaScript și că scriem pentru a adăuga text la o postare avea să fie marcate ca fiind publice pentru că există voi să fie un terț care le solicită - WordPress.
Să definim cele două funcții pentru wp_enqueue_scripts acțiune:
funcția publică register_plugin_styles () wp_register_style ('demo-plugin', plugins_url ('demo-plugin / css / plugin')); wp_enqueue_style ("demo-plugin"); funcția publică register_plugin_scripts () wp_register_script ('demo-plugin', plugins_url ('demo-plugin / js / display.js')); wp_enqueue_script ("demo-plugin"); Din nou, rețineți că aceste două funcții se așteaptă ca foile de stil și JavaScript să se afle css și js subdirectoare, respectiv. Pentru a vedea acest lucru în acțiune, nu uitați să verificați fișierul Plugin Boilerplate.
În cele din urmă, să definim funcția pentru continutul filtru:
funcția publică append_post_notification ($ content) $ notification = __ ("Acest mesaj a fost atașat cu un plugin demo", "demo-plugin-locale"); returneaza continutul $. notificare $; Rețineți că folosim funcția __ pentru a ne asigura că scriptul nostru este localizat cu DOMENIU_TEXT pe care am definit-o în constructor.
Dacă metodele publice sunt accesibile de oricine, atunci ar însemna că funcțiile private nu sunt accesibile nimănui, nu-i așa? În cea mai mare parte, este corect: Singura persoană - sau lucru - care pot apela metode private sunt clasa în care sunt definite.
Asta înseamnă că WordPress, obiecte de la terți și programatori nu pot apela programabil funcții private. Funcțiile private pot fi chemați numai din clasa în care sunt folosite.
În general, funcțiile private sunt foarte utile atunci când se scriu metode de ajutor - adică ele sunt utile pentru manipularea datelor interne pentru a ajuta o altă funcție să-și desfășoare activitatea.
Pentru a da un exemplu de lucru, sa definim o functie privata care va returna un sir localizat pe care-l folosim append_post_notification funcția poate utiliza:
funcția privată get_localized_notification () return __ ('Acest mesaj a fost atașat cu un plugin demo', 'demo-plugin-locale'); Apoi, să refăcut append_post_notification pentru a numi acest nou ajutor:
funcția publică append_post_notification ($ content) return $ content. $ This-> get_localized_notification ();
Observați că am simplificat prima funcție adăugând oa doua funcție. De asemenea, ați putea susține că am crescut lizibilitatea funcției inițiale prin adăugarea unui apel către o funcție cu un nume care ajută la clarificarea situației.
Poate că cel mai important lucru pe care trebuie să îl rețineți este că, pentru a apela funcții private, trebuie să prefixați apelul funcției cu $ this cuvânt cheie și ->. Acest lucru spune PHP: "Sunați la get_localized_notification funcția în care trăiește acest clasă."
În orice caz, am dat fiecărei metode o singură responsabilitate - o altă bună practică în programarea orientată pe obiecte - și am demonstrat utilizarea atât a funcțiilor publice, cât și a celor private.
În programarea orientată pe obiecte, există și alte tipuri de funcții care depășesc sfera de aplicare a acestui articol.
Pentru a fi complet, am vrut să le rezumăm aici:
DemoPlugin :: use_this_static_method (). În acest moment, am atins toate notele mari pentru dezvoltarea WordPress orientată pe obiecte. Pentru a rezuma avantajele:
Când utilizați programarea orientată pe obiecte, nu trebuie să prefixați o funcție cu numele temei sau numele pluginului pe care lucrați și nici nu trebuie să vă faceți griji cu privire la denumirea unei funcții care ar putea interfera cu o funcție WordPress, funcția unei alte teme sau funcția unui alt plugin.
În schimb, toate funcțiile trăiesc în contextul unei alte clase. Singurul lucru de care trebuie să vă asigurați este că clasa voastră nu este numită ceva care interferează cu o altă clasă existentă.
Prin utilizarea programării orientate pe obiecte, puteți apela programatic pluginul dvs. din afara standardului API WordPress.
Să presupunem că dezvoltați o temă și doriți ceva care să redea pe bara laterală pe care plugin-ul dvs. o oferă. În șablonul bara laterală, puteți să instanțiați plugin-ul dvs. și apoi să apelați metode pe el pentru a avea nevoie să scrie informații în bara laterală.
Acest lucru este util în mod special ori de câte ori lucrați la un șablon și doriți să furnizați date implicite dacă utilizatorul nu introduce manual ceva.
Așa cum am spus la începutul articolului: acesta este doar un mod în care vă puteți dezvolta pluginurile WordPress. Articolul lui Stephen se va referi la modul de utilizare a acestuia folosind programarea funcțională.
După ce ați citit acest articol, ar trebui să aveți o mai bună înțelegere a programării orientate pe obiecte, a avantajelor sale și ar trebui să puteți urmări împreună cu codul documentat în API-ul Widget, în Boilerplate-ul meu widget și chiar în locurile din codurile WordPress.
