En enkel guide för att organisera WordPress-centrerade klasser

En av de saker som jag har gjort en mycket mer samlad ansträngning, troligen mer än jag någonsin har gjort tidigare, är att hantera separationen av problem mellan klasserna som ansvarar för gränssnittet med WordPress och de som är ansvariga för att arbeta med problemdomänen.

Låt oss till exempel säga att du arbetar med ett plugin och att det kommer att kommunicera med ett tredje parts API. Dessutom kommer detta plugin också att erbjuda menyer, inläggstyper, taxonomier och så vidare inom WordPress administrationsområdet.

Här finns två ansvarsområden:

1. det område som ansvarar för att generellt lösa problemet,
2. området som ansvarar för gränssnittet med WordPress.

Du kan hävda att det är viktigt att enhetstesta områden som kommunicerar med WordPress, men jag vet också att dessa är beprövade API:er som har sina egna tester.

Istället borde vi fokusera på enhetstestning och separera vår affärslogik från WordPress.

Men det är inte meningen med det här inlägget. Istället handlar det mer om ett sätt att eventuellt lägga upp ett projekt när en del av det kommer att ha gränssnitt med WordPress.

Jag har pratat om vikten och fördelarna med namnutrymmen i tidigare inlägg så att jag inte ska gå för djupt in i den diskussionen här.

Istället är jag intresserad av att prata om att organisera filer på filsystemnivå och namnområdesnivå, så att de är renodlade i sina specialiseringsområden och så att vi kan se till att vi, säg, fokuserar våra enhetstester (och andra testning) på områden som är mest kritiska.

Abstrahera metaboxar

Jag vill se till att min katalog och filstruktur speglar mina namnområden. Visst, det hjälper med filorganisation, men också med en konceptuell organisation.

Det vill säga, om jag ska arbeta med metaboxar, då vet jag att jag sannolikt kan hitta metaboxfilerna i en katalog kapslad med den överordnade WordPress- katalogen och sedan i en Admin- underkatalog följt av en MetaBox- katalog.

För det ändamålet, hur kan en uppsättning klasser som är designade för att arbeta med metaboxar se ut om vi ska skriva kod för dem på ett återanvändbart sätt? Med tanke på vad vi vet om metaboxar vet vi att vi sannolikt kommer att behöva följande:

• en abstrakt klass som definierar inläggstypen som varje metabox kommer att vara bunden till,
• två funktioner för metaboxen – en för att registrera den, en för att visa innehållet,
• en katalog som innehåller vyn eller presentationen av metaboxen,
• en fil som kommer att fungera som nämnda vy.

Med tanke på ovanstående punkter kanske katalogstrukturen skulle se ut så här:

Därefter har vi kod som speglar denna struktur. Det vill säga, i vår WordPress- katalog skulle vi ha underkatalogen Admin eftersom metarutan visas inom administrationsområdet för WordPress, och vi skulle ha underkatalogen Visa som skulle innehålla filen som är ansvarig för att visa informationen.

Detta gör att vi behöver skapa några klasser enligt listan ovan. Kanske skulle den abstrakta basklassen se ut så här:

<?php

namespace AcmeWordPressAdminMetaBox;

abstract class AbstractMetaBox
{
    protected $postType;

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

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

Sedan skulle en konkret implementering utöka klassen, och den skulle se ut så här:

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

Och slutligen skulle vyn för klassen innehålla valfri uppmärkning och mallkod för att rendera information :

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

Detta ger oss precis vad vi behöver på ett välorganiserat, återanvändbart sätt för att arbeta med metaboxar. Det kan också upprepas för saker som menyer, inläggstyper, taxonomier och så vidare.

Men jag avviker.

Ett ord om enhetstestning (med PHPUnit)

Som jag nämnde tidigare i inlägget tror jag att enhetstestningsklasser som löser problem som är unika för vårt problemutrymme är viktiga. Detta innebär att du måste tala om för din PHPUnit-konfigurationsfil att utesluta dina WordPress-centrerade filer.

Fördelen med det jag har lagt upp ovan är att detta blir trivialt enkelt. Enkelt uttryckt kan du lägga till detta till din phpunit.xml -fil:

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

Detta ger dig möjligheten att fokusera på att skriva tester specifikt för ditt problemutrymme samtidigt som du ser till att du skriver skalbar, underhållbar och återanvändbar WordPress-baserad kod.

Jag håller för närvarande på att skriva en e-bok (tillsammans med en mängd annat premiuminnehåll). Om du är intresserad, kolla in vad du får.