Organizzare tipi, visualizzazioni e abbonati di WordPress

Una delle cose che mi ritrovo a fare regolarmente è semplificare il modo in cui sto costruendo funzionalità incentrate su WordPress. Ne ho parlato di recente, ma ho pensato di ampliarlo un po’ di più.

Cioè, ho pensato di definire l’approccio che adotto quando costruisco cose come tipi di post personalizzati, tassonomie, meta box e così via.

In generale, pensa a questa come a una strategia che seguo per costruire aspetti di un progetto che si interfaccia direttamente con WordPress ma potrebbe richiedere alcuni componenti come:

• classi che si registrano con WordPress tramite vari hook,
• classi che richiedono chiamate a determinate API di WordPress
• e classi che richiedono una visualizzazione personalizzata.

Certo, non tutte le cose che si interfacciano con WordPress avranno bisogno di tutto quanto sopra (ad esempio, un tipo di post personalizzato ha bisogno di una vista? No. Ma una meta box sì).

Organizzare i tipi di WordPress

Detto questo, prenderò un esempio più complesso come un meta box e poi analizzerò un modo in cui penso che possa essere implementato. Prenderò nota delle cose che ritengo necessarie e delle cose che sono facoltative.

E, come ho detto, sto usando una meta box come esempio perché ho un riferimento precedente e comporta la maggior parte del lavoro mentre qualcos’altro come una tassonomia personalizzata potrebbe non richiedere tutti (solo un sottoinsieme) dei pezzi .

Detto questo, lascia che ti spieghi il mio approccio.

Abbiamo bisogno di abbonati

Ho parlato abbastanza di questo modello particolare al punto in cui mi collegherò semplicemente a una sua definizione. Se stai leggendo questa pagina, probabilmente sei ben consapevole dei vari hook e di come utilizzarli in WordPress.

Foto di Alexander Andrews su Unsplash

Ma il motivo per cui voglio menzionarlo è perché invece di pensare di collegare una funzione da attivare ogni volta che accade qualcosa, voglio che tu pensi a un oggetto che si iscrive a un evento quando si verifica.

Ciò significa che avremo bisogno di un tipo di classe di abbonato.

Classi API di WordPress

In secondo luogo, abbiamo bisogno di classi che siano responsabili dell’interfacciamento diretto con WordPress. Queste sono le classi che chiamano l’API di WordPress e registrano qualunque cosa siano responsabili di fare.

Cioè, forse definiranno un tipo di post personalizzato o forse, come affermato, definiranno una meta box.

Definire le viste

Infine, è importante notare che per alcune funzionalità personalizzate per l’area di amministrazione di WordPress (o anche per aree pubbliche), potresti voler includere una vista o un modello o una vista parziale (generalmente li chiamo semplicemente viste) che lavorare per rappresentare i dati per una meta box.

Foto di Saketh Garuda su Unsplash

A volte questo sarà semplicemente informativo. A volte, ciò richiederà il postback sul server e la serializzazione dei dati. Anche se penso che parlare di quest’ultimo sarebbe davvero vantaggioso, è al di fuori dell’attuale scopo di questo post.

Forse in un prossimo post.

Organizzazione delle classi

Detto questo, come sarebbe stendere tutto questo? Come minimo, stiamo guardando:

• un abbonato,
• un tipo WordPress,
• una vista

E, al massimo, potresti essere interessato a definire interfacce o classi astratte per aiutare a far rispettare un contratto tra i vari tipi di WordPress. Questo è anche un sano principio orientato agli oggetti di cui parlerò in un prossimo post.

Per ora, però, parliamo di come impostare ciascuno di questi.

L’abbonato

In poche parole, l’abbonato è responsabile di ascoltare ogni volta che WordPress genera un evento (pubblica un evento). E quando si accorge che lo fa, attiva una funzione che è collegata ad esso.

Questo è generalmente definito nel modello di registro. Se non hai letto quel post, te lo consiglio, ma impostare il codice è abbastanza semplice:

<?php

class AcmeMetaBoxSubscriber extends AbstractSubscriber
{
    public function __construct(string $hook)
    {
        parent::__construct($hook);
    }

    public function load()
    {
        (new AcmeMetaBox())->render();
    }
}

Da lì, ogni volta che l’evento viene generato, la funzione si attiverà. Ecco la cosa però: la funzione deve far parte di una certa classe. Pertanto, la necessità del tipo WordPress

Il tipo WordPress

Mi piace considerare i tipi di cose che si interfacciano con WordPress come tipi di WordPress (proprio come i nostri linguaggi di programmazione hanno tipi nativi come stringhe e numeri interi). WordPress ha tassonomie, meta box, menu e così via.

Affinché il nostro abbonato funzioni correttamente, deve essere informato del nostro tipo di WordPress. In linea con l’esempio della meta box, ecco come potrebbe apparire:

<?php

class AcmeMetaBox extends AbstractMetaBox
{
    public function render()
    {
        add_meta_box(
            'acme-data',
            'Acme Data',
            [$this, 'display'],
            $this->postType,
            'normal',
            'high'
        );
    }

    public function display()
    {
        include_once plugin_dir_path(__FILE__).'Views/acme-data.php';
    }
}

Quindi dobbiamo assicurarci che il registro sia a conoscenza di questa classe.

La vista

Infine, per un meta box, dobbiamo assicurarci che ci sia una vista che mostri almeno le informazioni. Serializzare le informazioni e quindi aggiornare la vista per l’utente è un po’ una bestia diversa.

Ma come potrebbe essere una vista? Facile :

<div class="acme-data-metabox">
  <?php echo __('Acme Data', 'acme-meta-box'); ?>
  <p class="description">
    This is the content of the metabox.
  </p>
</div>

È solo un markup di base che rende le informazioni all’utente.

Legare tutto insieme

Ogni volta che metto tutto questo insieme, di solito ho una classe di plugin che fa iniziare tutto. Se un progetto è grande, potrebbe essercene più di uno, ma in questo caso penso che sia giusto mostrare come appare usando una singola classe.

Quindi, per prima cosa, la classe di plugin principale è simile a questa:

<?php

class Plugin
{
    private $registry;

    public function __construct(Registry $registry)
    {
        $this->registry = $registry;
    }

    public function start()
    {
        array_map(function ($subscriber) {
            add_action($subscriber->getHook(), [$subscriber, 'load']);
        }, $this->registry->getRegisteredSubscribers());
    }
}

E il bootstrap per il plugin si presenta così:

<?php

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

// Register all of our objects with a basic registry.
$registry->add('acmeMetaBoxSubscriber', new AcmeMetaBoxSubscriber('add_meta_boxes'));

$plugin = new Plugin($registry);
$plugin->start();

E, da lì, tutto il resto si mette in moto.

Che dire di funzionalità più avanzate?

Sollevo questa domanda perché ne ho già parlato un po’ all’inizio del post. Vale a dire, ho parlato di:

1. l’idea di inviare i dati al server (e probabilmente leggerli di nuovo),
2. e ho parlato dell’uso delle interfacce.

Queste sono entrambe cose che penso valga la pena esplorare in modo più dettagliato. Ma prima di farlo, gettare le basi per il modo in cui organizzo queste informazioni è costruito soprattutto dato che si basa su post precedenti come Registry Pattern e anche l’organizzazione di classi incentrate su WordPress tramite meta box.