Opprett Vedlikeholdbare WordPress Meta Bokser Refactoring

Gjennom hele denne serien har vi fokusert på å bygge vedlikeholdbare WordPress meta bokser. Dermed mener jeg at vi har jobbet for å lage et WordPress-plugin som er godt organisert, følger WordPress-kodingsstandarder, og det kan enkelt tilpasses og vedlikeholdes ettersom prosjektet beveger seg fremover over tid.

Selv om vi har implementert noen gode praksiser, er det fortsatt plass til refactoring. For denne serien gjøres dette med design. Når du jobber med et prosjekt for en klient eller for et større selskap, er oddsene for at du behøver å opprettholde en eksisterende kodebase, ganske høy. Som sådan ville jeg at vi kunne komme tilbake til kodebase for å finjustere noen av kodene som vi har skrevet.

Merk denne artikkelen vil ikke bli skrevet i formatet som de andre har blitt skrevet - det vil si at det ikke vil være en "Først gjør vi dette, så gjør vi dette" tilnærming til utvikling. I stedet skal vi markere flere områder som trenger refactoring og håndtere dem uavhengig av de andre endringene vi gjør.

refactoring

For å være klar, er act of refactoring (som definert av Wikipedia):

Refactoring forbedrer ikke-funksjonelle attributter av programvaren. Fordeler inkluderer forbedret kodelesbarhet og redusert kompleksitet for å forbedre kildekoden vedlikeholdsevne, og skape en mer ekspressiv intern arkitektur eller objektmodell for å forbedre utvidbarheten.

Kort sagt, det gjør koden mer lesbar, mindre kompleks, enklere å følge, og gjør alt uten å endre kodeksens oppførsel fra sluttbrukerens synspunkt..

Dette kan oppnås på en rekke forskjellige måter som hver er unike for det oppgitte prosjektet. I vårt tilfelle skal vi se på refactoring av våre konstruktører, noen av våre lagringsmetoder, noen av våre hjelpemetoder og mer.

Til slutt er målet å vise noen strategier som kan brukes i ditt fremtidige WordPress-arbeid. Jeg vil sikte på å dekke så mye som mulig i denne artikkelen; Vær imidlertid oppmerksom på at det kan være muligheter for ytterligere refactoring som ikke er dekket.

Hvis det er tilfelle, flott! Du er velkommen til å lage dem på din egen forekomst av kodebase. Med det sagt, la oss komme i gang.

Konstruktøren

Hvis du ser på vår konstruktør:

navn = $ navn; $ this-> version = $ version; $ this-> meta_box = nye Authors_Commentary_Meta_Box (); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_styles')); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_scripts'));

Legg merke til at det for tiden gjør to ting:

Initialiserer egenskaper som navn og versjon
Registrere kroker med WordPress

Det er vanlig å se kroker satt i sammenheng med en konstruktør i et WordPress-plugin, men det er egentlig ikke et flott sted å gjøre det.

En konstruktør bør brukes til å initialisere alle egenskaper som er relevante for den oppgitte klassen, slik at når en bruker instanser en klasse, har han / hun alt som trengs for å jobbe med klassen.

Siden de kanskje ikke vil registrere kroker på det tidspunktet de initialiserer klassen, må vi abstrahere dette til eget initialize_hooks metode. Vår kode skal nå se slik ut:

navn = $ navn; $ this-> version = $ version; $ this-> meta_box = nye Authors_Commentary_Meta_Box ();  offentlig funksjon initialize_hooks () add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_styles')); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_scripts'));

Etter det må vi sørge for å oppdatere kjernekoden til forfattere-commentary.php slik at den ordner riktig og registrerer kroker.

initialize_hooks ();  run_author_commentary ();

Her er hovedforskjellen at vi har oppdatert versjonsnummeret som vi passerer til hovedklassen, og vi kaller også eksplisitt initialize_hooks fungere innenfor rammen av run_author_commentary.

Hvis du kjører koden din akkurat nå, bør alt fungere akkurat som det gjorde før dette refactoring.

Jeg vil også legge til at du kan gjøre en sak for å ha en egen klasse ansvarlig for koordinering av kroker og tilbakeringinger slik at ansvaret ligger i en egen klasse. Selv om jeg er en fan av denne tilnærmingen, er det utenfor rammen av denne spesielle artikkelen.

Neste, la oss gå videre og gjøre det samme klasse-forfattere-kommentar-meta-box.php. I stedet for å skape en ny funksjon, kan vi ganske enkelt gi nytt navn til konstruktøren, siden konstruktøren egentlig ikke gjør noe. Dette betyr at vår kode skal gå fra å se slik ut:

Til dette:

Og den siste endringen vi må gjøre er å oppdatere konstruktøren i hovedklassen slik at den nå leser innsiden av initialize_hooks funksjonen som vi opprettet i hovedtilleggsklassen.

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

