Ассоциация метаданных WordPress: связанные объекты

На данный момент мы рассмотрели, как создавать объекты в плагине (что, как мы уже говорили, является просто модным словом для другой конкретной идеи). А именно, у нас есть пользователь и пользовательский тип записи или книга. И здесь мы начинаем брать две отдельные сущности, объединять и работать с тем, что мы назовем ассоциацией метаданных WordPress.

Но перед этим важно понять два типа метаданных, с которыми мы будем работать, и два способа (или три способа, в зависимости от того, как вы на это смотрите) того, как мы можем связать метаданные.

Как и в случае с остальными сообщениями в этой серии, это не означает глубокого погружения в понимание каждой из таблиц или подробного изучения каждой функции API. Вместо этого мы рассмотрим, что доступно, применим их и оставим более мелкие детали для будущих сообщений (или, возможно, для обсуждения в комментариях).

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

Метаданные не являются эксклюзивными для WordPress. Вы, наверное, знаете это. И это часто определяется как :

Информация об информации или данные о данных.

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

• метаданные комментариев,
• опубликовать метаданные,
• термин метаданные,
• и пользовательские метаданные

И все это доступно «из коробки».

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

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

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

В нашем примере мы будем использовать одну или обе из следующих двух таблиц:

1. wp_postmeta
2. wp_usermeta

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

Во-вторых, мы будем использовать соответствующие функции 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-интерфейсы метаданных настолько просты и последовательны в работе, работать с ними несложно. Для каждого из них обычно требуется как минимум два из следующих действий:

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

Что касается того, какой идентификатор и какой ключ вы выберете, часто зависит от вашей реализации, как мы видели.

До этого момента мы рассмотрели, как создать одностороннюю ассоциацию. Двусторонняя ассоциация ничем не отличается. Просто вместо того, чтобы сообщать одному объекту о другом, мы сообщаем обоим объектам о другом:

<?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 вместе с работающим плагином для изучения. Если вы заинтересованы в этом, подпишитесь на список рассылки здесь, и я обязательно дам вам знать, когда он будет готов; в противном случае используйте информацию из серии, чтобы двигаться вперед и создавать что-то стоящее

Хочу больше?

Сообщения серии

1. Ассоциация метаданных WordPress: как это сделать
2. Программное создание пользователей WordPress
3. Типы записей WordPress: абстракция для сущностей
4. Ассоциация метаданных WordPress: связанные объекты