Widgets do WordPress: Refatoração, Parte 8
Quando se trata de refatorar o WordPress Widget Boilerplate, fizemos muito trabalho para trazer a base de código para um padrão mais orientado a objetos. Além disso, introduzimos uma variedade de outras ferramentas que nos permitem trazer nosso código para padrões mais modernos
Agora que passamos tempo fazendo isso, é hora de voltar ao código e começar a refatorá-lo de forma que permita o uso de classes abstratas e assinantes (que funcionam como parte do padrão de design orientado a eventos ).
No final do post anterior, escrevi:
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.
Então, neste post, vamos fazer exatamente isso. Especificamente, vamos começar a trabalhar em um assinante para o widget e, em seguida, fazer com que o widget base seja exibido primeiro no lado administrativo do site.
The WordPress Widget Boilerplate: Refatoração, Parte 8
O motivo pelo qual estou interessado em focar principalmente no lado administrativo do site é que ele nos permite:
- saiba como os assinantes funcionam,
- veja como a base de código precisará ser organizada,
- codificar algumas informações antes de trabalhar com serialização.
Uma vez que tudo isso esteja no lugar, estaremos em uma boa posição para voltar nossa atenção para coisas mais avançadas. Ou seja, poderemos apresentar assinantes para exibir informações na área de administração e assinantes para sanitizar, serializar, recuperar, validar e exibir dados.
Mas primeiro, vamos fazer o trabalho necessário para configurar uma nova classe, configurar o autoloader e exibir o conteúdo na área administrativa do site.
1 O Assinante Abstrato
Vamos revisar primeiro o assinante abstrato, pois é isso que todos os assinantes implementarão.
<?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();
}
Observe que ele tem duas funções públicas – a construção que define o gancho e uma função para recuperar o gancho. Ele também possui uma função de carga abstrata que é onde qualquer classe que estende essa classe implementa sua funcionalidade específica.
Lembre-se de que, devido à maneira como o WordPress lida com ações e filtros, tudo é anexado a um gancho específico (aqueles que o WordPress define ou ganchos personalizados).
2 O espaço de nomes do WordPress
Sempre que estou trabalhando em uma funcionalidade fortemente acoplada ao WordPress, tento me certificar de colocá-la em um namespace do WordPress. Isso indica para mim, assim como para outros desenvolvedores, que o que quer que resida nesse namespace não pode ser divorciado do aplicativo principal.
Portanto, dentro do diretório src, crie um diretório WordPress. É aqui que a classe principal do Widget residirá junto com quaisquer outras classes que serão introduzidas ao longo desta série.
Isso significa que não precisamos mais da classe no diretório da API. Portanto, certifique-se de mover a classe, atualizar seu namespace e remover o diretório. Eu vou ter uma captura de tela e algum código para isso um pouco mais tarde.
Além disso, lembre-se no início da série, colocamos o diretório Views na raiz do diretório src, mas agora podemos movê-lo para o diretório WordPress. Então vá em frente e faça isso agora.
O resultado final deve ficar mais ou menos assim:
Agora podemos voltar nossa atenção para o código.
3 Uma olhada na classe Widget
Vamos simplificar um pouco a classe de widget principal neste post. Vai desfazer parte do trabalho que fizemos, mas precisávamos desse trabalho anterior para chegar a este ponto.
Por enquanto, estamos nos concentrando no construtor e na função para recuperar o slug do widget. Isso é o que acabará por nos permitir ver algo na área administrativa do WordPress.
Então, primeiro, certifique-se de que sua classe Widget seja 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 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;
}
}Em seguida, como movemos este arquivo para o namespace do WordPress, precisamos atualizar a seção de carregamento automático do nosso arquivo de configuração do Composer :
"autoload": {
"psr-4": {
"WordPressWidgetBoilerplate": "src/",
"WordPressWidgetBoilerplateUtilities": "src/Utilities/",
"WordPressWidgetBoilerplateSubscriber": "src/Subscriber/",
"WordPressWidgetBoilerplateWordPress": "src/WordPress/"
}
},Em seguida, precisamos apresentar um assinante.
4 Apresentando o Assinante de Widget
Sempre que tenho uma classe principal de algum tipo, geralmente tento criar um assinante simples que instancia a classe principal e permite que ela faça seu trabalho.
Faço isso porque o WordPress, como mencionado, usa o padrão de design orientado a eventos, o que significa que tudo deve ser registrado em algum tipo de gancho. E eu não gosto de misturar lógica de domínio com a mesma classe que se conecta ao WordPress. Então eu os separo.
E é isso que um assinante faz. Ele se registra no WordPress e então invoca a classe responsável por realmente fazer o trabalho.
Com isso dito, volte sua atenção para o diretório Subscriber e adicione uma classe chamada WidgetSubscriber. Nessa classe, adicione o seguinte 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'));
}
}
O construtor registrará a classe com um gancho específico que revisaremos em breve; então ele usará a API do WordPress para instanciar nosso widget (que é o que está acontecendo na função de carregamento ).
5 O Bootstrap
Finalmente, precisamos atualizar o bootstrap para que:
- registra o WidgetSubscriber com o gancho apropriado,
- adiciona o assinante ao Registro ,
- e inicia o plugin (o que estamos fazendo).
O bootstrap, depois de tudo isso, deve se parecer com o seguinte :
<?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();Em seguida, você poderá fazer login no WordPress e ativar o plug-in.
Um olhar sobre a área administrativa
Neste ponto, não há muito o que olhar, mas estamos chegando lá. Primeiro, você deve notar que o widget agora aparece na área que inclui os widgets disponíveis:
E você também deve ver que ao arrastar o widget para uma área widgetizada (ou qualquer barra lateral) ele não tem opções disponíveis.
Dito isso, estamos em um bom lugar para continuar construindo o que temos. Você sempre pode continuar acompanhando o desenvolvimento do clichê no GitHub.
Continuando
Em seguida, continuaremos desenvolvendo a funcionalidade para a área administrativa do widget. Depois disso, voltaremos nossa atenção para o lado público do widget, bem como para a funcionalidade de serialização.
Você deve ser capaz de ver como as coisas estão começando a tomar forma à medida que começamos a separar a lógica em seus vários componentes. Se não, porém, não se preocupe – há muito mais por vir.
E a versão final do Boilerplate, é claro, demonstrará todos os princípios que estamos construindo ao longo desta série de posts.