Mis puutub WordPressi vidina katlaplaadi ümbertöötamisse, siis oleme teinud palju tööd, et viia koodibaas rohkem objektorienteeritud standardile. Lisaks oleme kasutusele võtnud mitmeid muid tööriistu, mis võimaldavad meil viia oma koodi kaasaegsematele standarditele
Nüüd, kui oleme selleks aega kulutanud, on aeg hüpata tagasi koodi juurde ja alustada selle ümberkujundamist viisil, mis võimaldab kasutada abstraktseid klasse ja tellijaid (mis toimivad sündmusepõhise kujundusmustri osana ).
Eelmise postituse lõpus kirjutasin:
Järgmistes postitustes vaatleme, kuidas saaksime tellijaid saidi avalikul küljel (st kus kuvatakse vidina sisu) juurutada. Sama teeme ka saidi haldusalaga.
Nii et selles postituses teeme täpselt seda. Täpsemalt, alustame sellest, et töötame vidina tellija kallal ja seejärel saame esmalt kuvada põhividina saidi haldusküljel.
WordPressi vidina katlaplaat: ümbertöötamine, 8. osa
Põhjus, miks ma olen huvitatud peamiselt saidi administratiivsele poolele keskendumisest, on see, et see võimaldab meil:
- saada aru, kuidas tellijad töötavad,
- vaadake, kuidas koodibaasi tuleb korraldada,
- enne serialiseerimisega töötamist kõvasti kodeerige teatud teave.
Kui see kõik on paigas, on meil hea võimalus pöörata tähelepanu keerukamatele asjadele. Nimelt saame tutvustada tellijaid info kuvamiseks haldusalas ning tellijaid andmete desinfitseerimiseks, serialiseerimiseks, hankimiseks, valideerimiseks ja kuvamiseks.
Kuid kõigepealt teeme vajalikud tööd uue klassi seadistamiseks, automaatlaaduri konfigureerimiseks ja saidi haldusalas sisu kuvamiseks.
1 Abstraktne tellija
Vaatame esmalt üle abstraktse tellija, kuna seda rakendavad kõik tellijad.
<?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();
}
Pange tähele, et sellel on kaks avalikku funktsiooni – konstruktsioon, mis määrab konksu ja funktsioon konksu kättesaamiseks. Sellel on ka abstraktne laadimisfunktsioon, kus iga klass, mis seda klassi laiendab, rakendab oma spetsiifilisi funktsioone.
Tuletage meelde, et WordPressi toimingute ja filtrite käsitlemise tõttu on kõik seotud konkreetse konksuga (kas need , mille WordPress määrab, või kohandatud konksud).
2 WordPressi nimeruum
Kui töötan WordPressiga tihedalt seotud funktsioonide kallal, proovin veenduda, et paigutan selle WordPressi nimeruumi. See näitab nii mulle kui ka teistele arendajatele, et selles nimeruumis asuvat ei saa põhirakendusest lahutada.
Nii et looge src kataloogis WordPressi kataloog. See on koht, kus asub vidinate põhiklass koos kõigi teiste selle sarja jooksul tutvustatavate klassidega.
See tähendab, et me ei vaja enam klassi API kataloogis. Nii et teisaldage klass kindlasti, värskendage selle nimeruumi ja eemaldage kataloog. Mul on selle jaoks ekraanipilt ja kood veidi hiljem.
Lisaks, meenutage seeria varasemaid, paigutasime kataloogi Views src kataloogi juure, kuid nüüd saame selle teisaldada WordPressi kataloogi. Nii et jätkake ja tehke seda kohe.
Lõpptulemus peaks välja nägema umbes selline:
Nüüd saame pöörata tähelepanu koodile.
3 Pilk vidinaklassile
Selles postituses lihtsustame veidi põhividinate klassi. See tühistab osa tööst, mida oleme teinud, kuid vajasime seda eelnevat tööd, et jõuda selleni.
Praegu keskendume konstruktorile ja vidina nälkja toomise funktsioonile. See võimaldab meil lõpuks WordPressi haldusalas midagi näha.
Nii et kõigepealt veenduge, et teie vidinaklass näeb välja selline :
<?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;
}
}Järgmiseks, kuna teisaldasime selle faili WordPressi nimeruumi, peame värskendama oma helilooja konfiguratsioonifaili automaatse laadimise jaotist :
"autoload": {
"psr-4": {
"WordPressWidgetBoilerplate": "src/",
"WordPressWidgetBoilerplateUtilities": "src/Utilities/",
"WordPressWidgetBoilerplateSubscriber": "src/Subscriber/",
"WordPressWidgetBoilerplateWordPress": "src/WordPress/"
}
},Järgmisena peame tutvustama tellijat.
4 Vidina tellija tutvustus
Kui mul on mingisugune põhiklass, püüan üldiselt luua lihtsa abonendi, mis loob põhiklassi ja võimaldab sellel oma tööd teha.
Teen seda seetõttu, et WordPress, nagu mainitud, kasutab sündmustepõhist kujundusmustrit, mis tähendab, et kõik tuleb registreerida teatud tüüpi konksu külge. Ja mulle ei meeldi segada domeeniloogikat sama klassiga, mis haakub WordPressiga. Nii et ma eraldan nad.
Ja seda tellija teeb. See registreerib end WordPressis ja kutsub seejärel klassi, kes vastutab töö tegeliku tegemise eest.
Seda öeldes pöörake tähelepanu tellijate kataloogile ja lisage klass nimega WidgetSubscriber. Selles klassis lisage järgmine kood :
<?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 registreerib klassi konkreetse konksuga, mille vaatame hetke pärast üle; siis kasutab see meie vidina loomiseks WordPressi API-d (mis toimub laadimisfunktsioonis ).
5 Bootstrap
Lõpuks peame värskendama alglaadimist, et see:
- registreerib WidgetSubscriberi õige konksuga,
- lisab abonendi registrisse ,
- ja käivitab pistikprogrammi (mida oleme teinud).
Pärast kõike seda peaks buutstrap välja nägema järgmine :
<?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();Järgmisena peaksite saama WordPressi sisse logida ja pistikprogrammi aktiveerida.
Pilk haldusalale
Praegu pole palju vaadata, kuid me jõuame selleni. Esiteks peaksite märkama, et vidin ilmub nüüd saadaolevaid vidinaid sisaldavas piirkonnas:
Samuti peaksite nägema, et kui lohistate vidina vidinatega varustatud alale (või mis tahes külgribale), pole sellel valikuid.
Sellegipoolest oleme heas kohas, et jätkata olemasolevale tuginedes. Saate alati GitHubis jätkata katlaplaadi arengu jälgimist .
Jätkub
Järgmisena jätkame vidina haldusala funktsionaalsuse väljatöötamist. Pärast seda pöörame tähelepanu nii vidina avalikkusele kui ka serialiseerimisfunktsioonile.
Peaksite nägema, kuidas asjad hakkavad kujunema, kui hakkame loogikat selle erinevateks komponentideks eraldama. Kui ei, siis ärge muretsege – tulemas on veel palju.
Ja Boilerplate’i lõplik versioon demonstreerib loomulikult kõiki põhimõtteid, millele me selle postituste seeria jooksul tugineme.