WordPress-Widgets: Refactoring, Teil 12
Was das Refactoring des WordPress-Widget-Boilerplates betrifft – vor allem wenn man bedenkt, wie weit wir seit dem Start des Projekts vor acht Jahren gekommen sind – haben wir viel Arbeit geleistet.
Wir haben es auf einen viel moderneren Standard gebracht und machen es viel einfacher, damit zu arbeiten, so dass das Erstellen zukünftiger Widgets einfacher sein sollte. Und das nicht nur vom Standard der Boilerplate, sondern von einem objektorientierten Standard, so dass die Wartungs- und Codequalität höher ist.
Im letzten Beitrag haben wir einen Großteil der Arbeit für den Verwaltungsbereich abgeschlossen und sind bereit, mit der Arbeit am Code für das Frontend zu beginnen.
Wir sagten:
Als Nächstes sehen wir uns das Rendern von Inhalten im Front-End an. Wir nähern uns dem Ende des Refactorings der Boilerplate, aber es gibt noch ein bisschen mehr zu tun, bevor wir bereit sind, es in den Master-Zweig der Codebasis zu integrieren.
In diesem Beitrag werden wir also dort ansetzen. Wenn Sie bis zu diesem Punkt mitverfolgt haben, sollten Sie alles haben, was Sie aus dem Entwicklungszweig benötigen.
Wenn nicht, stellen Sie sicher, dass Sie es ziehen, da wir im Rest des Beitrags darauf eingehen werden.
Das WordPress-Widget Boilerplate: Refactoring Teil 12
Wenn es um das Front-End geht, ist es einfach, sich das Front-End als alles vorzustellen, was der Benutzer vor sich sieht, unabhängig davon, ob es sich im Verwaltungsbereich befindet oder nicht.
Diese Serie hat jedoch deutlich gemacht, dass wir das, was der Benutzer sieht, zwischen dem Verwaltungsbereich und dem öffentlich zugänglichen Bereich der Website aufteilen.
Wir werden also an dem Bereich des Codes arbeiten, der Informationen für den Benutzer im öffentlich zugänglichen Bereich der Website darstellt. Wir beginnen damit, einfach die Informationen zu lesen und anzuzeigen.
Dann werden wir uns im nächsten Beitrag die Arbeit mit bedingter Logik in Bezug auf einige der Optionen ansehen, um zu sehen, ob wir etwas tun müssen.
Nachdem dies gesagt ist, lassen Sie uns in den Code einsteigen.
Über die Daten, die wir anzeigen
Denken Sie daran, dass das Widget an dieser Stelle drei Dinge hat, die seine Anzeige beeinflussen:
- der Widget-Titel,
- der Widget-Inhalt,
- ein Umschalter, ob wir den Titel anzeigen sollen oder nicht
Die dritte Option besteht hauptsächlich darin, zu zeigen, wie man einen anderen Elementtyp verwendet. Denn technisch gesehen würden wir, wenn wir den Widget-Titel nicht anzeigen wollten, einfach nichts in das Widget einfügen.
Aber ich denke, es hilft zu zeigen, wie man verschiedene Elementtypen und ihre Werte auf praktische (oder halbpraktische) Weise verwendet.
Wie dem auch sei, wir wissen, dass für jede gegebene Instanz des Widgets Daten mit dem Titel , dem Inhalt und dem Namen und den IDs des Anzeigetitels gespeichert werden, wie sie von WordPress bereitgestellt werden.
Daher verwenden wir diese in unserem Front-End-Code, um die Werte anzuzeigen.
Anzeigefunktionen vorbereiten
Typischerweise ist die Widget- Funktion dafür verantwortlich, die Ausgabe des Widgets anzuzeigen. Aber eines der Dinge, die wir versucht haben, ist, die Belange unseres Widgets in eine fokussiertere Gruppe von Klassen und Funktionen zu unterteilen.
Das erste, was wir tun wollen, ist, eine WidgetDisplay -Klasse zu schreiben, die für die Anzeige des Inhalts des Widgets verantwortlich ist, wie es sicherlich offensichtlich ist.
Vorerst beinhaltet dies bedingungslos den Titel, den Inhalt und den Wert, ob der Titel enthalten sein soll oder nicht. WordPress stellt auch bestimmte Inhalte wie Markup zur Verfügung, die vor dem Widget und nach dem Widget erscheinen sollten, also stellen wir sicher, dass dies ebenfalls enthalten ist.
Aber lassen Sie uns zuerst die Klasse ausblenden :
Danach müssen wir sicherstellen, dass wir es auch für die anderen Klassen aufschreiben. Zuerst stellen wir sicher, dass es in unsere Widget-Klasse aufgenommen wird :
Und dann fügen wir es der WidgetAdmin-Klasse hinzu (da sich hier die zentralen Widget-API-Funktionen befinden – es delegiert nur die Verantwortung an die richtige Klasse):
Zu diesem Zeitpunkt zeigen wir noch nichts an. Wir sind in der Nähe und werden uns bald darauf konzentrieren.
Anzeigen der Daten
Angenommen, Sie können den obigen Code fehlerfrei hinzufügen, ist es an der Zeit, den Inhalt des Widgets anzuzeigen.
Wir können dies auf verschiedene Arten tun, von einem einfachen var_dump bis hin zur tatsächlichen Anzeige des Inhalts in einer benutzerfreundlicheren Weise. Und ich bin viel mehr ein Fan von letzterem.
Also lass uns das tun.
Fügen Sie in der Show- Funktion Ihrer WidgetDisplay -Klasse den folgenden Code hinzu :
Und dann kann die Ansicht für die Vorlage so einfach sein :
Dadurch wird sichergestellt, dass das richtige Markup für alle Inhalte vor dem Widget, der Inhalt des Widgets und der Inhalt richtig gerendert werden.
Denken Sie noch einmal daran, dass wir einige Inhalte anzeigen, die nicht in der endgültigen Version davon enthalten sein werden, aber wir kommen dem näher und werden uns im nächsten Beitrag damit befassen.
Ich würde empfehlen, mit der Option Titel anzeigen herumzuspielen, um zu sehen, wie sie angesichts des von uns bereitgestellten Markups auf dem Frontend gerendert wird.
Im Moment sollte die Ausgabe des Widgets in etwa so aussehen:
Aber das ist alles, was es in diesem Beitrag zu behandeln gibt.
In den endgültigen Refactor
Das letzte, was wir uns danach ansehen werden, ist die Verschärfung der bedingten Logik zusammen mit einem Wort zum Zwischenspeichern von Daten (da wir uns bereits in früheren Posts ein wenig damit beschäftigt haben).
Im Moment können Sie jedoch gerne mit dem herumspielen, was wir hier haben, zusammen mit dem Code, den wir nicht eingefügt haben (z. B. was vor oder nach dem Widget angezeigt werden kann.
Sie wurden in diesem Beispiel absichtlich weggelassen, aber je nach Ihrer Arbeit werden sie möglicherweise nicht immer weggelassen.