WordPress-tyyppien, -näkymien ja -tilaajien järjestäminen

Yksi asioista, joita yritän tehdä säännöllisesti, on virtaviivaistaa WordPress-painotteisten toimintojen rakentamista. Olen äskettäin puhunut tästä, mutta ajattelin laajentaa sitä hieman enemmän.

Toisin sanoen ajattelin esitellä lähestymistavan, jota käytän rakentaessani asioita, kuten mukautettuja viestityyppejä, taksonomioita, metalaatikoita ja niin edelleen.

Yleensä ajattelen tätä strategiana, jota noudatan rakentaessani sellaisia ​​projektin näkökohtia, jotka liittyvät suoraan WordPressiin, mutta jotka voivat vaatia muutamia komponentteja, kuten:

• luokat, jotka rekisteröivät itsensä WordPressiin erilaisten koukkujen kautta,
• luokat, jotka vaativat kutsuja tiettyihin WordPress-sovellusliittymiin
• ja luokat, jotka vaativat mukautetun näkymän.

Kaikki WordPressin kanssa käyttöliittymät eivät tietenkään tarvitse kaikkia yllä olevia (esimerkiksi tarvitseeko mukautettu viestityyppi näkymää? Ei. Mutta metalaatikko tarvitsee.)

WordPress-tyyppien järjestäminen

Tämän sanottuani otan osallistuvamman esimerkin, kuten metalaatikon, ja sitten rikon tavan, jolla se voidaan mielestäni toteuttaa. Merkitsen ne asiat, jotka ovat mielestäni tarpeellisia ja valinnaisia.

Ja kuten sanoin, käytän metalaatikkoa esimerkkinä, koska minulla on aikaisempi viittaus ja se vaatii eniten työtä, kun taas jokin muu, kuten mukautettu taksonomia, ei välttämättä vaadi kaikkia (vain osajoukkoa) kappaleista .

Tämän sanottuani, anna minun esittää lähestymistapani.

Tarvitsemme tilaajia

Olen puhunut tästä tietystä mallista tarpeeksi siihen pisteeseen, että aion yksinkertaisesti linkittää sen määritelmään. Jos luet tätä sivua, olet todennäköisesti hyvin tietoinen WordPressin erilaisista koukuista ja niiden käyttämisestä.

Kuva: Alexander Andrews Unsplashissa

Mutta syy, miksi haluan mainita sen, johtuu siitä, että sen sijaan, että ajattelet funktion kytkemistä käynnistymään aina, kun jotain tapahtuu, haluan sinun ajattelevan objektia, joka tilaa tapahtuman sen tapahtuessa.

Tämä tarkoittaa, että tarvitsemme tietyn tyyppisen tilaajaluokan.

WordPress API luokat

Toiseksi tarvitsemme luokkia, jotka vastaavat suoraan WordPress-liittymästä. Nämä ovat luokat, jotka kutsuvat WordPress API:ta ja rekisteröivät sen, mistä he ovat vastuussa.

Eli ehkä he määrittelevät mukautetun viestityypin tai kenties, kuten todettiin, he aikovat määritellä metalaatikon.

Näkymien määrittäminen

Lopuksi on tärkeää huomata, että joihinkin WordPress-hallinta-alueen mukautettuihin toimintoihin (tai jopa julkisiin alueisiin) saatat haluta sisällyttää näkymän tai mallin tai osan (jota yleensä kutsun vain näkymiksi), joka työ edustaa metalaatikon tietoja.

Kuva: Saketh Garuda Unsplashissa

Joskus tämä on yksinkertaisesti informatiivinen. Joskus tämä edellyttää, että se lähettää takaisin palvelimelle ja sarjoittaa tiedot. Vaikka uskon, että jälkimmäisestä puhuminen olisi todella hyödyllistä, se ei kuulu tämän viestin nykyiseen soveltamisalaan.

Ehkä jossain tulevassa postauksessa.

Luokkien järjestäminen

Mitä se kaikki sanoi, miltä näyttäisi tämän kaiken esittäminen? Ainakin katsomme:

• tilaaja,
• WordPress-tyyppinen,
• näkymä

Ja korkeintaan saatat olla kiinnostunut määrittelemään rajapintoja tai abstrakteja luokkia, jotka auttavat toimeenpanemaan sopimusta eri WordPress-tyyppien välillä. Tämä on myös terve oliolähtöinen periaate, josta puhun seuraavassa postauksessa.

Puhutaan nyt kuitenkin siitä, miten kukin näistä määritetään.

Tilaaja

Yksinkertaisesti sanottuna tilaaja on vastuussa kuuntelemisesta aina, kun WordPress herättää tapahtuman (julkaisee tapahtuman). Ja kun se huomaa sen, se käynnistää toiminnon, joka on koukussa siihen.

Tämä on yleensä määritelty rekisterimallissa. Jos et ole lukenut tätä viestiä, suosittelen sitä, mutta koodin asettaminen sille on melko helppoa:

<?php

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

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

Sieltä aina, kun tapahtuma nostetaan, toiminto käynnistyy. Asia on kuitenkin tässä: Funktion on oltava osa tiettyä luokkaa. Näin ollen WordPress-tyypin tarve

WordPress-tyyppi

Tykkään pitää WordPressin kanssa käyttöliittymän tyyppejä WordPress-tyypeinä (kuten ohjelmointikielillämme on natiivityyppejä, kuten merkkijonoja ja kokonaislukuja). WordPressissä on taksonomioita, metaruutuja, valikoita ja niin edelleen.

Jotta tilaajamme toimisi kunnolla, hänen tulee olla tietoinen WordPress-tyypistämme. Metalaatikkoesimerkin mukaisesti se voi näyttää tältä:

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

Sitten meidän on varmistettava, että rekisteri on tietoinen tästä luokasta.

Näkymä

Lopuksi, meidän on varmistettava, että metalaatikossa on näkymä, joka näyttää ainakin tiedot. Tietojen sarjoittaminen ja sitten näkymän päivittäminen käyttäjälle on hieman erilainen peto.

Mutta miltä näkymä voi näyttää? Helppoa :

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

Se on vain perusmerkintä, joka tuottaa tietoa käyttäjälle.

Sitomalla kaikki yhteen

Aina kun yhdistän tämän kaiken, minulla on yleensä laajennusluokka, joka saa kaiken alkuun. Jos projekti on suuri, niitä voi olla useampi kuin yksi, mutta tässä tapauksessa mielestäni on oikein näyttää, miltä se näyttää yhdellä luokalla.

Joten ensinnäkin päälaajennusluokka näyttää tältä:

<?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());
    }
}

Ja laajennuksen bootstrap näyttää tältä:

<?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();

Ja sieltä kaikki muu lähtee liikkeelle.

Entä edistyneemmät toiminnot?

Esitän tämän kysymyksen, koska olen puhunut tästä jo hieman aiemmin postauksessa. Puhuin nimittäin:

1. ajatus tietojen lähettämisestä takaisin palvelimelle (ja luultavasti lukeminen uudelleen),
2. ja olen puhunut käyttöliittymien käytöstä.

Nämä ovat molemmat asioita, joihin mielestäni kannattaa tutustua tarkemmin. Mutta ennen kuin teen sen, perustan tämän tiedon järjestämiselle on se, että se on rakennettu erityisesti, koska se perustuu aikaisempiin viesteihin, kuten rekisterimalliin, ja WordPress-keskeisten luokkien järjestämiseen myös metalaatikoiden kautta .