Share
În ultima mea serie de articole, am analizat conceptele programării orientate obiect din perspectiva începătorului. Scopul seriei a fost acela de a lua pe cei care nu erau familiarizați cu programarea orientată-obiect în PHP și de a explora aspectele fundamentale ale paradigmei în contextul WordPress.
Dacă nu ați avut ocazia să citiți seria, puteți să citiți un rezumat succint (împreună cu link-uri către fiecare articol din serie) în mesajul final.
În cursul seriei, unul din lucrurile pe care le-am făcut pentru a demonstra principiile orientate pe obiecte, precum și unele dintre caracteristicile API-ului WordPress a fost construirea unui plugin.
Mai precis, am construit un plugin care ne-a permis să vizualizăm toate datele meta date asociate unei postări date în tabloul de bord WordPress.
Pluginul este disponibil pentru descărcare de pe GitHub unde puteți de asemenea să răsfoiți codul sursă, să vizualizați comentariile despre cod și, în general, să vedeți tot ce a urmat creării plugin-ului atunci când l-am dezvoltat.
De când a fost scrisă o anumită postare, am primit o serie de întrebări diferite, unul dintre care a fost modul în care luăm datele afișate în tabloul de bord - adică meta date postare - și afișăm-o în partea din față a paginii web teren.
În acest articol, vom examina extensia pluginului astfel încât să putem afișa datele pe o singură pagină de postare. Vom vorbi despre cum să facem acest lucru, având în vedere codul nostru existent, cum să facem acest lucru și vom vorbi de asemenea de ce ar putea să nu fie o idee bună.
Cu ce a spus asta, să începem.
Înainte de a începe să planificăm modul în care vom extinde plugin-ul, cred că merită o scurtă discuție cu privire la afișarea acestui tip de informații pe interfață - deși este posibil - poate că nu este o idee bună.
Adică cred că acest lucru este un caz în care, atunci când se ocupă cu anumite tipuri de date, este important să se ia în considerare ramificațiile a ceea ce optăm să facem atunci când construim produse pentru alții și cum gestionăm datele.
Pe scurt, doar pentru că noi poate sa face ceva nu înseamnă că noi ar trebui să Fă-o.
Gândiți-vă în acest fel: datele meta asociate cu o postare dată sunt stocate în baza de date - unele de WordPress, unele de teme și altele de pluginuri - toate acestea utilizează informațiile pentru nevoile lor specifice.
Dacă aruncați o privire la imaginea de mai sus, veți observa că unele rânduri sunt identificate prin chei prefixate cu o subliniere. De exemplu, avem _edit_lock și _edit_last și apoi câteva valori numerice. Acesta este un exemplu de date pe care WordPress le utilizează pentru a gestiona intern starea posturilor.
Celelalte chei pe care le vedeți au de a face cu plugin-urile pe care le-am instalat în instalarea WordPress locală și sunt folosite pentru a demonstra cum alte utilitare pot salva date în tabela meta date și apoi o pot raporta la postul dat.
Problema cu afișarea tuturor acestor informații în partea frontală este că ar putea fi afișate prea multe informații pentru utilizator.
În cazul de mai sus, nu este nimic deosebit de periculos sau sensibil care ar putea ajuta la compromiterea instalării, dar asta nu înseamnă că va fi întotdeauna cazul. Chiar și mai mult, există șanse semnificative să sfârșim afișarea informațiilor legate de un plugin sau de o temă care nu și-a dorit ca informațiile să fie afișate.
În plus, pentru mulți - sau chiar cei mai mulți - care vizitează un blog, văzând că informațiile afișate în partea din față a blogului vor arăta ca zgomotul. Jargonul tehnic nu înseamnă nimic. Acesta este motivul pentru care cred că păstrarea acestor informații retrogradate la tabloul de bord este cel mai bun loc pentru a face acest lucru.
Pe scurt, da, dar nu pentru că cred că afișarea acestui tip de informație către utilizator este o idee bună, ci pentru că există o aplicație practică care vine cu extinderea unui plugin existent, beneficiile utilizării codului existent și văzând ramificațiile negative ale a face astfel.
Deci da - uneori, cele mai bune lecții pot veni din idei de implementare care ar putea să nu fie bune în retrospectivă.
Dar este în regulă. Acesta este modul în care învățăm, corect?
În plus, există încă câteva lecții practice care vin cu învățarea modului de extindere a unei baze de cod existente.
Ca și în toate tutorialele pe care le împărtășesc, încerc să planific exact ce facem să facem înainte să o facem, astfel încât să nu codificăm o mulțime de lucrări de ghici și să avem un plan de acțiune privind arhitectura soluției noastre.
Așadar, înainte de a merge mai departe, dacă nu ați revizuit Managerul Meta Post Meta, atunci vă rugăm să faceți acest lucru acum și vom continua.
După ce ați terminat, iată ce intenționăm să facem:
Accentsconagua
public parte a blogului în mod specific în contextul posturilor unice.Nimic prea complicat, nu? Trebuie doar să fim mai clari în pașii noștri. Deci sa începem.
Presupunând că ați activat deja douăzeci și unsprezece și plugin-ul instalat, hai să lucrăm la introducerea funcționalității noastre. Primul lucru pe care trebuie să-l facem este
public directorSingle_Post_Meta_Manager_Public clasăDupă adăugarea fișierelor, cele de mai sus se pot face prin următoarele rânduri de coduri load_dependencies funcția în include / un singur post-meta-manager.php.
funcția privată load_dependencies () require_once plugin_dir_path (dirname (__FILE__)). 'Admin / clasa-un singur post-meta-manager-admin.php'; require_once plugin_dir_path (dirname (__FILE__)). 'Public / clasă-un singur post-meta-manager-public.php'; require_once plugin_dir_path (__FILE__). 'Clasă-un singur post-meta-manager-loader.php'; $ acest-> încărcător = nou Single_Post_Meta_Manager_Loader ();
Observați că singura linie nouă este cea de-a doua require_once care importă fișierul de clasă.
După aceea, să definim proprietățile, constructorul și metodele pentru Single_Post_Meta_Manager_Public clasă:
versiune = $ versiune; / ** * Utilizează parțial localizat în directorul admin pentru redarea metadatelor * post după sfârșitul conținutului mesajului. * * @ param string $ content Conținutul mesajului. * @ retur string $ content Conținutul postului, inclusiv datele postate date meta. * / funcția publică display_post_meta_data ($ content) ob_start (); require_once plugin_dir_path (dirname (__FILE__)). 'Admin / amprente parțiale / un singur post-meta-manager.php'; $ template = ob_get_contents (); $ content = $ șablon; ob_end_clean (); returnați conținut $;
Apoi, trebuie să creați Managerul unic de mesaje Meta define_public_hooks funcţie. Ar trebui să arate astfel:
get_version ()); $ this-> loader-> add_action ('the_content', $ public, 'display_post_meta_data'); Apoi, trebuie să definim un apel la această funcție în interiorul constructorului. Adică, chiar sub limita $ This-> define_admin_hooks (); line, adăugați $ This-> define_public_hooks (); apel.
Presupunând că totul a mers bine, ar trebui să puteți activa pluginul, să încărcați orice postare și să vedeți aceleași meta date afișate acum în partea din față a postului, precum și în tabloul de bord al postării:
Așa cum am menționat mai devreme în acest tutorial, afișarea acestui tip de informații pe capătul unui post nu este neapărat cea mai bună idee; cu toate acestea, învățarea cum să adăugați practic la un plugin existent va introduce funcționalități complet noi, în timp ce reutilizați și unele dintre componentele existente.
În cele din urmă, reținerea cheie este de două ori:
Deci, după ce ați citit acest tutorial special, rețineți că nu susțin neapărat acest lucru într-un mediu la nivel de producție, ci mai mult ca un instrument de învățare. Asta este, folosiți-l pe propriul dvs. risc.
Ca de obicei, vă rugăm să lăsați toate întrebările, comentariile și multe altele în feedul de mai jos!
