Wenn es um das Refactoring des WordPress Widget Boilerplate geht, haben wir viel Arbeit geleistet, um die Codebasis auf einen objektorientierteren Standard zu bringen. Darüber hinaus haben wir eine Vielzahl anderer Tools eingeführt, mit denen wir unseren Code auf modernere Standards bringen können

Nachdem wir uns damit beschäftigt haben, ist es an der Zeit, wieder in den Code einzusteigen und ihn so umzugestalten, dass die Verwendung abstrakter Klassen und Abonnenten (die als Teil des ereignisgesteuerten Entwurfsmusters funktionieren) möglich ist.

Am Ende des vorherigen Beitrags schrieb ich:

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.

In diesem Beitrag werden wir genau das tun. Insbesondere beginnen wir mit der Arbeit an einem Abonnenten für das Widget und bringen dann das Basis-Widget dazu, zuerst auf der Verwaltungsseite der Website angezeigt zu werden.

Das WordPress-Widget Boilerplate: Refactoring, Teil 8

Der Grund, warum ich daran interessiert bin, mich zuerst hauptsächlich auf die administrative Seite der Website zu konzentrieren, ist, dass sie uns Folgendes ermöglicht:

• verstehen, wie Abonnenten arbeiten,
• sehen, wie die Codebasis organisiert werden muss,
• einige Informationen hartcodieren, bevor Sie mit der Serialisierung arbeiten.

Sobald all dies vorhanden ist, werden wir in einer guten Position sein, um unsere Aufmerksamkeit fortgeschritteneren Dingen zuzuwenden. Wir können nämlich Abonnenten zum Anzeigen von Informationen im Verwaltungsbereich und Abonnenten zum Bereinigen, Serialisieren, Abrufen, Validieren und Anzeigen von Daten einführen.

Aber lassen Sie uns zuerst die Arbeit erledigen, die zum Einrichten einer neuen Klasse, zum Konfigurieren des Autoloaders und zum Anzeigen von Inhalten im Verwaltungsbereich der Site erforderlich ist.

1 Der Abstract-Abonnent

Sehen wir uns zuerst den abstrakten Abonnenten an, da dies alle Abonnenten implementieren werden.

<?php

/*
 * This file is part of WordPress Widget Boilerplate
 * (c) Tom McFarlin <tom@tommcfarlin.com>
 *
 * This source file is subject to the GPL license that is bundled
 * with this source code in the file LICENSE.
 */

namespace WordPressWidgetBoilerplateSubscriber;

/**
 * An abstract implementation of a subscriber that requires a hook and the ability to
 * start the class.
 */
abstract class AbstractSubscriber
{
    /**
     * @var string a reference to the hook to which the subscriber should be registered
     */
    protected $hook;

    /**
     * @param string $hook the hook to which the subscriber is registered
     */
    public function __construct(string $hook)
    {
        $this->hook = $hook;
    }

    /**
     * @return string the hook to which the subscriber is registered
     */
    public function getHook(): string
    {
        return $this->hook;
    }

    /**
     * Implements the domain logic for the concrete class implementating this subcriber.
     */
    abstract public function load();
}

Beachten Sie, dass es zwei öffentliche Funktionen hat – das Konstrukt, das den Hook setzt, und eine Funktion zum Abrufen des Hooks. Es hat auch eine abstrakte Ladefunktion, bei der jede Klasse, die diese Klasse erweitert, ihre spezifische Funktionalität implementiert.

Denken Sie daran, dass aufgrund der Art und Weise, wie WordPress mit Aktionen und Filtern umgeht, alles an einen bestimmten Hook angehängt ist (entweder die , die WordPress definiert, oder benutzerdefinierte Hooks).

2 Der WordPress-Namespace

Immer wenn ich an Funktionen arbeite, die eng mit WordPress gekoppelt sind, versuche ich sicherzustellen, dass ich sie in einem WordPress-Namespace platziere. Dies zeigt mir und anderen Entwicklern, dass alles, was sich in diesem Namensraum befindet, nicht von der Kernanwendung getrennt werden kann.

