✅ Notícias, temas e plug-ins da WEB e do WordPress. Aqui compartilhamos dicas e as melhores soluções para sites.

Widgets do WordPress: Refatoração, Parte 7

17

Nas últimas postagens, trabalhamos muito para levar o código ao ponto de refatoração que será abordado neste artigo.

Especificamente, cobrimos:

Tudo isso vai desempenhar um papel no que vamos fazer hoje.

The WordPress Widget Boilerplate: Refatoração, Parte 7

Para aqueles que estão familiarizados com o WordPress Widgets API, então você provavelmente sabe que não mudou muito nos últimos anos.

Além disso, ele realmente consiste apenas em quatro funções (uma das quais é o construtor):

  1. O construtor é responsável por definir várias propriedades no widget, mais comumente seu nome e a descrição do mesmo.
  2. A função widget é responsável por renderizar o conteúdo do widget.
  3. A função de formulário é responsável por exibir o formulário na área de administração do WordPress ao trabalhar com o widget.
  4. A função de atualização é responsável por atualizar as opções que estão salvas no banco de dados (ou inicializadas e depois salvar as opções que ainda não existem no banco de dados).

O bom é que essa abordagem específica é alcançada herdando uma funcionalidade para a classe WP_Widget.

O problema, porém, é que é muito trabalho para uma única classe fazer.

Em vez disso, devemos separar cada uma das funções em sua própria área de funcionalidade.

Como acontece com qualquer coisa na programação, haverá maneiras pelas quais algumas coisas serão claras sobre como podem ser feitas e, em seguida, algumas coisas poderão ser feitas de várias maneiras.

O que vou apresentar é como estou abordando isso por enquanto. Isso pode mudar no futuro, ou talvez não, e outros podem ter uma opinião diferente sobre isso.

Independentemente disso, a implementação será muito mais orientada a objetos e dará a cada classe seu próprio conjunto de responsabilidades.

A primeira pergunta, porém, é como dividir uma classe com quatro funções e que herda de uma classe pai?

Atualizando o Bootstrap

Primeiro, há algumas coisas que precisamos ajustar no bootstrap do plugin. Ou seja, precisamos fazer o seguinte:

  1. instanciar o Registro e disponibilizá-lo através do projeto,
  2. atualize a classe Plugin para que ela aceite um registro e carregue os assinantes,
  3. revise o bootstrap

Aqui está uma olhada em todos os três acima.

1 Instanciar o Registro

Como já abordamos isso no início da série, deve ficar claro como fazer isso.

Primeiramente, veja o seguinte 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;
});

Em seguida, observe que estamos instanciando o Registro (falaremos sobre seu namespace momentaneamente) e, em seguida, estamos conectando-o a um filtro personalizado que nos permite acessá-lo em todo o plug-in sempre que quisermos.

2 Atualize a Classe do Plugin

Em seguida, precisamos atualizar a classe do plugin principal (que reside no  diretório src) para que faça referência ao registro e carregue todos os assinantes 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());
    }
}

Observe, no entanto, que ainda não configuramos nenhum assinante. Começamos isso no início da série e agora é hora de voltar, mas faremos isso mais tarde.

No entanto, precisamos adicionar uma função – mesmo que temporária – para que possamos adicionar classes que não sejam assinantes 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);
}

Isso será reformulado posteriormente, pois transformaremos as classes principais em assinantes posteriormente.

3 Revise o Bootstrap

Antes de prosseguir, acho importante revisar o bootstrap. Embora o cabeçalho e a documentação possam variar, é importante observar que estamos fazendo o seguinte:

  • namespace do bootstrap,
  • impedindo que o arquivo seja acessado,
  • chamando o autoloader,
  • configurando o registro,
  • e iniciando o plug-in.

Parece muito, mas o código é bem curto :

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

Neste ponto, porém, é hora de ver como é dividir a classe filha da API Widgets padrão em algo que se encaixe no modelo de código com o qual estamos trabalhando.

Dividindo uma classe filha

Esta parte provavelmente abrangerá alguns posts, pois há um pouco de trabalho a ser feito, mas começaremos criando nossa própria classe de widget que herdará da classe Widget base.

Primeiro, vá em frente e crie um  diretório de API no diretório src e adicione um arquivo chamado Widget.php. É aqui que o básico do widget residirá. Entraremos em folhas de estilo administrativas e públicas e arquivos JavaScript na próxima postagem.

Neste ponto, o básico do arquivo deve ficar assim :

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

Observe que ele recebe um único argumento. Eu usei o nome do widget, mas você pode usar o que quiser, desde que represente seu widget.

Isso é para mostrar que a classe está sendo instanciada e carregada corretamente quando o plugin é ativado. Se você não vir isso, algo não está certo (o que revisaremos momentaneamente).

Em seguida, é importante garantir que essa classe seja adicionada ao Registro. Então adicione as seguintes linhas do código no bootstrap:

<?php

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

E agora, ao ativar o plugin, você deverá ver o seguinte:

Widgets do WordPress: Refatoração, Parte 7

Caso contrário, certifique-se de revisar o código na ramificação de desenvolvimento para garantir que você tenha tudo o que está descrito neste post.

Implementando assinantes

Nas próximas postagens, veremos como podemos implementar assinantes para o lado público do site (ou seja, onde o conteúdo do widget é exibido). E faremos o mesmo para a área de administração do site.

Por fim, voltaremos nossa atenção para o código responsável por proteger e serializar os dados (leia-se: atualizar nosso widget) e, em seguida, ver como é a versão final de um clichê atualizado.

Neste post, porém, a principal estratégia que estamos empregando é dividir uma classe filha para que ela ainda possa ser usada com outras classes usando interfaces e classes base que já estão definidas no código base.

Fonte de gravação: tommcfarlin.com

Este site usa cookies para melhorar sua experiência. Presumiremos que você está ok com isso, mas você pode cancelar, se desejar. Aceitar Consulte Mais informação