Jeśli chodzi o refaktoryzację WordPress Widget Boilerplate, wykonaliśmy dużo pracy, aby dostosować bazę kodu do standardu bardziej zorientowanego obiektowo. Ponadto wprowadziliśmy wiele innych narzędzi, które pozwalają nam dostosować nasz kod do bardziej nowoczesnych standardów
Teraz, gdy spędziliśmy na tym trochę czasu, nadszedł czas, aby wrócić do kodu i rozpocząć jego refaktoryzację w taki sposób, aby umożliwić korzystanie z klas abstrakcyjnych i subskrybentów (działających jako część wzorca projektowania sterowanego zdarzeniami ).
Pod koniec poprzedniego posta napisałem:
W nadchodzących postach przyjrzymy się, jak możemy zaimplementować subskrybentów dla publicznej strony witryny (czyli tam, gdzie wyświetlana jest treść widżetu). I zrobimy to samo dla obszaru administracyjnego witryny.
W tym poście zrobimy dokładnie to. Konkretnie, zaczniemy od pracy nad subskrybentem widżetu, a następnie wyświetleniem podstawowego widżetu po stronie administracyjnej witryny.
WordPress Widget Boilerplate: Refaktoryzacja, część 8
Powodem, dla którego interesuje mnie przede wszystkim skupienie się na stronie administracyjnej witryny, jest to, że pozwala nam ona:
- zapoznaj się z pracą subskrybentów,
- zobacz jak trzeba będzie uporządkować bazę kodów,
- zakodować pewne informacje przed rozpoczęciem pracy z serializacją.
Gdy to wszystko będzie na miejscu, będziemy w dobrej pozycji, aby zwrócić naszą uwagę na bardziej zaawansowane rzeczy. Mianowicie, będziemy mogli wprowadzić subskrybentów do wyświetlania informacji w obszarze administracyjnym oraz subskrybentów do czyszczenia, serializacji, pobierania, sprawdzania i wyświetlania danych.
Ale najpierw wykonajmy pracę niezbędną do ustawienia nowej klasy, skonfigurowania autoloadera i wyświetlenia treści w obszarze administracyjnym witryny.
1 Abstrakcyjny subskrybent
Przyjrzyjmy się najpierw subskrybentowi abstraktu, ponieważ to właśnie zaimplementują wszyscy subskrybenci.
<?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();
}
Zauważ, że ma dwie publiczne funkcje — konstrukcję, która ustawia zaczep i funkcję do pobierania zaczepu. Posiada również abstrakcyjną funkcję ładowania, w której każda klasa, która rozszerza tę klasę, implementuje swoją specyficzną funkcjonalność.
Przypomnij sobie, że ze względu na sposób, w jaki WordPress obsługuje akcje i filtry, wszystko jest dołączone do określonego haka (albo tych , które WordPress definiuje, albo niestandardowych haków).
2 Przestrzeń nazw WordPress
Za każdym razem, gdy pracuję nad funkcjonalnością ściśle powiązaną z WordPress, staram się umieścić ją w przestrzeni nazw WordPressa. Wskazuje to dla mnie, jak również dla innych programistów, że wszystko, co znajduje się w tej przestrzeni nazw, nie może być oddzielone od podstawowej aplikacji.
Tak więc w katalogu src utwórz katalog WordPress. To tutaj będzie znajdować się podstawowa klasa Widgetów wraz z innymi klasami wprowadzonymi w tej serii.
Oznacza to, że nie potrzebujemy już klasy w katalogu API. Dlatego upewnij się, że przenosisz klasę, aktualizujesz jej przestrzeń nazw i usuwasz katalog. Trochę później zrobię zrzut ekranu i trochę kodu.
Dodatkowo, przypomnijmy, wcześniej w serii umieściliśmy katalog Views w katalogu głównym katalogu src, ale teraz możemy go przenieść do katalogu WordPress. Więc śmiało zrób to teraz.
Ostateczny wynik powinien wyglądać mniej więcej tak:
Teraz możemy zwrócić uwagę na kod.
3 Spojrzenie na klasę widżetów
W tym poście zamierzamy nieco uprościć podstawową klasę widżetów. To cofnie część naszej pracy, ale potrzebowaliśmy tej poprzedniej pracy, aby doprowadzić nas do tego punktu.
Na razie skupiamy się na konstruktorze i funkcji pobierania informacji o widżecie. To właśnie ostatecznie pozwoli nam zobaczyć coś w obszarze administracyjnym WordPressa.
Więc najpierw upewnij się, że Twoja klasa Widget wygląda tak :
<?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;
}
}Następnie, ponieważ przenieśliśmy ten plik do przestrzeni nazw WordPress, musimy zaktualizować sekcję autoload naszego pliku konfiguracyjnego Composera :
"autoload": {
"psr-4": {
"WordPressWidgetBoilerplate": "src/",
"WordPressWidgetBoilerplateUtilities": "src/Utilities/",
"WordPressWidgetBoilerplateSubscriber": "src/Subscriber/",
"WordPressWidgetBoilerplateWordPress": "src/WordPress/"
}
},Następnie musimy wprowadzić subskrybenta.
4 Przedstawiamy subskrybenta widżetu
Za każdym razem, gdy mam jakąś klasę podstawową, zazwyczaj staram się stworzyć prostego subskrybenta, który tworzy instancję klasy podstawowej i pozwala jej wykonywać swoją pracę.
Robię to, ponieważ WordPress, jak wspomniano, używa wzorca projektowego opartego na zdarzeniach, co oznacza, że wszystko musi być zarejestrowane w jakimś typie haka. I nie lubię mieszać logiki domeny z tą samą klasą, która łączy się z WordPressem. Więc je rozdzielam.
I to właśnie robi subskrybent. Rejestruje się w WordPressie, a następnie wywołuje klasę odpowiedzialną za faktyczne wykonanie pracy.
Powiedziawszy to, zwróć uwagę na katalog Subscriber i dodaj klasę o nazwie WidgetSubscriber. W tej klasie dodaj następujący kod :
<?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'));
}
}
Konstruktor zarejestruje klasę z konkretnym hakiem, który za chwilę przyjrzymy; następnie użyje API WordPressa do utworzenia instancji naszego widżetu (co dzieje się w funkcji ładowania ).
5 Zapasy
Na koniec musimy zaktualizować bootstrap, aby:
- rejestruje WidgetSubscriber z odpowiednim hakiem,
- dodaje subskrybenta do Rejestru ,
- i uruchamia wtyczkę (co robiliśmy).
Po tym wszystkim bootstrap powinien wyglądać tak :
<?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();Następnie powinieneś być w stanie zalogować się do WordPressa i aktywować wtyczkę.
Spojrzenie na obszar administracyjny
W tym momencie nie ma na co patrzeć, ale do tego dochodzimy. Po pierwsze, powinieneś zauważyć, że widżet pojawia się teraz w obszarze zawierającym dostępne widżety:
Powinieneś także zauważyć, że po przeciągnięciu widżetu do obszaru widżetów (lub dowolnego paska bocznego), nie ma on dostępnych opcji.
To powiedziawszy, jesteśmy w dobrym miejscu, aby dalej budować na tym, co mamy. Zawsze możesz nadal śledzić rozwój boilerplate’u w serwisie GitHub.
Kontynuacja wł.
Następnie będziemy kontynuować tworzenie funkcjonalności obszaru administracyjnego widżetu. Następnie zwrócimy uwagę na publiczną stronę widżetu oraz na funkcję serializacji.
Powinieneś być w stanie zobaczyć, jak rzeczy zaczynają nabierać kształtu, gdy zaczynamy rozdzielać logikę na jej różne elementy. Jeśli nie, nie martw się – przed nami jeszcze wiele.
A ostateczna wersja Boilerplate będzie oczywiście zademonstrować wszystkie zasady, na których opieramy się w tej serii postów.