Organización de tipos, vistas y suscriptores de WordPress

Una de las cosas que me encuentro tratando de hacer regularmente es optimizar la forma en que construyo la funcionalidad enfocada en WordPress. Recientemente hablé sobre esto, pero pensé en ampliarlo un poco más.

Es decir, pensé en exponer el enfoque que tomo cuando construyo cosas como tipos de publicaciones personalizadas, taxonomías, metaboxes, etc.

En general, piense en esto como una estrategia que sigo para desarrollar aspectos de un proyecto que interactúa directamente con WordPress pero puede requerir algunos componentes como:

• clases que se registran en WordPress a través de varios ganchos,
• clases que requieren llamadas a ciertas API de WordPress
• y clases que requieren una vista personalizada.

Claro, no todo lo que interactúa con WordPress necesitará todo lo anterior (por ejemplo, ¿un tipo de publicación personalizada necesita una vista? No. Pero un cuadro meta sí).

Organización de los tipos de WordPress

Dicho esto, voy a tomar un ejemplo más complicado, como un cuadro meta y luego desglosaré una forma en la que creo que se puede implementar. Voy a anotar las cosas que creo que son necesarias y las cosas que son opcionales.

Y, como dije, estoy usando un cuadro meta como ejemplo porque tengo una referencia anterior e implica la mayor cantidad de trabajo, mientras que otra cosa, como una taxonomía personalizada, puede no requerir todas (solo un subconjunto) de las piezas. .

Dicho esto, permítanme exponer mi enfoque.

Necesitamos Suscriptores

He hablado lo suficiente sobre este patrón en particular hasta el punto en que simplemente voy a vincular a una definición del mismo. Si está leyendo esta página, es probable que esté al tanto de los diversos ganchos y de cómo usarlos en WordPress.

Foto de Alexander Andrews en Unsplash

Pero la razón por la que quiero mencionarlo es porque en lugar de pensar en conectar una función para que se active cada vez que suceda algo, quiero que pienses en un objeto que se suscriba a un evento cuando ocurra.

Esto significa que necesitaremos un tipo de clase de suscriptor.

Clases de la API de WordPress

En segundo lugar, necesitamos clases que sean responsables de interactuar directamente con WordPress. Estas son las clases que llaman a la API de WordPress y registran lo que sea que sean responsables de hacer.

Es decir, tal vez van a definir un tipo de publicación personalizada o tal vez, como se dijo, van a definir un metabox.

Definición de vistas

Finalmente, es importante tener en cuenta que para algunas funciones personalizadas para el área de administración de WordPress (o incluso áreas públicas), es posible que desee incluir una vista, una plantilla o una vista parcial (generalmente me refiero a ellas como vistas) que trabajar para representar los datos de un cuadro meta.

Foto de Saketh Garuda en Unsplash

A veces esto será simplemente informativo. A veces, esto requerirá que se publique en el servidor y serialice los datos. Aunque creo que hablar de esto último sería realmente beneficioso, está fuera del alcance actual de esta publicación.

Quizás en un futuro post.

Organización de clases

¿Qué dijo todo eso, cómo sería exponer todo esto? Por lo menos, estamos viendo:

• un suscriptor,
• un tipo de WordPress,
• una vista

Y, como máximo, puede estar interesado en definir interfaces o clases abstractas para ayudar a hacer cumplir un contrato entre los distintos tipos de WordPress. Este también es un principio saludable orientado a objetos del que hablaré en una publicación futura.

Por ahora, sin embargo, hablemos de cómo configurar cada uno de estos.

el suscriptor

En pocas palabras, el suscriptor es responsable de escuchar cada vez que WordPress genera un evento (publica un evento). Y cuando se da cuenta de que lo hace, activa una función que está enganchada a él.

Esto generalmente se define en el patrón de registro. Si no has leído esa publicación, te la recomiendo, pero configurar el código es bastante fácil:

<?php

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

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

A partir de ahí, cada vez que se genere el evento, la función se activará. Sin embargo, aquí está la cosa: la función tiene que ser parte de una cierta clase. Por lo tanto, la necesidad del tipo WordPress

El tipo de WordPress

Me gusta considerar los tipos de cosas que interactúan con WordPress como tipos de WordPress (al igual que nuestros lenguajes de programación tienen tipos nativos como cadenas y números enteros). WordPress tiene taxonomías, metacuadros, menús, etc.

Para que nuestro suscriptor funcione correctamente, debe conocer nuestro tipo de WordPress. De acuerdo con el ejemplo del cuadro meta, así es como se verá:

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

Luego, debemos asegurarnos de que el registro reconozca esta clase.

La vista

Finalmente, para un cuadro meta, debemos asegurarnos de que haya una vista que al menos muestre información. Serializar información y luego actualizar la vista para el usuario es un poco diferente.

Pero, ¿cómo sería una 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>

Es solo un marcado básico que brinda información al usuario.

Atarlo todo junto

Cada vez que reúno todo esto, generalmente tengo una clase de complemento que lo pone todo en marcha. Si un proyecto es grande, puede haber más de uno, pero en este caso, creo que está bien mostrar cómo se ve usando una sola clase.

Entonces, primero, la clase de complemento principal se ve así:

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

Y el arranque para el complemento se ve así:

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

Y, a partir de ahí, todo lo demás se pone en marcha.

¿Qué pasa con la funcionalidad más avanzada?

Hago esta pregunta porque ya he hablado un poco sobre esto anteriormente en la publicación. Es decir, hablé de:

1. la idea de volver a publicar datos en el servidor (y probablemente leerlos de nuevo),
2. y he hablado sobre el uso de interfaces.

Ambas son cosas que creo que vale la pena explorar con más detalle. Pero antes de hacer eso, sentar las bases de cómo organizo esta información es que está construida especialmente dado que se basa en publicaciones anteriores como el patrón de registro y también organiza clases centradas en WordPress a través de metaboxes.