Lihtne juhend WordPressi-kesksete tundide korraldamiseks

Viimati uuendatud nov. 9, 2022

Sisu

Mõni sõna üksuste testimise kohta (koos PHPUnitiga)

Üks asi, mida olen teinud palju kooskõlastatumalt, tõenäoliselt rohkem kui kunagi varem, on murede eraldamine WordPressiga liidestamise ja probleemse domeeniga töötamise eest vastutavate klasside vahel.

Oletame näiteks, et töötate pistikprogrammi kallal ja see hakkab suhtlema kolmanda osapoole API-ga. Lisaks pakub see pistikprogramm WordPressi haldusalas ka menüüsid, postituste tüüpe, taksonoomiat ja nii edasi.

Siin on kaks vastutusvaldkonda:

valdkond, mis vastutab probleemi üldise lahendamise eest,
WordPressiga liidestamise eest vastutav ala.

Võite väita, et WordPressiga suhtlevate testpiirkondade ühendamine on oluline, kuid ma tean ka, et need on proovitud ja tõelised API-d, millel on oma testide komplekt.

Selle asemel peaksime keskenduma üksuste testimisele ja eraldama oma äriloogika WordPressist eemale.

Aga see pole selle postituse mõte. Selle asemel on tegemist pigem viisiga, kuidas projekti potentsiaalselt paika panna, kui osa sellest liidestub WordPressiga.

Olen varasemates postitustes rääkinud nimeruumide tähtsusest ja eelistest, et ma sellesse arutelusse siin liiga sügavalt ei sukelduks.

Selle asemel tahaksin rääkida failide korraldamisest failisüsteemi ja nimeruumi tasemel, et need oleksid selgelt oma spetsialiseerumisvaldkondadeks eraldatud ja et saaksime olla kindlad, et keskendume näiteks oma üksusetestidele (ja muudele testimine) piirkondades, mis on kõige kriitilisemad.

Abstraheerivad metakastid

Mulle meeldib veenduda, et mu kataloog ja failistruktuur peegeldavad minu nimeruumide struktuuri. Muidugi, see aitab failide korraldamisel, aga ka kontseptuaalsel korraldusel.

See tähendab, et kui ma hakkan töötama metakastidega, siis tean, et leian tõenäoliselt metakastifailid kataloogist, mis on pesastatud WordPressi emakataloogiga, seejärel administraatori alamkataloogist, millele järgneb MetaBoxi kataloog.

Kuidas võiks sel eesmärgil välja näha metakastidega töötamiseks mõeldud klasside komplekt, kui peaksime neile korduvkasutatavat koodi kirjutama? Arvestades seda, mida me metakastide kohta teame, teame, et vajame tõenäoliselt järgmist.

abstraktne klass, mis määrab postituse tüübi, millega iga metakast seotakse,
metaboksi kaks funktsiooni – üks selle registreerimiseks, teine sisu kuvamiseks,
kataloog, mis sisaldab metakasti vaadet või esitlust,
fail, mis toimib nimetatud vaatena.

Arvestades ülaltoodud punkte, võib kataloogi struktuur välja näha selline:

Järgmisena on meil kood, mis peegeldab seda struktuuri. See tähendab, et meie WordPressi kataloogis oleks meil alamkataloog Admin, kuna metakast kuvatakse WordPressi haldusalas, ja meil oleks alamkataloog Vaade, mis sisaldaks teabe kuvamise eest vastutavat faili.

See jätab meile vajaduse luua mõned ülaltoodud klassid. Võib-olla näeks abstraktne baasklass välja selline:

<?php

namespace AcmeWordPressAdminMetaBox;

abstract class AbstractMetaBox
{
    protected $postType;

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

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

Siis laiendaks konkreetne teostus klassi ja see näeks välja järgmine:

<?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 lõpuks, klassi vaade sisaldaks mis tahes märgistus- ja mallikoodi teabe renderdamiseks :

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

See annab meile täpselt selle, mida vajame hästi organiseeritud korduvkasutataval viisil, et töötada metakastidega. Seda saab korrata ka selliste asjade puhul nagu menüüd, postituste tüübid, taksonoomiad jne.

Aga ma kaldun kõrvale.

Mõni sõna üksuste testimise kohta (koos PHPUnitiga)

Nagu ma varem postituses mainisin, usun, et meie probleemiruumile ainulaadseid probleeme lahendavad ühikutestimise tunnid on olulised. See tähendab, et peate oma PHPUniti konfiguratsioonifailile ütlema, et WordPressi-kesksed failid välistaks.

Selle eeliseks, mida ma eespool kirjeldasin, on see, et see muutub triviaalselt lihtsaks. Lihtsamalt öeldes saate selle lisada oma faili phpunit.xml :

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

See annab teile võimaluse keskenduda spetsiaalselt oma probleemiruumi jaoks mõeldud testide kirjutamisele, tagades samal ajal, et kirjutate skaleeritavat, hooldatavat ja taaskasutatavat WordPressi-põhist koodi.

Kirjutan praegu e-raamatut (koos mitme muu esmaklassilise sisuga). Kui olete huvitatud, vaadake, mida saate.

: tommcfarlin.com