Una guía simple para organizar clases centradas en WordPress

Una de las cosas en las que he estado haciendo un esfuerzo mucho más concertado, probablemente más que nunca antes, es gestionar la separación de preocupaciones entre las clases responsables de la interfaz con WordPress y las responsables de trabajar con el dominio del problema.

Por ejemplo, supongamos que está trabajando en un complemento y se comunicará con una API de terceros. Además, este complemento también ofrecerá menús, tipos de publicaciones, taxonomías, etc. dentro del área de administración de WordPress.

Aquí hay dos áreas de responsabilidad:

1. el área responsable de la solución general del problema,
2. el área responsable de la interfaz con WordPress.

Puede argumentar que es importante realizar pruebas unitarias en las áreas que se comunican con WordPress, pero también sé que estas son API probadas y verdaderas que tienen su propio conjunto de pruebas.

En su lugar, deberíamos centrarnos en las pruebas unitarias y separar nuestra lógica empresarial de WordPress.

Pero ese no es el punto de esta publicación. En cambio, se trata más de una forma de diseñar potencialmente un proyecto cuando una parte de él se conectará con WordPress.

He hablado sobre la importancia y las ventajas de los espacios de nombres en publicaciones anteriores para no profundizar demasiado en esa discusión aquí.

En cambio, me interesa hablar sobre la organización de archivos a nivel de sistema de archivos y de espacio de nombres, para que estén claramente separados en sus áreas de especialización y para que podamos asegurarnos de que estamos, digamos, enfocando nuestras pruebas unitarias (y otras pruebas) en las áreas que son más críticas.

Abstracción de metacajas

Me gusta asegurarme de que mi estructura de directorios y archivos refleje la de mis espacios de nombres. Claro, ayuda con la organización de archivos, pero también con una organización conceptual.

Es decir, si voy a trabajar con metaboxes, entonces sé que probablemente pueda encontrar los archivos de metaboxes en un directorio anidado con el directorio principal de WordPress y luego dentro de un subdirectorio Admin seguido de un directorio MetaBox.

Con ese fin, ¿cómo se vería un conjunto de clases diseñadas para trabajar con cajas meta si escribimos código para ellas de manera reutilizable? Teniendo en cuenta lo que sabemos sobre los metaboxes, sabemos que probablemente necesitaremos lo siguiente:

• una clase abstracta que define el tipo de publicación a la que se vinculará cada metabox,
• dos funciones para el cuadro meta: una para registrarlo, otra para mostrar el contenido,
• un directorio para contener la vista o la presentación del meta box,
• un archivo que servirá como dicha vista.

Teniendo en cuenta los puntos anteriores, quizás la estructura del directorio se vería así:

A continuación, tenemos un código que refleja esta estructura. Es decir, dentro de nuestro directorio de WordPress, tendríamos el subdirectorio Admin ya que el cuadro meta se muestra dentro del área de administración de WordPress, y tendríamos el subdirectorio Ver que contendría el archivo responsable de mostrar la información.

Esto nos deja con la necesidad de crear algunas clases como se indica arriba. Quizás la clase base abstracta se vería así:

<?php

namespace AcmeWordPressAdminMetaBox;

abstract class AbstractMetaBox
{
    protected $postType;

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

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

Luego, una implementación concreta extendería la clase y se vería así:

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

Y finalmente, la vista de la clase contendría cualquier marca y código de plantilla para representar la información :

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

Esto nos brinda exactamente lo que necesitamos de una manera bien organizada y reutilizable para trabajar con metaboxes. También se puede repetir para elementos como menús, tipos de publicaciones, taxonomías, etc.

Pero yo divago.

Una palabra sobre las pruebas unitarias (con PHPUnit)

Como mencioné anteriormente en la publicación, creo que las clases de pruebas unitarias que resuelven problemas exclusivos de nuestro espacio de problemas son importantes. Esto significa que necesitaría decirle a su archivo de configuración de PHPUnit que excluya sus archivos centrados en WordPress.

La ventaja de lo que he expuesto anteriormente es que esto se vuelve trivialmente fácil. En pocas palabras, puede agregar esto a su archivo phpunit.xml :

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

Esto le brinda la capacidad de concentrarse en escribir pruebas específicamente para su espacio problemático mientras se asegura de que está escribiendo código escalable, mantenible y reutilizable basado en WordPress.

Actualmente estoy escribiendo un libro electrónico (junto con una variedad de otro contenido premium). Si estás interesado, echa un vistazo a lo que obtienes.