Aanmaakbare WordPress-metaboxen maken refactoring

Gedurende deze reeks hebben we ons gericht op het bouwen van onderhoudbare WordPress-metaboxen. Daarmee bedoel ik dat we hebben gewerkt aan het maken van een WordPress-plug-in die goed georganiseerd is, volgens WordPress-coderingsstandaarden, en die gemakkelijk kan worden aangepast en onderhouden terwijl het project in de loop van de tijd verder gaat.

Hoewel we enkele goede werkwijzen hebben geïmplementeerd, is er nog steeds ruimte voor refactoring. Voor deze serie wordt dit gedaan door het ontwerp. Wanneer u werkt aan een project voor een klant of voor een groter bedrijf, is de kans groot dat u een bestaande codebase moet onderhouden. Als zodanig wilde ik dat we terug konden gaan naar onze codebasis om een deel van de code die we hebben geschreven te verfijnen.

Merk op dat dit artikel niet zal worden geschreven in de vorm waarin de andere zijn geschreven - dat wil zeggen dat er geen "Eerst zullen we dit doen, dan doen we dit" benadering van ontwikkeling. In plaats daarvan gaan we verschillende gebieden markeren die moeten worden aangepast en deze vervolgens behandelen, onafhankelijk van de andere wijzigingen die we aanbrengen.

refactoring

Voor de duidelijkheid, de handeling van refactoring (zoals gedefinieerd door Wikipedia) is:

Refactoring verbetert niet-functionele kenmerken van de software. Voordelen zijn onder meer verbeterde leesbaarheid van de code en minder complexiteit om de onderhoudbaarheid van de broncode te verbeteren, en een expressievere interne architectuur of objectmodel te creëren om de uitbreidbaarheid te verbeteren.

Kortom, het maakt de code leesbaarder, minder complex, gemakkelijker te volgen en doet dit allemaal zonder het gedrag van de code vanuit het standpunt van de eindgebruikers te veranderen.

Dit kan op een aantal verschillende manieren worden bereikt, die elk uniek zijn voor het gegeven project. In ons geval gaan we kijken naar het refactoren van onze constructeurs, enkele van onze opslagmethoden, enkele van onze hulpmethoden en nog veel meer.

Uiteindelijk is het doel om enkele strategieën te laten zien die kunnen worden gebruikt tijdens uw toekomstige WordPress-inspanningen. Ik zal proberen zoveel mogelijk in dit artikel te behandelen; Houd er echter rekening mee dat er mogelijk mogelijkheden zijn voor extra refactoring die niet wordt gedekt.

Als dat het geval is, geweldig! Voel je vrij om ze op je eigen exemplaar van de codebase te maken. Met dat gezegd, laten we aan de slag gaan.

De aannemer

Als je onze constructeur bekijkt:

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

Merk op dat het momenteel twee dingen doet:

Initialisatie van eigenschappen zoals de naam en de versie
Haken registreren bij WordPress

Het is gebruikelijk om hooks in de context van een constructor in een WordPress plug-in te zien, maar het is niet echt een geweldige plek om het te doen.

Een constructor moet worden gebruikt om alle eigenschappen die relevant zijn voor de gegeven klasse te initialiseren, zodat wanneer een gebruiker een klasse instelt, hij / zij alles heeft wat nodig is om met de klasse te werken.

Omdat ze misschien geen haken willen registreren op het moment dat ze de klas initialiseren, moeten we dit opsommen in zijn eigen klasse initialize_hooks methode. Onze code zou er nu als volgt uit moeten zien:

naam = $ naam; $ this-> version = $ version; $ this-> meta_box = new Authors_Commentary_Meta_Box ();  public function initialize_hooks () add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_styles')); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_scripts'));

Hierna moeten we ervoor zorgen dat de kerncode van authors-commentary.php wordt bijgewerkt, zodat deze de haken correct identificeert en registreert.

initialize_hooks ();  run_author_commentary ();

Hier is het belangrijkste verschil dat we het versienummer dat we doorgeven aan de hoofdklasse hebben bijgewerkt en dat we ook expliciet het initialize_hooks functie binnen de context van run_author_commentary.

Als je nu je code uitvoert, zou alles precies zo moeten werken als vóór deze refactoring.

Ik zou ook willen toevoegen dat je een pleidooi kunt maken voor het hebben van een aparte klasse die verantwoordelijk is voor het coördineren van hooks en callbacks, zodat de verantwoordelijkheid in een aparte klasse ligt. Hoewel ik fan ben van die aanpak, valt dit buiten het bestek van dit specifieke artikel.

Laten we vervolgens hetzelfde doen class-auteurs-commentaar-meta-box.php. In plaats van een nieuwe functie te creëren, kunnen we de constructor eenvoudigweg hernoemen, omdat de constructeur eigenlijk niets doet. Dit betekent dat onze code eruit moet zien als er zo uitziet:

Hiernaar:

En de laatste verandering die we moeten aanbrengen, is de constructor in de hoofdklasse bij te werken zodat deze nu in de hoofdklasse wordt gelezen initialize_hooks functie die we hebben gemaakt in de hoofdinvoegklasse.

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

