Rekisterin, tilaajien ja palveluiden käyttäminen WordPressissä

TL;DR: Pidän rekisterin, tilaajien ja palveluiden käyttämistä erittäin hyödyllisenä, kun rakennetaan taustakeskeisiä laajennuksia ja apuohjelmia WordPressille. Tämä viesti opastaa kuinka se tehdään.

Kun olet työskennellyt vuosien suunnittelumallien, olioohjelmoinnin ja WordPressin parissa, yleisiä tapoja ratkaista ongelmia syntyy varmasti.

Näin saimme alkuun oliopohjaiset suunnittelumallit, joten ehkä tämä on WordPress-keskeinen muunnelma siitä.

Vaikka olen kirjoittanut esimerkiksi rekisteristä aiemmissa artikkeleissa (ja sellaisissa, jotka eivät edes ole niin vanhoja ), ei ole koskaan huono idea palata samaan aiheeseen, varsinkin kun on jotain lisättävää edelliseen osioon.

Rekisteri, tilaajat ja palvelut

Kaikki alla kuvattu on ymmärrettävä WordPress-laajennuksen yhteydessä. Toisin sanoen tätä ei ole tarkoitus lukea tapana työskennellä muiden kehysten, kielten, sovellusten kanssa tai käytettäessä sitä muiden mallien kanssa.

Muista tämä lukiessasi.

Joka tapauksessa yleinen idea näiden objektityyppien yhdistelmän takana, jos seuraavat:

1. Rekisteri käsittelee kaikki tilaajat,
2. Tilaajat kuuntelevat WordPressin koukkuja (olemassa olevia tai jopa mukautettuja koukkuja),
3. Palvelut tekevät varsinaisen työn aina, kun tilaaja lähettää ne.

Tarkoituksena on, että työn lähettämisestä vastaavat luokat rekisteröidään yhdessä paikassa. Se siitä.

Lisäksi tämä helpottaa asioiden pitämistä erillään, joten jos haluat testata palveluitasi erillään, se on paljon helpompaa, koska ne eivät välttämättä ole tiiviisti kytketty WordPressiin. Ja jos ne ovat, voit pilkata dataa, joka on siirrettävä tiettyyn funktioon, ja arvioida sitten tuloksen.

Tämä ei kuitenkaan ole artikkeli testaamisesta, joten takaisin varsinaisiin luokkiin.

Rekisteri

Määritelmän mukaan rekisterin tarkoitus on pitää kirjaa asioista. Mitä tulee tämän mallin toteuttamiseen WordPressissä, ajatuksena on, että rekisteri voi seurata tilaajia (jotka määritän myöhemmin tässä artikkelissa).

Kuva Denny Müller Unsplashista

Lisäksi ajatuksena on, että kun sen aika tulee, mikä on todennäköisesti erilainen laajennuksen rakenteesta riippuen, kaikki tilaajat ovat instantioita. Siihen asti haluat kuitenkin todennäköisesti tehdä sen WordPressin elinkaaren varhaisessa vaiheessa.

Tässä on kuitenkin esimerkki tilaajien rekisteröinnin koodista:

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

Seuraavaksi tässä on toiminto tilaajien instantoimiseksi.

Nämä lohkot voivat olla osa samaa toimintoa tai ne voivat olla erillisiä tarpeidesi mukaan.

Tilaajat

Kuten mainittiin, tilaajat voivat:

1. Kuuntele tiettyä koukkua WordPressissä
2. Lähetä palvelu suorittamaan kaikki työt, jotka on tarkoitettu kyseiselle koukkuun.

Oletetaan siis hetkeksi, että haluat tehdä jotain aina, kun käyttäjä poistetaan. Haluat luoda palvelun tilaajan kautta aina, kun tämä koukku tapahtuu.

Kuva: Lee Campbell Unsplashista

Esimerkiksi:

Huomaa, että tilaaja on tietoinen palvelusta (vaikka se ei olekaan riippuvainen siitä, koska se on vain välittäjä WordPressin ja palvelun välillä) ja määrittää koukun palveluun, jonka se luo.

Palvelut

Lopuksi palvelut ovat objekteja, jotka tekevät kaiken laajennuksen raskaan noston. Tämä tarkoittaa, että jos heidän täytyy lukea tai kirjoittaa tietokantaan, tiedostojärjestelmään, verkkoon, käsitellä tietoja jne., kaikki tapahtuu heidän kontekstissaan.

Kuva Erik Mclean Unsplashista

He saattavat olla tietoisia muista luokista, he eivät ehkä ole tietoisia. Ne voivat toteuttaa rajapinnan tai abstraktin luokan tai eivät. Se ei todellakaan kuulu tämän postauksen piiriin. Mutta pointti on, että ylhäältä koukkua esimerkkinä käyttäen, jos haluat tehdä jotain, kun käyttäjä poistetaan, teet sen palvelun sisällä.

Esimerkiksi:

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

Ja siihen se loppuu. Kun palvelu on käynnissä, hallinta palautetaan WordPressille ja sovellus jatkaa suoritusta normaalisti.

Kaikki yhdessä nyt

Olettaen, että sinulla on laajennukselle bootstrap-tiedosto, jota useimmat tekevät, koska vaadittu laajennus on määritelty tässä, tarvitaan automaattinen lataus, ja itse laajennus toteutuu.