Verwaltbare WordPress-Meta-Boxen erstellen Refactoring

In dieser Serie haben wir uns darauf konzentriert, wartungsfähige WordPress-Meta-Boxen zu erstellen. Damit meine ich, dass wir daran gearbeitet haben, ein WordPress-Plugin zu erstellen, das gut organisiert ist, den Codierungsstandards von WordPress folgt und das im Laufe der Zeit leicht angepasst und gepflegt werden kann.

Obwohl wir einige bewährte Praktiken implementiert haben, gibt es noch Raum für das Refactoring. Bei dieser Serie geschieht dies per Design. Wenn Sie an einem Projekt für einen Kunden oder für ein größeres Unternehmen arbeiten, ist die Wahrscheinlichkeit, dass Sie eine vorhandene Codebase unterhalten müssen, ziemlich hoch. Daher wollte ich, dass wir zu unserer Codebase zurückkehren können, um den Code, den wir geschrieben haben, zu verfeinern.

Beachten Sie, dass dieser Artikel nicht in dem Format geschrieben wird, in dem die anderen verfasst wurden. Das heißt, es gibt keinen Ansatz "Zuerst machen wir das, dann machen wir das". Stattdessen werden wir einige Bereiche hervorheben, die ein Refactoring erfordern, und diese dann unabhängig von den anderen Änderungen behandeln, die wir vornehmen.

Umgestaltung

Um es klar zu sagen, ist der Akt des Refactorings (wie von Wikipedia definiert):

Durch Refactoring werden nicht funktionale Attribute der Software verbessert. Zu den Vorteilen zählen eine verbesserte Lesbarkeit des Codes und eine geringere Komplexität, um die Wartbarkeit des Quellcodes zu verbessern, und eine ausdrucksstärkere interne Architektur oder ein Objektmodell zu erstellen, um die Erweiterbarkeit zu verbessern.

Kurz gesagt, der Code wird lesbarer, weniger komplex und kann leichter verfolgt werden, ohne dass das Verhalten des Codes aus Sicht der Endbenutzer geändert wird.

Dies kann auf verschiedene Arten erreicht werden, von denen jede für das gegebene Projekt einzigartig ist. In unserem Fall werden wir unsere Konstruktoren, einige unserer Save-Methoden, einige unserer Helper-Methoden und mehr überarbeiten.

Letztendlich besteht das Ziel darin, einige Strategien aufzuzeigen, die während Ihrer zukünftigen WordPress-Bemühungen verwendet werden können. Ich werde versuchen, so viel wie möglich in diesem Artikel zu behandeln. Beachten Sie jedoch, dass möglicherweise Möglichkeiten für zusätzliches Refactoring bestehen, die nicht abgedeckt werden.

Wenn dem so ist, großartig! Fühlen Sie sich frei, sie auf Ihrer eigenen Instanz der Codebase zu erstellen. Nachdem dies gesagt ist, lasst uns anfangen.

Der Konstruktor

Wenn Sie einen Blick auf unseren Konstruktor werfen: 

name = $ name; $ 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')); 

Beachten Sie, dass es derzeit zwei Dinge tut:

1. Eigenschaften wie Name und Version werden initialisiert
2. Hooks mit WordPress registrieren

Es ist üblich, Hooks im Kontext eines Konstruktors in einem WordPress-Plugin zu sehen, aber es ist nicht wirklich ein großartiger Ort, um dies zu tun.

Ein Konstruktor sollte verwendet werden, um alle Eigenschaften zu initialisieren, die für die angegebene Klasse relevant sind. Wenn ein Benutzer eine Klasse instanziiert, hat er / sie alles, um mit der Klasse zu arbeiten. 

Da sie möglicherweise keine Hooks zu dem Zeitpunkt registrieren möchten, zu dem sie die Klasse initialisieren, müssen wir dies in ihre eigene abstrahieren initialize_hooks Methode. Unser Code sollte jetzt so aussehen:

name = $ name; $ 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'));  

Danach müssen wir sicherstellen, dass der Kerncode von Autors-commentary.php so aktualisiert wird, dass die Hooks ordnungsgemäß instanziiert und registriert werden.

initialize_hooks ();  run_author_commentary ();

Der Hauptunterschied besteht hier darin, dass wir die Versionsnummer, die wir an die Hauptklasse übergeben, aktualisiert haben, und wir nennen auch explizit die initialize_hooks Funktion im Kontext von run_author_commentary.

