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


Оглавление (нажмите, чтобы открыть):

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

25 просмотра

1 ответ

406 Репутация автора

У меня есть мета записи с именем car_code, созданная в ACF, и мне нужно отобразить значение car_code в зависимости от идентификатора записи внутри $ d. Я застрял с этим кодом: $ ); $ d должен отобразить 1101 для меня, чтобы получить значение car_code.

Мне нужен дисплей, как это: CODE1, CODE2, CODE3

Ответы (1)

плюса

406 Репутация автора

Я только что получил это! Мне нужно было добавить [0], чтобы получить значение из get_post_meta ().

WordPress — Вывод основных метаданных (просмотры, автор, дата, и т.д.)

Приветствую друзья, в данной записи я решил собрать все самые основные метаданные которые необходимо время от времени или прикрутить к какой-то из тем, или же отобразить при создании того или иного решения. На данный момент список метаданных для вывода в WordPress не полный, но он будет пополняться время от времени. Основная цель данной записи собрать все необходимые для вывода метаданные.

Вывод количества просмотров:

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

В файл functions.php (который находится в корне темы WP) добавляем код:

В коде указанном выше, имеется 2 функции:

1 — функция производит фиксацию просмотров записи

2 — функция отображает количество данных просмотров

Остается только вставить код для отображения результатов работы данных функций.

Функцию которая будет фиксировать просмотры необходимо добавить в файл который будет запускаться при каждом просмотре в основном это single.php, page.php, index.php или им подобные:

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

Также имеется код который отобразит в админ панели блога количество просмотров записей, в отдельной колонке (которая появится после применения кода ниже):

Вывод даты:

1. Отображение даты в формате установленном в настройках WordPress:

2. Отображение даты в формате 2020-07-23 + обернем дату в тег

Метаданные в таксономиях без использования плагинов

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

Шаг 1. Создание таблицы в базе данных

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

Ну что же, похоже, что единственный выход — это создание собственной таблицы в БД, наподобие wp_postmeta .

Вообще назвать нужно её wp_termmeta (естественно префикс может быть другим), иначе стандартные вордпрессовские функции по работе с метаданными у нас просто не будут работать.

Есть два способа создания таблицы:

  1. Лезем в phpMyAdmin и создаем там.
  2. Через SQL-запрос, который можно задействовать прямо в коде.

Способ 1. Создание таблицы в базе данных через phpMyAdmin

Открываем phpMyAdmin, выбираем базу данных своего сайта, затем нажимаем на ссылку . Настройки выставляем примерно следующие, одним словом ориентируемся на таблицу wp_postmeta .

Способ 2. Использование SQL-запроса для создания таблицы


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

После того, как таблица будет создана, можно будет перейти к следующему шагу.

Шаг 2. Универсальное решение по добавлению настроек — использование PHP класса

Реально — использование готового класса это круто и легко. Вы на лету сможете создавать столько настроек в таксономиях, сколько захотите.

И я дам вам готовый класс с некоторыми базовыми полями: (текстовый и чекбокс), if ( isset ( $param [ ‘desc’ ] ) ) echo ‘

‘ ?>

break ; > > ?>

> > /* * Функция сохранения значений полей */ function save ( $term_id ) < foreach ( $this ->options [ ‘args’ ] as $param ) < if ( isset ( $_POST [ $this ->prefix . $param [ ‘id’ ] ] ) && trim ( $_POST [ $this -> prefix . $param [ ‘id’ ] ] ) ) < update_metadata ( 'term' , $term_id , $this ->prefix . $param [ ‘id’ ] , trim ( $_POST [ $this -> prefix . $param [ ‘id’ ] ] , » ) ) ; > else < delete_metadata ( 'term' , $term_id , $this ->prefix . $param [ ‘id’ ] , » , false ) ; > > > >

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

Вот в принципе и всё. Я написал только про самое основное.

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

По теме

Впервые познакомился с WordPress в 2009 году. С 2014 года меня можно встретить на WordCamp по всему миру — официальной конфе по WordPress, иногда там выступаю, но с 2020 выступаю только на тех, которые сам организовываю. Также периодически школа Epic Skills и LoftSchool приглашают меня вести у них уроки/вебинары.