Igjen, oppdater siden og pluginet ditt skulle fortsatt fungere akkurat som det var før denne refactoring.

Hjelpermetoder

I Authors_Commentary_Meta_Box klasse, vi har en rekke conditionals i lagre post funksjon som er svært overflødig. Når dette skjer, betyr dette vanligvis at mye av funksjonaliteten kan abstraheres til en hjelperfunksjon og deretter kalt innfra funksjonen der de først ble plassert.

La oss se koden som den står akkurat nå:

is_valid_post_type () || ! $ this-> user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) return;  // Hvis "Drafts" textarea er blitt fylt opp, sanitiserer vi informasjonen. hvis (! tomt ($ _POST ['authors-comment-draft'])) // Vi fjerner alt hvitt mellomrom, HTML-koder og kode informasjonen som skal lagres $ drafts = trim ($ _POST ['authors- kommentarer-utkast ')); $ drafts = esc_textarea (strip_tags ($ drafts)); update_post_meta ($ post_id, 'author-commentary draft', $ drafts);  ellers if ("! == get_post_meta ($ post_id," authors-comment-draft ", true)) delete_post_meta ($ post_id, 'author-comment-draft'); // Hvis ressursene 'Resources' eksisterer, lukter gjennom dem og sanitiserer dem hvis (! tomt ($ _POST ['authors-commentary-resources'])) $ resources = $ _POST ['authors-commentary-resources']; $ sanitized_resources = array (); ($ ressurser som $ ressurs) $ resource = esc_url (strip_tags ($ ressurs)), hvis (! tom ($ ressurs)) $ sanitized_resources [] = $ ressurs; update_post_meta ($ post_id, ressurser ', $ sanitized_resources); else if ("! == get_post_meta ($ post_id," authors-commentary-resources ", sant)) delete_post_meta ($ post_id," authors-commentary-resources ");  // Hvis det er noen verdier lagret i "Publisert" -innspilling, lagre dem hvis (! Tomt ($ _POST ['authors-commentary-comments'])) update_post_meta ($ post_id, 'authors-commentary-comments' , $ _POST ['authors-commentary-comments']);  ellers if ("! == get_post_meta ($ post_id," authors-commentary-comments ", sant)) delete_post_meta ($ post_id," authors-commentary-comments ");

Bortsett fra at metoden er altfor lang til å begynne med, er det en rekke ting vi kan rydde opp:

Den første betingede som bruker logisk ikke og logisk ELLER operatører
Tilstandsbetingelsene som kontrollerer tilstedeværelsen av informasjon i $ _POST matrise
Sanitiserings-, oppdaterings- og / eller slettingsfunksjonene for tilhørende metadata

Så la oss ta en titt på hver av disse individuelt og arbeide med å refactoring denne funksjonen.

1. Den opprinnelige tilstanden

Formålet med den første betingede kontrollen er å sørge for at den nåværende brukeren har muligheten til å lagre data til det angitte innlegget. Akkurat nå sjekker vi bokstavelig talt for å se om den nåværende posttypen er en gyldig innleggstype, og hvis brukeren har tillatelse til å lagre gitt at dagens nåværende verdier blir vedtatt av WordPress.

Akkurat nå leser koden:

Hvis dette ikke er en gyldig posttype eller brukeren ikke har tillatelse til å lagre, avslutter du denne funksjonen.

Det er ikke alt sammen forferdelig, men kan definitivt bli bedre. I stedet for å ha en ELLER, la oss konsolidere det til en enkelt evaluering slik at den leser:

Hvis brukeren ikke har tillatelse til å lagre, avslutter du denne funksjonen.

Heldigvis er dette en relativt enkel løsning. Siden typen post som blir lagret bidrar til å diktere hvorvidt brukeren har tillatelse, lagrer innlegget, kan vi flytte den logikken inn i user_can_save funksjon.

Så la oss ta is_valid_post_type funksjonen og flytt den inn i user_can_save funksjon:

is_valid_post_type () && $ is_valid_nonce;

Nå er all logikken som er ansvarlig for å bestemme om brukeren kan lagre post-metadataene, innkapslet i en funksjon som er spesielt utviklet for å evaluere nøyaktig det.

Vi startet med dette:

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

Og nå har vi dette:

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

Leser mye lettere, gjør det ikke?

2. Kontrollerer $ _POST Array

Neste, før vi begynner å sanitisere, validere og lagre (eller slette) metadata, sjekker vi $ _POST samling for å sikre at dataene egentlig eksisterer.

Vi kan skrive en liten hjelperfunksjon som tar seg av denne evalueringen for oss. Selv om vi i utgangspunktet skriver litt kode som gjør evalueringen mer oversatt, vil betingelsene lese litt klarere enn om vi nettopp hadde forlatt dem som-er.

