Eine einfache Anleitung zum Organisieren von WordPress-zentrierten Klassen

Eines der Dinge, die ich viel konzertierter unternommen habe, wahrscheinlich mehr als je zuvor, ist die Trennung von Bedenken zwischen den Klassen, die für die Schnittstelle zu WordPress verantwortlich sind, und denjenigen, die für die Arbeit mit der Problemdomäne verantwortlich sind.

Nehmen wir zum Beispiel an, dass Sie an einem Plugin arbeiten und es mit einer Drittanbieter-API kommunizieren wird. Darüber hinaus bietet dieses Plugin auch Menüs, Beitragstypen, Taxonomien usw. im WordPress-Administrationsbereich.

Hier gibt es zwei Aufgabenbereiche:

1. der für die allgemeine Problemlösung zuständige Bereich,
2. der Bereich, der für die Schnittstelle zu WordPress zuständig ist.

Sie können argumentieren, dass es wichtig ist, Bereiche zu testen, die mit WordPress kommunizieren, aber ich weiß auch, dass dies erprobte und wahre APIs sind, die ihre eigenen Tests haben.

Stattdessen sollten wir uns auf Unit-Tests konzentrieren und unsere Geschäftslogik von WordPress trennen.

Aber darum geht es in diesem Beitrag nicht. Stattdessen geht es eher um eine Möglichkeit, ein Projekt möglicherweise zu entwerfen, wenn ein Teil davon mit WordPress verbunden wird.

Ich habe in früheren Beiträgen über die Bedeutung und Vorteile von Namespaces gesprochen, sodass ich hier nicht zu tief in diese Diskussion eintauchen werde.

Stattdessen bin ich daran interessiert, über die Organisation von Dateien auf Dateisystemebene und Namespaceebene zu sprechen, damit sie sauber in ihre Spezialgebiete unterteilt sind und wir sicherstellen können, dass wir uns beispielsweise auf unsere Komponententests (und andere Tests) in den kritischsten Bereichen.

Meta-Boxen abstrahieren

Ich stelle gerne sicher, dass meine Verzeichnis- und Dateistruktur die meiner Namensräume widerspiegelt. Sicher, es hilft bei der Dateiorganisation, aber auch bei einer konzeptionellen Organisation.

Das heißt, wenn ich mit Meta-Boxen arbeite, weiß ich, dass ich die Meta-Box-Dateien wahrscheinlich in einem Verzeichnis finden kann, das mit dem übergeordneten WordPress -Verzeichnis verschachtelt ist, und dann in einem Admin – Unterverzeichnis, gefolgt von einem MetaBox- Verzeichnis.

Wie könnte zu diesem Zweck ein Satz von Klassen aussehen, die für die Arbeit mit Metaboxen entwickelt wurden, sollten wir Code für sie in wiederverwendbarer Weise schreiben? Angesichts dessen, was wir über Metaboxen wissen, wissen wir, dass wir wahrscheinlich Folgendes benötigen werden:

• eine abstrakte Klasse, die den Beitragstyp definiert, an den jede Metabox gebunden wird,
• zwei Funktionen für die Metabox – eine zum Registrieren, eine zum Anzeigen des Inhalts,
• ein Verzeichnis, das die Ansicht oder die Präsentation der Metabox enthält,
• eine Datei, die als besagte Ansicht dient.

Angesichts der obigen Punkte würde die Verzeichnisstruktur vielleicht so aussehen:

Als nächstes haben wir Code, der diese Struktur widerspiegelt. Das heißt, in unserem WordPress – Verzeichnis hätten wir das Unterverzeichnis Admin, da die Metabox im Verwaltungsbereich von WordPress angezeigt wird, und wir hätten das Unterverzeichnis View, das die Datei enthält, die für die Anzeige der Informationen verantwortlich ist.

Dadurch müssen wir einige Klassen erstellen, wie oben aufgeführt. Vielleicht würde die abstrakte Basisklasse so aussehen:

<?php

namespace AcmeWordPressAdminMetaBox;

abstract class AbstractMetaBox
{
    protected $postType;

    public function __construct()
    {
        $this->postType = 'acme_post_type';
    }

    abstract public function render();
    abstract public function display();
}

Dann würde eine konkrete Implementierung die Klasse erweitern, und sie würde so aussehen:

<?php

namespace AcmeWordPressAdminMetaBox;

class AcmeMetaBox extends AbstractMetaBox
{
    /**
     * {@inheritdoc}
     */
    public function render()
    {
        add_meta_box(
            'acme-product-image',
            'Product Image',
            [$this, 'display'],
            $this->postType,
            'side',
            'default'
        );
    }

    /**
     * {@inheritdoc}
     */
    public function display()
    {
        include_once plugin_dir_path(__FILE__).'Views/acme-product-image.php';
    }
}

Und schließlich würde die Ansicht für die Klasse Markup- und Vorlagencode zum Rendern von Informationen enthalten :

<div class="product-image-metabox">
    <p>
        <img src="<?= esc_html(get_post_meta(get_the_ID(), 'product_image', true)); ?>" alt="<?= esc_attr(get_the_title()); ?>" />
        <input type="text" value="<?= esc_html(get_post_meta(get_the_ID(), 'product_image', true)); ?>" />
    </p>
</div>

Das gibt uns genau das, was wir in einer gut organisierten, wiederverwendbaren Weise brauchen, um mit Metaboxen zu arbeiten. Es kann auch für Dinge wie Menüs, Beitragstypen, Taxonomien usw. wiederholt werden.

Aber ich schweife ab.

Ein Wort über Unit-Tests (mit PHPUnit)

Wie ich bereits in diesem Beitrag erwähnt habe, glaube ich, dass Unit-Testing-Klassen, die Probleme lösen, die in unserem Problembereich einzigartig sind, wichtig sind. Das bedeutet, dass Sie Ihrer PHPUnit-Konfigurationsdatei mitteilen müssen, dass sie Ihre WordPress-zentrierten Dateien ausschließt.

Der Vorteil gegenüber dem, was ich oben dargelegt habe, ist, dass dies trivial einfach wird. Einfach ausgedrückt, Sie können dies zu Ihrer phpunit.xml -Datei hinzufügen:

<testsuites>
  <testsuite name="Plugin">
    <directory>./tests</directory>
    <exclude>./tests/phpunit</exclude>
    <exclude>./src/WordPress</exclude>
  </testsuite>
</testsuites>

Dies gibt Ihnen die Möglichkeit, sich auf das Schreiben von Tests speziell für Ihren Problembereich zu konzentrieren und gleichzeitig sicherzustellen, dass Sie skalierbaren, wartbaren und wiederverwendbaren WordPress-basierten Code schreiben.

Ich schreibe gerade ein eBook (zusammen mit einer Vielzahl anderer Premium-Inhalte). Wenn Sie interessiert sind, sehen Sie sich an, was Sie bekommen.