Параметры произвольного поля WP. Как прописать Custom field label?

Question

[Александр Соболев]

Пишу ajax генерацию произвольных полей непосредственно пользователем "налету".
При создании, с использованием функции add_post_meta( $post_id, $meta_key, $meta_value, $unique ) мы вбиваем ид записи, ключ, значение и уникальность )
Вопрос: где, как, и куда вбивается label (Название)?
Если оно вбивается как ключ, то получается, что при желании пользователя отредактировать только название поля скрипт должен менять ключ ($meta_key) - а это по-сути создание нового и удаление текущего (меняемого) произвольного поля?
Или label произвольного поля как-то и куда-то прописывается?

Answer 1

[Игорь Воротнёв]

Label в данном случае это просто string, который вы отображаете в UI? То есть, каждое созданное поле будет иметь 2 "параметра" - label (то что отображается возле поля) и value (то, что ввели в поле)? Я тут вижу еще одно узкое место - когда вы доберетесь до полей других типов (number, radio, checkbox и тд), то у вас возникнут дополнительные "параметры" - тип поля и другие свойства. И вот тут все станет намного интереснее :)

Есть такой вариант - хранить в postmeta сразу 2 записи на одно поле:

fieldname => field value (значение)
fieldname_label => label value (лейбл)

Называть поля можно по разному. Например:

fieldname => value
_fieldname = label

В этом случае поле, которое начинается с подчеркивания, считается "скрытым" и "системным". Можно суффикс добавлять. Ну а дальше понадобится куча "подсистем", чтобы с этим удобно было работать.

А есть еще один вариант - хранить всю (любую) необходимую информацию в значении поля в виде сериализованного массива. Очевидный минус - по такому полю искать будет сложно (впрочем, внешнее индексирование с помощью того же Elastic Search проблему решит). В остальном - пихайте туда что хотите - значение поля, его лейбл, плейсхолдер, лимит символов и тд. Да хоть весь html целиком.

Comments

[Александр Соболев]

В любом случае при "буквенном" ключе понадобится перепись двух полей... Если только не записывать ключи в виде id -> id, и _id - что тоже те еще костыли))) Массив не удобен..
Неужели алгоритмы плагина ACF устроенны так сложно? Получается надежнее при активации плагина создавать свою таблицу в базе с id-записи, key, label и value ?

[Игорь Воротнёв]

Александр Соболев, ACF устроен проще (хотя, как посмотреть): поля и их свойства - это custom post type. Значения этих полей в postmeta пишутся 2мя записями - как раз в виде трюка с подчеркиванием. "Служебное" поле _fieldname содержит уникальный ID поля (не ID в базе в классическом понимании), по которому ACF и получает все свойства поля, а поле fieldname уже содержит само значение. Впрочем, у ACF есть и альтернативные подходы - сами поля можно хранить как JSON, так и в виде PHP-кода. Оба метода будут быстрее, плюс удобнее в разработке. Особенно последний, поскольку получается и кеширование опкода, и полноценное версионирование, и удобство работы, потому что можно прям на лету все генерить, при необходимости - php из php.