✅ Noticias, temas, complementos de WEB y WordPress. Aquí compartimos consejos y las mejores soluciones para sitios web.

Widgets de WordPress: Refactorización, Parte 7

15

En las últimas publicaciones, hemos trabajado mucho para llevar el código al punto de refactorización que se tratará en este artículo.

Específicamente, hemos cubierto:

Todos estos van a desempeñar un papel en lo que vamos a hacer hoy.

El modelo de widget de WordPress: refactorización, parte 7

Para aquellos que están familiarizados con la API de widgets de WordPress, es probable que sepan que no ha cambiado mucho en los últimos años.

Además, en realidad solo consta de cuatro funciones (una de las cuales es el constructor):

  1. El constructor es responsable de establecer varias propiedades en el widget, más comúnmente su nombre y su descripción.
  2. La función de widget es responsable de representar el contenido del widget.
  3. La función de formulario es responsable de mostrar el formulario en el área de administración de WordPress cuando se trabaja con el widget.
  4. La función de actualización es responsable de actualizar las opciones que se guardan en la base de datos (o inicializar y luego guardar las opciones que pueden no existir aún en la base de datos).

Lo bueno es que este enfoque particular se logra al heredar una funcionalidad para la clase WP_Widget.

Sin embargo, el problema es que es mucho trabajo para una sola clase.

En cambio, deberíamos separar cada una de las funciones en su propia área de funcionalidad.

Al igual que con cualquier cosa en la programación, habrá formas en las que algunas cosas estén claras sobre cómo se pueden hacer y luego habrá algunas cosas que se pueden hacer de varias maneras.

Lo que voy a presentar es cómo lo estoy abordando por ahora. Esto podría cambiar en el futuro, o tal vez no, y otros pueden tener una opinión diferente al respecto.

Independientemente, la implementación estará mucho más orientada a objetos y le dará a cada clase su propio conjunto de responsabilidades.

La primera pregunta, sin embargo, es ¿cómo dividimos una clase con cuatro funciones y que hereda de una clase principal?

Actualización de Bootstrap

Primero, hay algunas cosas que debemos ajustar en el arranque del complemento. Es decir, tenemos que hacer lo siguiente:

  1. instanciar el Registro y ponerlo a disposición a través del proyecto,
  2. actualizar la clase Plugin para que acepte un registro y cargue los suscriptores,
  3. revisar el arranque

He aquí un vistazo a los tres de los anteriores.

1 Instanciar el Registro

Dado que ya hemos cubierto esto anteriormente en la serie, debería quedar claro cómo hacerlo.

Primero, vea el siguiente código :

<?php

// Setup a filter so we can retrieve the registry throughout the plugin.
$registry = new Registry();
add_filter('wpwBoilerplateRegistry', function() use ($registry) {
    return $registry;
});

A continuación, tenga en cuenta que estamos instanciando el Registro (hablaremos de su espacio de nombres en un momento) y luego lo conectamos a un filtro personalizado que nos permite acceder a él a través del complemento cuando lo deseemos.

2 Actualizar la clase de complemento

A continuación, debemos actualizar la clase de complemento principal (que reside en el  directorio src) para que haga referencia al registro y cargue a los suscriptores registrados :

<?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 WordPressWidgetBoilerplate;

use WordPressWidgetBoilerplateUtilitiesRegistry;

/**
 * The base class for this plugin. Maintains a copy of the registry and starts
 * all of the objects that should hook into WordPress.
 */
class Plugin
{
    /**
     * @var Registry a reference to the simple container used to maintain plugin objects
     */
    private $registry;

    /**
     * @param Registry $registry a reference to the simple container used to maintain plugin objects
     */
    public function __construct(Registry $registry)
    {
        $this->registry = $registry;
    }

    /**
     * Iterates through each of the subscribers maintained in the registry and registers them
     * to the proper WordPress hook.
     */
    public function start()
    {
        array_map(function ($subscriber) {
            add_action($subscriber->getHook(), [$subscriber, 'load']);
        }, $this->registry->getRegisteredSubscribers());
    }
}

Tenga en cuenta, sin embargo, que todavía no hemos configurado ningún suscriptor. Comenzamos esto anteriormente en la serie y ahora es el momento de volver a él, pero lo haremos más tarde.

Sin embargo, necesitamos agregar una función, incluso si es temporal, para que podamos agregar clases que no son suscriptores de eventos explícitos:

<?php
/**
 * @return array all of the the objects that aren't subscribers registered with WordPress
 */
