Im vorherigen Beitrag sind wir durch viele Umgestaltungen gegangen, die Bedenken in ihre eigenen Klassen aufgeteilt haben.

Letztendlich hilft dies zu zeigen, wie wir ein hohes Maß an Zusammenhalt aufrechterhalten können, während wir nicht nur mit Klassen in WordPress arbeiten, sondern dies neben bereits vorhandenen APIs tun.

Da die letzten Posts zum Refactoring der Codebasis so lang waren, konzentrieren sich die aktuellen Posts auf kleine, inkrementelle Änderungen und daher kürzere, fokussiertere Posts.

Wie im vorherigen Artikel erwähnt:

Wenn Sie die Seite jedoch aktualisieren, stellen Sie möglicherweise fest, dass die Bereinigung und Serialisierung beim Abrufen der Daten nicht zu funktionieren scheinen. Und dem gehen wir im nächsten Beitrag nach.

Das ist es also, wo wir in diesem Artikel ansetzen werden.

Das WordPress-Widget Boilerplate: Refactoring Teil 11

Bevor Sie Code schreiben, sollten Sie als Erstes Folgendes beachten, wenn Sie einen der Inhaltsbereiche des Widgets (z. B. den Titel) mit etwas wie dem Folgenden füllen :

<script type="text/javascript">This is the Title</script>

Und dann auf Speichern klicken, der eigentliche Inhalt wird bereinigt und in die Datenbank geschrieben. Sie können sehen, dass dies wahr ist, indem Sie sich den Wert des Widgets in der Datenbank ansehen.

Außerdem sehen die Daten auf den ersten Blick gut aus, aber wenn Sie die Seite aktualisieren, wird der unsaubere Inhalt angezeigt. Wenn Sie zu einer anderen Seite wie Menüs navigieren und dann zurückkehren, wird der Widget-Inhalt angezeigt, aber ordnungsgemäß bereinigt.

Warum zeigt es dann bei bestimmten Schritten eine Sache in der Datenbank und eine Sache im Frontend des Administrationsbereichs an?

Das hat mit dem Widget-Cache zu tun, und zum Glück können wir diesen Cache nach Belieben leeren, indem wir beliebige Hooks verwenden (das heißt, wir können jedes Ereignis abonnieren und dann den Cache leeren).

Aus der Codereferenz :

Entfernt den Cache-Inhalt, der mit Schlüssel und Gruppe übereinstimmt.

Beachten Sie jedoch, dass wir den Schlüssel und eine optionale Gruppe angeben müssen. In der Boilerplate haben wir den Slug des Widgets als Schlüssel- und Gruppen-Widget verwendet.

Leeren des Caches

Da die Funktion mit jedem Ereignis verbunden werden kann, können wir einen Abonnenten erstellen, den wir mit jedem Ereignis verbinden können. Das bedeutet, dass wir einen DeleteWidgetCache-Abonnenten in unserem Abonnenten-Namespace erstellen können:

<?php

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

/**
 * Deletes the cached contents of the widget.
 */
class DeleteWidgetCacheSubscriber extends AbstractSubscriber
{
    /**
     * {@inheritdoc}
     */
    public function __construct(string $hook)
    {
        parent::__construct($hook);
    }

    /**
     * Flushes the widget's cache based on the key that's specified in the function arguments.
     */
    public function load()
    {
        /* Because we're implementing an abstract class, we'll parse arguments from the
         * func_get_args().
         */
        $args = func_get_args();
        if (!$this->hasValidArguments($args)) {
            return;
        }

        // TODO: More to come...
    }

    /**
     * Verifies that we have valid arguments with which to work.
     *
     * @param array $args the array of arguments we are validating
     *
     * @return bool true if the arguments are valid; otherwise, false
     */
    private function hasValidArguments(array $args): bool
    {
        // First, check the initial index of the arguments.
        if (!isset($args[0])) {
            return false;
        }

        // Next, check the values of the arguments for the widget key and group.
        $args = $args[0];
        if (!isset($args[0]) && !isset($args[1])) {
            return false;
        }

        return true;
    }
}