Wenn Sie Ihren Code jetzt ausführen, sollte alles genauso funktionieren wie vor diesem Refactoring.

Ich möchte auch hinzufügen, dass Sie die Möglichkeit haben können, eine separate Klasse für das Koordinieren von Hooks und Callbacks zu verwenden, sodass sich die Verantwortung in einer separaten Klasse befindet. Ich bin zwar ein Fan dieses Ansatzes, liegt aber außerhalb des Rahmens dieses Artikels.

Als Nächstes wollen wir das Gleiche tun Klassenautoren-Kommentar-Meta-Box.php. Anstatt eine neue Funktion zu erstellen, können Sie den Konstruktor einfach umbenennen, da der Konstruktor nichts tut. Dies bedeutet, dass unser Code folgendermaßen aussehen sollte:

Zu diesem:
Und die letzte Änderung, die wir vornehmen müssen, ist das Aktualisieren des Konstruktors in der Hauptklasse, so dass er jetzt in der initialize_hooks Funktion, die wir in der Hauptplugin-Klasse erstellt haben.
meta_box-> initialize_hooks (); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_styles')); add_action ('admin_enqueue_scripts', array ($ this, 'enqueue_admin_scripts')); 
Aktualisieren Sie die Seite erneut, und Ihr Plugin sollte immer noch genauso funktionieren wie vor diesem Refactoring.
Hilfsmethoden
In dem Authors_Commentary_Meta_Box Klasse, wir haben eine Reihe von Bedingungen in der save_post Funktion, die sehr redundant sind. In diesem Fall bedeutet dies normalerweise, dass ein Großteil der Funktionalität in eine Hilfsfunktion abstrahiert und dann innerhalb der Funktion aufgerufen werden kann, in der sie ursprünglich platziert wurden.
Schauen wir uns den Code so an, wie er jetzt ist:
is_valid_post_type () || ! $ this-> user_can_save ($ post_id, 'Autors_commentary_nonce', 'Autors_commentary_save')) return;  // Wenn der Textbereich "Entwürfe" gefüllt wurde, werden die Informationen bereinigt. if (! empty ($ _POST ['Autors-Commentary-Drafts'])) // Wir entfernen alle Leerzeichen und HTML-Tags und kodieren die zu speichernden Informationen. $ drafts = trim ($ _POST ['Autors- Kommentar-Entwürfe ']); $ drafts = esc_textarea (strip_tags ($ drafts)); update_post_meta ($ post_id, 'Autors-Commentary-Drafts', $ Drafts);  else if ("! == get_post_meta ($ post_id, 'Autors-Commentary-Drafts', true)) delete_post_meta ($ Post_id, 'Autors-Commentary-Drafts'); // Wenn die 'Ressourcen' eingegeben werden existieren, iterieren Sie durch und reinigen Sie sie, wenn (! empty ($ _POST ['Autors-Kommentar-Ressourcen'])) $ resources = $ _POST ['Autors-Kommentar-Ressourcen']; $ sanitized_resources = array (); foreach ($ resources als $ resource) $ resource = esc_url (strip_tags ($ resource)); if (! empty ($ resource)) $ sanitized_resources [] = $ resource; update_post_meta ($ post_id, 'Autors-Kommentar- resources ', $ sanitized_resources); else if ("! == get_post_meta ($ post_id,' Autors-Kommentar-Ressourcen ', true)) delete_post_meta ($ Post_id,' Autors-Kommentar-Ressourcen ');  // Wenn in der Eingabe "Published" Werte gespeichert sind, speichern Sie sie, wenn (! Empty ($ _POST ['Autors-Commentary-comments'])) update_post_meta ($ post_id, 'Autors-Commentary-comments') , $ _POST ['Autors-Kommentar-Kommentare']);  else if ("! == get_post_meta ($ post_id, 'Autors-Kommentar-Kommentare', true)) delete_post_meta ($ post_id, 'Autors-Kommentar-Kommentare');
Abgesehen davon, dass die Methode anfangs viel zu lang ist, gibt es einige Dinge, die wir aufräumen können:
 
Die anfängliche Bedingung, die logisch verwendet nicht und logisch ODER Betreiber
 
Die Bedingungen, die das Vorhandensein von Informationen im überprüfen $ _POST Array
 