public function getRegisteredObjects()
{
    $objects = [];
    foreach ($this->registry as $object) {
        if (!$object instanceof AbstractSubscriber) {
            $objects[] = $object;
        }
    }

    return array_filter($objects);
}

Esto se reelaborará más adelante, ya que convertiremos las clases principales en suscriptores más adelante.

3 Revisar el Bootstrap

Antes de continuar, creo que es importante revisar el arranque. Aunque su encabezado y documentación pueden variar, es importante tener en cuenta que estamos haciendo lo siguiente:

  • espacio de nombres del arranque,
  • impidiendo que se acceda al archivo,
  • llamando al cargador automático,
  • configurar el registro,
  • e iniciar el complemento.

Parece mucho, pero el código es bastante corto :

<?php
/**
 * WordPress Widget Boilerplate
 *
 * The WordPress Widget Boilerplate is an organized, maintainable boilerplate for building
 * widgets using WordPress best practices.
 *
 * @package   WordPressWidgetBoilerplate
 * @author    Your Name <email@example.com>
 * @license   GPL-3.0+
 * @link      http://example.com
 * @copyright 2018 - 2019 Your Name or Company Name
 *
 * @wordpress-plugin
 * Plugin Name:       WordPress Widget Boilerplate
 * Plugin URI:        https://github.com/tommcfarlin/wordpress-widget-boilerplate
 * Description:       An object-oriented foundation for building WordPress Widgets.
 * Version:           1.0.0
 * Author:            Tom McFarlin
 * Author URI:        https://tommcfarlin.com
 * Text Domain:       widget-name
 * License:           GPL-3.0+
 * License URI:       http://www.gnu.org/licenses/gpl-3.0.txt
 * Domain Path:       /lang
 */

namespace WordPressWidgetBoilerplate;

use WordPressWidgetBoilerplateUtilitiesRegistry;
use WordPressWidgetBoilerplatePlugin;

// 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;
});

// Start the machine.
(new Plugin($registry))->start();

En este punto, sin embargo, es hora de ver cómo es dividir la clase secundaria de la API de Widgets estándar en algo que encaje con el modelo de código con el que estamos trabajando.

Dividir una clase infantil

Es probable que esta parte abarque algunas publicaciones, ya que hay un poco de trabajo por hacer, pero comenzaremos creando nuestra propia clase de widget que heredará de la clase base de Widget.

Primero, continúe y cree un  directorio API en el  directorio src y agregue un archivo llamado Widget.php. Aquí es donde residirán los conceptos básicos del widget. Nos ocuparemos de las hojas de estilo administrativas y públicas y los archivos JavaScript en la próxima publicación.

En este punto, los conceptos básicos del archivo deberían verse 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 WordPressWidgetBoilerplateAPI;

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;

        // TODO: update description
        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;
    }

    /**
     * TODO: This is a temporary message to show that the Boilerplate has loaded.
     */
    public function load()
    {
        $html = '<p style="text-align:center; background: #fff; padding: 1em; border: 1px dotted gray; margin: 2em 2em 2em 14em;">';
        $html .= 'The Widget Boilerplate is loaded.';
        $html .= '</p>';
        echo $html;
    }
}

Tenga en cuenta que se necesita un solo argumento. He usado el nombre del widget, pero puedes usar lo que quieras siempre que represente tu widget.

Esto es para mostrar que la clase se está instanciando y cargando correctamente cuando se activa el complemento. Si no ve esto, entonces algo no está bien (lo cual revisaremos en un momento).

A continuación, es importante asegurarse de que esta clase se agregue al Registro. Así que agregue las siguientes líneas del código en el arranque:

<?php

// Add the Widget base class to the Registry.
$registry->add('widget', new Widget('widget-name'));

Y ahora, cuando active el complemento, debería ver lo siguiente:

Widgets de WordPress: Refactorización, Parte 7

De lo contrario, asegúrese de revisar el código en la rama de desarrollo para asegurarse de que tiene todo lo que se describe en esta publicación.

Implementación de suscriptores

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.

Finalmente, centraremos nuestra atención en el código responsable de proteger y serializar los datos (léase: actualizar nuestro widget) y luego ver cómo se ve la versión final de un modelo actualizado.

Sin embargo, en esta publicación, la estrategia principal que estamos empleando es dividir una clase secundaria para que aún pueda usarse con otras clases usando interfaces y clases base que ya están definidas en el código base.

Fuente de grabación: tommcfarlin.com

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More