Una guida semplice per organizzare classi incentrate su WordPress

Una delle cose su cui ho fatto uno sforzo molto più concertato, probabilmente più di quanto abbia mai fatto prima, è la gestione della separazione delle preoccupazioni tra le classi responsabili dell’interfacciamento con WordPress e quelle responsabili del lavoro con il dominio problematico.

Ad esempio, supponiamo che stai lavorando su un plug-in e comunicherà con un’API di terze parti. Inoltre, questo plugin offrirà anche menu, tipi di post, tassonomie e così via nell’area di amministrazione di WordPress.

Ci sono due aree di responsabilità qui:

1. l’area responsabile della soluzione generale del problema,
2. l’area preposta all’interfacciamento con WordPress.

Puoi sostenere che è importante unità di test delle aree che comunicano con WordPress, ma so anche che queste sono API collaudate e vere che hanno il loro set di test.

Invece, dovremmo concentrarci sugli unit test e separare la nostra logica aziendale da WordPress.

Ma non è questo il punto di questo post. Invece, si tratta più di un modo per presentare potenzialmente un progetto quando una parte di esso si interfaccerà con WordPress.

Ho parlato dell’importanza e dei vantaggi degli spazi dei nomi nei post precedenti in modo da non immergermi troppo in questa discussione qui.

Invece, mi interessa parlare dell’organizzazione dei file a livello di filesystem e di namespace, in modo che siano nettamente separati nelle loro aree di specializzazione e così possiamo assicurarci di concentrare, diciamo, i nostri unit test (e altri test) sulle aree più critiche.

Astrazione di Meta Box

Mi piace assicurarmi che la mia directory e la struttura dei file rispecchino quella dei miei spazi dei nomi. Certo, aiuta con l’organizzazione dei file, ma anche con un’organizzazione concettuale.

Cioè, se lavorerò con meta box, so che probabilmente posso trovare i file meta box in una directory annidata con la directory principale di WordPress, quindi all’interno di una sottodirectory Admin seguita da una directory MetaBox.

A tal fine, come potrebbe essere un insieme di classi progettate per lavorare con i meta box, dovremmo scrivere il codice per loro in modo riutilizzabile? Dato quello che sappiamo sui meta box, sappiamo che probabilmente avremo bisogno di quanto segue:

• una classe astratta che definisce il tipo di post a cui sarà legato ogni meta box,
• due funzioni per il meta box: uno per registrarlo, uno per visualizzare il contenuto,
• una directory per contenere la vista o la presentazione del meta box,
• un file che fungerà da detta vista.

Dati i punti precedenti, forse la struttura della directory sarebbe simile a questa:

Successivamente, abbiamo un codice che rispecchia questa struttura. Cioè, all’interno della nostra directory di WordPress, avremmo la sottodirectory Admin poiché la meta box viene visualizzata nell’area di amministrazione di WordPress e avremmo la sottodirectory View che conterrebbe il file responsabile della visualizzazione delle informazioni.

Questo ci lascia con la necessità di creare alcune classi come elencato sopra. Forse la classe base astratta sarebbe simile a questa:

<?php

namespace AcmeWordPressAdminMetaBox;

abstract class AbstractMetaBox
{
    protected $postType;

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

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

Quindi un’implementazione concreta estenderebbe la classe e assomiglierebbe a questa:

<?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';
    }
}

E infine, la vista per la classe conterrebbe qualsiasi codice di markup e modello per il rendering delle informazioni :

<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>

Questo ci dà esattamente ciò di cui abbiamo bisogno in un modo ben organizzato e riutilizzabile per lavorare con i meta box. Può anche essere ripetuto per cose come menu, tipi di post, tassonomie e così via.

Ma sto divagando.

Una parola sui test unitari (con PHPUnit)

Come accennato in precedenza nel post, credo che le classi di unit test che risolvono problemi unici nel nostro spazio problematico siano importanti. Ciò significa che dovresti dire al tuo file di configurazione PHPUnit di escludere i tuoi file incentrati su WordPress.

Il vantaggio di ciò che ho esposto sopra è che questo diventa banalmente facile. In poche parole, puoi aggiungerlo al tuo file phpunit.xml :

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

Ciò ti dà la possibilità di concentrarti sulla scrittura di test specifici per il tuo spazio problematico assicurandoti allo stesso tempo di scrivere codice basato su WordPress scalabile, manutenibile e riutilizzabile.

Attualmente sto scrivendo un eBook (insieme a una varietà di altri contenuti premium). Se sei interessato, controlla cosa ottieni.