Widget WordPress: refactoring, parte 8
Quando si tratta di refactoring di WordPress Widget Boilerplate, abbiamo lavorato molto per portare la base di codice a uno standard più orientato agli oggetti. Inoltre, abbiamo introdotto una varietà di altri strumenti che ci consentono di portare il nostro codice a standard più moderni
Ora che abbiamo passato del tempo a farlo, è ora di tornare al codice e iniziare a refactoring in modo tale da consentire l’uso di classi e abbonati astratti (che funzionano come parte del modello di progettazione basato sugli eventi ).
Alla fine del post precedente ho scritto:
Nei prossimi post, vedremo come implementare gli abbonati per il lato pubblico del sito (ovvero, dove viene visualizzato il contenuto del widget). E faremo lo stesso per l’area di amministrazione del sito.
Quindi in questo post faremo esattamente questo. In particolare, inizieremo lavorando su un abbonato per il widget e quindi facendo in modo che il widget di base venga visualizzato prima sul lato amministrativo del sito.
The WordPress Widget Boilerplate: Refactoring, parte 8
Il motivo per cui sono interessato a concentrarmi principalmente sul lato amministrativo del sito è che ci consente di:
- ottenere un controllo su come funzionano gli abbonati,
- guarda come dovrà essere organizzata la base di codice,
- codificare alcune informazioni prima di lavorare con la serializzazione.
Una volta che tutto questo sarà a posto, saremo in una buona posizione per rivolgere la nostra attenzione a cose più avanzate. Vale a dire, saremo in grado di introdurre abbonati per la visualizzazione delle informazioni nell’area di amministrazione e abbonati per la sanificazione, serializzazione, recupero, convalida e visualizzazione dei dati.
Ma prima, eseguiamo il lavoro necessario per impostare una nuova classe, configurare il caricatore automatico e visualizzare il contenuto nell’area amministrativa del sito.
1 L’abbonato astratto
Esaminiamo prima l’abbonato astratto poiché questo è ciò che tutti gli abbonati implementeranno.
<?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();
}
Si noti che ha due funzioni pubbliche: il costrutto che imposta l’hook e una funzione per recuperare l’hook. Ha anche una funzione di caricamento astratta che è dove qualsiasi classe che estende questa classe implementa la sua funzionalità specifica.
Ricordiamo che a causa del modo in cui WordPress gestisce azioni e filtri, tutto è collegato a uno specifico hook (sia quelli che WordPress definisce sia quelli personalizzati).
2 Lo spazio dei nomi di WordPress
Ogni volta che lavoro su funzionalità strettamente legate a WordPress, cerco di assicurarmi di inserirle in uno spazio dei nomi di WordPress. Questo indica a me e ad altri sviluppatori che qualunque cosa risieda in questo spazio dei nomi non può essere separata dall’applicazione principale.
Quindi all’interno della directory src, crea una directory di WordPress. È qui che risiederà la classe Widget principale insieme a tutte le altre classi che verranno introdotte in questa serie.
Ciò significa che non abbiamo più bisogno della classe nella directory API. Quindi assicurati di spostare la classe, aggiornare il suo spazio dei nomi e rimuovere la directory. Avrò uno screenshot e del codice per questo un po ‘più tardi.
Inoltre, ricordando in precedenza nella serie, abbiamo posizionato la directory Views nella radice della directory src, ma ora possiamo spostarla nella directory di WordPress. Quindi vai avanti e fallo ora.
Il risultato finale dovrebbe assomigliare a questo:
Ora possiamo rivolgere la nostra attenzione al codice.
3 Uno sguardo alla classe dei widget
Semplificheremo un po’ la classe del widget principale in questo post. Distruggerà parte del lavoro che abbiamo fatto, ma avevamo bisogno di quel lavoro precedente per arrivare a questo punto.
Per ora, ci stiamo concentrando sul costruttore e sulla funzione per recuperare lo slug del widget. Questo è ciò che alla fine ci permetterà di vedere qualcosa nell’area amministrativa di WordPress.
Quindi, per prima cosa, assicurati che la tua classe Widget assomigli a questa :
<?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;
}
}Successivamente, poiché abbiamo spostato questo file nello spazio dei nomi di WordPress, dobbiamo aggiornare la sezione di caricamento automatico del nostro file di configurazione di Composer :
"autoload": {
"psr-4": {
"WordPressWidgetBoilerplate": "src/",
"WordPressWidgetBoilerplateUtilities": "src/Utilities/",
"WordPressWidgetBoilerplateSubscriber": "src/Subscriber/",
"WordPressWidgetBoilerplateWordPress": "src/WordPress/"
}
},Successivamente, dobbiamo presentare un abbonato.
4 Presentazione dell’abbonato al widget
Ogni volta che ho una classe principale di qualche tipo, generalmente provo a creare un semplice abbonato che istanzia la classe principale e le permetta di fare il suo lavoro.
Lo faccio perché WordPress, come accennato, utilizza il modello di progettazione basato sugli eventi, il che significa che tutto deve essere registrato su un tipo di hook. E non mi piace mescolare la logica di dominio con la stessa classe che si aggancia a WordPress. Quindi li separo.
Ed è quello che fa un abbonato. Si registra con WordPress, quindi richiama la classe responsabile dell’effettiva esecuzione del lavoro.
Detto questo, rivolgi la tua attenzione alla directory Subscriber e aggiungi una classe chiamata WidgetSubscriber. In quella classe, aggiungi il seguente codice :
<?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'));
}
}
Il costruttore registrerà la classe con un hook specifico che esamineremo tra poco; quindi utilizzerà l’API di WordPress per creare un’istanza del nostro widget (che è ciò che sta accadendo nella funzione di caricamento ).
5 Il Bootstrap
Infine, dobbiamo aggiornare il bootstrap in modo che:
- registra il WidgetSubscriber con l’apposito hook,
- aggiunge l’iscritto al Registro ,
- e avvia il plugin (cosa che abbiamo fatto).
Il bootstrap, dopo tutto questo, dovrebbe essere simile al seguente :
<?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();Successivamente, dovresti essere in grado di accedere a WordPress e attivare il plug-in.
Uno sguardo all’area amministrativa
A questo punto non c’è molto da guardare, ma ci stiamo arrivando. Innanzitutto, dovresti notare che il widget ora appare nell’area che include i widget disponibili:
E dovresti anche vedere che quando trascini il widget in un’area con widget (o qualsiasi barra laterale) che non ha opzioni disponibili.
Detto questo, siamo in una buona posizione per continuare a costruire su ciò che abbiamo. Puoi sempre continuare a monitorare lo sviluppo del boilerplate su GitHub.
Continuando
Successivamente, continueremo a creare funzionalità per l’area amministrativa del widget. Successivamente, rivolgeremo la nostra attenzione al lato pubblico del widget e alla funzionalità di serializzazione.
Dovresti essere in grado di vedere come le cose stanno iniziando a prendere forma mentre iniziamo a separare la logica nelle sue varie componenti. In caso contrario, però, non preoccuparti: c’è molto altro in arrivo.
E la versione finale di Boilerplate, ovviamente, dimostrerà tutti i principi su cui stiamo costruendo in questa serie di post.