Organizowanie typów, widoków i subskrybentów WordPress

Jedną z rzeczy, które staram się robić regularnie, jest usprawnienie sposobu budowania funkcjonalności skoncentrowanej na WordPressie. Niedawno o tym mówiłem, ale pomyślałem, że rozszerzę to trochę bardziej.

To znaczy, pomyślałem, że przedstawię podejście, które przyjmę podczas tworzenia takich rzeczy, jak niestandardowe typy postów, taksonomie, metaboxy i tak dalej.

Ogólnie rzecz biorąc, pomyśl o tym jako o strategii, którą stosuję do budowania aspektów projektu, który jest bezpośrednio połączony z WordPress, ale może wymagać kilku komponentów, takich jak:

• klasy, które rejestrują się w WordPressie poprzez różne hooki,
• klasy, które wymagają wywołań określonych API WordPress
• i klasy, które wymagają niestandardowego widoku.

Jasne, nie wszystko, co łączy się z WordPressem, będzie wymagało wszystkich powyższych (na przykład, czy niestandardowy typ posta wymaga widoku? Nie. Ale metabox tak).

Organizowanie typów WordPress

Powiedziawszy to, zamierzam wziąć bardziej zaangażowany przykład, taki jak metabox, a następnie podzielić sposób, w jaki myślę, że można go zaimplementować. Zanotuję rzeczy, które uważam za konieczne i te, które są opcjonalne.

I, jak powiedziałem, używam meta pola jako przykładu, ponieważ mam poprzednie odniesienie i wymaga to największej ilości pracy, podczas gdy coś innego, takie jak niestandardowa taksonomia, może nie wymagać wszystkich (tylko podzbioru) elementów .

Powiedziawszy to, pozwól, że przedstawię moje podejście.

Potrzebujemy subskrybentów

Opowiedziałem o tym konkretnym wzorcu wystarczająco do momentu, w którym po prostu połączę się z jego definicją. Jeśli czytasz tę stronę, prawdopodobnie dobrze wiesz o różnych haczykach i sposobach ich używania w WordPressie.

Zdjęcie autorstwa Alexandra Andrewsa na Unsplash

Ale powodem, dla którego chcę o tym wspomnieć, jest to, że zamiast myśleć o podłączaniu funkcji do uruchamiania, gdy coś się dzieje, chcę, abyś pomyślał o obiekcie, który subskrybuje zdarzenie, gdy ono wystąpi.

Oznacza to, że będziemy potrzebować typu klasy subskrybenta.

Klasy API WordPress

Po drugie, potrzebujemy klas, które są odpowiedzialne za bezpośrednie połączenie z WordPressem. Są to klasy, które wywołują API WordPressa i rejestrują wszystko, za co są odpowiedzialne.

Oznacza to, że być może zdefiniują niestandardowy typ posta, a może, jak wspomniano, zdefiniują pole meta.

Definiowanie widoków

Na koniec ważne jest, aby pamiętać, że w przypadku niektórych niestandardowych funkcji dla obszaru administracyjnego WordPress (lub nawet obszarów publicznych) możesz chcieć dołączyć widok, szablon lub część (zwykle nazywam je po prostu widokami), które będą pracy do reprezentowania danych dla pola meta.

Zdjęcie: Saketh Garuda na Unsplash

Czasami będzie to po prostu informacyjne. Czasami będzie to wymagać odesłania z powrotem do serwera i serializacji danych. Chociaż myślę, że rozmowa o tym ostatnim byłaby naprawdę korzystna, wykracza to poza obecny zakres tego postu.

Być może w przyszłym poście.

Organizowanie zajęć

Co to wszystko powiedziało, jak by to wyglądało, gdyby to wszystko rozłożyć? Przynajmniej patrzymy na:

• subskrybent,
• typu WordPress,
• widok

Co najwyżej możesz być zainteresowany zdefiniowaniem interfejsów lub klas abstrakcyjnych, aby pomóc w egzekwowaniu umowy między różnymi typami WordPressa. Jest to również zdrowa zasada zorientowania obiektowego, o której opowiem w przyszłym poście.

Na razie jednak porozmawiajmy o tym, jak skonfigurować każdy z nich.

Abonent

Mówiąc najprościej, subskrybent jest odpowiedzialny za słuchanie, gdy WordPress zgłasza zdarzenie (publikuje zdarzenie). A kiedy zauważy, że tak, uruchamia funkcję, która jest z nim podłączona.

Jest to ogólnie zdefiniowane we wzorcu rejestru. Jeśli nie czytałeś tego posta, polecam, ale ustawienie kodu jest dość łatwe:

<?php

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

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

Stamtąd, za każdym razem, gdy zdarzenie zostanie wywołane, funkcja zostanie uruchomiona. Oto jednak rzecz: funkcja musi być częścią pewnej klasy. Tak więc potrzeba WordPress typu

Typ WordPress

Lubię traktować typy rzeczy, które współpracują z WordPressem jako typy WordPress (podobnie jak nasze języki programowania mają natywne typy, takie jak ciągi i liczby całkowite). WordPress zawiera taksonomie, metaboxy, menu i tak dalej.

Aby nasz subskrybent mógł prawidłowo działać, musi być świadomy naszego typu WordPress. Zgodnie z przykładem metabox, oto jak może wyglądać:

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

Następnie musimy upewnić się, że rejestr jest świadomy tej klasy.

Widok

Na koniec, w przypadku meta pola, musimy upewnić się, że istnieje widok, który przynajmniej wyświetli informacje. Serializowanie informacji, a następnie aktualizowanie widoku dla użytkownika to trochę inna bestia.

Ale jak może wyglądać widok? Łatwy :

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

To tylko podstawowe znaczniki, które renderują informacje użytkownikowi.

Łącząc to wszystko razem

Ilekroć łączę to wszystko razem, zwykle mam klasę wtyczek, od której wszystko się zaczyna. Jeśli projekt jest duży, może być ich więcej niż jeden, ale w tym przypadku myślę, że można pokazać, jak to wygląda, używając jednej klasy.

Po pierwsze, główna klasa wtyczki wygląda tak:

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

A bootstrap dla wtyczki wygląda tak:

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

I od tego momentu wszystko inne jest w ruchu.

A co z bardziej zaawansowaną funkcjonalnością?

Podnoszę to pytanie, ponieważ już trochę o tym mówiłem wcześniej w poście. Mianowicie mówiłem o:

1. pomysł wysyłania danych z powrotem na serwer (i prawdopodobnie ponownego ich odczytania),
2. i mówiłem o użyciu interfejsów.

Myślę, że są to obie rzeczy, które warto zbadać bardziej szczegółowo. Ale zanim to zrobisz, kładę podwaliny pod to, jak organizuję te informacje, są one zbudowane, szczególnie biorąc pod uwagę, że są oparte na poprzednich postach, takich jak Wzorzec rejestru i organizowanie klas opartych na WordPressie również za pomocą metaboxów.