Раніше ми розглядали концепції об’єктно-орієнтованого програмування (ООП) з точки зору початківця програміста. Метою цих статей було впровадити основні концепції ООП в PHP стосовно WordPress у вашу повсякденну практику веб-програмування.

Якщо ви не читали ці статті, можете познайомитися з ними, прочитавши підсумкову статтю циклу і, якщо знадобиться, пройшовши по посиланнях на більш ранні статті.

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

Кажучи конкретніше, ми створили плагін, який дозволяє переглядати метадані, пов’язані з поточним постом, консолі 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:

    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(). Це робиться так:

    get_version() );
    $this->loader->add_action( ‘the_content’, $public, ‘display_post_meta_data’ );
    }

    Викличемо цю функцію з конструктора класу. Наступним рядком після $this->define_admin_hooks(); додамо $this->define_public_hooks();.

    Якщо все було зроблено правильно, ви зможете активувати плагін і побачити в кожному пості ті ж метадані, які відображаються в консолі:

    Відображення метаданих в пості у WordPress

    Підсумки

    Як ми вже говорили, показувати метадані користувачеві – не найкраща думка. Тим не менш, на даному прикладі ми вивчили нові функції WordPress з використанням вже знайомого нам коду.

    Таким чином, користь від сьогоднішнього уроку двояка:

    • з одного боку, ми зміцнили свої навички і повторного використання коду;
    • а з іншого – засвоїли на практиці, що показувати внутрішні дані системи в інтерфейсі може бути не естетично і навіть небезпечно.

    Зрозуміло, ми рекомендуємо вам встановлювати даний плагін тільки для самонавчання, а не на готовому, публічно доступному сайті. Іншими словами, використовуйте цей код на свій страх і ризик.

    Переклад статті «How To Display Post Meta Data on a WordPress Post» був підготовлений дружною командою проекту Сайтостроение від А до Я.

    ОСТАВЬТЕ ОТВЕТ

    Please enter your comment!
    Please enter your name here