Først introduserer du følgende funksjon (og merk at det tar i en parameter):

Deretter refactor alle samtalene som ble opprinnelig kalte ! tomt ($ _POST [...]) slik at de utnytter denne funksjonen.

Funksjonssamtalene skal for eksempel se slik ut:

hvis ($ this-> value_exists ('author-commentary-comments')) // ... annet // ...

2. Slette metadata

Legg merke til at i alle betingelsene som er plassert i den funksjonen, vurderer hver evaluering for å slette post-metadata hvis verdien ikke eksisterer, nøyaktig samme.

For eksempel ser vi noe slikt her hver gang:

Dette er en åpenbar sjanse til å refactor koden. Som sådan, la oss opprette en ny funksjon som heter delete_post_meta og få den til å inkapslere all denne informasjonen:

Nå kan vi gjøre tilbake og erstatte alle de andre betingede vurderingene for å ringe til denne enkeltfunksjonen slik at den leser noe som følger:

value_exists ('authirs-commentary-draft')) // Vi fjerner alt hvitt mellomrom, HTML-koder og koder informasjonen som skal lagres $ drafts = trim ($ _POST ['authors-commentary-draft']); $ drafts = esc_textarea (strip_tags ($ drafts)); update_post_meta ($ post_id, 'author-commentary draft', $ drafts);  ellers $ this-> delete_post_meta ($ post_id, 'authors-comment-draft');

På dette punktet har vi egentlig bare ett annet aspekt av denne delen av koden til refactor.

3. Sanitisering og lagring

Akkurat nå er måten postemetallene lagres på, gjort gjennom en prosess for å evaluere tilstedeværelsen av dataene i $ _POST samling, sanitizing det basert på typen informasjon, og deretter lagre den til post-metadataene.

Ideelt sett vil vi gjerne sanitere dataene i egen funksjon, samt lagre innleggets metadata i egen funksjon. Dermed må vi introdusere nye funksjoner.

La oss først jobbe med sanitisering. Fordi vi har å gjøre med textareas og arrays, er det et par måter vi trenger å håndtere sanitiseringssamtalen på. Siden vi enten arbeider med en matrise eller ikke, kan vi lage en funksjon som aksepterer en valgfri parameter som angir hvorvidt vi arbeider med en matrise.

Hvis vi ikke jobber med en matrise, behandler vi innkommende data som tekst; Ellers behandler vi det som en matrise:

Deretter kan vi oppdatere sanitiseringsanropene for å bruke denne metoden. Men før vi gjør det, la oss også skrive en liten hjelper som vil være ansvarlig for å oppdatere post-metadataene med de sanitiserte innganger:

Nå kan vi oppdatere alle betingelsene som vi brukte tidligere i funksjonen for å lese slik:

user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) return;  $ this-> value_exists ('authors-commentary-draft')) $ this-> update_post_meta ($ post_id, 'authors-comment-draft', $ this-> sanitize_data ('author-commentary draft') );  ellers $ this-> delete_post_meta ($ post_id, 'authors-comment-draft');  $ this-> value_exists ('authors-commentary-resources')) $ this-> update_post_meta ($ post_id, 'authors-commentary-resources', $ this-> sanitize_data ('authors-commentary-resources' sant));  ellers $ this-> delete_post_meta ($ post_id, 'authors-commentary-resources');  hvis ($ this-> value_exists ('authors-commentary-comments')) $ this-> update_post_meta ($ post_id, 'authors-commentary-comments', $ _POST ['authors-commentary-comments']);  ellers $ this-> delete_post_meta ($ post_id, 'authors-commentary-comments');

Vær oppmerksom på at vi faktisk kunne refactor denne spesifikke enda mer, så det er ikke så mange betingelser, men for lengden av artikkelen, lengden på tid og også å prøve å introdusere andre strategier, vil dette bli oppe som en øvelse som skal gjøres på egen tid.

Konklusjon

Nå har vi fullført vårt plugin. Vi har skrevet et plugin som introduserer en meta-boks for å gi alternativer til forfatterne som skriver blogginnlegg.

I tillegg har vi benyttet WordPress-kodingsstandardene, noen sterke filorganisasjonsstrategier, og har opprettet en rekke hjelpemetoder og abstraksjoner som kan hjelpe oss med å opprettholde denne plugin-modulen når den gjennomgår fremtidig utvikling.

Fordi det ikke er lett å markere alle muligheter for refactoring, er det sannsynligvis flere endringer som kan gjøres. På egen tid, vær så snill å prøve å implementere noen av dem selv.

Totalt håper jeg at du har hatt glede av serien og lært mye av det, og jeg håper at det vil hjelpe deg med å skrive bedre, mer vedlikeholdbar kode i fremtidige WordPress-baserte prosjekter.

Kode