Раніше ми розглядали концепції об’єктно-орієнтованого програмування (ООП) з точки зору початківця програміста. Метою цих статей було впровадити основні концепції ООП в PHP стосовно WordPress у вашу повсякденну практику веб-програмування.
Якщо ви не читали ці статті, можете познайомитися з ними, прочитавши підсумкову статтю циклу і, якщо знадобиться, пройшовши по посиланнях на більш ранні статті.
Однією з практичних робіт, спрямованих на закріплення принципів ООП, а також на вивчення функцій WordPress API, було написання плагін для WordPress.
Кажучи конкретніше, ми створили плагін, який дозволяє переглядати метадані, пов’язані з поточним постом, консолі WordPress:
Познайомитися з кодом плагіна, його описом і коментарями, а також завантажити його можна на GitHub.
З тих пір, як був написаний цей плагін, мене кілька разів запитували, як відобразити ті дані, які плагін виводить на консоль сайту, у його користувача частини.
Прийшла пора розширити наш плагін. Зокрема, додати йому функціональності, що дозволяє виводити метадані в сторінку, що відображає окремий пост. Ми обговоримо, як це можна зробити найбільш раціональним способом, використовуючи вже наявний код, а головне – в яких ситуаціях висновок мета даних може бути корисний.
Отже, приступимо!
Можливі наслідки модифікації плагіна
Перш ніж ми почнемо планувати конкретні дії, я думаю, необхідно пояснити, чому публікувати таку інформацію, як метадані посту, у користувача частини може бути гарною чи поганою ідеєю.
Я вважаю, що кожен розробник, який створює або розширює системи, що працюють з делікатними даними, повинен замислюватися про те, ким і як буде використовуватися його продукт ще до етапу проектування.
Іншими словами, необов’язково робити щось тільки тому, що ми можемо це зробити.
Погляд на метадані
Метадані, пов’язані з постом, що зберігаються в базі даних. Вони потрапляють туди з різних джерел: з ядра системи, з тим, з різних плагінів. І призначені метадані для використання тільки у відповідному коді і з вельми різноманітними цілями.
На ілюстрації, показує приклад роботи нашого плагіна, можна помітити поля даних, імена яких починаються з символу підкреслення, наприклад, _edit_lock і _edit_last, що зберігають числові значення. Це приклад метаданих, використовуваних ядром WordPress для управління станом посту.
Інші метадані можуть зберігатися темами і плагінами, і також призначатися для управління їх внутрішньою роботою в контексті конкретного посту.
В чому проблема?
Проблема в тому, що відображення всього цього в користувацькому просторі може давати останньому занадто багато інформації.
На наведеній нами ілюстрації користувач не бачить нічого суттєвого з точки зору безпеки, але це не означає, що так буде в будь-якому випадку. Навпаки, ймовірність того, що якісь плагіни будуть зберігати в метаданих приватну, не призначену для перегляду всіма користувачами інформацію, досить велика.
І навіть якщо відволіктися від проблем інформаційної безпеки, то для більшості відвідувачів блогу дані, відображувані нашим плагіном, можуть виглядати як шум або незрозумілий технічний жаргон, і тому ускладнювати сприйняття основного вмісту.
Саме тому я спочатку вирішив, що консоль WordPress – саме підходяще місце для відображення метаданих.
І, тим не менш, ми вирішили це зробити?
Так, але не тому, що показувати користувачеві метадані – це хороша ідея, а тому що сам процес вивчення негативних наслідків розширення плагіна буде корисний з точки зору подальшого навчання WordPress.
Ну, й тому, що деякі вміють вчитися лише на власних помилках. Загалом, це нормальний процес навчання.
Крім того, сам по собі досвід підтримки й розширення існуючого коду вельми корисний для початківців розробників.
Розширення обробника метаданих поста
Як і у всіх своїх навчальних статтях, я постараюся спочатку дати вичерпну інформацію про те, що і як ми збираємося робити, щоб у процесі написання та огляду коду нам не доводилося гадати і імпровізувати. Як цим системним архітекторам, нам необхідно заздалегідь мати чіткий план дій.
Якщо ви ще не ознайомилися з вихідним кодом, саме час зробити це.
Готові? Тепер – наш план:
Нічого особливо складного, чи не правда? Але уточнити напрямок дій було необхідно. Тепер приступимо.
Створення загальнодоступного каталогу
Маючи на увазі, що тема «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 з використанням вже знайомого нам коду.
Таким чином, користь від сьогоднішнього уроку двояка:
- з одного боку, ми зміцнили свої навички і повторного використання коду;
- а з іншого – засвоїли на практиці, що показувати внутрішні дані системи в інтерфейсі може бути не естетично і навіть небезпечно.
Зрозуміло, ми рекомендуємо вам встановлювати даний плагін тільки для самонавчання, а не на готовому, публічно доступному сайті. Іншими словами, використовуйте цей код на свій страх і ризик.
Переклад статті «How To Display Post Meta Data on a WordPress Post» був підготовлений дружною командою проекту Сайтостроение від А до Я.
