Crearea WordPress Meta Boxes Refactoring

De-a lungul acestei serii, ne-am concentrat pe construirea de meniuri WordPress care pot fi întreținute. Prin asta, vreau sa spun ca am lucrat pentru a crea un plugin WordPress bine organizat, urmeaza standardele de codare WordPress si care poate fi usor adaptat si mentinut pe masura ce proiectul se misca in timp.

Deși am implementat câteva bune practici, există încă loc pentru refactorizare. Pentru această serie, acest lucru se face prin design. Ori de câte ori lucrați la un proiect pentru un client sau pentru o companie mai mare, șansele de a vă menține o bază de cod existentă sunt destul de mari. Ca atare, am vrut să ne putem întoarce la codul de bază pentru a rafina o parte din codul pe care l-am scris.

Rețineți că acest articol nu va fi scris în formatul pe care alții au fost scrise - adică nu va exista o abordare a dezvoltării "Facem întâi asta, apoi facem asta". În schimb, vom evidenția mai multe domenii care au nevoie de refactorizare și apoi le vom trata independent de celelalte schimbări pe care le facem.

refactorizare

Pentru a fi clar, actul refactorizării (așa cum este definit de Wikipedia) este:

Refactorizarea îmbunătățește atributele nefuncționale ale software-ului. Avantajele includ o citire mai bună a codului și o complexitate redusă pentru îmbunătățirea mentenabilității codului sursă și crearea unei arhitecturi interne mai expresive sau a unui model de obiect pentru a îmbunătăți extensibilitatea.

Pe scurt, face codul mai ușor de citit, mai puțin complex, mai ușor de urmărit și face acest lucru fără a schimba comportamentul codului de la punctul de vedere al utilizatorilor finali.

Acest lucru se poate realiza în mai multe moduri diferite, fiecare fiind unic pentru proiectul dat. În cazul nostru, vom analiza refactorizarea constructorilor noștri, unele dintre metodele noastre de salvare, câteva dintre metodele noastre de ajutor și multe altele.

În cele din urmă, obiectivul este de a arăta câteva strategii care pot fi utilizate pe parcursul viitoarelor eforturi WordPress. Voi încerca să acoperim cât mai mult posibil în acest articol; totuși, rețineți că pot exista oportunități pentru refactorizări suplimentare care nu sunt acoperite.

Dacă este așa, minunat! Simțiți-vă liber să le faceți pe propriul dvs. exemplu de bază de cod. Cu asta a spus, să începem.

Constructorul

Dacă vă uitați la constructorul nostru:

nume = $ nume; $ this-> version = $ version; $ this-> meta_box = nou Autorii_Commentare_Meta_Box (); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_styles')); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_scripts'));

Observați că în prezent efectuează două lucruri:

Inițializarea proprietăților, cum ar fi numele și versiunea
Înregistrarea cârligelor cu WordPress

Este o practică obișnuită să vedeți cârlige setate în contextul unui constructor într-un plugin WordPress, dar nu este într-adevăr un loc minunat pentru a face acest lucru.

Un constructor ar trebui utilizat pentru a inițializa toate proprietățile care sunt relevante pentru clasa dată, astfel încât atunci când un utilizator instanțiază o clasă, el / ea are tot ce este necesar pentru a lucra cu clasa.

Din moment ce este posibil ca aceștia să nu vrea să înregistreze cârligele la momentul inițializării clasei, trebuie să le abrogem în propria lor initialize_hooks metodă. Codul nostru ar trebui să arate astfel:

nume = $ nume; $ this-> version = $ version; $ this-> meta_box = nou Autorii_Commentare_Meta_Box ();  funcția publică initialize_hooks () add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_styles')); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_scripts'));

După aceea, trebuie să ne asigurăm că actualizăm codul de bază al autori-commentary.php astfel încât să instanțiate corect și să înregistreze cârligele.

initialize_hooks ();  run_author_commentary ();

Aici, principala diferență este că am actualizat numărul de versiune pe care îl transmitem la clasa principală și suntem, de asemenea, sunând în mod explicit initialize_hooks funcția în contextul run_author_commentary.

Dacă executați codul dvs. chiar acum, totul ar trebui să funcționeze exact așa cum a procedat înainte de această refacere.

Aș dori, de asemenea, să adaug că puteți face un caz pentru a avea o clasă separată responsabilă de coordonarea cârligelor și a apelurilor telefonice, astfel încât responsabilitatea să se afle într-o clasă separată. Deși sunt un fan al acestei abordări, este în afara domeniului de aplicare al acestui articol special.

Apoi, să mergem mai departe și să facem același lucru clasă-autori-comentarii-meta-box.php. În loc să creați o funcție nouă, putem redenumi pur și simplu constructorul, deoarece constructorul nu face nimic. Aceasta înseamnă că codul nostru ar trebui să meargă după cum urmează:

La acest:

Și modificarea finală pe care trebuie să o facem este să actualizăm constructorul din clasa principală astfel încât să se citească acum în interiorul initialize_hooks funcția pe care am creat-o în clasa plugin-ului principal.

meta_box-> initialize_hooks (); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_styles')); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_scripts'));

Din nou, reîmprospătați pagina și plugin-ul dvs. trebuie să funcționeze exact așa cum a fost înainte de această refactorizare.

Metode de ajutor

În Authors_Commentary_Meta_Box clasa, avem un număr de condiționalități în save_post care sunt foarte redundante. Când se întâmplă acest lucru, aceasta înseamnă de obicei că o mare parte din funcționalitate poate fi abstractizată într-o funcție de ajutor și apoi apelată din interiorul funcției în care au fost inițial plasate.

Să aruncăm o privire la codul așa cum este acum:

is_valid_post_type () || ! $ this-> user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) retur;  // Dacă textarea 'Drafts' a fost populată, atunci am dezinfectat informațiile. ($ _POST ['autori-commentary-drafts'])) // vom elimina toate spațiile albe, etichetele HTML și vom codifica informațiile care trebuie salvate $ drafts = trim ($ _POST [ comentarii-drafts]]; $ drafts = esc_textarea (strip_tags ($ drafts)); update_post_meta ($ post_id, 'authors-drafts', $ drafts);  altceva if (! == get_post_meta ($ post_id, 'authors-comments-drafts', true)) delete_post_meta ($ post_id, authors- drafts drafts) există, iterați prin ele și dezinfectați-le dacă (! empty ($ _POST ['autori-commentary-resources'])) $ resources = $ _POST ['authors- commentary- resources']; ($ resource = resource); $ resource = esc_url (strip_tags ($ resource)); if ($ empty ($ resource)) $ sanitized_resources [] = $ resource; update_post_meta ($ post_id, ($ post_id, "authors-commentary-resources", true)) delete_post_meta ($ post_id, "autori-comentarii-resurse");  // Dacă există valori salvate în intrarea "Publicat", salvați-le dacă ! Empty $ _POST ['autori-commentary-comments'])) update_post_meta ($ post_id, , $ _POST ["autori-comentarii-comentarii"]);  altceva if (! == get_post_meta ($ post_id, 'authors-commentary-comments', true)) delete_post_meta ($ post_id,

În afară de metoda care este prea lungă pentru a începe, există o serie de lucruri pe care le putem curăța:

Condiționarea inițială care utilizează logica nu și logică SAU operatori
Condițiile care verifică prezența informațiilor în $ _POST mulțime
Funcțiile de dezinfectare, actualizare și / sau ștergere pentru meta date asociate

Deci, haideți să aruncăm o privire la fiecare dintre acestea în mod individual și să lucrăm la refăcând această funcție.

1. Condiția inițială

Scopul primei verificări condiționale este de a vă asigura că utilizatorul curent are capacitatea de a salva date în postul dat. În momentul de față, verificăm literalmente dacă tipul de post curent este un tip de post valid și dacă utilizatorul are permisiunea de a salva, având în vedere valorile curente care nu sunt transmise de WordPress.

Chiar acum, codul citește:

Dacă acesta nu este un tip de post valid sau dacă utilizatorul nu are permisiunea de a salva, închideți această funcție.

Nu toate sunt împreună teribile, dar cu siguranță ar putea fi îmbunătățite. În loc să ai un SAU, să o consolidăm într-o singură evaluare, astfel încât să se citească:

Dacă utilizatorul nu are permisiunea de a salva, închideți această funcție.

Din fericire, acesta este un remediu relativ ușor. Deoarece tipul de post care este salvat ajută să dicteze dacă utilizatorul are sau nu permisiunea de a salva postul, putem muta această logică în user_can_save funcţie.

Deci haideți să luăm is_valid_post_type și mutați-l în user_can_save funcţie:

is_valid_post_type () && $ is_valid_nonce;

Acum, toată logica care este responsabilă pentru a determina dacă utilizatorul poate salva datele post-meta este încapsulată într-o funcție special creată pentru a evalua exact acea.

Am inceput cu aceasta:

is_valid_post_type () || ! $ this-> user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) retur;

Și acum avem acest lucru:

user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) return;

Citește mult mai ușor, nu-i așa??

2. Verificarea matricei $ _POST

Apoi, înainte de a începe dezinfectarea, validarea și salvarea (sau ștergerea) datelor meta, verificăm $ _POST pentru a vă asigura că datele există.

Putem scrie o mică funcție de ajutor, care va avea grijă de această evaluare pentru noi. Deși în esență scriem un pic de cod care face ca evaluarea noastră să fie mai verbală, condiționările vor fi mai clare decât dacă le-am lăsa așa cum este.

Mai întâi, introduceți următoarea funcție (și rețineți că este nevoie de un parametru):

