Organizando tipos, visualizações e assinantes do WordPress

Uma das coisas que me vejo tentando fazer regularmente é simplificar a forma como estou construindo funcionalidades focadas no WordPress. Recentemente falei sobre isso, mas pensei em expandir um pouco mais.

Ou seja, pensei em apresentar a abordagem que adoto ao construir coisas como tipos de postagem personalizados, taxonomias, meta caixas e assim por diante.

Geralmente, pense nisso como uma estratégia que sigo para construir aspectos de um projeto que interage diretamente com o WordPress, mas pode exigir alguns componentes, como:

• classes que se registram no WordPress através de vários ganchos,
• classes que requerem chamadas para certas APIs do WordPress
• e classes que requerem uma visualização personalizada.

Claro, nem tudo que faz interface com o WordPress precisará de todos os itens acima (por exemplo, um tipo de postagem personalizado precisa de uma visualização? Não. Mas uma caixa meta precisa).

Organizando os tipos do WordPress

Com isso dito, vou pegar um exemplo mais envolvente, como uma caixa meta e, em seguida, detalhar uma maneira pela qual acho que pode ser implementada. Vou anotar as coisas que considero necessárias e as que são opcionais.

E, como eu disse, estou usando uma meta box como exemplo porque tenho uma referência anterior e envolve a maior quantidade de trabalho, enquanto outra coisa, como uma taxonomia personalizada, pode não exigir todas (apenas um subconjunto) das peças .

Com isso dito, deixe-me expor minha abordagem.

Precisamos de assinantes

Já falei sobre esse padrão específico o suficiente a ponto de simplesmente vincular a uma definição dele. Se você está lendo esta página, provavelmente conhece os vários ganchos e como usá-los no WordPress.

Foto de Alexander Andrews no Unsplash

Mas a razão pela qual quero mencioná-lo é porque, em vez de pensar em conectar uma função para disparar sempre que algo acontecer, quero que você pense em um objeto que se inscreve em um evento quando ele ocorre.

Isso significa que precisaremos de um tipo de classe de assinante.

Aulas de API do WordPress

Em segundo lugar, precisamos de classes que sejam responsáveis ​​pela interface direta com o WordPress. Essas são as classes que chamam a API do WordPress e registram o que são responsáveis ​​por fazer.

Ou seja, talvez eles definam um tipo de postagem personalizado ou talvez, como dito, definam uma meta box.

Definindo visualizações

Por fim, é importante observar que para algumas funcionalidades personalizadas para a área de administração do WordPress (ou mesmo áreas voltadas para o público), você pode querer incluir uma visualização ou um modelo ou uma parcial (geralmente me refiro a eles como visualizações) que trabalho para representar os dados para uma meta box.

Foto de Saketh Garuda no Unsplash

Às vezes, isso será simplesmente informativo. Às vezes, isso exigirá que ele poste de volta no servidor e serialize os dados. Embora eu ache que falar sobre o último seria realmente benéfico, está fora do escopo atual deste post.

Talvez em um post futuro.

Organização de aulas

O que tudo isso disse, como seria colocar tudo isso para fora? No mínimo, estamos olhando para:

• um assinante,
• um tipo WordPress,
• uma vista

E, no máximo, você pode estar interessado em definir interfaces ou classes abstratas para ajudar a impor um contrato entre os vários tipos do WordPress. Este também é um princípio orientado a objetos saudável sobre o qual falarei em um post futuro.

Por enquanto, porém, vamos falar sobre como configurar cada um deles.

O Assinante

Simplificando, o assinante é responsável por ouvir sempre que o WordPress gera um evento (publica um evento). E quando percebe que sim, ele dispara uma função que está ligada a ele.

Isso geralmente é definido no padrão de registro. Se você não leu esse post, eu recomendo, mas configurar o código para ele é bem fácil:

<?php

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

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

A partir daí, sempre que o evento for gerado, a função será acionada. Aqui está a coisa: A função tem que ser parte de uma determinada classe. Assim, a necessidade do tipo WordPress

O tipo WordPress

Eu gosto de considerar os tipos de coisas que fazem interface com o WordPress como WordPress-types (assim como nossas linguagens de programação têm tipos nativos, como strings e inteiros). O WordPress tem taxonomias, meta boxes, menus e assim por diante.

Para que nosso assinante funcione adequadamente, ele precisa estar ciente do nosso tipo de WordPress. Mantendo-se consistente com o exemplo da caixa meta, eis como pode ser:

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

Em seguida, precisamos garantir que o registro esteja ciente dessa classe.

A vista

Finalmente, para uma meta box, precisamos ter certeza de que há uma visualização que pelo menos exibirá informações. Serializar informações e, em seguida, atualizar a visualização para o usuário é um pouco diferente.

Mas como pode ser uma vista? Fácil :

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

É apenas marcação básica que renderiza informações para o usuário.

Amarrando tudo junto

Sempre que coloco tudo isso junto, geralmente tenho uma classe de plug-in que inicia tudo. Se um projeto for grande, pode haver mais de um, mas neste caso, acho que não há problema em mostrar como é usando uma única classe.

Então, primeiro, a classe principal do plugin se parece com isso:

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

E o bootstrap do plugin se parece com isso:

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

E, a partir daí, todo o resto é posto em movimento.

E quanto à funcionalidade mais avançada?

Eu levanto essa questão porque eu já falei um pouco sobre isso no início do post. Ou seja, falei sobre:

1. a ideia de postar dados de volta no servidor (e provavelmente lê-los novamente),
2. e falei sobre o uso de interfaces.

Essas são duas coisas que eu acho que valem a pena explorar com mais detalhes. Mas antes de fazer isso, estabelecer as bases para como eu organizo essas informações é que elas são construídas especialmente porque são construídas em postagens anteriores, como o padrão de registro, e também organizando classes centradas no WordPress por meio de caixas meta.