Die Bereinigungs-, Aktualisierungs- und / oder Löschfunktionen für die zugehörigen Metadaten
 
Sehen wir uns also jeden einzelnen einzeln an und arbeiten wir daran, diese Funktion zu überarbeiten.
1. Die Anfangsbedingung
Mit der ersten bedingten Prüfung soll sichergestellt werden, dass der aktuelle Benutzer die Möglichkeit hat, Daten im angegebenen Beitrag zu speichern. Im Moment prüfen wir buchstäblich, ob der aktuelle Beitragstyp ein gültiger Beitragstyp ist und ob der Benutzer die Berechtigung zum Speichern hat, wenn die aktuellen, von WordPress übergebenen Nonce-Werte vorliegen.
Im Moment lautet der Code:
Wenn dies kein gültiger Beitragstyp ist oder der Benutzer keine Berechtigung zum Speichern hat, beenden Sie diese Funktion.
Es ist nicht alles furchtbar zusammen, könnte aber definitiv verbessert werden. Anstelle einer ODER, Lassen Sie uns es in einer einzigen Bewertung zusammenfassen, so dass es lautet:
Wenn der Benutzer keine Berechtigung zum Speichern hat, beenden Sie diese Funktion.
Zum Glück ist dies eine relativ einfache Lösung. Da die Art des gesicherten Beitrags entscheidet, ob der Benutzer die Berechtigung zum Speichern des Beitrags hat, können wir diese Logik in den Postfach verschieben user_can_save Funktion.
Nehmen wir also die is_valid_post_type Funktion und verschieben Sie es in die user_can_save Funktion:
is_valid_post_type () && $ is_valid_nonce; 
Nun ist die gesamte Logik, die dafür verantwortlich ist, ob der Benutzer die Post-Metadaten speichern kann, in einer Funktion gekapselt, die speziell dafür ausgelegt ist, genau das auszuwerten.
Wir haben damit angefangen:
is_valid_post_type () || ! $ this-> user_can_save ($ post_id, 'Autors_commentary_nonce', 'Autors_commentary_save')) return; 
Und jetzt haben wir das:
user_can_save ($ post_id, 'Autors_commentary_nonce', 'Autors_commentary_save')) return;  
Liest viel einfacher, oder??
2. Überprüfen des $ _POST-Arrays
Bevor wir beginnen, die Metadaten zu desinfizieren, zu validieren und zu speichern (oder zu löschen), prüfen wir die $ _POST Sammlung, um sicherzustellen, dass die Daten tatsächlich vorhanden sind. 
Wir können eine kleine Hilfsfunktion schreiben, die diese Bewertung für uns erledigt. Obwohl wir im Wesentlichen ein bisschen Code schreiben, der unsere Bewertung ausführlicher macht, werden die Bedingungen etwas klarer gelesen, als wenn wir sie einfach so belassen hätten.
Führen Sie zunächst die folgende Funktion ein (und beachten Sie, dass sie einen Parameter enthält):
Richten Sie als Nächstes alle Anrufe um, die ursprünglich den Aufruf von hatten ! leer ($ _POST […]) so dass sie diese Funktion nutzen.
Die Funktionsaufrufe sollten beispielsweise so aussehen:
if ($ this-> value_exists ('Autors-Kommentar-Kommentare')) //… else //…
2. Löschen von Metadaten
Beachten Sie, dass in allen Bedingungen, die in dieser Funktion enthalten sind, jedes Auswerten zum Löschen von Post-Metadaten, wenn der Wert nicht vorhanden ist, genau gleich aussieht.
Zum Beispiel sehen wir jedes Mal so etwas:
Dies ist eine offensichtliche Chance, den Code zu überarbeiten. Als solches erstellen wir eine neue Funktion namens delete_post_meta und lassen Sie all diese Informationen einkapseln:
Jetzt können wir alle anderen bedingten Auswertungen rückgängig machen und ersetzen, um diese einzelne Funktion aufzurufen, sodass sie etwa Folgendes liest:
value_exists ('authirs-commentary-drafts')) // Wir entfernen alle Leerzeichen und HTML-Tags und kodieren die zu speichernden Informationen. $ drafts = trim ($ _POST ['Autors-Commentary-Drafts']); $ drafts = esc_textarea (strip_tags ($ drafts)); update_post_meta ($ post_id, 'Autors-Commentary-Drafts', $ Drafts);  else $ this-> delete_post_meta ($ post_id, 'Autors-Kommentar-Entwürfe'); 
An diesem Punkt haben wir eigentlich nur einen weiteren Aspekt dieses Teils des Codes, den Sie umgestalten können.
3. Desinfektion und Einsparung
Die Art und Weise, in der die Post-Metadaten gespeichert werden, geschieht derzeit durch die Auswertung des Vorhandenseins der Daten in der $ _POST Sammlung, bereinigen Sie sie basierend auf der Art der Informationen und speichern Sie sie anschließend in den Post-Metadaten.
Im Idealfall möchten wir die Daten in ihrer eigenen Funktion bereinigen sowie die Post-Meta-Daten in ihrer eigenen Funktion speichern. Daher müssen wir uns mit neuen Funktionen vertraut machen.
Lassen Sie uns zunächst an der Desinfektion arbeiten. Weil wir es zu tun haben Textbereiche und Arrays gibt es einige Möglichkeiten, wie wir mit dem Desinfektionsaufruf umgehen können. Da wir entweder mit einem Array arbeiten oder nicht, können wir eine Funktion erstellen, die einen optionalen Parameter akzeptiert, der angibt, ob wir mit einem Array arbeiten oder nicht.
Wenn wir nicht mit einem Array arbeiten, behandeln wir die eingehenden Daten als Text. Andernfalls behandeln wir es als Array:
Als Nächstes können wir die Desinfektionsaufrufe aktualisieren, um diese Methode zu verwenden. Bevor wir das tun, schreiben wir noch einen kleinen Helfer, der für die Aktualisierung der Post-Meta-Daten mit den bereinigten Eingaben verantwortlich ist:
Jetzt können wir alle Bedingungen, die wir zuvor in der Funktion verwendet haben, wie folgt aktualisieren:
user_can_save ($ post_id, 'Autors_commentary_nonce', 'Autors_commentary_save')) return;  if ($ this-> value_exists ('Autors-commentary-drafts')) $ this-> update_post_meta ($ post_id, 'Autors-commentary-drafts', $ this-> sanitize_data ('author-commentary-drafts') );  else $ this-> delete_post_meta ($ post_id, 'Autors-Kommentar-Entwürfe');  if ($ this-> value_exists ('Autors-commentary-resources')) $ this-> update_post_meta ($ post_id, 'autors-commentary-resources', $ this-> sanitize_data ('author-commentary-resources', wahr ) );  else $ this-> delete_post_meta ($ post_id, 'Autors-Kommentar-Ressourcen');  if ($ this-> value_exists ('Autors-Kommentar-Kommentare')) $ this-> Update_post_meta ($ post_id, 'Autors-Kommentar-Kommentare', $ _POST ['Autors-Kommentar-Kommentare']);  else $ this-> delete_post_meta ($ post_id, 'Autors-Kommentar-Kommentare'); 
Beachten Sie, dass wir dieses Problem sogar noch mehr umgestalten können, da es nicht so viele Bedingungen gibt, aber wegen der Länge des Artikels, der Zeitdauer und des Versuchs, andere Strategien einzuführen, wird dies als überlassen eine Übung, die Sie zu Ihrer eigenen Zeit machen können.
Fazit
Inzwischen haben wir unser Plugin fertiggestellt. Wir haben ein Plugin geschrieben, das eine Meta-Box enthält, in der den Autoren, die Blogbeiträge verfassen, Optionen angeboten werden. 
Darüber hinaus haben wir die Codierungsstandards von WordPress, einige starke Dateiorganisationsstrategien, verwendet und eine Reihe von Hilfsmethoden und Abstraktionen erstellt, die uns helfen werden, dieses spezielle Plugin bei der zukünftigen Entwicklung zu erhalten.
Da es nicht leicht ist, jede einzelne Möglichkeit für das Refactoring hervorzuheben, sind möglicherweise weitere Änderungen möglich. Fühlen Sie sich frei, einige von ihnen selbst zu implementieren.
Alles in allem hoffe ich, dass Sie die Serie genossen haben und viel daraus gelernt haben, und ich hoffe, dass Ihnen dies helfen wird, in zukünftigen WordPress-basierten Projekten besseren und wartungsfreundlicheren Code zu schreiben.



		
			
	   
	




Code