Konstruktor odpowiada za ustawienie kilku właściwości widżetu, najczęściej jego nazwy i opisu.
Funkcja widżetu odpowiada za renderowanie zawartości widżetu.
Funkcja formularza odpowiada za wyświetlanie formularza w obszarze administracyjnym WordPressa podczas pracy z widżetem.
Funkcja aktualizacji odpowiada za aktualizację opcji, które są zapisane w bazie danych (lub zainicjowane, a następnie zapisanie opcji, które mogą jeszcze nie istnieć w bazie danych).

Miłą rzeczą jest to, że to szczególne podejście jest osiągane poprzez dziedziczenie funkcjonalności klasy WP_Widget.

Problem polega jednak na tym, że jedna klasa to dużo pracy.

Zamiast tego powinniśmy rozdzielić każdą z funkcji na jej własny obszar funkcjonalności.

Podobnie jak w przypadku wszystkiego w programowaniu, będą sposoby, w których pewne rzeczy będą jasne, jak można je wykonać, a także będą pewne rzeczy, które można zrobić na wiele sposobów.

Zaprezentuję, jak do tego podchodzę na razie. Może się to zmienić w przyszłości, a może nie, a inni mogą mieć na to inne podejście.

Niezależnie od tego implementacja będzie znacznie bardziej zorientowana obiektowo i da każdej klasie własny zestaw obowiązków.

Pierwsze pytanie brzmi jednak, jak podzielić klasę z czterema funkcjami, która dziedziczy po klasie nadrzędnej?

Aktualizacja Bootstrapa

Po pierwsze, jest kilka rzeczy, które musimy dostosować w programie startowym wtyczki. Mianowicie musimy wykonać następujące czynności:

utworzyć instancję Rejestru i udostępnić go poprzez projekt,
zaktualizować klasę Plugin tak, aby akceptowała rejestr i ładowała subskrybentów,
przejrzyj bootstrap

Oto spojrzenie na wszystkie trzy z powyższych.

1 Utwórz instancję rejestru

Ponieważ omówiliśmy to już wcześniej w serii, powinno być jasne, jak to zrobić.

Najpierw zobacz następujący kod :

<?php

// Setup a filter so we can retrieve the registry throughout the plugin.
$registry = new Registry();
add_filter('wpwBoilerplateRegistry', function() use ($registry) {
    return $registry;
});

Następnie zauważ, że tworzymy instancję Rejestru (za chwilę porozmawiamy o jego przestrzeni nazw), a następnie podłączamy go do niestandardowego filtra, który umożliwia nam dostęp do niego przez całą wtyczkę, kiedy tylko chcemy.

2 Zaktualizuj klasę wtyczki

Następnie musimy zaktualizować podstawową klasę wtyczki (znajdującą się w katalogu src ), aby odwoływała się do rejestru i ładowała wszystkich zarejestrowanych subskrybentów :

<?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 WordPressWidgetBoilerplate;

use WordPressWidgetBoilerplateUtilitiesRegistry;

/**
 * The base class for this plugin. Maintains a copy of the registry and starts
 * all of the objects that should hook into WordPress.
 */
class Plugin
{
    /**
     * @var Registry a reference to the simple container used to maintain plugin objects
     */
    private $registry;

    /**
     * @param Registry $registry a reference to the simple container used to maintain plugin objects
     */
    public function __construct(Registry $registry)
    {
        $this->registry = $registry;
    }

    /**
     * Iterates through each of the subscribers maintained in the registry and registers them
     * to the proper WordPress hook.
     */
    public function start()
    {
        array_map(function ($subscriber) {
            add_action($subscriber->getHook(), [$subscriber, 'load']);
        }, $this->registry->getRegisteredSubscribers());
    }
}

Pamiętaj jednak, że tak naprawdę nie skonfigurowaliśmy jeszcze żadnych subskrybentów. Zaczęliśmy to wcześniej w serii i teraz nadszedł czas, aby do tego wrócić, ale zrobimy to później.

Musimy jednak dodać funkcję – nawet tymczasową – abyśmy mogli dodać klasy, które nie są jawnymi subskrybentami zdarzeń:

<?php
/**
 * @return array all of the the objects that aren't subscribers registered with WordPress
 */
public function getRegisteredObjects()
{
    $objects = [];
    foreach ($this->registry as $object) {
        if (!$object instanceof AbstractSubscriber) {
            $objects[] = $object;
        }
    }

    return array_filter($objects);
}

Zostanie to przerobione później, ponieważ później będziemy przekształcać podstawowe klasy w subskrybentów.

