WordPress-Widgets: Refactoring, Teil 7

In den letzten Beiträgen haben wir viel Arbeit geleistet, um den Code auf den Punkt der Umgestaltung zu bringen, der in diesem Artikel behandelt wird.

Konkret haben wir abgedeckt:

• Haken,
• eine Registrierung ,
• und Abonnenten.

All dies wird bei dem, was wir heute tun werden, eine Rolle spielen.

Das WordPress-Widget Boilerplate: Refactoring, Teil 7

Diejenigen, die mit der WordPress-Widgets-API vertraut sind, wissen wahrscheinlich, dass sie sich in den letzten Jahren nicht wesentlich geändert hat.

Außerdem besteht es wirklich nur aus vier Funktionen (von denen eine der Konstruktor ist):

1. Der Konstruktor ist dafür verantwortlich, mehrere Eigenschaften für das Widget festzulegen, am häufigsten seinen Namen und seine Beschreibung.
2. Die Widget-Funktion ist für das Rendern des Inhalts des Widgets verantwortlich.
3. Die Formularfunktion ist für die Anzeige des Formulars im Administrationsbereich von WordPress bei der Arbeit mit dem Widget zuständig.
4. Die Aktualisierungsfunktion ist für die Aktualisierung der Optionen verantwortlich, die in der Datenbank gespeichert sind (oder initialisiert und dann die Optionen gespeichert werden, die möglicherweise noch nicht in der Datenbank vorhanden sind).

Das Schöne ist, dass dieser spezielle Ansatz durch das Vererben einer Funktionalität für die Klasse WP_Widget erreicht wird .

Das Problem ist jedoch, dass es eine Menge Arbeit für eine einzelne Klasse ist.

Stattdessen sollten wir jede Funktion in ihren eigenen Funktionsbereich unterteilen.

Wie bei allem in der Programmierung wird es Wege geben, bei denen einige Dinge klar sind, wie sie erledigt werden können, und dann wird es einige Dinge geben, die auf verschiedene Arten erledigt werden können.

Was ich präsentieren werde, ist, wie ich es jetzt angehe. Dies könnte sich in Zukunft ändern oder auch nicht, und andere haben möglicherweise eine andere Sichtweise darauf.

Unabhängig davon wird die Implementierung viel objektorientierter sein und jeder Klasse ihre eigenen Verantwortlichkeiten geben.

Die erste Frage ist jedoch, wie teilen wir eine Klasse mit vier Funktionen auf, die von einer übergeordneten Klasse erbt?

Aktualisieren des Bootstrap

Zuerst gibt es ein paar Dinge, die wir im Bootstrap des Plugins anpassen müssen. Wir müssen nämlich Folgendes tun:

1. die Registry instanziieren und über das Projekt verfügbar machen,
2. Aktualisieren Sie die Plugin-Klasse, sodass sie eine Registrierung akzeptiert und die Abonnenten lädt.
3. Überprüfen Sie den Bootstrap

Hier ist ein Blick auf alle drei der oben genannten.

1 Instanziieren Sie die Registrierung

Da wir dies bereits früher in der Serie behandelt haben, sollte klar sein, wie das geht.

Sehen Sie sich zunächst den folgenden Code an :

Beachten Sie als Nächstes, dass wir die Registrierung instanziieren (wir werden gleich über ihren Namensraum sprechen) und sie dann in einen benutzerdefinierten Filter einbinden, der es uns ermöglicht, jederzeit im gesamten Plugin darauf zuzugreifen.

2 Aktualisieren Sie die Plug-in-Klasse

Als nächstes müssen wir die Core-Plugin-Klasse (die sich im src -Verzeichnis befindet) aktualisieren, damit sie auf die Registrierung verweist und alle registrierten Abonnenten lädt :

Beachten Sie jedoch, dass wir noch keine wirklichen Abonnenten eingerichtet haben. Wir haben früher in der Serie damit begonnen und jetzt ist es an der Zeit, darauf zurückzukommen, aber das machen wir später.

Wir müssen jedoch eine Funktion hinzufügen – auch wenn sie vorübergehend ist – damit wir Klassen hinzufügen können, die keine expliziten Ereignisabonnenten sind:

Dies wird später überarbeitet, da wir Kernklassen später in Abonnenten umwandeln werden.

3 Überprüfen Sie den Bootstrap

Bevor ich fortfahre, denke ich, dass es wichtig ist, den Bootstrap zu überprüfen. Obwohl Ihr Header und Ihre Dokumentation variieren können, ist es wichtig zu beachten, dass wir die folgenden Dinge tun:

• Namensraum für den Bootstrap,
• Zugriff auf die Datei verhindern,
• Aufruf des Autoloaders,
• Einrichtung der Registrierung,
• und das Plugin starten.

Es klingt viel, aber der Code ist ziemlich kurz :

An diesem Punkt ist es jedoch an der Zeit, sich anzusehen, wie es ist, die untergeordnete Klasse der Standard- Widgets-API in etwas aufzuteilen, das zu dem Codemodell passt, mit dem wir arbeiten.

Aufteilen einer untergeordneten Klasse

Dieser Teil wird wahrscheinlich einige Posts umfassen, da noch ein wenig Arbeit zu erledigen ist, aber wir beginnen damit, unsere eigene Widget-Klasse zu erstellen, die von der Basis-Widget-Klasse erbt.

Erstellen Sie zunächst ein API – Verzeichnis im src – Verzeichnis und fügen Sie eine Datei namens Widget.php hinzu. Hier befinden sich die Grundlagen des Widgets. Wir werden uns im nächsten Beitrag mit administrativen und öffentlich zugänglichen Stylesheets und JavaScript-Dateien befassen.

An dieser Stelle sollten die Grundlagen der Datei wie folgt aussehen :

Beachten Sie, dass es ein einzelnes Argument braucht. Ich habe Widget-Name verwendet, aber Sie können verwenden, was Sie möchten, solange es Ihr Widget darstellt.

Dies soll zeigen, dass die Klasse ordnungsgemäß instanziiert und geladen wird, wenn das Plugin aktiviert wird. Wenn Sie dies nicht sehen, stimmt etwas nicht (was wir gleich überprüfen werden).

Als nächstes ist es wichtig sicherzustellen, dass diese Klasse zur Registrierung hinzugefügt wird. Fügen Sie also die folgenden Codezeilen in den Bootstrap ein:

Und jetzt, wenn Sie das Plugin aktivieren, sollten Sie Folgendes sehen:

Wenn nicht, überprüfen Sie bitte den Code im Entwicklungszweig, um sicherzustellen, dass Sie alles haben, was in diesem Beitrag beschrieben wird.

Abonnenten implementieren

In den kommenden Beiträgen werden wir uns ansehen, wie wir Abonnenten für die öffentlich zugängliche Seite der Website (d. h. dort, wo der Widget-Inhalt angezeigt wird) implementieren können. Und wir werden dasselbe für den Verwaltungsbereich der Website tun.

Abschließend richten wir unsere Aufmerksamkeit auf den Code, der für die Sicherung und Serialisierung von Daten verantwortlich ist (sprich: Aktualisierung unseres Widgets), und sehen uns dann an, wie die endgültige Version einer aktualisierten Boilerplate aussieht.

In diesem Beitrag verwenden wir jedoch hauptsächlich die Strategie, eine untergeordnete Klasse aufzuteilen, sodass sie weiterhin mit anderen Klassen verwendet werden kann, die Schnittstellen und Basisklassen verwenden, die bereits in der Codebasis definiert sind.