Если вам нужна помощь с вашим сайтом или может даже разработка с нуля — пишите мне.

Комментарии 11

Здравствуйте Михаил! У вас замечательный и полезный сайт! Я изучаю программирование сама и столкнулась с проблемой, которую никак не могу реализовать. Мне нужно написать плагин для WordPres с помощью которого можно будет реализовывать схему для страниц и постов WordPress в админке которая добавляет метабокс на страницу в котором можно задавать: название услуги\товара, описание услуги\товара, изображение услуги\товара, цену услуги\товара, валюту услуги\товара так же плагин создает виджет который выводит указанные данные если они заданы для страницы на которой он вызывается. если не заданы, то просто не выводит виджет на этой странице
так же плагин создает шорткод который можно вставить в текст страницы и который будет выводить те же данные в виде блока. (шорткод принимает значение в виде id записи\поста, если значение на задано, то выводит данные той записи из которой вызван). Вы не могли бы как будет время создать пост на эту тему ? Заранее спасибо

Как к этим данным потом обращаться из кода?

В версии WP 4.3 не работает.
Выяснил, что _get_meta_table отдает false и соответственно прекращается работа функции update.

False отдает из-за того, что в $wpdb нет объекта termmeta. Решил добавлением public $termmeta; в wp-includes/wp-db.php

Понятно, что при обновлении WP слетит всё. Может есть какое-то решение?

Спасибо за замечание!
Попробую доработать код.

Работа с WordPress Metadata

Привет читателям. Прежде всего, наша сегодняшняя тема заинтересует WP разработчиков начального и среднего уровней, а также всех тех, кто желает поближе познакомиться с метаданными WordPress (WordPress Metadata) и научиться их использовать. Приступим.

Что такое метаданные?

Часто можно услышать, что метаданные – это информация об информации, и это не самое плохое определение, так как оно очень близко к истине. Но, что такое метаданные в контексте WordPress? Чтоб ответить на этот вопрос, важно понять, что WordPress предлагает 4 типа метаданных:

  • Метаданные записи (Post Metadata)
  • Метаданные пользователя (User Metadata)
  • Метаданные комментариев (Comment Metadata)
  • Метаданные термов (Term Metadata).

Каждый из этих типов метаданных тесно связан с более крупным родственным элементом системы, к примеру, метаданные записи имеют непосредственную связь с WordPress-записями, страницами и пользовательскими типами записей. В то время как, метаданные комментариев – это вся дополнительная информация, которая связана с комментариями, оставленными пользователями. Также можно сказать, что метаданные термов (самая новая для WordPress форма метаданных) имеют непосредственную связь с таксономией и термами. Мы обсудим каждый из этих типов метаданных позже.

1.Метаданные записи

Бесспорно, записи – это самый знаковый и узнаваемый элемент WordPress. Также стоит отметить, что остальные метаданные тоже связаны с записями. Например, метаданные пользователей связаны с записями, потому что та или иная запись была написана пользователем.

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

Если вы посмотрите на таблицу WordPress post meta (в вашей базе данных представлена таблицей wp_postmeta), вы увидите, какой шаблон соответствует конкретной записи. Вы, также, увидите файлы, которые относятся к определенной записи. Кроме того, вы можете найти более подробную пользовательскую информацию, которую разработчик связывает с записью.

Таким образом, если мы научимся работать с метаданными, то сможем увеличить объем информации, которая относится к записи.

2. Метаданные пользователя

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

Мастер Йода рекомендует:  Что нужно изучить, чтобы быть востребованным

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

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

3. Метаданные комментариев


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

Интересно, что сразу после первичной установки WordPress уже имеет пустое поле для такой информации:

4. Метаданные термов

Чтоб понять, как работает это тип метаданных вам нужно знать, как работают таксономии и термы, а также понимать какая между ними существует взаимосвязь.

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

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

WordPress-хук для редактирования метаданных поста перед отображением страницы редактирования поста

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

Я смотрел на hook-post.php, но это вызвано до того, как сообщение загружено (если я это правильно понял), поэтому идентификатор сообщения и метаданные являются нулевыми. Я пробовал другие крючки, но я не смог выполнить эту работу.

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

Пример: цена = 10 в базе данных, но я хочу, чтобы она была Price = 15, когда она отображается на странице редактирования после публикации.