3 Przejrzyj Bootstrap

Zanim przejdziemy dalej, myślę, że ważne jest, aby przejrzeć bootstrap. Chociaż Twój nagłówek i dokumentacja mogą się różnić, ważne jest, aby pamiętać, że wykonujemy następujące czynności:

nazwanie bootstrapu,
uniemożliwienie dostępu do pliku,
wywołanie autoloadera,
założenie rejestru,
i uruchomienie wtyczki.

Brzmi to dużo, ale kod jest dość krótki :

<?php
/**
 * WordPress Widget Boilerplate
 *
 * The WordPress Widget Boilerplate is an organized, maintainable boilerplate for building
 * widgets using WordPress best practices.
 *
 * @package   WordPressWidgetBoilerplate
 * @author    Your Name <email@example.com>
 * @license   GPL-3.0+
 * @link      http://example.com
 * @copyright 2018 - 2019 Your Name or Company Name
 *
 * @wordpress-plugin
 * Plugin Name:       WordPress Widget Boilerplate
 * Plugin URI:        https://github.com/tommcfarlin/wordpress-widget-boilerplate
 * Description:       An object-oriented foundation for building WordPress Widgets.
 * Version:           1.0.0
 * Author:            Tom McFarlin
 * Author URI:        https://tommcfarlin.com
 * Text Domain:       widget-name
 * License:           GPL-3.0+
 * License URI:       http://www.gnu.org/licenses/gpl-3.0.txt
 * Domain Path:       /lang
 */

namespace WordPressWidgetBoilerplate;

use WordPressWidgetBoilerplateUtilitiesRegistry;
use WordPressWidgetBoilerplatePlugin;

// 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;
});

// Start the machine.
(new Plugin($registry))->start();

W tym momencie jednak nadszedł czas, aby przyjrzeć się, jak to jest podzielić klasę potomną ze standardowego interfejsu API widżetów na coś, co pasuje do modelu kodu, z którym pracujemy.

Dzielenie klasy dziecka

Ta część prawdopodobnie obejmie kilka postów, ponieważ jest trochę pracy do wykonania, ale zaczniemy od stworzenia własnej klasy widżetów, która będzie dziedziczyć po podstawowej klasie widżetów.

Najpierw stwórz katalog API w katalogu src i dodaj plik o nazwie Widget.php. Tutaj będą znajdować się podstawy widżetu. W następnym poście zajmiemy się administracyjnymi i publicznymi arkuszami stylów oraz plikami JavaScript.

W tym momencie podstawy pliku powinny 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 WordPressWidgetBoilerplateAPI;

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;

        // TODO: update description
        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;
    }

    /**
     * TODO: This is a temporary message to show that the Boilerplate has loaded.
     */
    public function load()
    {
        $html = '<p style="text-align:center; background: #fff; padding: 1em; border: 1px dotted gray; margin: 2em 2em 2em 14em;">';
        $html .= 'The Widget Boilerplate is loaded.';
        $html .= '</p>';
        echo $html;
    }
}

Zauważ, że zajmuje jeden argument. Użyłem nazwy widżetu, ale możesz użyć tego, co chcesz, o ile reprezentuje twój widżet.

Ma to na celu pokazanie, że klasa jest poprawnie tworzona i ładowana, gdy wtyczka jest aktywowana. Jeśli tego nie widzisz, oznacza to, że coś jest nie tak (co za chwilę sprawdzimy).

Następnie ważne jest, aby upewnić się, że ta klasa została dodana do Rejestru. Dodaj więc następujące wiersze kodu w bootstrapie:

<?php

// Add the Widget base class to the Registry.
$registry->add('widget', new Widget('widget-name'));

A teraz, kiedy aktywujesz wtyczkę, powinieneś zobaczyć:

Jeśli nie, sprawdź kod w gałęzi deweloperskiej, aby upewnić się, że masz wszystko, co jest opisane w tym poście.

Wdrażanie subskrybentów

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.

Na koniec zwrócimy uwagę na kod odpowiedzialny za zabezpieczenie i serializację danych (czytaj: aktualizacja naszego widżetu), a następnie zobaczymy, jak wygląda finalna wersja zaktualizowanego boilerplate’u.

Jednak w tym poście podstawową strategią, którą stosujemy, jest podzielenie klasy potomnej tak, aby nadal mogła być używana z innymi klasami przy użyciu interfejsów i klas bazowych, które są już zdefiniowane w kodzie bazowym.

Źródło nagrywania: tommcfarlin.com