WordPress-Widgets: Ein objektorientierter Ansatz

Vor Jahren habe ich das WordPress Widget Boilerplate mit dem Ziel erstellt, Folgendes zu sein:

Eine organisierte, wartbare Boilerplate zum Erstellen von Widgets unter Verwendung von WordPress Best Practices.

Seitdem hat sich in Bezug auf die Widgets-API (auf die wir später in diesem Beitrag noch eingehen werden) nicht viel geändert, aber was ich als „Best Practices“ betrachte, hat sich geändert. Außerdem hat sich das Ausmaß geändert, in dem ich diese API für solide halte Beispiel für einführende objektorientierte Programmierung in WordPress ist hoch.

Das liegt nicht daran, dass es viele objektorientierte Prinzipien verwendet, es liegt nicht daran, dass es moderne Standards verwendet (zumindest was modernes PHP betrifft), sondern weil es einige Dinge verwendet, die uns helfen, ein paar zu erkennen, sagen wir: Signale zur objektorientierten Programmierung in WordPress.

Und das sollte nicht unterschätzt werden: Wenn Sie nach Beispielen für objektorientierte Programmierung in WordPress suchen, suchen Sie nach APIs, die es verwenden.

Wenn Sie außerdem nach Möglichkeiten suchen, Ihr eigenes Niveau bei der Bewertung eines Codestücks (geschweige denn einer Codebasis) für die Verwendung von Klassen und einigen der fortgeschritteneren Funktionen von OOP zu messen, warum haben Sie dann nicht eine Art? eines Lackmustests, um zu sehen, wie es dir geht?

Und genau das tut die Widgets-API.

WordPress-Widgets: Eine Einführung

In einer kleineren Serie als meiner letzten möchte ich mir also die Widgets-API ansehen und ein paar Dinge tun:

1. zeigen Ihnen das Grundgerüst eines Widgets und warum es objektorientiert ist,
2. besprechen Sie, welche Dinge Sie bemerken sollten und warum,
3. aktualisiere das Widget Boilerplate zuerst direkt auf dieser Seite und pushe es dann auf GitHub,
4. Erstellen Sie ein Widget mithilfe der API mit der Boilerplate als Grundlage für unsere Arbeit.

Und in diesem Beitrag werden wir mit dem ersten Punkt oben beginnen.

Aber zuerst…

Bevor ich in diesen Beitrag gehe, empfehle ich, die folgenden Beiträge zu lesen:

1. Zwei Säulen der objektorientierten Programmierung: Teil 1 von 2
2. Zwei Säulen der objektorientierten Programmierung: Teil 2 von 2
3. Abstrakte Klassen, Teil 1 – Abstraktes Verhalten
4. Abstrakte Klassen, Teil 2 – Abstrakte Klassen und Schnittstellen

Sobald Sie fertig sind (oder wenn Sie das Gefühl haben, die Themen bereits verstanden zu haben), können wir loslegen.

[bezahlt einschränken = "true"]

Die Grundlagen der Widgets-API

Wenn Sie die Handbuchseite zu Widgets durchlesen, werden Sie viele Inhalte sehen. Das ist eine gute Sache, aber es ist nicht immer der beste Schritt, wenn Sie versuchen, Inhalte für ein Publikum wie Sie selbst zu destillieren, wenn Sie nach praktischen, objektorientierten Ratschlägen suchen.

Also werde ich relevante Teile aus der API-Dokumentation heraussuchen und sie dann auf den Code anwenden, der uns ebenfalls zur Verfügung gestellt wird.

Was ist ein Widget?

Ich denke, die meisten von uns, die mit WordPress arbeiten, wissen, was ein Widget ist, aber es ist wichtig, den Begriff zu definieren, damit wir alle an der gleichen Idee arbeiten. Das Handbuch lautet:

Ein Widget ist ein PHP-Objekt, das etwas HTML ausgibt. Dieselbe Art von Widget kann mehrmals auf derselben Seite verwendet werden (z. B. das Text-Widget). Widgets können Daten in der Datenbank speichern (in der Optionstabelle).

Lassen Sie uns nun einen Blick auf den Code eines benutzerdefinierten Widgets werfen, zumindest einen Teil davon, und sehen, was wir in Bezug auf seine objektorientierte Natur herausfinden können.

Die Widget-Klasse

Bevor wir uns den Code überhaupt ansehen, wissen wir, dass es ein gewisses Maß an objektorientierter Programmierung geben wird, einfach weil die Dokumentation uns sagt, dass wir drei Dinge tun sollen:

1. Erstellen Sie die Klasse Ihres Widgets, indem Sie die Standardklasse WP_Widget und einige ihrer Funktionen erweitern.
2. Registrieren Sie Ihr Widget, damit es auf dem Widgets -Bildschirm verfügbar ist.
3. Stellen Sie sicher, dass Ihr Design mindestens einen Widget-Bereich hat, in dem Sie die Widgets hinzufügen können.

In diesem Beitrag werde ich mich auf den ersten Punkt konzentrieren (obwohl wir schließlich dazu kommen werden, wie wir unsere Widgets in ein Thema einführen, bevor die Serie zu Ende ist).

Lassen Sie uns also den Code so darstellen, wie er in der Dokumentation dargestellt wird, und darüber sprechen, was wir daraus lernen können:

<?php
class AcmeWidget extends WP_Widget 
{ 
    public function __construct() 
    {
    }

    public function widget($args, $instance) 
    {
    }

    public function form($instance)
    {
    }

