Комментарии 24
В ней в формате JSON сохранены условия и значения.
a:12:{s:8:"location";a:1:
{i:0;a:1:
{i:0;a:3
{s:5:"param";s:13:"post_taxonomy";s:8:"operator";s:2:"==";s:5:"value";s:27:"product_cat:fruit";}
}
}
s:8:"position";s:6:"normal";s:5:"style";s:7:"default";s:15:"label_placement";s:4:"left";s:21:"instruction_placement";s:5:"label";s:14:"hide_on_screen";s:0:"";s:11:"description";s:0:"";s:18:"acfe_display_title";s:0:"";s:13:"acfe_autosync";s:0:"";s:9:"acfe_form";i:0;s:9:"acfe_meta";s:0:"";s:9:"acfe_note";s:0:"";
}Это же не JSON.
Верно. Это сериализованное значение - встроенная в php функция serialize()
Ошибку исправил. Вы правы, это сериализованный массив.
Он всех надурить решил! Это сериализованный массив!
Это не JSON, это сериализованный массив
Шел 2021-й год, в WordPress из коробки всё ещё нет минимально приемлемых кастомных полей для постов и разработчики вынуждены пользоваться платным плагином(из которого недавно выпилили пожизненную лицензию).
Есть же давным-давно https://wordpress.org/support/article/custom-fields/
минимально приемлемых
Не знаю людей которые считают нормальным расширять модели исключительно набором пар string=>string. Это нельзя типизировать для конкретного типа поста, доступ к этим полям предоставляется в виде четырех функций и одной формой на фронте. Если нужно как в туториале прикрепить жанр или оценку к фильму то сойдет, но если нужны вложенные структуры или повторения... придется покупать подписываться на ACF.
По-сути, все кастомные поля пользуют функционал вордпресса и они ничего не вносят в БД, просто создают функционал для управления тем, что уже имеется.
В примере я поставил понятные условия, для которых очень часто используются кастомные поля. Но, конечно, фантазии по использованию могут быть разные.
Проблема с которой я столкнулся - это вынести заполнение полей за пределы админ панели, при этом сохранив все условия применения. Внутри админки дописывать функционал не имеет смысла, там всё великолепно.
Есть платный https://www.advancedcustomfields.com/pro/ в котором есть масса разных полей.
О нем и речь в посте.
@Druj же имеет в виду, что подобная функциональность не помешала бы из коробки, однако, за 18 лет в вордпрессе до этого так и не дошло.
Наверное. Но у меня нет речи о том, что нужно добавить какие-то поля. Я вывожу заполнение полей во фронтенд и получаю из БД условия по которым эти поля будут получены. Этого нет ни в обычной версии, ни в версии "про".
Поэтому я разбираю как эти поля устроены.
У WordPress уже очень долго есть поддержка Metadata API, а также огромное количество плагинов для реализации дополнительных полей, начиная с ACF и заканчивая Carbon Fields и CMB2.
В случае с ACF нужно напомнить, что он есть как в платной, так и в бесплатной версии.
Что касается самого WordPress, то здесь нет ничего удивительного. Эта система создавалась, чтобы быть расширяемой. Если плагин делает свою работу очень хорошо, то зачем пытаться его повторить и добавить в ядро?
Ну так механизм произвольных полей в WP есть, ты можешь через update_post_meta() и get_post_meta() записать и получить любые произвольные поля. И минимальный интерфейс для этого в админке тоже есть. ACF делает ровно то же самое, но оборачивает это в свою дополнительную логику. Но самое важное, что делает ACF - это избавляет тебя от необходимости писать все эти метабоксы для заполнения этих полей в админке. Что, в принципе тоже можно сделать, но ACF дешевле, чем работа разработчика) $50 на покупку PRO версии в бюджет сайта заложить не проблема.
Да, у WP есть достаточно инструментов для того, чтобы добавлять и редактировать мета информацию. И да, действительно, ACF только использует тот же функционал. В этом нет ничего нового. Но иногда не хватает функционала, который есть в ACF и приходится поверх него писать свой, используя тот функционал, который он дает.
Т.е. я не предлагаю создавать поля и писать свой ACF, но в случае необходимости дописать функционал для него можно, для этого нужно понимать как поля устроены изнутри.
Для многих разработчиков такой задачи вообще может быть никогда не будет стоять.
А для большинства клиентов и версия PRO для их задач не нужна.
В Joomla уже давно это встроенная функция встроенная в саму CMS ? вообще непонятно почему все помешались на этом блоговом движке который по сути мало что умеет без дополнительных плагинов, которые в свою очередь сильно замедляют работу сайта когда их поставят в достаточном количестве, что бы сайт мог хоть что то кроме блога.
Не могу сказать конкретно по этому функционалу - может быть есть что-то лучше (имею ввиду в других CMS). Но если брать в целом, то лучше Wordpress я не видел CMS. У меня есть опыт разработки под Joomla, Opencart, Bitrix, работал с некоторыми мелкими CMS. Помимо широкого инструментария, Wordpress очень устойчивая система, множество возможностей управления контентом, организации взаимодействия плагинов. Т.е. при правильной организации плагина я могу предоставить возможности для другого разработчика управлять всем необходимым в моём плагине, встроится в процессы другого плагина без необходимости что-то там исправлять и т.п.
ACF - это банальный пример расширения возможностей. В ближайшее время планирую несколько статей по другим аспектам разработки под Wordpress - если ознакомитесь, возможно пересмотрите своё отношение. По моему опыту - Wordpress - лучшая CMS на сегодняшний день.
К сожалению, статья полна неточностей и не раскрывает сути вопроса.
Начнем с того, что данные хранятся или как обычный текст, или в сериализированном виде. Это совершенно иной формат чем JSON, который изначально поддерживается WordPress (да, именно так пишется название CMS). Единственное исключение здесь - это поле Google Maps. Там да, данные хранятся в виде JSON.
Вторая неточность - это место хранения данных. Metadata API поддерживает метаданные не только для записей, но и для пользователей, комментариев, и терминов таксономий (категорий). Отдельно тут стоят опции, поля виджетов, и т.д., которые хранятся в таблице с опциями (wp_options, обычно).
Третья неточность касается самого способа хранения. Неужели у автора не возникало вопросов почему для каждого поля создается ещё одно с описанием типа? Это по сути самый большой недостаток ACF.
Неужели не возникало желания посмотреть как хранят данные поля Repeater и Group? Там вообще все очень интересно. Для своих проектов я написал небольшой плагин, который исправляет эту проблему и просто серилизирует сложные объекты.
В общем, такое.
Возможно мы по разному с вами видим задачи этой статьи. Я не искал философии разработчиков ACF, моей основной задачей было разобрать устройство конкретно этого плагина - я это сделал.
По поводу того, что большинство данных в WP имеет Meta надстройку - да, это так, я это использую в разработках на своём уровне. Но это никак не влияет на то, как устроен ACF.
Со своей стороны скажу, что вообще вижу мало подобной информации, поэтому и написал статью. Она приземленная, она не ищет варианты, она просто рассказывает разработчику то, что он возможно не знает где найти.
И да, поддержу вас в том, что неплохо бы написать ещё информацию об устройстве других данных в WP - в том числе все Meta надстройки неплохо было бы описать. И виджеты, и сохранение Image, и типы полей. Но это всё уже цели для следующих статей. Пока я стартовал с простого устройства ACF.
В свое время пришлось отказаться от этого плагина, потому что он не поддерживает кэширование (redis/memcache). Оказалось, что есть замечательные бесплатные плагины, которые имеют такой же набор функциональности и лишены этого недостатка, но пришлось поискать.
Использую Carbonfields... Доволен как слон
Как устроены Advanced Custom Fields в Wordpress