WordPress-Plugin-Konstrukteure sollten keine Hooks definieren

WordPress-Plugin-Konstrukteure scheinen immer mehr ein Diskussionsthema zu sein, wenn es darum geht, was sie definieren sollten. Ich habe schon früher darüber gesprochen, aber es ist in Ordnung, ein Thema wie dieses von Zeit zu Zeit wieder aufzugreifen, oder?

Schließlich gibt es Dinge, die wir lernen und Dinge, die wir ändern, wenn wir mehr Erfahrung sammeln.

Es ist überhaupt nicht ungewöhnlich, dass Plugins Hooks und anderes Verhalten definieren, aber ich bin kein Fan dieses Ansatzes. Stattdessen denke ich, dass die Handhabung der Hook-Registrierung in einer eigenen Funktion oder, noch drastischer, durch eine Reihe von Klassen erfolgen sollte.

Aber bevor ich darauf eingehe, möchte ich erklären, was in einen WordPress-Plugin-Konstruktor gehen sollte, warum es in einen Konstruktor gehen sollte und wie dies bei der Arbeit an Ihren Plugins gehandhabt werden kann.

WordPress-Plugin-Konstruktoren

Von Anfang an denke ich, dass Konstruktoren für eine Sache verwendet werden sollten:

• Initialisieren des Zustands eines Objekts.

Was den Anfangszustand eines Objekts definiert, kann davon abhängen, ob es „von Grund auf neu“ erstellt wurde oder ob es mit Informationen aus einem früheren Satz geladen wurde (wie eine Sitzung, die serialisiert wird). So wie ich es sehe:

• Attribute sind Substantive, die ein Objekt beschreiben,
• Funktionen sind Verben, die beschreiben, was das Objekt tun kann.

Die Funktionen erledigen natürlich die Arbeit, zu der das Objekt in der Lage ist. Sie können den Status des Objekts ändern, wenn sie aufgerufen werden, oder sie können an den Argumenten arbeiten, die an die Funktionen übergeben werden.

Was sollte in einem Konstruktor vorkommen?

Wenn ein Objekt konstruiert wird, sollte es einfach so gesetzt werden, dass seine Attribute gesetzt sind und seine Funktionen bereit sind zu arbeiten.

Wenn etwas im Konstruktor den Anfangszustand eines Objekts nicht beeinflusst, sollte es nicht vorhanden sein.

Warum sollten Attribute in einem Konstruktor enthalten sein?

Vielleicht könnte man diese Frage besser stellen:

Warum sollten Hooks nicht im Konstruktor definiert werden?

Das Hook-System von WordPress ist Teil des ereignisgesteuerten Designmusters (von dem ich ein Fan bin), aber das Registrieren von Hooks beschreibt nicht den Zustand des Objekts. Stattdessen ist es auf der grundlegendsten Ebene etwas, das eine Beziehung zwischen dem Objekt und WordPress herstellt.

Der Anfangszustand des Objekts muss nichts über WordPress wissen, keine seiner Funktionen auf die Kopplung mit WordPress eingestellt haben oder eine Verarbeitung mit WordPress durchführen.

Denken Sie daran, dass Attribute in einem Konstruktor initialisiert werden. WordPress ist kein Attribut. Es ist eine Abhängigkeit. Um eine Abhängigkeit zu erstellen, müssen Sie eine Aktion ausführen, die die Definition eines Verbs ist.

Daher sollte die gesamte Hook-Registrierung in einer Funktion erfolgen.

Wie können wir die Hook-Registrierung handhaben?

Dies ist eines dieser Themen, das ein eigener Beitrag oder eine Reihe von Beiträgen sein kann.

• Es ist möglich, eine Klasse zu erstellen, die eine Registrierung von Objekten und den Hooks mit WordPress verwaltet.
• Es ist auch möglich, die Hook-Registrierung innerhalb einer Funktion in der Klasse zu definieren.
• Wir können auch eine Reihe von Dingen mit der Abhängigkeitsinversion machen .

All dies sind Dinge, die den Rahmen dieses Beitrags sprengen würden, aber der Einfachheit halber zeige ich ein Beispiel dafür, wie eine Klasse ihre Funktionen bei WordPress in einer Init-Funktion registrieren kann :

<?php

namespace AcmeAdmin;
use AcmeAdminInterfaces;

class JavaScript_Assets implements InterfacesAsset {

    private $assets_dir;

    private $js_dir;

    public function __construct() {

        $this->assets_dir = trailingslashit(
            plugin_dir_url( __FILE__ ). 'assets'
        );

        $this->js_dir = trailingslashit( $this->assets_dir. 'js' );
    }

    public function init() {

        add_action(
            'admin_enqueue_scripts',
            array( $this, 'enqueue') );
    }

    public function enqueue() {

        wp_enqueue_script(
            'toggle-admin-notices',
            $this->js_dir. 'admin.js',
            array( 'jquery' ),
            false
        );
    }
}

Auf diese Weise können wir das Objekt instanziieren, testen, verwenden usw., aber wir müssen uns um nichts kümmern, was mit WordPress zu tun hat, ohne die init- Funktion explizit aufzurufen.

Sobald das aufgerufen ist, ist die Abhängigkeit erstellt, WordPress wird benötigt, und die Dinge werden komplizierter.

Oh, und diese Testsache

Ich möchte noch einen Punkt erwähnen, der etwas über den Rahmen und Sinn dieses Beitrags hinausgeht, aber dennoch relevant ist: Wenn es um das Testen einer Klasse geht, sollten wir in der Lage sein:

1. Erstellen Sie eine Instanz der Klasse,
2. Testen seiner Logik durch Aufrufen von Funktionen,
3. ihm Parameter übergeben und seine Rückgabewerte auswerten.

Und wir sollten in der Lage sein, so viel wie möglich isoliert zu tun. Wenn im Konstruktor Hooks definiert sind, entsteht eine unmittelbare Abhängigkeit von WordPress, die nicht benötigt werden sollte.

WordPress beschreibt nicht den Zustand eines Objekts. Es ist eine Abhängigkeit des Objekts.

Wie auch immer, der Punkt, den ich zu machen versuche, ist, dass WordPress-Plugin-Konstrukteure die Registrierung von Hooks nicht handhaben sollten, da Hooks ihren Zustand nicht beschreiben. Sie beziehen sich auf etwas, das die Klasse tut, und sie hindern uns daran, ein Objekt isoliert zu testen.

Sie haben also ihren Platz, aber nicht im Konstruktor.