    public function update($newInstance, $oldInstance)
    {
    }
}

Zunächst stellen wir fest, dass wir zwar eine Klasse definiert haben (die wir beliebig benennen können, auf meine Weise), diese aber WP_Widget erweitern muss. Das bedeutet, dass es im WordPress-Kern eine WP_Widget -Klasse gibt. Auf dieser Seite können Sie eine gut organisierte Aufschlüsselung des Quellcodes anzeigen .

Zweitens zeigt das Schlüsselwort extend an, dass wir die PHP-Vererbung verwenden, die eine Kernsäule der objektorientierten Programmierung ist.

Drittens müssen wir vier Funktionen implementieren, von denen zwei Argumente erfordern. Die Funktionen, die wir implementieren müssen, sind wie folgt:

• __construct(), das ist der grundlegende Klassenkonstruktor. Hier müssen wir sicherstellen, dass der Konstruktor der übergeordneten Klasse aufgerufen wird, falls vorhanden, und dann alle Eigenschaften initialisieren, die wir für unser Widget für erforderlich halten. Wir werden uns das später in der Serie ansehen.
• widget() ist für die Ausgabe der Inhalte des Widgets zuständig, die der Benutzer über die Oberfläche im administrativen Bereich bereitstellt. Es akzeptiert zwei Parameter – $args und $instance. Der $args- Parameter ist die Information, die auf der Seite gerendert werden soll, und die $instance ist ein Verweis auf die Instanz des Widgets (da mehrere Widgets auf einer Seite gerendert werden können).
• form() zeigt die Verwaltungsschnittstelle an, mit der der Benutzer interagiert, um zu steuern, was auf dem Front-End der Website ausgegeben wird. Es erfordert auch das $instance- Argument, sodass die bereitgestellten Informationen für das tatsächliche Widget gelten, mit dem der Benutzer arbeitet (im Gegensatz zu allen Instanzen des Widgets).
• update() wird verwendet, um die Werte in der aktuellen Instanz des Widgets zu speichern. Es akzeptiert zwei Argumente. Das erste ist die neue Instanz des Widgets mit aktualisierten Werten, die der Benutzer bereitgestellt hat (denken Sie an die Aktualisierung des Werts eines aktiven Text-Widgets), und das zweite Argument ist das der alten Instanz des Widgets oder vielleicht der vorherigen Instanz oder vielleicht „ die Instanz, die die vorherigen Werte enthielt.“

Diese vier Funktionen müssen als Teil der Widget-API implementiert werden, als Teil des Erbens von Funktionen von der erweiterten Schnittstelle und um die grundlegende Funktionalität eines Widgets zu erzeugen.

Das bedeutet nicht, dass nicht mehr hinzugefügt werden kann, aber in guter objektorientierter Weise wäre es wahrscheinlich am besten, dieses Verhalten in andere Klassen zu verlagern. Aber wir werden uns das später in der Serie ansehen, wenn wir unser eigenes Widget erstellen.

Was sind die wichtigsten Erkenntnisse?

Um sicherzustellen, dass mir klar ist, was unter diesem Beitrag verstanden werden würde, ist es Folgendes:

• Die Widgets-API ist objektorientiert. Es ist nicht nur objektorientiert, weil es eine Klasse verwendet (obwohl das sicherlich ein guter Ausgangspunkt ist), sondern auch, weil es Funktionalität erbt, die in eine bereits vorhandene Basisklasse eingebaut ist.
• Wann immer wir Verhalten von einer Basisklasse oder einer übergeordneten Klasse erben, erhalten wir kostenlos vorentwickelte Funktionen. Das ist eine wirklich tolle Sache bei der objektorientierten Programmierung, weil es uns ermöglicht, uns speziell auf die Programmierlogik zu konzentrieren, die wir implementieren möchten.

Stellen Sie sich für einen Moment vor, dass Sie ein Widget entwickeln möchten, aber jedes Mal, wenn Sie dies tun, müssen Sie alle Funktionen schreiben, die sich in WordPress einklinken, um die gleiche, sich wiederholende Boilerplate-Funktionalität zu erreichen.

Hier kommen Vererbung und objektorientierte Programmierung ins Spiel. Der sich wiederholende Code wird in eine Basisklasse abstrahiert, sodass er nur einmal geschrieben wird, und dann bleibt uns die Implementierung des Codes überlassen, auf den wir uns konzentrieren möchten.

All dies sollte verstanden werden, wenn man diesen anfänglichen Durchlauf des Quellcodes für eine grundlegende, objektorientierte API in WordPress liest.

Was kommt als nächstes?

Im nächsten Beitrag dieser Serie werden wir uns mit der objektorientierten Natur der Widgets-API befassen und welche Dinge Sie sofort erkennen können sollten, indem Sie den Code lesen.

Das liegt daran, dass es wichtig ist, bestimmte objektorientierte Prinzipien in der Praxis zu erkennen, und dies ist ein guter Weg, um einzuschätzen, ob Sie dazu in der Lage sind oder nicht. Wenn ja, großartig! Dann hilft es weiter, diesen Muskel zu entwickeln. Wenn nicht, keine Sorge – es hilft Ihnen trotzdem, diesen Muskel zu entwickeln.

Und es wird Ihnen gute Dienste leisten, wenn wir mit praktischen Mitteln immer mehr in die objektorientierte WordPress-Entwicklung einsteigen.

Die notwendige Theorie wurde abgedeckt. Beginnen wir also damit, es tatsächlich in die Praxis umzusetzen.