Erstellen Sie also im src- Verzeichnis ein WordPress- Verzeichnis. Hier befindet sich die Kern-Widget-Klasse zusammen mit allen anderen Klassen, die in dieser Serie eingeführt werden.

Das bedeutet, dass wir die Klasse im API-Verzeichnis nicht mehr benötigen. Stellen Sie also sicher, dass Sie die Klasse verschieben, ihren Namespace aktualisieren und das Verzeichnis entfernen. Ich werde ein wenig später einen Screenshot und etwas Code dafür haben.

Erinnern Sie sich außerdem, dass wir das Views -Verzeichnis früher in der Serie im Stammverzeichnis des src – Verzeichnisses platziert haben, aber jetzt können wir es in das WordPress – Verzeichnis verschieben. Also mach weiter und mach das jetzt.

Das Endergebnis sollte in etwa so aussehen:

Jetzt können wir uns dem Code zuwenden.

3 Ein Blick auf die Widget-Klasse

Wir werden die Kern-Widget-Klasse in diesem Beitrag etwas vereinfachen. Es wird einen Teil der Arbeit, die wir geleistet haben, zunichte machen, aber wir brauchten diese vorherige Arbeit, um an diesen Punkt zu gelangen.

Im Moment konzentrieren wir uns auf den Konstruktor und die Funktion zum Abrufen des Widget-Slugs. Dies wird uns letztendlich erlauben, etwas im administrativen Bereich von WordPress zu sehen.

Stellen Sie also zunächst sicher, dass Ihre Widget-Klasse so aussieht :

<?php

/*
 * This file is part of WordPress Widget Boilerplate
 * (c) Tom McFarlin <tom@tommcfarlin.com>
 *
 * This source file is subject to the GPL license that is bundled
 * with this source code in the file LICENSE.
 */

namespace WordPressWidgetBoilerplateWordPress;

use WP_Widget;

class Widget extends WP_Widget
{
    /**
     * @var string unique identifier for your widget
     */
    protected $widgetSlug;

    /**
     * Initializes the plugin by setting its properties and calling the parent class with the description.
     *
     * @param mixed $widgetSlug
     */
    public function __construct($widgetSlug)
    {
        $this->widgetSlug = $widgetSlug;

        parent::__construct(
            $this->getWidgetSlug(),
            __('Widget Name', $this->getWidgetSlug()),
            [
                'classname' => $this->getWidgetSlug().'-class',
                'description' => __('Short description of the widget goes here.', $this->getWidgetSlug()),
            ]
        );
    }

    /**
     * Return the widget slug.
     *
     * @return string slug variable
     */
    public function getWidgetSlug()
    {
        return $this->widgetSlug;
    }
}

Da wir diese Datei in den WordPress – Namespace verschoben haben, müssen wir als Nächstes den Autoload-Abschnitt unserer Composer-Konfigurationsdatei aktualisieren :

"autoload": {
    "psr-4": {
        "WordPressWidgetBoilerplate": "src/",
        "WordPressWidgetBoilerplateUtilities": "src/Utilities/",
        "WordPressWidgetBoilerplateSubscriber": "src/Subscriber/",
        "WordPressWidgetBoilerplateWordPress": "src/WordPress/"
    }
},

Als nächstes müssen wir einen Abonnenten vorstellen.

4 Vorstellung des Widget-Abonnenten

Immer wenn ich eine Kernklasse habe, versuche ich im Allgemeinen, einen einfachen Abonnenten zu erstellen, der die Kernklasse instanziiert und ihr erlaubt, ihre Arbeit zu erledigen.

Ich mache das, weil WordPress, wie erwähnt, das ereignisgesteuerte Designmuster verwendet, was bedeutet, dass alles für eine Art Hook registriert werden muss. Und ich mag es nicht, Domänenlogik mit derselben Klasse zu mischen, die sich in WordPress einklinkt. Also trenne ich sie.

