Utilizzo di un registro, abbonati e servizi in WordPress

TL; DR: Trovo molto utile l’utilizzo di un registro, abbonati e servizi quando si creano plugin e utilità incentrati sul back-end per WordPress. Questo post spiega come farlo.

Dopo aver lavorato per anni con modelli di progettazione, programmazione orientata agli oggetti e WordPress, è inevitabile che sorgano modi comuni per risolvere i problemi.

Questo è il modo in cui abbiamo ottenuto modelli di progettazione orientati agli oggetti per cominciare, quindi forse questa è una variazione incentrata su WordPress.

Anche se ho scritto di cose come i registri in articoli precedenti (e anche quelli che non sono così vecchi ), non è mai una cattiva idea rivisitare lo stesso argomento, specialmente quando c’è qualcosa da continuare ad aggiungere alla versione precedente.

Un registro, abbonati e servizi

Tutto quanto descritto di seguito è da intendersi nel contesto del plugin di WordPress. Cioè, questo non deve essere letto come un modo per lavorare con altri framework, linguaggi, applicazioni o quando lo si utilizza con altri modelli.

Ricordalo quando leggi questo.

Ad ogni modo, l’idea generale alla base della combinazione di questi tipi di oggetti è la seguente:

1. Il registro gestisce tutti gli abbonati,
2. Gli abbonati ascoltano gli hook all’interno di WordPress (quelli che esistono o anche gli hook personalizzati),
3. I servizi fanno il lavoro vero e proprio ogni volta che l’abbonamento li invia.

Lo scopo è che c’è un unico posto per registrare le classi responsabili dell’invio del lavoro. Questo è tutto.

Inoltre, questo rende anche facile tenere le cose separate in modo che se vuoi testare i tuoi servizi in isolamento, è molto più facile perché non sono necessariamente accoppiati strettamente a WordPress. E se lo sono, puoi deridere i dati che devono essere passati in una determinata funzione e quindi valutare il risultato.

Tuttavia, questo non è un articolo sui test, quindi torniamo alle classi effettive.

Registro

Per definizione, lo scopo di un registro è quello di tenere traccia delle cose. Quando si tratta di implementare questo modello in WordPress, l’idea è che il registro possa tenere traccia degli abbonati (che definirò più avanti in questo articolo).

Foto di Denny Müller su Unsplash

Inoltre, l’idea è che quando arriverà il momento, che probabilmente sarà diverso per come è strutturato il tuo plugin, tutti gli abbonati saranno istanziati. A quel punto, però, probabilmente vorrai farlo all’inizio del ciclo di vita di WordPress.

Detto questo, ecco un esempio di come inserire il codice per la registrazione degli abbonati:

private $subscribers = [
    AssetSubscriber::class,
    // ...
    DeletedUserSubscriber::class,
];

Quindi, ecco una funzione per creare un’istanza degli abbonati.

Questi blocchi possono far parte della stessa funzione o possono essere separati a seconda delle tue esigenze.

Iscritti

Come accennato, gli abbonati sono il modo per:

1. Ascolta un certo hook in WordPress
2. Invia un servizio per eseguire qualsiasi lavoro sia previsto per l’hook specificato.

Quindi supponi per un momento di voler fare qualcosa ogni volta che un utente viene eliminato. Si desidera creare un’istanza di un servizio tramite l’abbonato ogni volta che si verifica questo hook.

Foto di Lee Campbell su Unsplash

Come esempio:

Nota che l’abbonato è a conoscenza del servizio (sebbene non mantenga alcuna dipendenza da esso in quanto è semplicemente un intermediario tra WordPress e il servizio) e specifica l’hook sul servizio che sta creando un’istanza.

Servizi

Infine, i servizi sono gli oggetti che fanno tutto il lavoro pesante in un plugin. Ciò significa che se hanno bisogno di leggere o scrivere nel database, nel file system, nella rete, nei dati di processo, ecc., tutto avviene nel loro contesto.

Foto di Erik Mclean su Unsplash

Potrebbero essere a conoscenza di altre classi, potrebbero non esserlo. Possono implementare un’interfaccia o una classe astratta oppure no. Questo è davvero oltre lo scopo di questo post. Ma il punto è che, usando l’hook di cui sopra come esempio, se vuoi fare qualcosa quando un utente viene eliminato, lo fai all’interno del servizio.

Per esempio:

class DeletedUserService
{
    public function add(string $hook)
    {
        add_action($hook, [$this, 'deletedUser'], 99, 1);
    }

    public function deletedUser(int $userId)
    {
        $user = get_userdata($userId);
        if (false === $user) {
            return;
        }

        // Do work with the user that's being deleted.   
    }
}

E questa è la fine. Una volta eseguito il servizio, il controllo verrà restituito a WordPress e l’applicazione continuerà l’esecuzione normalmente.

Tutti insieme ora

Supponendo che tu abbia un file di bootstrap per il tuo plug-in, che la maggior parte fa poiché è qui che viene definito il plug-in richiesto, è richiesto un caricatore automatico e si verifica l’istanza del plug-in stesso.