Wederom, vernieuw de pagina en uw plug-in zou nog steeds precies moeten functioneren als het was voorafgaand aan deze refactoring.

Helper-methoden

In de Authors_Commentary_Meta_Box klas, we hebben een aantal conditionals in de save_post functie die erg overbodig zijn. Wanneer dit gebeurt, betekent dit meestal dat een groot deel van de functionaliteit kan worden geabstraheerd naar een helperfunctie en vervolgens kan worden aangeroepen vanuit de functie waarin ze oorspronkelijk waren geplaatst.

Laten we eens kijken naar de code zoals die er nu uitziet:

is_valid_post_type () || ! $ this-> user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) return;  // Als het tekstvak 'Concepten' is ingevuld, dan zuiveren we de informatie. if (! empty ($ _POST ['authors-commentary-drafts'])) // We verwijderen alle witte ruimte, HTML-tags en coderen de informatie die moet worden opgeslagen $ drafts = trim ($ _POST ['authors- commentaar-concepten ']); $ drafts = esc_textarea (strip_tags ($ concepten)); update_post_meta ($ post_id, 'authors-commentary-drafts', $ drafts);  else if ("! == get_post_meta ($ post_id, 'authors-commentary-drafts', true)) delete_post_meta ($ post_id, 'authors-commentary-drafts'); // Als de 'Resources' inputs bestaan, doorleer ze en ontsmet ze als (! empty ($ _POST ['authors-commentary-resources'])) $ resources = $ _POST ['authors-commentary-resources']; $ sanitized_resources = array (); foreach ($ resources als $ resource) $ resource = esc_url (strip_tags ($ resource)); if (! empty ($ resource)) $ sanitized_resources [] = $ resource; update_post_meta ($ post_id, 'authors-commentary- resources ', $ sanitized_resources); else if ("! == get_post_meta ($ post_id,' authors-commentary-resources ', true)) delete_post_meta ($ post_id,' authors-commentary-resources ');  // Als er waarden zijn opgeslagen in de 'Gepubliceerd' invoer, sla ze dan op als (! Empty ($ _POST ['authors-commentary-comments'])) update_post_meta ($ post_id, 'authors-commentary-comments' , $ _POST ['authors-commentary-comments']);  else if ("! == get_post_meta ($ post_id, 'authors-commentary-comments', true)) delete_post_meta ($ post_id, 'authors-commentary-comments');

Afgezien van de methode die veel te lang is om mee te beginnen, zijn er een aantal dingen die we kunnen opruimen:

De initiële voorwaardelijke die logisch gebruikt niet en logisch OF operators
De conditionals die de aanwezigheid van informatie in de $ _POST rangschikking
De functies voor opschonen, bijwerken en / of verwijderen van de bijbehorende metadata

Dus laten we elk van deze afzonderlijk bekijken en werken aan het herformuleren van deze functie.

1. De beginvoorwaarde

Het doel van de eerste voorwaardelijke controle is om ervoor te zorgen dat de huidige gebruiker de mogelijkheid heeft om gegevens in de gegeven post op te slaan. Op dit moment controleren we letterlijk of het huidige berichttype een geldig berichttype is en of de gebruiker toestemming heeft om op te slaan, aangezien de huidige nonce-waarden worden doorgegeven door WordPress.

Op dit moment luidt de code:

Als dit geen geldig berichttype is of als de gebruiker geen toestemming heeft om op te slaan, sluit u deze functie.

Het is niet allemaal samen verschrikkelijk, maar kan zeker worden verbeterd. In plaats van een OF, laten we het consolideren in een enkele evaluatie, zodat het luidt:

Als de gebruiker geen toestemming heeft om op te slaan, verlaat u deze functie.

Gelukkig is dit een relatief eenvoudige oplossing. Omdat het type bericht dat wordt opgeslagen helpt om te dicteren of de gebruiker toestemming heeft om het bericht op te slaan, kunnen we die logica verplaatsen naar de user_can_save functie.

Dus laten we de is_valid_post_type functie en verplaats het naar de user_can_save functie:

is_valid_post_type () && $ is_valid_nonce;

Nu is alle logica die verantwoordelijk is voor het bepalen of de gebruiker de post-metadata kan opslaan, ingekapseld in een functie die specifiek is ontworpen om precies dat te evalueren.

We zijn hiermee begonnen:

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

En nu hebben we dit:

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

Leest veel gemakkelijker, nietwaar?

2. De $ _POST-array controleren

Voordat we beginnen met het zuiveren, valideren en opslaan (of verwijderen) van de metadata, controleren we de $ _POST verzameling om ervoor te zorgen dat de gegevens daadwerkelijk bestaan.

We kunnen een kleine hulpfunctie schrijven die voor deze evaluatie zorgt. Hoewel we in essentie een beetje code schrijven die onze evaluatie gedetailleerder maakt, zullen de conditionals een beetje duidelijker lezen dan als we ze gewoon hadden achtergelaten zoals ze zijn..

