WordPress-widgets: Refactoring, del 8
När det kommer till att omstrukturera WordPress Widget Boilerplate har vi gjort mycket arbete för att få upp kodbasen till en mer objektorienterad standard. Vidare har vi introducerat en mängd andra verktyg som gör att vi kan höja vår kod till modernare standarder
Nu när vi har lagt ner tid på att göra det är det dags att hoppa tillbaka in i koden och börja omstrukturera den på ett sådant sätt som tillåter användning av abstrakta klasser och prenumeranter (som fungerar som en del av det händelsedrivna designmönstret ).
I slutet av förra inlägget skrev jag:
I de kommande inläggen kommer vi att titta på hur vi kan implementera prenumeranter för den offentliga sidan av webbplatsen (det vill säga där widgetinnehållet visas). Och vi kommer att göra samma sak för sajtens administrationsområde.
Så i det här inlägget ska vi göra precis det. Specifikt kommer vi att börja med att arbeta på en prenumerant för widgeten och sedan få baswidgeten att visas på den administrativa sidan av webbplatsen först.
WordPress Widget Boilerplate: Refactoring, del 8
Anledningen till att jag är intresserad av att i första hand fokusera på den administrativa sidan av webbplatsen är att den tillåter oss att:
- få koll på hur prenumeranter fungerar,
- se hur kodbasen måste organiseras,
- hårdkoda lite information innan du arbetar med serialisering.
När allt detta är på plats kommer vi att vara i en bra position att rikta vår uppmärksamhet mot mer avancerade saker. Vi kommer nämligen att kunna introducera prenumeranter för att visa information i administrationsområdet och prenumeranter för att sanera, serialisera, hämta, validera och visa data.
Men först, låt oss göra det arbete som krävs för att skapa en ny klass, konfigurera autoloadern och visa innehåll i det administrativa området på webbplatsen.
1 Den abstrakta prenumeranten
Låt oss granska den abstrakta prenumeranten först eftersom detta är vad alla prenumeranter kommer att implementera.
<?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();
}
Observera att den har två offentliga funktioner – konstruktionen som sätter kroken och en funktion för att hämta kroken. Den har också en abstrakt laddningsfunktion som är där varje klass som utökar denna klass implementerar sin specifika funktionalitet.
Kom ihåg att på grund av hur WordPress hanterar åtgärder och filter är allt kopplat till en specifik krok (antingen de som WordPress definierar eller anpassade krokar).
2 WordPress-namnutrymmet
När jag arbetar med funktionalitet som är tätt kopplad till WordPress försöker jag se till att jag placerar den i ett WordPress-namnområde. Detta indikerar för mig och andra utvecklare att allt som finns i det här namnutrymmet inte kan skiljas från kärnapplikationen.
Så inom src- katalogen, skapa en WordPress- katalog. Det är här klassen Widgets kärna kommer att finnas tillsammans med alla andra klasser som kommer att introduceras i den här serien.
Det betyder att vi inte längre behöver klassen i API-katalogen. Så se till att flytta klassen, uppdatera dess namnutrymme och ta bort katalogen. Jag ska ha en skärmdump och lite kod för detta lite senare.
Dessutom, minns tidigare i serien, placerade vi Views- katalogen i roten av src- katalogen, men nu kan vi flytta den till WordPress- katalogen. Så fortsätt och gör det nu.
Det slutliga resultatet bör se ut ungefär så här:
Nu kan vi rikta vår uppmärksamhet mot koden.
3 En titt på widgetklassen
Vi kommer att förenkla klassen core widget lite i det här inlägget. Det kommer att ångra en del av det arbete vi har gjort, men vi behövde det tidigare arbetet för att få oss till denna punkt.
För tillfället fokuserar vi på konstruktorn och funktionen för att hämta widgetsnigeln. Detta är vad som i slutändan kommer att tillåta oss att se något inom det administrativa området för WordPress.
Så först, se till att din Widget-klass ser ut så här :
<?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;
}
}Sedan, eftersom vi har flyttat den här filen till WordPress – namnutrymmet, måste vi uppdatera avsnittet för automatisk laddning av vår Composer-konfigurationsfil :
"autoload": {
"psr-4": {
"WordPressWidgetBoilerplate": "src/",
"WordPressWidgetBoilerplateUtilities": "src/Utilities/",
"WordPressWidgetBoilerplateSubscriber": "src/Subscriber/",
"WordPressWidgetBoilerplateWordPress": "src/WordPress/"
}
},Därefter måste vi introducera en prenumerant.
4 Introduktion av Widget-abonnenten
När jag har en kärnklass av något slag försöker jag i allmänhet skapa en enkel prenumerant som instansierar kärnklassen och låter den göra sitt arbete.
Jag gör detta eftersom WordPress, som nämnts, använder det händelsedrivna designmönstret vilket innebär att allt måste registreras till någon typ av krok. Och jag gillar inte att blanda domänlogik med samma klass som hakar in i WordPress. Så jag skiljer dem åt.
Och det är vad en prenumerant gör. Den registrerar sig själv med WordPress och anropar sedan klassen som är ansvarig för att faktiskt utföra arbetet.
Med det sagt, vänd din uppmärksamhet till Subscriber -katalogen och lägg till en klass som heter WidgetSubscriber. Lägg till följande kod i den klassen :
<?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'));
}
}
Konstruktören kommer att registrera klassen med en specifik krok som vi kommer att granska om ett ögonblick; då kommer den att använda WordPress API för att instansiera vår widget (vilket är vad som händer i laddningsfunktionen ).
5 Bootstrap
Slutligen måste vi uppdatera bootstrap så att det:
- registrerar WidgetSubscriber med rätt krok,
- lägger till abonnenten i registret ,
- och startar plugin (vilket vi har gjort).
Bootstrap, efter allt detta, bör se ut så här :
<?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();Därefter bör du kunna logga in på WordPress och aktivera plugin.
En titt på förvaltningsområdet
Vid det här laget finns det inte mycket att titta på, men vi närmar oss. Först bör du lägga märke till att widgeten nu visas i området som innehåller de tillgängliga widgetarna:
Och du bör också se att när du drar widgeten till ett widgetiserat område (eller någon sidofält) att den inte har några tillgängliga alternativ.
Som sagt, vi är på ett bra ställe att fortsätta bygga på det vi har. Du kan alltid fortsätta att följa utvecklingen av boilerplate på GitHub.
Fortsätter på
Därefter fortsätter vi att bygga ut funktionalitet för det administrativa området för widgeten. Efter det kommer vi att rikta vår uppmärksamhet mot den offentliga sidan av widgeten samt serialiseringsfunktionalitet.
Du borde kunna se hur saker och ting börjar ta form när vi börjar dela upp logiken i dess olika komponenter. Om inte, men oroa dig inte – det finns mycket mer på gång.
Och den slutliga versionen av Boilerplate kommer naturligtvis att visa alla principer som vi bygger på genom hela den här serien av inlägg.