Und das tut ein Abonnent. Es registriert sich bei WordPress und ruft dann die Klasse auf, die für die eigentliche Arbeit verantwortlich ist.

Nachdem dies gesagt ist, wenden Sie sich dem Abonnentenverzeichnis zu und fügen Sie eine Klasse namens WidgetSubscriber hinzu. Fügen Sie in dieser Klasse den folgenden Code hinzu :

<?php

<?php

namespace WordPressWidgetBoilerplateSubscriber;

use WordPressWidgetBoilerplateWordPressWidget;

/**
 * Initializes the core Widget class that's used by WordPress to instantiate the widget,
 * renders the administrative area, provide serialization functionality, and displays the
 * public-facing view.
 */
class WidgetSubscriber extends AbstractSubscriber
{
    /**
     * {@inheritdoc}
     */
    public function __construct(string $hook)
    {
        parent::__construct($hook);
    }

    /**
     * Registers the core Widget class using the WordPress APIs.
     */
    public function load()
    {
        register_widget(new Widget('widget-name'));
    }
}

Der Konstruktor registriert die Klasse mit einem bestimmten Hook, den wir uns gleich ansehen werden; dann wird es die WordPress-API verwenden, um unser Widget zu instanziieren (was in der Ladefunktion passiert ).

5 Der Bootstrap

Schließlich müssen wir den Bootstrap so aktualisieren, dass er:

• registriert den WidgetSubscriber mit dem richtigen Hook,
• fügt den Abonnenten der Registrierung hinzu ,
• und startet das Plugin (was wir getan haben).

Der Bootstrap sollte nach all dem wie folgt aussehen :

<?php

namespace WordPressWidgetBoilerplate;

use WordPressWidgetBoilerplateUtilitiesRegistry;
use WordPressWidgetBoilerplatePlugin;
use WordPressWidgetBoilerplateSubscriberWidgetSubscriber;

// Prevent this file from being called directly.
defined('WPINC') || die;

// Include the autoloader.
require_once __DIR__. '/vendor/autoload.php';

// Setup a filter so we can retrieve the registry throughout the plugin.
$registry = new Registry();
add_filter('wpwBoilerplateRegistry', function() use ($registry) {
    return $registry;
});

// Add the Widget base class to the Registry.
$registry->add('widgetSubscriber', new WidgetSubscriber('widgets_init'));

// Start the machine.
(new Plugin($registry))->start();

Als nächstes sollten Sie sich bei WordPress anmelden und das Plugin aktivieren können.

Ein Blick in den Verwaltungsbereich

An diesem Punkt gibt es nicht viel zu sehen, aber wir kommen dorthin. Zunächst sollten Sie feststellen, dass das Widget jetzt in dem Bereich erscheint, der die verfügbaren Widgets enthält:

Und Sie sollten auch sehen, dass beim Ziehen des Widgets in einen mit Widgets versehenen Bereich (oder eine beliebige Seitenleiste) keine Optionen verfügbar sind.

Das heißt, wir sind an einem guten Ort, um weiter auf dem aufzubauen, was wir haben. Auf GitHub können Sie die Entwicklung der Boilerplate jederzeit weiter verfolgen .

Fortsetzung auf

Als Nächstes bauen wir die Funktionalität für den Verwaltungsbereich des Widgets weiter aus. Danach wenden wir uns der öffentlich zugänglichen Seite des Widgets sowie der Serialisierungsfunktion zu.

Sie sollten sehen können, wie die Dinge Gestalt annehmen, wenn wir beginnen, die Logik in ihre verschiedenen Komponenten zu zerlegen. Wenn nicht, machen Sie sich keine Sorgen – es kommt noch viel mehr.

Und die endgültige Version der Boilerplate wird natürlich alle Prinzipien demonstrieren, auf denen wir in dieser Reihe von Beiträgen aufbauen.