Apoi, refactor toate apelurile care au fost inițial de asteptare ! gol ($ _POST [...]) astfel încât să profite de această funcție.

De exemplu, apelurile pentru funcții ar trebui să arate astfel:

dacă ($ this-> value_exists ("autori-comentarii-comentarii")) // ... altceva // ...

2. Ștergerea datelor meta

Rețineți că pe parcursul condițiilor care sunt plasate în acea funcție, fiecare evaluare pentru ștergerea datelor post-meta dacă valoarea nu există pare exact aceeași.

De exemplu, vedem ceva de genul asta de fiecare dată:

Aceasta este o șansă evidentă de a reface codul. Ca atare, hai să creăm o nouă funcție numită delete_post_meta și să o încapsuleze toate aceste informații:

Acum putem face înapoi și înlocuiți toate celelalte evaluări condiționale pentru a face un apel la această singură funcție, astfel încât să citească ceva de genul:

value_exists ('authirs-commentary-drafts')) // Vom elimina toate spațiul alb, etichetele HTML și codificăm informațiile care trebuie salvate $ drafts = trim ($ _POST ['authors-comments-drafts']); $ drafts = esc_textarea (strip_tags ($ drafts)); update_post_meta ($ post_id, 'authors-drafts', $ drafts);  altceva $ this-> delete_post_meta ($ post_id, "autori-comentarii-drafts");

În acest moment, avem într-adevăr un alt aspect al acestei părți a codului la refactor.

3. Sanitizarea și salvarea

În prezent, modul în care sunt salvate datele post-meta se face astfel printr-un proces de evaluare a prezenței datelor în $ _POST colectând, dezinfectând-o pe baza tipului de informații și apoi salvând-o la datele post-meta.

În mod ideal, am dori să dezinfectăm datele în funcția sa proprie, precum și să salvăm post-meta-datele în funcție proprie. Astfel, trebuie să introducem noi funcții.

Mai întâi, să lucrăm la dezintoxicare. Pentru că avem de-a face cu textarea și a rețelelor, există câteva moduri în care trebuie să facem apelul la dezintoxicare. Deoarece lucrăm fie cu o matrice, fie nu suntem, putem crea o funcție care acceptă un parametru opțional care să indice dacă lucrăm sau nu cu un tablou.

Dacă nu lucrăm cu o matrice, atunci vom trata datele primite ca text; în caz contrar, o vom trata ca o matrice:

Apoi, putem actualiza apelurile de dezintoxicare pentru a utiliza această metodă. Dar, înainte de a face acest lucru, să scriem, de asemenea, un mic ajutor, care va fi responsabil pentru actualizarea post-meta datelor cu intrările dezinfectate:

Acum putem actualiza toate condițiile pe care le-am folosit mai devreme în funcția de a citi astfel:

user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) return;  dacă ($ this-> value_exists ("autori-comment-drafts")) $ this-> update_post_meta ($ post_id, "authors- commentary drafts", $ this-> sanitize_data );  altceva $ this-> delete_post_meta ($ post_id, "autori-comentarii-drafts");  dacă ($ this-> value_exists ('author-commentary-resources')) $ this-> update_post_meta ($ post_id, 'authors- commentary- resources', $ this-> sanitize_data Adevărat ) );  altceva $ this-> delete_post_meta ($ post_id, "autori-comentarii-resurse");  dacă ($ this-> value_exists ('authors-commentary-comments')) $ this-> update_post_meta ($ post_id, 'authors-commentary-comments', $ _POST ['authors-commentary-comments');  altceva $ this-> delete_post_meta ($ post_id, "autori-comentarii-comentarii");

Rețineți că am putea refactoriza acest lucru chiar mai mult, astfel încât nu există atât de multe condiționări, dar din motive de lungime a articolului, durata de timp și, de asemenea, încercarea de a introduce alte strategii, acest lucru va fi lăsat ca un exercițiu care trebuie făcut în timpul tău.

Concluzie

Până acum, am terminat pluginul nostru. Am scris un plugin care introduce o casetă meta pentru a oferi opțiuni autorilor care scriu mesaje pe blog.

În plus, am folosit standardele de codare WordPress, unele strategii puternice de organizare a fișierelor și am creat o serie de metode și abstracții de ajutor care ne vor ajuta să menținem acest plugin special, deoarece acesta este supus dezvoltării viitoare.

Deoarece nu este ușor să subliniem fiecare ocazie pentru refactorizare, sunt posibile modificări suplimentare care ar putea fi făcute. În timpul vostru, nu ezitați să încercați să implementați unele dintre ele pe cont propriu.

În general, sper că v-ați bucurat de seria și ați învățat multe din ea și sper că vă va ajuta să scrieți un cod mai bun și mai sustenabil în viitoarele proiecte bazate pe WordPress.

Cod