Любые ссылки, советы и идеи очень ценятся. 🙂

Как удалить/добавить пост в WordPress и его метаданные с помощью SQL запроса?

Тимур Туз: у вас какая задача? добавить большое количество постов, так?
Через wp-cli это сделать гораздо легче и быстрее, чем придумывать sql запрос или писать код под аякс запрос.

берете, например, вот это
wp-cli.org/commands/post/create
скармливаете туда готовый файл
получаете кучу добавленных постов постов

Тимур Туз: оно будет работать быстрее стандартного интерфейса WP как минимум по тому, что не будет грузить этот самый интерфейс.
Посмотрите исходный код, там видно что и как оно делает
https://github.com/wp-cli/wp-cli/blob/master/php/c.

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

Тимур Туз: вроде ж написал, если вставлять своим sql запросом, не будет срабатывать очень много чего. Что плохо.

Если вам это не критично, сложно разбираться с wp-cli, не умеете добавлять что-то в базу sql запросами, но прям очень хочется именно sql запросом добавлять, сделайте так:
откройте phpMyAdmin,
зайдите там в вашу базу, в таблицу wp_posts,
там заполните нужные поля кроме ID,
нажмите ok, оно вам вставит один пост.
И напишет, какой запрос оно сделало, чтоб вставить этот пост.

Копируйте этот запрос, потом подставляйте свои данные, выполняйте его повторно.

Удалить мета данные дата автор сайт WordPress

Привет! Мы продолжаем разбирать самые интересные и самые полезные плагины для сайта WordPress! Сегодня вы узнаете как можно очень просто и быстро удалить со своего сайта мета данные – автора и дату записи и страницы. У вас будет два способа удаления мета данных, с помощью CSS и с помощью PHP. В конце записи я объясню как действуют данные методы.

Установить плагин WP Meta and date remover вы сможете прямо из админ-панели WordPress. Перейдите на страницу: Плагины – Добавить новый , введите название плагина в форму поиска, нажмите Enter, установите и активируйте плагин.

После установки и активации плагина, мета данные будут автоматически скрыты, то есть вам ничего не нужно настраивать. В настройках вы сможете отключить CSS или PHP удаление данных. До активации плагина:

После активации плагина:

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

Далее, перейдите на страницу: Настройки – WP meta and Date Remover . Здесь вы сможете выбрать способ удаления мета данных, автора и дату поста или страницы.

– Disable PHP removal, с помощью php вы полностью удаляете данные, даже из исходного кода, чтобы поисковые системы не могли их индексировать. Поставьте здесь галочку, чтобы отключить PHP удаление данных.

– Disable CSS removal, с помощью CSS, более простой метод, скрывает только с сайта, а в исходном коде данные по прежнему отображаются и доступны для индексирования. Поставьте здесь галочку, чтобы отключить CSS удаление данных.

– Customize CSS, оставьте по умолчанию.

Остались вопросы? Напиши комментарий! Удачи!

Как работать с метаданными пользователя WordPress

Russian (Pусский) translation by Sergey Zhuk (you can also view the original English article)

В предыдущей статье мы обсудили работу с метаданными публикации в WordPress с использованием предоставленных API. Мы также рассказали о различных инструментах, идеях безопасности и о том, что потребуется для настройки среды, в которой будет работать код, который будет представлен в учебном пособии.

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

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


Пользовательский мета-API WordPress

Напомним ранее в этой серии, WordPress определяет метаданные следующим образом:

Метаданные обрабатываются с помощью пар ключ/значение. Ключ — это имя элемента метаданных. Значение — это информация, которая будет отображаться в списке метаданных для каждой отдельной записи, с которой связана информация.

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

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

Работа с API пользовательских метаданных

Рассматривая WordPress Post Meta API, мы рассмотрели и использовали следующие функции:

  • add_post_meta
  • update_post_meta
  • get_post_meta
  • delete_post_meta

Да, среди них есть свои особенности, особенно это касается того, как работают add_post_meta и update_post_meta , а также различные способы работы get_post_meta и delete_post_meta , и API-интерфейсы, которые мы собираемся изучить, будут работать одинаково.

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

Если вам интересно, я буду использовать следующий набор инструментов:

Обратите внимание, что метаданные пользователя будут храниться в таблице базы данных wp_usermeta , поэтому мы будем ссылаться на них на любых снимках экрана базы данных. В отличие от исходной таблицы метаданных, в таблице метаданных пользователей фактически есть некоторые данные.

Это связано с некоторыми данными, хранящимися на экране профиля пользователя:

Тем не менее API позволит нам записать нашу собственную информацию в таблицу. Итак, сказав это, давайте посмотрим, как работать с функциями, предоставляемыми WordPress.

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

Добавление метаданных пользователя

Вы можете найти ссылку на функцию add_user_meta в Codex. Определение функции примерно настолько сжато, насколько это возможно:

Добавить метаданные в запись пользователя.

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

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

Независимо от того, как вы это делаете. Однако вот что: помните, как написание метаданных для сообщения с помощью функции add_post_meta приводило к тому, что несколько строк могли быть записаны с использованием одного и того же ключа?

То же самое можно сделать с помощью add_user_meta . Однако функция API принимает необязательный четвертый параметр, независимо от того, должно или нет вводимое значение быть уникальным или нет.

Неуникальные значения

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

Код для этого будет выглядеть так:

Обратите внимание, что мы используем ту же стратегию, что и ранее в этой серии:

  1. Мы подключаемся к the_content .
  2. Мы проверяем, находимся ли мы в сообщении Hello World.
  3. Если это так, мы добавляем пользовательские метаданные.
  4. Мы возвращаем $content в WordPress.

С помощью этого кода и сообщения Hello World, загруженного в ваш браузер, обновите страницу несколько раз.

После этого итоговая таблица базы данных будет выглядеть так:

Как я уже сказал, он очень похоже на то, как работает API метаданных поста.

Уникальные значения

Используя интерфейс базы данных, удалите созданные строки или выберите новый ключ (возможно, что-то вроде instagram_username ). Я собираюсь удалить строки.

Мастер Йода рекомендует:  Что может РНР

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

Во-первых, укажите уникальное значение для метазначения (или третьего аргумента) в вызове функции. Обновите страницу несколько раз, а затем взгляните на базу данных. Она должен выглядеть примерно так:


Обратили внимание, что интересно? Есть еще несколько значений, но они все одинаковые.

Попробуйте несколько раз изменить аргумент meta value, а затем взгляните на базу данных и вы увидите что-то вроде этого:

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

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

Обновление пользовательских метаданных

Аналогично тому, как работает Post Meta API, функциональность обновления работает следующим образом:

Обновление метаполя пользователя на основе идентификатора пользователя. Используйте параметр $prev_value, чтобы различать метаполя с одинаковым ключом и идентификатором пользователя. Если метаполя для пользователя не существует, оно будет добавлено.

При работе с этой функцией полезно рассматривать ее в двух сценариях:

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

В первом случае это помогает предоставить $prev_value , потому что вы сообщаете WordPress, какое значение должно предназначаться для обновления.

Когда мы добавили метаданные

Например, предположим, что наша база данных выглядит так же, как она была показана ранее в учебнике:

И мы хотим обновить записи, которые имеют предыдущее значение https://twitter.com/tommcfarlin/ . Для этого мы обновим код, который выглядит следующим образом.

И тогда обновление базы данных будет выглядеть так:

Обратите внимание, что это обновляет все значения, связанные с этим мета-ключом. Конечно, это только одна функция.

При добавлении новых метаданных

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

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

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

В этом случае мы сделаем следующее:

И это приводит к записи следующей записи в базу данных:

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

Тогда, если бы мы хотели когда-либо изменить это значение, мы бы обновили метазначение, связанное с указанным мета-ключом, и он обновил бы эту единственную запись.

Получение пользовательских метаданных

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

Но как насчет мета значения?

Помните, когда мы получаем информацию, нам нужен только идентификатор пользователя и мета-ключ, так как это идентификационная информация для определенного значения.

Но что произойдет, если разработчик имеет несколько записей для одного ключа? Более конкретно, что, если они использовали функцию add_user_meta , как мы сделали выше, и имеют несколько записей?

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

Получение всех записей

Предположим, что мы работаем с тем же набором данных, что и в предыдущем уроке. То есть, у нас есть несколько записей для учетной записи пользователя Twitter. Напомним, что база данных выглядела так:

Чтобы получить всю эту информацию из базы данных и отобразить на экране, мы использовали бы следующий код:

Предполагая, что все прошло хорошо, вы должны увидеть что-то вроде этого в верхней части вашего сообщения Hello World:

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

Получение одиночной записи


В случае, когда вы хотите получить одну запись, вы можете передать true как последний параметр функции. Это приведет к извлечению первой записи, созданной в строковом формате.

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

Обратите внимание, что если вы используете update_user_meta и не указываете true в качестве последнего параметра, вы получите массив с одним индексом, переданный вам.

Таким образом, если вы ищете строковое представление информации, всегда передавайте значение true .

Удаление пользовательских метаданных

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

Из сопроводительной страницы Codex:

Удалите критерии сопоставления метаданных с пользователем. Вы можете соответствовать на основе ключа, или ключа и значения. Удаление на основе ключа и значения предотвратит удаление повторяющихся метаданных одним и тем же ключом. Это также позволяет удалить все ключи сопоставления метаданных, если это необходимо.

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

Удаление нескольких записей

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

Здесь у нас есть несколько записей. Чтобы удалить записи с одним и тем же ключом, мы используем единственный вызов функции delete_user_meta и передаем идентификатор пользователя и мета-ключ.

И если вы обновите информацию в таблице базы данных, вы заметите, что все записи были удалены:

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

Единая запись

Если, с другой стороны, у вас есть одна запись для удаления, то вам нужно три части информации:

  1. Идентификатор пользователя
  2. Мета ключ
  3. Мета-значение

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

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

В нашем примере мы занимаемся только удалением второго значения. Для этого мы будем использовать следующий код:

А затем, если вы обновите свою базу данных, вы увидите следующее (или нечто подобное):

Приятно, когда API выполняет то, что вы ожидаете.

Полный исходный код

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

Кроме того, не стесняйтесь добавлять это в файл, который мы создали в предыдущем уроке. Именно это я и делал, когда работал над примерами; Однако вы должны быть осторожны при работе с файлом, чтобы соответствующие вызовы add_action устанавливались на основе того, что вы хотите сделать.

Заключение

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

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

Конечно, это все еще оставляет нам метаданные, связанные с таксономиями. Из-за природы таксономий, терминов и API-интерфейсов мы рассмотрим их в последующих сериях.

А пока продолжайте экспериментировать с кодом, представленным в этой статье. Помните, что он предназначен только для демонстрационных целей и не должен выполняться в боевой среде.

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

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

В то же время, если вы ищете другие утилиты, которые помогут вам пополнить свой растущий набор инструментов для WordPress или код для изучения и стать более сведущими в WordPress, не забудьте посмотреть, что у нас есть в Envato Рынок.

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

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


Создание метабоксов в WordPress

Специфичные свойства поста, вносимые в структуру сайта вашим плагином, настраиваются с помощью метабоксов. Это — панели, содержащие все необходимые элементы настройки. Располагаются они на экранах редактирования.

Мастер Йода рекомендует:  Облачные технологии — всё по этой теме для программистов

Без метабокса не обойтись, когда новые свойства
* задействованы в большинстве постов;
* имеют жёсткие ограничения (напр., числа конкретного формата);
* трудно или неудобно вводить в виде строк (напр., значения из списка);
* взаимосвязаны друг с другом и являются одним целым.

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

Заготовка

Для экспериментаторских целей создадим простейший плагин, Состоять он будет из одного скрипта. Назовём его metatest.php и поместим прямо в wp-content.

Вот минимум, необходимый для появления метабокса на странице редактирования записи после активации плагина:

В момент, когда следует создавать собственные метабоксы, активируется хук add_meta_boxes. Мы привязали к нему функцию metatest_init, создающую бокс ‘MetaTest-параметры поста’ на боковой панели экрана редактирования записи. Содержимое его формирует функция metatest_showup. Результат расположился между боксами «Миниатюра записи» и «Метки»:

Всю работу здесь выполняет функция add_meta_box. Определение её выглядит так:

Внешний вид и содержимое задаётся тремя первыми аргументами: $id — идентификатор метабокса, $title — заголовок, $callback — функция, выдающая содержимое метабокса.