Stel eerst de volgende functie in (en merk op dat er een parameter in zit):

Werk vervolgens alle oproepen bij die aanvankelijk de ! empty ($ _POST [...]) zodat ze profiteren van deze functie.

De functieaanroepen moeten er bijvoorbeeld als volgt uitzien:

if ($ this-> value_exists ('authors-commentary-comments')) // ... else // ...

2. Verwijderen van metadata

Merk op dat gedurende de voorwaardelijke voorwaarden die in die functie worden geplaatst, elke evaluatie voor het verwijderen van post-metadata als de waarde niet bestaat exact hetzelfde lijkt.

We zien bijvoorbeeld elke keer zoiets als:

Dit is een voor de hand liggende kans om de code te refactoren. Laten we als zodanig een nieuwe functie aanmaken genaamd delete_post_meta en laat het al deze informatie inkapselen:

Nu kunnen we terug doen en alle andere voorwaardelijke evaluaties vervangen om een oproep te doen naar deze enkele functie, zodat deze als volgt luidt:

value_exists ('authirs-commentary-drafts')) // We verwijderen alle witte ruimte, HTML-tags en coderen de te bewaren informatie $ drafts = trim ($ _POST ['authors-commentary-drafts']); $ drafts = esc_textarea (strip_tags ($ concepten)); update_post_meta ($ post_id, 'authors-commentary-drafts', $ drafts);  else $ this-> delete_post_meta ($ post_id, 'authors-commentary-drafts');

Op dit punt hebben we eigenlijk maar één ander aspect van dit deel van de code aan refactor.

3. Sanering en besparing

Op dit moment wordt de manier waarop de metagegevens van de post worden opgeslagen, gedaan door een evaluatie van de aanwezigheid van de gegevens in de $ _POST verzamelen, het opschonen op basis van het type informatie en het vervolgens opslaan in de post-metadata.

In het ideale geval willen we de gegevens in de eigen functie opschonen en de post-metadata opslaan in zijn eigen functie. We moeten dus nieuwe functies introduceren.

Laten we eerst werken aan ontsmetting. Omdat we te maken hebben met textareas en arrays, er zijn een aantal manieren waarop we de saneringsaanroep moeten afhandelen. Omdat we met een array werken of niet, kunnen we een functie maken die een optionele parameter accepteert die aangeeft of we wel of niet met een array werken.

Als we niet met een array werken, behandelen we de inkomende gegevens als tekst; anders behandelen we het als een array:

Vervolgens kunnen we de ontsmettingsoproepen bijwerken om deze methode te gebruiken. Maar laten we voordat we dat doen ook een kleine helper schrijven die verantwoordelijk zal zijn voor het bijwerken van de post-metadata met de opgeschoonde invoer:

Nu kunnen we alle conditionals bijwerken die we eerder in de functie gebruikten om als volgt te lezen:

user_can_save ($ post_id, 'authors_commentary_nonce', 'authors_commentary_save')) return;  if ($ this-> value_exists ('authors-commentary-drafts')) $ this-> update_post_meta ($ post_id, 'authors-commentary-drafts', $ this-> sanitize_data ('authors-commentary-drafts') );  else $ this-> delete_post_meta ($ post_id, 'authors-commentary-drafts');  if ($ this-> value_exists ('authors-commentary-resources')) $ this-> update_post_meta ($ post_id, 'authors-commentary-resources', $ this-> sanitize_data ('authors-commentary-resources', waar));  else $ this-> delete_post_meta ($ post_id, 'authors-commentary-resources');  if ($ this-> value_exists ('authors-commentary-comments')) $ this-> update_post_meta ($ post_id, 'authors-commentary-comments', $ _POST ['authors-commentary-comments']);  else $ this-> delete_post_meta ($ post_id, 'authors-commentary-comments');

Merk op dat we dit specifieke zelfs nog meer kunnen refactiveren, dus er zijn niet zoveel conditionals, maar omwille van de lengte van het artikel, de tijdsduur en ook het proberen om een aantal andere strategieën te introduceren, zal dit worden overgelaten als een oefening om te doen in je eigen tijd.

Conclusie

Inmiddels hebben we onze plug-in voltooid. We hebben een plug-in geschreven die een metabox introduceert voor het bieden van opties voor de auteurs die blogposts schrijven.

Daarnaast hebben we de coderingsstandaarden van WordPress gebruikt, een aantal sterke bestandsorganisatiestrategieën en een aantal hulpmethoden en abstracties gemaakt die ons zullen helpen om deze specifieke plug-in te behouden wanneer deze toekomstige ontwikkeling ondergaat..

Omdat het niet eenvoudig is om elke gelegenheid tot refactoring te markeren, zijn er waarschijnlijk nog meer wijzigingen die kunnen worden aangebracht. In uw vrije tijd kunt u enkele van hen zelf proberen te implementeren.

Over het algemeen hoop ik dat je de serie leuk vond en er veel van hebt geleerd, en ik hoop dat het je zal helpen om betere, beter te onderhouden code te schrijven in toekomstige WordPress-projecten.

Code