Wir aktualisieren dann den Bootstrap, um den Abonnenten zur Registrierung hinzuzufügen, und wir verwenden einen benutzerdefinierten Hook, flush_widget_cache, den wir vorübergehend verwenden werden.

<?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;
use WordPressWidgetBoilerplateSubscriberWidgetSubscriber;
use WordPressWidgetBoilerplateSubscriberDeleteWidgetCacheSubscriber;

// 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 subscribers.
$registry->add('deleteWidgetCacheSubscriber', new DeleteWidgetCacheSubscriber('flush_widget_cache'));

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

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

Für die Boilerplate verwenden wir das benutzerdefinierte Ereignis immer dann, wenn der Serialisierungscode des Widgets aufgerufen wird.

Zuerst definieren wir einen do_action -Aufruf, identifizieren ihn als flush_widget_cache und übergeben dann die erforderlichen Argumente an das Ereignis, damit der Abonnent sie lesen kann:

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

/**
 * Santiizes and saves the data for the widget.
 */
class WidgetSerializer
{
    /**
     * @var string a reference to the slug of the widget to which the serialier is associated
     */
    private $widgetSlug;

    /**
     * Initializes the class.
     *
     * @param string a reference to the slug of the widget to which the serialier is associated
     */
    public function __construct(string $widgetSlug)
    {
        $this->widgetSlug = $widgetSlug;
    }

    /**
     * Updates the values of the widget. Sanitizes the information before saving it.
     *
     * @param array $newInstance the array of new options to save
     */
    public function update($newInstance)
    {
        $instance = [];
        foreach ($newInstance as $key => $value) {
            $instance[$key] = strip_tags(
                stripslashes($value)
            );
        }

        do_action('flush_widget_cache', [$this->widgetSlug, 'widget']);

        return $instance;
    }
}

Und dann leeren wir im Abonnenten den Cache basierend auf den eingehenden Argumenten:

<?php

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

/**
 * Deletes the cached contents of the widget.
 */
class DeleteWidgetCacheSubscriber extends AbstractSubscriber
{
    /**
     * {@inheritdoc}
     */
    public function __construct(string $hook)
    {
        parent::__construct($hook);
    }

    /**
     * Flushes the widget's cache based on the key that's specified in the function arguments.
     */
    public function load()
    {
        /* Because we're implementing an abstract class, we'll parse arguments from the
         * func_get_args().
         */
        $args = func_get_args();
        if (!$this->hasValidArguments($args)) {
            return;
        }

        $args = $args[0];
        wp_cache_delete($args[0], $args[1]);
    }

    /**
     * Verifies that we have valid arguments with which to work.
     *
     * @param array $args the array of arguments we are validating
     *
     * @return bool true if the arguments are valid; otherwise, false
     */
    private function hasValidArguments(array $args): bool
    {
        // First, check the initial index of the arguments.
        if (!isset($args[0])) {
            return false;
        }

        // Next, check the values of the arguments for the widget key and group.
        $args = $args[0];
        if (!isset($args[0]) && !isset($args[1])) {
            return false;
        }

        return true;
    }
}

Und das tut es.

Bereit für das Front-End

An diesem Punkt haben wir einen Mechanismus eingerichtet, der den Widget-Cache jederzeit leeren kann – nicht nur mit einem benutzerdefinierten Ereignis – sondern auch mit allen von WordPress angebotenen Ereignissen.

Dies kann praktisch sein, wenn Sie die Boilerplate für etwas verwenden, das eine zwischengespeicherte Abfrage oder einen anderen Caching-Mechanismus verwendet, und sicherstellen möchten, dass der Inhalt klar ist.

Als Nächstes sehen wir uns das Rendern von Inhalten im Front-End an. Wir nähern uns dem Ende des Refactorings der Boilerplate, aber es gibt noch ein bisschen mehr zu tun, bevor wir bereit sind, es in den Master-Zweig der Codebasis zu integrieren.