WordPressi tüüpide, vaadete ja tellijate korraldamine

Üks asi, mida ma proovin regulaarselt teha, on WordPressile keskendunud funktsioonide loomise sujuvamaks muutmine. Olen sellest hiljuti rääkinud, kuid mõtlesin, et räägin sellest veidi rohkem.

See tähendab, et ma mõtlesin, et kirjeldan lähenemisviisi, mida kasutan selliste asjade loomisel nagu kohandatud postitustüübid, taksonoomiad, metakastid jne.

Üldiselt mõelge sellele kui strateegiale, mida järgin sellise projekti aspektide väljatöötamisel, mis liidestuvad otse WordPressiga, kuid mis võib nõuda mõnda komponenti, näiteks:

• klassid, kes registreerivad end WordPressis erinevate konksude kaudu,
• klassid, mis nõuavad teatud WordPressi API-de kõnesid
• ja klassid, mis nõuavad kohandatud vaadet.

Muidugi ei vaja kõik WordPressiga liidestavad asjad kõike ülaltoodut (nt kas kohandatud postituse tüüp vajab vaadet? Ei. Aga metakast seda vajab).

WordPressi tüüpide korraldamine

Seda silmas pidades võtan ma kaasavama näite, näiteks metakasti, ja seejärel kirjeldan viisi, kuidas seda minu arvates saab rakendada. Märgin üles asjad, mida pean vajalikuks, ja asjad, mis on valikulised.

Ja nagu ma ütlesin, kasutan näitena metakasti, kuna mul on eelmine viide ja see nõuab kõige rohkem tööd, samas kui midagi muud, näiteks kohandatud taksonoomia, ei pruugi nõuda kõiki (ainult alamhulka) tükke. .

Seda öeldes lubage mul kirjeldada oma lähenemisviisi.

Vajame tellijaid

Olen sellest konkreetsest mustrist piisavalt rääkinud kuni punktini, kus ma lihtsalt lingin selle definitsiooniga. Kui loete seda lehte, olete tõenäoliselt hästi teadlik erinevatest konksudest ja nende kasutamisest WordPressis.

Foto autor Alexander Andrews saidil Unsplash

Kuid põhjus, miks ma seda mainida tahan, on see, et selle asemel, et mõelda funktsiooni käivitamisele, kui midagi juhtub, tahan, et mõtleksite objektile, mis registreerib sündmuse, kui see juhtub.

See tähendab, et vajame teatud tüüpi abonendiklassi.

WordPressi API klassid

Teiseks vajame klasse, mis vastutavad otse WordPressiga liidestamise eest. Need on klassid, mis helistavad WordPressi API-le ja registreerivad kõik, mille eest nad vastutavad.

See tähendab, et võib-olla hakkavad nad määratlema kohandatud postituse tüübi või, nagu öeldud, metakasti.

Vaadete määratlemine

Lõpetuseks on oluline märkida, et mõne WordPressi haldusala (või isegi avalike alade) kohandatud funktsioonide jaoks võiksite lisada vaate või malli või osalise (ma üldiselt nimetan neid lihtsalt vaadeteks), mis tööd metakasti andmete esitamiseks.

Saketh Garuda foto saidil Unsplash

Mõnikord on see lihtsalt informatiivne. Mõnikord nõuab see, et see postitaks tagasi serverisse ja järjestaks andmed. Kuigi ma arvan, et viimasest rääkimine oleks tõesti kasulik, jääb see selle postituse praegusest ulatusest välja.

Võib-olla mõnes tulevases postituses.

Klasside korraldamine

Mida see kõik ütles, kuidas näeks välja seda kõike välja panna? Vähemalt me ​​vaatame:

• tellija,
• WordPressi tüüpi,
• vaade

Ja kõige rohkem võite olla huvitatud liideste või abstraktsete klasside määratlemisest, mis aitavad erinevate WordPressi tüüpide vahel lepinguid jõustada. See on ka tervislik objektorienteeritud põhimõte, millest räägin tulevases postituses.

Praegu aga räägime sellest, kuidas neid kõiki seadistada.

Tellija

Lihtsamalt öeldes vastutab tellija selle kuulamise eest, kui WordPress sündmuse tõstatab (sündmuse avaldab). Ja kui ta seda märkab, käivitab see funktsiooni, mis on sellega ühendatud.

See on üldiselt määratletud registri mustris. Kui te pole seda postitust lugenud, siis soovitan seda, kuid selle koodi seadistamine on üsna lihtne:

<?php

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

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

Sealt alates käivitub funktsioon alati, kui sündmus tõstatatakse. Siin on aga asi: funktsioon peab olema teatud klassi osa. Seega on vaja WordPress-tüüpi

WordPressi tüüp

Mulle meeldib käsitleda WordPressiga liidestavaid asju WordPressi tüüpidena (sarnaselt meie programmeerimiskeelte algtüüpidega, nagu stringid ja täisarvud). WordPressil on taksonoomiad, metakastid, menüüd ja nii edasi.

Selleks, et meie tellija korralikult töötaks, peab ta olema teadlik meie WordPressi tüübist. Kooskõlas metakasti näitega võib see välja näha järgmine:

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

Seejärel peame veenduma, et register on sellest klassist teadlik.

Vaade

Lõpuks peame metakasti puhul tagama, et seal oleks vaade, mis kuvab vähemalt teavet. Teabe järjestamine ja seejärel kasutaja jaoks vaate värskendamine on veidi erinev loom.

Aga milline võiks vaade välja näha? Lihtne :

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

See on lihtsalt põhimärgistus, mis annab kasutajale teavet.

Sidudes kõik koos

Kui ma selle kõik kokku panen, on mul tavaliselt pistikprogrammide klass, millest see kõik alguse saab. Kui projekt on suur, võib neid olla rohkem kui üks, kuid sel juhul on minu arvates okei näidata, kuidas see välja näeb, kasutades ühte klassi.

Niisiis, esiteks näeb peamine pistikprogrammi klass välja selline:

<?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 pistikprogrammi alglaadimine näeb välja selline:

<?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 sealt edasi läheb kõik muu liikuma.

Aga täiustatud funktsionaalsus?

Ma tõstatan selle küsimuse, kuna olen sellest postituses juba natuke rääkinud. Nimelt rääkisin sellest:

1. idee postitada andmed tagasi serverisse (ja tõenäoliselt neid uuesti lugeda),
2. ja olen rääkinud liideste kasutamisest.

Need on mõlemad asjad, mida minu arvates tasub põhjalikumalt uurida. Kuid enne seda panen selle teabe korraldamise aluse sellele, et see on üles ehitatud, eriti arvestades, et see põhineb varasematel postitustel, nagu registri muster, ja WordPressi-kesksete klasside korraldamine metakastide kaudu.