Асоціація метаданих WordPress: пов’язані сутності

Останнє оновлення Лис 9, 2022

Зміст

Асоціація метаданих WordPress

1 Таблиці метаданих

2 Асоціювання метаданих

Кінець

На цьому етапі ми розглянули, як створити сутності в плагіні (що, як ми вже сказали, є просто модним словом для іншої конкретної ідеї). А саме, у нас є користувач і власний тип публікації, або книга. І тут ми починаємо об’єднувати дві окремі сутності та працювати з тим, що ми називатимемо асоціацією метаданих WordPress.

Але перед тим, як це зробити, важливо зрозуміти два типи метаданих, з якими ми будемо працювати, і два способи (або три способи, залежно від того, як ви на це дивитеся) як ми можемо пов’язати метадані.

Як і в інших публікаціях у серії, це не означає глибоке занурення в розуміння кожної з таблиць або глибоке занурення в кожну з функцій API. Замість цього ми збираємося вивчити доступні матеріали, використати їх і залишити більш детальну інформацію для майбутніх публікацій (або, можливо, обговорень у коментарях).

Асоціація метаданих WordPress

Метадані не є ексклюзивними для WordPress. Ви напевно це знаєте. І це часто визначається як :

Інформація про інформацію або дані про дані.

І це гарний спосіб сказати. WordPress пропонує кілька різних таблиць бази даних, які ми можемо використовувати для надання інформації про певні інші типи об’єктів у WordPress. Ми збираємося використовувати пару з них пізніше в цій публікації, але досить сказати, що WordPress пропонує :

метадані коментарів,
метадані публікації,
метадані терміна,
і метадані користувача

І все це доступно з коробки.

Одна з таблиць метаданих WordPress.

API для кожного з них узгоджені, що теж приємно. Але, знову ж таки, до кінця цієї публікації ми будемо стурбовані лише кількома з них.

1 Таблиці метаданих

У нашому прикладі ми будемо використовувати одну або обидві з наступних двох таблиць:

Звичайно, у вашій установці вони можуть мати інший префікс, але суфікс той самий, і ви зрозуміли ідею.

По-друге, ми будемо використовувати відповідні функції API для зв’язування наших метаданих. Ми розглядатимемо їх у коді, коли будемо пов’язувати дані між нашим користувачем і користувацьким типом публікації (або нашим автором і нашими книгами, якщо ви хочете використовувати точнішу термінологію).

Тоді добре. Вся ця перша частина допису лише закладає основу для того, які частини основної інфраструктури WordPress ми збираємося використовувати. З огляду на все це, давайте подивимося, як ми можемо програмно перетворити цю річ на щось трохи більш корисне.

2 Асоціювання метаданих

Ідея асоціації метаданих WordPress звучить складніше, ніж насправді. Подумайте про це так:

Маючи дві таблиці, як ми можемо обмінюватися інформацією між двома сутностями, щоб одна знала про іншу?

Наприклад, враховуючи користувача, як ми можемо повідомити метадані користувача про метадані публікації. Або, навпаки, як ми можемо дозволити метаданим публікації знати щось про пов’язані метадані користувача?

На високому рівні ми справді робимо це: ми повідомляємо одній сутності про існування іншої та пов’язуємо це з іншою. Або це може піти іншим шляхом. Залежно від вашої реалізації, один може бути більш вигідним, ніж інший.

1 Односторонній

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

Таким чином, ми можемо налаштувати після того, як публікація створена, наприклад, якщо відповідний користувач знає про щойно створену публікацію :

<?php

// Using post title as the value, but it's just an example.
add_user_meta( $user_id, $post_id, $post_title );

Або, можливо, це означає, що повідомлення відомо про користувача:

<?php

// User user email address a value but just an example.
add_post_meta( $post_id, $user_id, $email_address );

Але як би ви не дивилися на це, асоціація йде лише в одну сторону.

І хоча стосунки розвиваються в одному напрямку, це не повинно бути саме так. Тобто обидві сутності можуть знати одна одну.

2 Двосторонній

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

певний ідентифікатор, з яким пов’язані метадані,
мета-ключ, який можна використовувати для пошуку інформації,
значення, яке зберігає інформацію, пов’язану з ідентифікатором і публікацією.

Вибір ідентифікатора та ключа часто залежить від вашої реалізації, як ми бачили.

До цього моменту ми розглядали, як створити односторонню асоціацію. Двостороння асоціація нічим не відрізняється. Це просто замість того, щоб одна сутність усвідомлювала іншу, ми інформуємо обидві сутності про іншу:

<?php

/**
 * Using this association will give you the ability to query for information 
 * both on posts and users and then work with the data accordingly.
 */
add_user_meta( $user_id, $post_id, $post_title );
add_post_meta( $post_id, $user_id, $email_address );

Але це рішення не слід приймати просто так. Натомість варто подумати про деякі причини, чому ви можете вибрати те чи інше.

Продумайте проблему

Коли справа доходить до вирішення подібних проблем, немає остаточного рішення в термінах «ви повинні остаточно підійти до цього [таким чином]», яким би способом це не було. Натомість ви повинні поставити собі запитання на зразок «що робить для найпростіший спосіб керувати цими даними?»

Наприклад, якщо ви в першу чергу зацікавлені в управлінні користувачами, тоді, можливо, все, що вам потрібно, це мати дані про метадані користувача про те, з якою сутністю вони пов’язані. Таким чином, коли користувача буде видалено, ви також обов’язково знайдете пов’язані з ним об’єкти в таблиці метаданих користувача та також видалите їх.

Подібним чином, можливо, одна й та сама функція буде працювати в обох напрямках. Тобто так само, як ви хочете переконатися, що після видалення користувача його або її дописи також видаляються, ви також можете видаляти користувача (або змінювати) щоразу, коли видаляється один із його дописів. І якщо це так, то двостороння асоціація дозволяє це зробити.

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

Кінець

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

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

Хочу більше?

Повідомлення серії

Джерело запису: tommcfarlin.com