При формировании экрана идентификатор $id даётся секции, содержащей метабокс. Идентификатор галочки, задающей отображение бокса и расположенной в настройках экрана, формируется как «<$id>-hide».

Это может быть полезно при установке стилей или при использовании в скриптах.

Все остальные аргументы опциональны.

Следующие три из них определяют расположение: $screen — экран редактирования поста конкретного типа, $context — положение на этом экране, $priority — приоритет в отношении боксов, расположенных на том же экране и в том же контексте.

Значение аргумента $screen — это, по сути, тип постов, страница редактирования которых имеется в виду. Из стандартных, которыми WordPress владеет изначально, это ‘post’ (запись), ‘page’ (страница) и ‘attachment’ (медиафайлы и прочие вложения). Если значение не задано (или равно null’ю), метабокс будет присутствовать на всех экранах вне зависимости от типа редактируемого поста.

Положение, задаваемое в $context, может быть одним из следующих: ‘normal’ — основные элементы редактирования — верхняя часть центрального столбца; ‘advanced’ — дополнительные элементы — нижняя часть центрального столбца; ‘side’ — боковая панель, экран должен иметь два столбца. После ручного изменения WordPress запоминает положение метабокса и игнорирует заданные в add_meta_box умолчания. Поэтому, для ознакомления с размещением, можно добавить ещё три таких же бокса в различные контексты:

Аргумент $priority задаёт приоритет размещения панели по отношению к остальным. Чем выше приоритет, тем раньше отрисуется панель. Возможные значения приоритета, по убыванию: ‘high’, ‘core’, ‘default’, ‘low’.

В $callback_args передаётся произвольный параметр для функции $callback. Она принимает два аргумента: редактируемый пост (экземпляр класса WP_Post) и информацию о метабоксе. Информация содержится в массиве, ключи которого почти одноимённы с аргументами add_meta_box: ‘id’, ‘title’, ‘callback’ и ‘args’. Значение $callback_args помещено в ‘args’:

Передать несколько аргументов можно в виде массива

Внутри функции выражение

поместит переменные $varN в текущую область видимости.

Метаданные

Одна из основных задач метабокса — редактирование связанных с постом данных. Аналогичную же задачу выполняет и панель «Произвольные поля», но поля, имена которых начинаются с символа подчёркивания, ею игнорируются. Это следует помнить, чтобы уберечь данные от бесконтрольных изменений.

Формирование полей ввода и вывод имеющихся значений (или значений по умолчанию) возлагаются на функцию рисования метабокса. Информация извлекается из базы данных и помещается в поле ввода:

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

Функция сохранения

Отредактированная информация приходит от пользователя по нажатию им кнопки «Сохранить» или «Опубликовать/Обновить». Получив её, WordPress активирует хук ‘save_post’. К нему следует привязать функцию, которая проверяет и пишет метаданные в БД:

Первый (и, в данном случае, единственный) аргумент функции — идентификатор сохраняемого поста. Сам сохраняемый пост можно получить либо вызовом get_post($postID), либо вторым аргументом:

В этом случае количество принимаемых аргументов следует задать явно в четвёртом параметре add_action:

В качестве предпоследнего параметра — приоритета выполнения нашей функции — взято его значение по умолчанию (из wp-includes/plugin.php).

Действие ‘save_post’ выполняется с двумя аргументами: идентификатором поста и самим постом в виде экземпляра класса WP_Post. Поэтому в большем количестве аргументов смысла нет.

Функция metatest_save немного сложнее, чем остальные в нашем плагине. План её выглядит так:
* проверяем наличие информации от нашего метабокса;
* проверяем принимающий её пост;
* убеждаемся в подлинности её источника;
* контролируем корректность данных и устраняем потенциально опасные последовательности;
* наконец, сохраняем чистую информацию в БД.

Проверки

Вся присланная пользователем информация находится в глобальном массиве $_POST. Но поля наших метаданных в нём по разным причинам может не быть: при автосохранении, сохранении поста другого типа, при создании пустых постов во время формирования экрана редактирования, и т.д. Тест на его наличие довольно прост:

Если поля нет — выходим.

С целевым постом связана пара существенных моментов.


