Отображение метаданных в посте в WordPress

2020-10-20

Ранее мы рассматривали концепции объектно-ориентированного программирования (ООП) с точки зрения начинающего программиста. Целью этих статей было внедрить основные концепции ООП в PHP применительно к WordPress в вашу повседневную практику веб-программирования.

Если вы не читали эти статьи, можете познакомиться с ними, прочитав итоговую статью цикла и, если понадобится, пройдя по ссылкам на более ранние статьи.

Одной из практических работ, направленных на закрепление принципов ООП, а также на изучение функций WordPress API, было написание плагина для WordPress.

Говоря конкретнее, мы создали плагин, который позволяет просматривать метаданные, ассоциированные с текущим постом, в консоли WordPress:

Возможные последствия модификации плагина
Взгляд на метаданные
В чём проблема?
Расширение обработчика метаданных поста
Создание общедоступного каталога
Итоги

Познакомиться с кодом плагина, его описанием и комментариями, а также загрузить его можно на GitHub.

С тех пор, как был написан этот плагин, меня несколько раз спрашивали, как отобразить те данные, которые плагин выводит в консоль сайта, в его пользовательской части.

Пришла пора расширить наш плагин. В частности, добавить ему функциональности, позволяющей выводить метаданные в страницу, отображающую отдельный пост. Мы обсудим, как это можно сделать наиболее рациональным способом, используя уже имеющийся код, а главное – в каких ситуациях вывод мета данных может быть полезен.

Итак, приступим!

Возможные последствия модификации плагина

Прежде чем мы начнём планировать конкретные действия, я думаю, необходимо объяснить, почему публиковать такую информацию, как метаданные поста, в пользовательской части может быть хорошей или плохой идеей.

Я считаю, что каждый разработчик, создающий или расширяющий системы, работающие с деликатными данными, должен задумываться о том, кем и как будет использоваться его продукт ещё до этапа проектирования.
Иными словами, необязательно делать что-то только потому, что мы можем это сделать.

Взгляд на метаданные

Метаданные, ассоциированные с постом, хранятся в базе данных. Они попадают туда из разных источников: из ядра системы, из тем, из различных плагинов. И предназначены метаданные для использования только в соответствующем коде и с весьма разнообразными целями.

На иллюстрации, показывающей пример работы нашего плагина, можно заметить поля данных, имена которых начинаются с символа подчёркивания, например, _edit_lock и _edit_last, хранящие числовые значения. Это пример метаданных, используемых ядром WordPress для управления состоянием поста.

Другие метаданные могут сохраняться темами и плагинами, и также предназначаться для управления их внутренней работой в контексте конкретного поста.

В чём проблема?

Проблема в том, что отображение всего этого в пользовательском пространстве может давать последнему слишком много информации.

На приведённой нами иллюстрации пользователь не видит ничего существенного с точки зрения безопасности, но это не значит, что так будет в любом случае. Наоборот, вероятность того, что какие-то плагины будут хранить в метаданных частную, не предназначенную для просмотра всеми посетителями информацию, весьма велика.

И даже если отвлечься от проблем информационной безопасности, то для большинства посетителей блога данные, отображаемые нашим плагином, могут выглядеть как шум или непонятный технический жаргон, и потому затруднять восприятие основного контента.

Именно поэтому я изначально решил, что консоль WordPress – самое подходящее место для отображения метаданных.

И, тем не менее, мы решили это сделать?

Да, но не потому, что показывать пользователю метаданные – это хорошая идея, а потому что сам процесс изучения негативных последствий расширения плагина будет полезен с точки зрения дальнейшего обучения WordPress.

Ну, и потому, что некоторые умеют учиться только на своих собственных ошибках. В общем, это нормальный процесс обучения.

Кроме того, сам по себе опыт поддержки и расширения существующего кода весьма полезен для начинающих разработчиков.

Расширение обработчика метаданных поста

Как и во всех своих обучающих статьях, я постараюсь сначала дать исчерпывающую информацию о том, что и как мы собираемся делать, чтобы в процессе написания и обзора кода нам не приходилось гадать и импровизировать. Как настоящим системным архитекторам, нам необходимо заранее иметь чёткий план действий.

Если вы ещё не ознакомились с исходным кодом, самое время сделать это.

Готовы? Теперь – наш план:

