Widgets de WordPress: Refactorización, Parte 8
Cuando se trata de refactorizar el estándar de widgets de WordPress, hemos trabajado mucho para llevar la base del código a un estándar más orientado a objetos. Además, hemos introducido una variedad de otras herramientas que nos permiten actualizar nuestro código a estándares más modernos.
Ahora que hemos pasado tiempo haciendo eso, es hora de volver al código y comenzar a refactorizarlo de tal manera que permita el uso de clases abstractas y suscriptores (que funcionan como parte del patrón de diseño basado en eventos ).
Al final del post anterior, escribí:
En las próximas publicaciones, veremos cómo podemos implementar suscriptores para el lado público del sitio (es decir, donde se muestra el contenido del widget). Y haremos lo mismo para el área de administración del sitio.
Así que en esta publicación, vamos a hacer exactamente eso. Específicamente, vamos a comenzar trabajando en un suscriptor para el widget y luego hacer que el widget base se muestre primero en el lado administrativo del sitio.
El modelo de widget de WordPress: refactorización, parte 8
La razón por la que me interesa centrarme principalmente en el lado administrativo del sitio primero es que nos permite:
- obtener una idea de cómo funcionan los suscriptores,
- ver cómo será necesario organizar la base de código,
- codifique alguna información antes de trabajar con la serialización.
Una vez que todo esto esté en su lugar, estaremos en una buena posición para centrar nuestra atención en cosas más avanzadas. Es decir, podremos introducir suscriptores para mostrar información en el área de administración y suscriptores para desinfectar, serializar, recuperar, validar y mostrar datos.
Pero primero, hagamos el trabajo necesario para configurar una nueva clase, configurar el cargador automático y mostrar contenido en el área administrativa del sitio.
1 El suscriptor abstracto
Primero revisemos el suscriptor abstracto, ya que esto es lo que implementarán todos los suscriptores.
<?php
/*
* This file is part of WordPress Widget Boilerplate
* (c) Tom McFarlin <tom@tommcfarlin.com>
*
* This source file is subject to the GPL license that is bundled
* with this source code in the file LICENSE.
*/
namespace WordPressWidgetBoilerplateSubscriber;
/**
* An abstract implementation of a subscriber that requires a hook and the ability to
* start the class.
*/
abstract class AbstractSubscriber
{
/**
* @var string a reference to the hook to which the subscriber should be registered
*/
protected $hook;
/**
* @param string $hook the hook to which the subscriber is registered
*/
public function __construct(string $hook)
{
$this->hook = $hook;
}
/**
* @return string the hook to which the subscriber is registered
*/
public function getHook(): string
{
return $this->hook;
}
/**
* Implements the domain logic for the concrete class implementating this subcriber.
*/
abstract public function load();
}
Tenga en cuenta que tiene dos funciones públicas: la construcción que establece el gancho y una función para recuperar el gancho. También tiene una función de carga abstracta que es donde cualquier clase que extienda esta clase implementa su funcionalidad específica.
Recuerde que, debido a la forma en que WordPress maneja las acciones y los filtros, todo se adjunta a un gancho específico (ya sean los que define WordPress o los ganchos personalizados).
2 El espacio de nombres de WordPress
Cada vez que trabajo en una funcionalidad estrechamente relacionada con WordPress, trato de asegurarme de colocarla en un espacio de nombres de WordPress. Esto me indica a mí y a otros desarrolladores que lo que sea que resida en este espacio de nombres no se puede divorciar de la aplicación principal.
Entonces, dentro del directorio src, cree un directorio de WordPress. Aquí es donde residirá la clase principal Widget junto con cualquier otra clase que se presente a lo largo de esta serie.
Esto significa que ya no necesitamos la clase en el directorio API. Así que asegúrese de mover la clase, actualizar su espacio de nombres y eliminar el directorio. Tendré una captura de pantalla y algo de código para esto un poco más tarde.
Además, recuerde que anteriormente en la serie colocamos el directorio Views en la raíz del directorio src, pero ahora podemos moverlo al directorio de WordPress. Así que adelante y haz eso ahora.
El resultado final debería ser algo como esto:
Ahora podemos centrar nuestra atención en el código.
3 Una mirada a la clase de widgets
Vamos a simplificar un poco la clase de widget principal en esta publicación. Va a deshacer parte del trabajo que hemos hecho, pero necesitábamos ese trabajo previo para llegar a este punto.
Por ahora, nos estamos enfocando en el constructor y la función para recuperar el slug del widget. Esto es lo que finalmente nos permitirá ver algo en el área administrativa de WordPress.
Entonces, primero, asegúrese de que su clase de Widget se vea así :
<?php
/*
* This file is part of WordPress Widget Boilerplate
* (c) Tom McFarlin <tom@tommcfarlin.com>
*
* This source file is subject to the GPL license that is bundled
* with this source code in the file LICENSE.
*/
namespace WordPressWidgetBoilerplateWordPress;
use WP_Widget;
class Widget extends WP_Widget
{
/**
* @var string unique identifier for your widget
*/
protected $widgetSlug;
/**
* Initializes the plugin by setting its properties and calling the parent class with the description.
*
* @param mixed $widgetSlug
*/
public function __construct($widgetSlug)
{
$this->widgetSlug = $widgetSlug;
parent::__construct(
$this->getWidgetSlug(),
__('Widget Name', $this->getWidgetSlug()),
[
'classname' => $this->getWidgetSlug().'-class',
'description' => __('Short description of the widget goes here.', $this->getWidgetSlug()),
]
);
}
/**
* Return the widget slug.
*
* @return string slug variable
*/
public function getWidgetSlug()
{
return $this->widgetSlug;
}
}A continuación, dado que hemos movido este archivo al espacio de nombres de WordPress, necesitamos actualizar la sección de carga automática de nuestro archivo de configuración de Composer :
"autoload": {
"psr-4": {
"WordPressWidgetBoilerplate": "src/",
"WordPressWidgetBoilerplateUtilities": "src/Utilities/",
"WordPressWidgetBoilerplateSubscriber": "src/Subscriber/",
"WordPressWidgetBoilerplateWordPress": "src/WordPress/"
}
},A continuación, necesitamos presentar un suscriptor.
4 Presentación del suscriptor de widgets
Cada vez que tengo una clase central de algún tipo, generalmente trato de crear un suscriptor simple que instancia la clase central y le permite hacer su trabajo.
Hago esto porque WordPress, como se mencionó, usa el patrón de diseño basado en eventos, lo que significa que todo tiene que estar registrado en algún tipo de gancho. Y no me gusta mezclar la lógica de dominio con la misma clase que se conecta a WordPress. Así que los separo.
Y eso es lo que hace un suscriptor. Se registra en WordPress y luego invoca la clase responsable de hacer el trabajo.
Dicho esto, dirija su atención al directorio de suscriptores y agregue una clase llamada WidgetSubscriber. En esa clase, agregue el siguiente código :
<?php
<?php
namespace WordPressWidgetBoilerplateSubscriber;
use WordPressWidgetBoilerplateWordPressWidget;
/**
* Initializes the core Widget class that's used by WordPress to instantiate the widget,
* renders the administrative area, provide serialization functionality, and displays the
* public-facing view.
*/
class WidgetSubscriber extends AbstractSubscriber
{
/**
* {@inheritdoc}
*/
public function __construct(string $hook)
{
parent::__construct($hook);
}
/**
* Registers the core Widget class using the WordPress APIs.
*/
public function load()
{
register_widget(new Widget('widget-name'));
}
}
El constructor registrará la clase con un gancho específico que revisaremos en un momento; luego usará la API de WordPress para crear una instancia de nuestro widget (que es lo que sucede en la función de carga ).
5 El arranque
Finalmente, necesitamos actualizar el bootstrap para que:
- registra el WidgetSubscriber con el enlace adecuado,
- agrega el suscriptor al Registro ,
- e inicia el complemento (que hemos estado haciendo).
El bootstrap, después de todo esto, debería verse así :
<?php
namespace WordPressWidgetBoilerplate;
use WordPressWidgetBoilerplateUtilitiesRegistry;
use WordPressWidgetBoilerplatePlugin;
use WordPressWidgetBoilerplateSubscriberWidgetSubscriber;
// Prevent this file from being called directly.
defined('WPINC') || die;
// Include the autoloader.
require_once __DIR__. '/vendor/autoload.php';
// Setup a filter so we can retrieve the registry throughout the plugin.
$registry = new Registry();
add_filter('wpwBoilerplateRegistry', function() use ($registry) {
return $registry;
});
// Add the Widget base class to the Registry.
$registry->add('widgetSubscriber', new WidgetSubscriber('widgets_init'));
// Start the machine.
(new Plugin($registry))->start();A continuación, debería poder iniciar sesión en WordPress y activar el complemento.
Una mirada al área administrativa
En este punto, no hay mucho que ver, pero estamos llegando allí. Primero, debe notar que el widget ahora aparece en el área que incluye los widgets disponibles:
Y también debería ver que cuando arrastra el widget a un área widgetizada (o cualquier barra lateral) no tiene opciones disponibles.
Dicho esto, estamos en un buen lugar para seguir construyendo sobre lo que tenemos. Siempre puede seguir el seguimiento del desarrollo del modelo en GitHub.
Continuando
A continuación, continuaremos desarrollando funcionalidades para el área administrativa del widget. Después de eso, centraremos nuestra atención en el lado público del widget, así como en la funcionalidad de serialización.
Debería poder ver cómo las cosas comienzan a tomar forma a medida que comenzamos a separar la lógica en sus diversos componentes. Sin embargo, si no es así, no se preocupe, hay mucho más por venir.
Y la versión final de Boilerplate, por supuesto, demostrará todos los principios que estamos construyendo a lo largo de esta serie de publicaciones.