Organisera WordPress-typer, vyer och prenumeranter

En av de saker som jag kommer på mig själv försöker göra regelbundet är att effektivisera hur jag bygger WordPress-fokuserad funktionalitet. Jag har nyligen pratat om detta men tänkte att jag skulle utveckla det lite mer.

Det vill säga, jag tänkte att jag skulle lägga upp det tillvägagångssätt jag tar när jag bygger saker som anpassade inläggstyper, taxonomier, metaboxar och så vidare.

Tänk generellt på detta som en strategi som jag följer för att bygga ut aspekter av ett projekt som gränssnitt direkt med WordPress men kan kräva några komponenter som:

• klasser som registrerar sig med WordPress genom olika krokar,
• klasser som kräver anrop till vissa WordPress-API:er
• och klasser som kräver en anpassad vy.

Visst, inte alla saker som har gränssnitt med WordPress behöver allt ovanstående (behöver till exempel en anpassad inläggstyp en vy? Nej. Men en metabox gör det.)

Organisera WordPress-typer

Med det sagt ska jag ta ett mer involverat exempel som en metabox och sedan bryta ner ett sätt på vilket jag tror att det kan implementeras. Jag kommer att notera de saker jag tycker är nödvändiga och de saker som är valfria.

Och, som jag sa, jag använder en metabox som exempel eftersom jag har en tidigare referens och den kräver mest arbete medan något annat som en anpassad taxonomi kanske inte kräver alla (bara en delmängd) av bitarna .

Med det sagt, låt mig lägga ut min strategi.

Vi behöver prenumeranter

Jag har pratat tillräckligt om det här mönstret till en punkt där jag helt enkelt ska länka till en definition av det. Om du läser den här sidan är du förmodligen väl medveten om de olika krokarna och hur du använder dem i WordPress.

Foto av Alexander Andrews på Unsplash

Men anledningen till att jag vill nämna det är att snarare än att tänka på att koppla upp en funktion för att avfyra när något händer, vill jag att du tänker på ett objekt som prenumererar på en händelse när den inträffar.

Det betyder att vi behöver en typ av abonnentklass.

WordPress API-klasser

För det andra behöver vi klasser som ansvarar för gränssnitt direkt med WordPress. Det här är klasserna som anropar WordPress API och registrerar vad det än är de ansvarar för att göra.

Det vill säga, kanske kommer de att definiera en anpassad posttyp eller kanske, som sagt, de kommer att definiera en metabox.

Definiera vyer

Slutligen är det viktigt att notera att för viss anpassad funktionalitet för WordPress-administrationsområdet (eller till och med offentliga områden), kanske du vill inkludera en vy eller en mall eller en del (jag brukar bara kalla dem vyer) som arbeta för att representera data för en metabox.

Foto av Saketh Garuda på Unsplash

Ibland är detta helt enkelt informativt. Ibland kräver detta att den skickar tillbaka till servern och serialiserar data. Även om jag tror att det skulle vara riktigt fördelaktigt att prata om det senare, ligger det utanför det här inläggets nuvarande omfattning.

Kanske i ett framtida inlägg.

Organisera klasser

Vad allt detta sa, hur skulle det se ut att lägga ut allt detta? Vi tittar åtminstone på:

• en prenumerant,
• en WordPress-typ,
• En utsikt

Och som mest kan du vara intresserad av att definiera gränssnitt eller abstrakta klasser för att hjälpa till att genomdriva ett kontrakt mellan de olika WordPress-typerna. Detta är också en sund objektorienterad princip som jag kommer att prata om i ett framtida inlägg.

För nu, men låt oss prata om hur man ställer in var och en av dessa.

Abonnenten

Enkelt uttryckt är prenumeranten ansvarig för att lyssna på när WordPress tar upp ett evenemang (publicerar ett evenemang). Och när den märker att den gör det, aktiverar den en funktion som är kopplad till den.

Detta definieras i allmänhet i registermönstret. Om du inte har läst det inlägget rekommenderar jag det, men att ställa in koden för det är ganska enkelt:

<?php

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

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

Därifrån, närhelst eventet höjs, kommer funktionen att aktiveras. Men här är grejen: Funktionen måste vara en del av en viss klass. Alltså behovet av WordPress-typ

WordPress-typen

Jag gillar att betrakta de typer av saker som gränssnitt med WordPress som WordPress-typer (ungefär som våra programmeringsspråk har inhemska typer som strängar och heltal). WordPress har taxonomier, metaboxar, menyer och så vidare.

För att vår prenumerant ska kunna fungera korrekt måste den göras medveten om vår WordPress-typ. I enlighet med metabox-exemplet kan det se ut så här:

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

Sedan måste vi se till att registret är medvetet om denna klass.

Vyn

Slutligen, för en metabox måste vi se till att det finns en vy som åtminstone visar information. Att serialisera information och sedan uppdatera vyn för användaren är lite av en annan best.

Men hur kan en utsikt se ut? Lätt :

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

Det är bara grundläggande uppmärkning som återger information till användaren.

Att knyta ihop allt

När jag sätter ihop allt detta brukar jag ha en plugin-klass som sätter igång det hela. Om ett projekt är stort kan det finnas fler än ett, men i det här fallet tycker jag att det är okej att visa hur det ser ut med en enda klass.

Så för det första ser huvudpluginklassen ut så här:

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

Och startbandet för pluginet ser ut så här:

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

Och därifrån sätts allt annat igång.

Vad sägs om mer avancerad funktionalitet?

Jag ställer denna fråga eftersom jag redan har pratat lite om detta tidigare i inlägget. Jag pratade nämligen om:

1. idén att skicka tillbaka data till servern (och förmodligen läsa den igen),
2. och jag har pratat om användningen av gränssnitt.

Det här är båda saker som jag tycker är värda att utforska närmare. Men innan jag gör det, lägger grunden för hur jag organiserar denna information, att den är byggd speciellt med tanke på att den bygger på tidigare inlägg som Registry Pattern och organiserar WordPress-centrerade klasser via metaboxar också.