Мы возьмём за основу тему по умолчанию «2014»;
Мы создадим общедоступный каталог, который будет отображать метаданные в контексте одного поста;
Мы определим обработчики, которые будут добавлять данные в пост и отображать их в нижней части страницы. Мы создадим и используем для этого рудиментарную таблицу, которая унаследует стили текущей темы. Учтите, что с разными темами результат будет выглядеть по-разному. Конкретные модификации для улучшения внешнего вида нашего плагина вам придётся сделать самостоятельно;
Наконец, для отображения метаданных в посте мы воспользуемся шаблоном, который создали в первоначальной версии плагина.

Ничего особенно сложного, не правда ли? Но уточнить направление действий было необходимо. Теперь приступим.

Создание общедоступного каталога

Подразумевая, что тема «2014» уже активна и наш плагин уже установлен, приступим к реализации нового функционала. Прежде всего, мы должны:

создать каталог public;
создать класс Single_Post_Meta_Manager_Public;
добавить класс в базовый код плагина.

Кроме создания файлов, необходимо добавить следующий код в функцию load_dependencies() в файл includes/single-post-meta-manager.php:

private function load_dependencies() {

    require_once plugin_dir_path( dirname( __FILE__ ) ) . 'admin/class-single-post-meta-manager-admin.php';
    require_once plugin_dir_path( dirname( __FILE__ ) ) . 'public/class-single-post-meta-manager-public.php';

    require_once plugin_dir_path( __FILE__ ) . 'class-single-post-meta-manager-loader.php';
    $this->loader = new Single_Post_Meta_Manager_Loader();

}

Фактически, нами была добавлена только одна строка с директивой require_once, импортирующая файл класса в плагин.
Теперь зададим свойства, конструктор и методы класса Single_Post_Meta_Manager_Public:

<?php
/**
 * The Single Post Meta Manager Public defines all functionality for the public-facing
 * sides of the plugin
 *
 * @package SPMM
 */

/**
 * The Single Post Meta Manager Public defines all functionality for the public-facing
 * sides of the plugin.
 *
 * This class defines the meta box used to display the post meta data and registers
 * the style sheet responsible for styling the content of the meta box.
 *
 * @since    1.0.0
 */
class Single_Post_Meta_Manager_Public {

    /**
     * A reference to the version of the plugin that is passed to this class from the caller.
     *
     * @access private
     * @var    string    $version    The current version of the plugin.
     */
    private $version;

    /**
     * Initializes this class and stores the current version of this plugin.
     *
     * @param    string    $version    The current version of this plugin.
     */
    public function __construct( $version ) {
        $this->version = $version;
    }

    /**
     * Uses the partial located in the admin directory for rendering the
     * post meta data the end of the post content.
     *
     * @param    string    $content    The post content.
     * @return   string    $content    The post content including the given posts meta data.
     */
    public function display_post_meta_data( $content ) {

        ob_start();

        require_once plugin_dir_path( dirname( __FILE__ ) ) . 'admin/partials/single-post-meta-manager.php';
        $template = ob_get_contents();
        $content .= $template;

        ob_end_clean();

        return $content;

    }

}

Теперь нам нужно задать функцию-обработчик общедоступного интерфейса нашего плагина при помощи вызова define_public_hooks(). Это делается так:

<?php
/**
 * Defines the hooks and callback functions that are used for rendering information on the front
 * end of the site.
 *
 * This function relies on the Single Post Meta Manager Public class and the Single Post Meta Manager
 * Loader class property.
 *
 * @access    private
 */
private function define_public_hooks() {

    $public = new Single_Post_Meta_Manager_Public( $this->get_version() );
    $this->loader->add_action( 'the_content', $public, 'display_post_meta_data' );

}

Вызовем эту функцию из конструктора класса. Следующей строчкой после $this->define_admin_hooks(); добавим $this->define_public_hooks();.

Если всё было сделано правильно, вы сможете активировать плагин и увидеть в каждом посте те же метаданные, которые отображаются в консоли:

Итоги

Как мы уже говорили, показывать метаданные пользователю – не самая хорошая мысль. Тем не менее, на данном примере мы изучили новые функции WordPress с использованием уже знакомого нам кода.

Таким образом, польза от сегодняшнего урока двояка:

с одной стороны, мы укрепили свои навыки по вторичному использованию кода;
а с другой – усвоили на практике, что показывать внутренние данные системы в пользовательском интерфейсе может быть не эстетично и даже опасно.

Разумеется, мы рекомендуем вам устанавливать данный плагин только для самообучения, а не на готовом, публично доступном сайте. Иными словами, используйте этот код на свой страх и риск.