Yksinkertainen opas WordPress-keskeisten kurssien järjestämiseen

Viimeisin päivitys marras 10, 2022

Sisältö

Yksi asioista, joita olen ponnistellut paljon yhtenäisemmin, todennäköisesti enemmän kuin koskaan ennen, on huolenaiheiden erottaminen WordPressin ja ongelma-alueen kanssa työskentelystä vastaavien luokkien välillä.

Oletetaan esimerkiksi, että työskentelet laajennuksen parissa ja se kommunikoi kolmannen osapuolen API:n kanssa. Lisäksi tämä laajennus tarjoaa myös valikoita, viestityyppejä, taksonomioita ja niin edelleen WordPressin hallinta-alueella.

Tässä on kaksi vastuualuetta:

alue, joka vastaa ongelman yleisestä ratkaisemisesta,
alue, joka vastaa WordPressin käyttöliittymästä.

Voit todeta, että WordPressin kanssa kommunikoivien testialueiden yhdistäminen on tärkeää, mutta tiedän myös, että nämä ovat kokeiltuja ja oikeita API-liittymiä, joilla on omat testinsä.

Sen sijaan meidän pitäisi keskittyä yksikkötestaukseen ja erottaa liiketoimintalogiikkamme WordPressistä.

Mutta se ei ole tämän postauksen tarkoitus. Sen sijaan kyse on tavasta mahdollisesti laatia projekti, kun osa siitä on vuorovaikutuksessa WordPressin kanssa.

Olen puhunut nimiavaruuksien tärkeydestä ja eduista aikaisemmissa viesteissäni, jotta en sukeltaa liian syvälle tähän keskusteluun täällä.

Sen sijaan olen kiinnostunut keskustelemaan tiedostojen järjestämisestä tiedostojärjestelmätasolla ja nimiavaruuden tasolla, jotta ne erotettaisiin selkeästi erikoisaloihinsa ja jotta voimme varmistaa, että esimerkiksi keskitämme yksikkötestejämme (ja muita testaus) kriittisimmillä alueilla.

Tiivistelevät metalaatikot

Haluan varmistaa, että hakemistoni ja tiedostorakenteeni heijastavat nimiavaruuksieni rakennetta. Toki se auttaa tiedostojen järjestämisessä, mutta myös käsitteellisessä organisoinnissa.

Eli jos aion työskennellä metalaatikoiden kanssa, tiedän, että löydän todennäköisesti metalaatikkotiedostot hakemistosta, joka on sisäkkäinen WordPress -emohakemiston kanssa ja sitten Admin – alihakemistosta, jota seuraa MetaBox- hakemisto.

Miltä sitä varten luokkien joukko, joka on suunniteltu työskentelemään metalaatikoiden kanssa, voisi näyttää, jos meidän pitäisi kirjoittaa niille koodi uudelleen käytettävällä tavalla? Koska tiedämme metalaatikoista, tiedämme, että tarvitsemme todennäköisesti seuraavan:

abstrakti luokka, joka määrittää viestityypin, johon kukin metalaatikko sidotaan,
kaksi toimintoa metalaatikolle – yksi sen rekisteröintiä, yksi sisällön näyttämistä varten,
hakemisto, joka sisältää metalaatikon näkymän tai esityksen,
tiedosto, joka toimii mainittuna näkymänä.

Yllä olevat seikat huomioon ottaen hakemistorakenne voisi ehkä näyttää tältä:

Seuraavaksi meillä on koodi, joka heijastaa tätä rakennetta. Eli WordPress -hakemistossamme olisi Admin – alihakemisto, koska metaruutu näkyy WordPressin hallinta-alueella, ja meillä olisi Näytä – alihakemisto, joka sisältää tietojen näyttämisestä vastaavan tiedoston.

Tämän vuoksi meidän on luotava muutama yllä lueteltu luokka. Ehkä abstrakti perusluokka näyttäisi tältä:

<?php

namespace AcmeWordPressAdminMetaBox;

abstract class AbstractMetaBox
{
    protected $postType;

    public function __construct()
    {
        $this->postType = 'acme_post_type';
    }

    abstract public function render();
    abstract public function display();
}

Sitten konkreettinen toteutus laajentaisi luokkaa, ja se näyttäisi tältä:

<?php

namespace AcmeWordPressAdminMetaBox;

class AcmeMetaBox extends AbstractMetaBox
{
    /**
     * {@inheritdoc}
     */
    public function render()
    {
        add_meta_box(
            'acme-product-image',
            'Product Image',
            [$this, 'display'],
            $this->postType,
            'side',
            'default'
        );
    }

    /**
     * {@inheritdoc}
     */
    public function display()
    {
        include_once plugin_dir_path(__FILE__).'Views/acme-product-image.php';
    }
}

Ja lopuksi, luokan näkymä sisältäisi merkintä- ja mallikoodin tietojen renderöintiä varten :

<div class="product-image-metabox">
    <p>
        <img src="<?= esc_html(get_post_meta(get_the_ID(), 'product_image', true)); ?>" alt="<?= esc_attr(get_the_title()); ?>" />
        <input type="text" value="<?= esc_html(get_post_meta(get_the_ID(), 'product_image', true)); ?>" />
    </p>
</div>

Tämä antaa meille juuri sen, mitä tarvitsemme hyvin organisoidussa, uudelleenkäytettävässä työskentelyssä metalaatikoiden kanssa. Se voidaan myös toistaa esimerkiksi valikoissa, viestityypeissä, taksonomioissa ja niin edelleen.

Mutta poikkean.

Sana yksikkötestauksesta (PHPUnitilla)

Kuten aiemmin postauksessa mainitsin, uskon, että yksikkötestausluokat, jotka ratkaisevat ongelmatilanteemme ainutlaatuisia ongelmia, ovat tärkeitä. Tämä tarkoittaa, että sinun on kerrottava PHPUnit-määritystiedostollesi jättämään WordPress-keskeiset tiedostosi pois.

Edellä esittämäni etuna on, että tästä tulee triviaalisen helppoa. Yksinkertaisesti sanottuna voit lisätä tämän phpunit.xml – tiedostoosi:

<testsuites>
  <testsuite name="Plugin">
    <directory>./tests</directory>
    <exclude>./tests/phpunit</exclude>
    <exclude>./src/WordPress</exclude>
  </testsuite>
</testsuites>

Tämä antaa sinulle mahdollisuuden keskittyä testien kirjoittamiseen erityisesti ongelmatilanteeseesi ja samalla varmistaa, että kirjoitat skaalautuvaa, ylläpidettävää ja uudelleen käytettävää WordPress-pohjaista koodia.

Kirjoitan tällä hetkellä e-kirjaa (monenlaisen muun premium-sisällön ohella). Jos olet kiinnostunut, katso mitä saat.

: tommcfarlin.com