Момент первый — ревизии. Каждая новая редакция поста вытесняет его предыдущее содержимое в ревизию — дочерний, неизменяемый пост. При этом активируется ещё один ‘save_post’, уже с идентификатором ревизии. Таким образом, функция metatest_save будет вызвана дважды, причём единственное отличие в вызовах — значение $postID.

Владельцем метаданных является пост. Поэтому сохранение ревизии должно игнорироваться:

Функция wp_is_post_revision возвращает истину, если идентификатор, переданный в аргументе, принадлежит ревизии.

Второй момент — автосохранение. Происходит регулярно при редактировании поста, по умолчанию — каждые две минуты. Информация при этом присылается неполная — только та, что касается текста поста. Обычно в этом случае хватает проверки на наличие данных в $_POST. Но так как в будущих версиях (с 3.6) обещана принадлежность метаданных ревизиям, и так как поведение WordPress сильно зависит от плагинов, проверкой на автосохранение пренебрегать не стоит.

Автосохранение, создаваемое для поста — вид ревизии. В ответ на его идентификатор функция wp_is_post_revision также вернёт истину. Но тут есть подводный камень: при автосохранении черновиков хук ‘save_post’ активируется с идентификатором самого поста, и эта функция не сработает.

То же можно сказать и о специализированной wp_is_post_autosave: она сработает только при автосохранении уже опубликованного поста:

Опираться в данном случае следует на константу DOING_AUTOSAVE, устанавливаемую в true функцией wp_ajax_autosave, вызываемую сервером при получении автосохраняемых данных. (Функция wp_ajax_autosave расположена в wp-admin/includes/ajax-actions.php). Соответствующий этому код может выглядеть, например, так:

Происходящее автосохранение также можно определить по значению $_POST[‘action’] == ‘autosave’.

Проверка подлинности источника основана на одноразовом коде, встраиваемом в форму к нашим полям ввода. Он помогает обезопасить сайт от атак вида CSRF. При таких атаках браузер авторизованного пользователя, выполняя код злоумышленника, производит действия с полномочиями этого пользователя. В данном случае — устанавливает собственные значения наших метаданных.

Установку надо поместить в код формирования тела метабокса:

Контроль корректности

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

Прежде всего следует проконтролировать корректность сохраняемых метаданных. Два условия должны выполняться:
1) данные приемлемы;
2) данные безопасны;

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

О безопасности метаданных в отношении БД позаботится функция update_post_meta.

В отношении же сайта и пользователей безопасность данных определяется методами их применения. Не должно быть бесконтрольного HTML-кода, интерпретируемых произвольных JavaScript’ов, лазеек для злонамеренных URL, и т.д.

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

Сохранение

Запись данных — цель функции — производится одним вызовом:

Обратите внимание на символ подчёркивания, с которого начинается имя поля. Он делает поле недоступным из панели «произвольные поля».

Теперь применим всю изложенную теорию на практике. Заголовок плагина выглядит по-прежнему, добавлена только регистрация функции сохранения:

Функция рисования метабокса пополнилась формированием одноразового кода и выглядит теперь так:

А вот функция сохранения данных:

Результат, после сохранения строки «Hello, world!» и обновления страницы, должен выглядеть так:

Как видим, простейший метабокс создать несложно. Он опирается на два хука — ‘add_meta_box’ и ‘save_post’, и состоит из двух функций — вывода тела формы и сохранения данных.

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

Отображение метаданных типа пользовательских сообщений на главной странице WordPress

Я действительно надеюсь, что вы можете помочь здесь.

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

Я создал функцию в моем файле functions.php под названием «show_testimonials», и я вызываю это в своем файле index.php (я еще не разделял все на свои составляющие, например, header.php, footer.php и т.д.). Эта функция предназначена для отображения сообщений и метаинформации из пользовательского типа сообщений «Отзывы», но это не так.

Я вижу, что я переношу правильные метаданные в свою переменную $ meta.

Ниже приведен код функции show_testimonials.

Ниже приведен файл index.php.

Вот полный файл functions.php.

Здесь ссылка на сайт разработки, где вы можете увидеть, что я выводил правильные метаданные, используя ‘print_r ($ meta);’. https://dev.garethdaine.com/shiverschool

Надеюсь, кто-то может указать мне в правильном направлении. Приветствия заранее.

Добавить комментарий