WordPress-widgetit: Refaktorointi, osa 8
Kun on kyse WordPress Widget Boilerplaten uudelleenmuodostamisesta, olemme tehneet paljon työtä saattaaksemme koodipohjan oliokeskeisempään standardiin. Lisäksi olemme ottaneet käyttöön useita muita työkaluja, joiden avulla voimme saattaa koodimme nykyaikaisempien standardien mukaisiksi
Nyt kun olemme käyttäneet aikaa tämän tekemiseen, on aika hypätä takaisin koodiin ja aloittaa sen muokkaaminen uudelleen sellaisella tavalla, joka mahdollistaa abstraktien luokkien ja tilaajien käytön (jotka toimivat osana tapahtumalähtöistä suunnittelumallia ).
Edellisen postauksen lopussa kirjoitin:
Tulevissa viesteissä aiomme tarkastella, kuinka voimme ottaa tilaajat käyttöön sivuston julkiselle puolelle (eli missä widgetin sisältö näytetään). Ja teemme samoin sivuston hallintoalueella.
Joten tässä viestissä aiomme tehdä juuri niin. Tarkemmin sanottuna aiomme aloittaa työstämällä widgetin tilaajaa ja saamalla sitten peruswidgetin näkyviin ensin sivuston hallinnollisella puolella.
WordPress Widget Boilerplate: Refactoring, osa 8
Syy, miksi olen kiinnostunut keskittymään ensisijaisesti sivuston hallinnolliseen puoleen, on se, että sen avulla voimme:
- saat käsityksen siitä, miten tilaajat toimivat,
- katso kuinka koodikanta on järjestettävä,
- Koodaa joitakin tietoja ennen sarjoittamista.
Kun tämä kaikki on paikoillaan, pystymme kohdistamaan huomiomme edistyneempiin asioihin. Voimme nimittäin esitellä tilaajia tietojen näyttämiseen hallinta-alueella ja tilaajia tietojen desinfiointiin, sarjoitukseen, hakemiseen, validointiin ja näyttämiseen.
Mutta ensin tehdään tarvittavat työt uuden luokan perustamiseksi, automaattisen latausohjelman määrittämiseksi ja sisällön näyttämiseksi sivuston hallintoalueella.
1 Abstract Subscriber
Tarkastellaan ensin abstraktia tilaajaa, koska kaikki tilaajat toteuttavat tämän.
<?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();
}
Huomaa, että sillä on kaksi julkista toimintoa – konstruktio, joka asettaa koukun ja toiminto koukun noutamiseen. Siinä on myös abstrakti latausfunktio, jossa mikä tahansa luokka, joka laajentaa tätä luokkaa, toteuttaa tietyn toiminnallisuuden.
Muista, että koska WordPress käsittelee toimintoja ja suodattimia, kaikki on kiinnitetty tiettyyn koukkuun (joko WordPressin määrittelemiin tai mukautettuihin koukkuihin).
2 WordPressin nimitila
Aina kun työskentelen WordPressiin tiiviisti kytkettyjen toimintojen parissa, yritän varmistaa, että sijoitan sen WordPressin nimiavaruuteen. Tämä osoittaa minulle ja muille kehittäjille, että mitä tahansa tässä nimiavaruudessa sijaitsevaa ei voida erottaa ydinsovelluksesta.
Joten luo src -hakemistoon WordPress – hakemisto. Tässä on Widget-ydinluokka ja kaikki muut luokat, jotka esitellään koko sarjassa.
Tämä tarkoittaa, että emme enää tarvitse luokkaa API-hakemistossa. Muista siis siirtää luokka, päivittää sen nimiavaruus ja poistaa hakemisto. Otan tästä kuvakaappauksen ja koodin vähän myöhemmin.
Lisäksi, muistaakseni sarjan aiemmin, sijoitimme Views -hakemiston src -hakemiston juureen, mutta nyt voimme siirtää sen WordPress – hakemistoon. Joten mene eteenpäin ja tee se nyt.
Lopputuloksen pitäisi näyttää suunnilleen tältä:
Nyt voimme kääntää huomiomme koodiin.
3 Katsaus widget-luokkaan
Tässä viestissä yksinkertaistamme hieman widgettien ydinluokkaa. Se kumoaa osan tekemästämme työstä, mutta tarvitsimme aiemman työn päästäksemme tähän pisteeseen.
Toistaiseksi keskitymme rakentajaan ja widget-slugin noutamistoimintoon. Tämä antaa meille mahdollisuuden nähdä jotain WordPressin hallintoalueella.
Varmista siis ensin, että Widget-luokkasi näyttää tältä :
<?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;
}
}Seuraavaksi, koska olemme siirtäneet tämän tiedoston WordPressin nimiavaruuteen, meidän on päivitettävä Composer-määritystiedostomme automaattinen latausosio :
"autoload": {
"psr-4": {
"WordPressWidgetBoilerplate": "src/",
"WordPressWidgetBoilerplateUtilities": "src/Utilities/",
"WordPressWidgetBoilerplateSubscriber": "src/Subscriber/",
"WordPressWidgetBoilerplateWordPress": "src/WordPress/"
}
},Seuraavaksi meidän on esitettävä tilaaja.
4 Widget-tilaajan esittely
Aina kun minulla on jonkinlainen ydinluokka, yritän yleensä luoda yksinkertaisen tilaajan, joka instantoi ydinluokan ja antaa sen tehdä työnsä.
Teen tämän, koska WordPress, kuten mainittiin, käyttää tapahtumalähtöistä suunnittelumallia, mikä tarkoittaa, että kaikki on rekisteröitävä jonkin tyyppiseen koukkuun. Enkä pidä verkkotunnuksen logiikan sekoittamisesta samaan luokkaan, joka kytkeytyy WordPressiin. Joten erotan ne.
Ja niin tilaaja tekee. Se rekisteröi itsensä WordPressiin ja kutsuu sitten työn suorittamisesta vastaavan luokan.
Kiinnitä huomiosi Tilaajahakemistoon ja lisää luokka nimeltä WidgetSubscriber. Lisää kyseiselle luokalle seuraava koodi :
<?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'));
}
}
Rakentaja rekisteröi luokan tietyllä koukulla, jonka tarkistamme hetken kuluttua; sitten se käyttää WordPress-sovellusliittymää widgetin luomiseen (mikä tapahtuu lataustoiminnossa ).
5 Bootstrap
Lopuksi meidän on päivitettävä bootstrap niin, että se:
- rekisteröi WidgetSubscriberin oikeaan koukkuun,
- lisää tilaajan rekisteriin ,
- ja käynnistää laajennuksen (mitä olemme tehneet).
Bootstrapin pitäisi kaiken tämän jälkeen näyttää tältä :
<?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();Seuraavaksi sinun pitäisi pystyä kirjautumaan WordPressiin ja aktivoimaan laajennus.
Katsaus hallintoalueelle
Tässä vaiheessa ei ole paljon katseltavaa, mutta perille ollaan tulossa. Ensinnäkin sinun tulee huomata, että widget näkyy nyt alueella, joka sisältää käytettävissä olevat widgetit:
Ja sinun pitäisi myös nähdä, että kun vedät widgetin widgetoidulle alueelle (tai mihin tahansa sivupalkkiin), siinä ei ole valittavissa olevia vaihtoehtoja.
Meillä on kuitenkin hyvä paikka jatkaa sen pohjalta, mitä meillä on. Voit aina jatkaa tiivistelmän kehityksen seuraamista GitHubissa.
Jatkuu
Seuraavaksi jatkamme widgetin hallinnollisen alueen toiminnallisuuden rakentamista. Tämän jälkeen kiinnitämme huomiomme widgetin julkiseen puoleen sekä serialisointitoimintoihin.
Sinun pitäisi pystyä näkemään, kuinka asiat alkavat muotoutua, kun alamme erottaa logiikan sen eri osiin. Jos ei, älä huoli – lisää on tulossa.
Ja Boilerplaten lopullinen versio näyttää tietysti kaikki periaatteet, joihin rakennamme tässä viestisarjassa.