Повествование ведется от лица Йоста де Валка.
Внедрение нативной регистрации CPT (произвольных типов записей) в Gutenberg (и затем в ядро WordPress), — это настоящий прорыв. Ник Цекурас и Марин Атанасов прошли путь от публикации тикета до внедрения возможности в редактор менее чем за две недели. Именно в такой скорости WordPress нуждается больше всего. Те, кто жалуется, что это должно было появиться в версии 5.0, технически правы, но мы получили это сейчас, что тоже хорошо.
Скептики в статье Рэй Мори (Джонатан Дерозье, Брэд Уильямс, Паоло Таяни) не ошибаются, задаваясь вопросом, является ли это территорией плагинов. У CPT UI более миллиона активных установок. Есть веские основания полагать, что ядро не должно конкурировать с плагинами в этой области.
Однако я не согласен. Моделирование контента — это основополагающий принцип. Задача CMS в 2026 году — позволить вам описать структуру контента и обеспечить его вывод. Если вы не можете сделать это без установки плагина, то зачем вам тогда CMS? Так что: да, в ядре. Прекрасно.
Аргумент с количеством установок работает в обратную сторону. Миллион человек, устанавливающих один и тот же плагин для получения базовой функции, — это самый сильный сигнал о том, что эта функция должна быть в ядре, а не аргумент против её добавления. Та же логика применима и к SEO-инфраструктуре. Yoast, Rank Math, All in One SEO и множество более мелких плагинов существуют отчасти потому, что ядро никогда не включало в себя такой базовый функционал, как поле meta description. Стандартный примитив произвольных полей открывает простой путь к решению этой проблемы: метаописание становится зарегистрированным полем в записях и страницах, а не ключом postmeta от еще одного плагина.
Асимметрия
Произвольный тип записей без произвольных полей — это просто переименованная запись. Любая реальная модель контента, будь то товары, рецепты, события, недвижимость, подкасты или курсы, зиждется на метаданных. Заголовок и контент покрывают, возможно, 20% того, что редактору нужно заполнить. Остальные 80% — это поля: структурированные, часто вложенные, иногда повторяющиеся, почти всегда со своими собственными требованиями к UI.
Именно поэтому Advanced Custom Fields (ACF) имеет более 2 миллионов установок. Именно поэтому существуют Meta Box, CMB2, Pods и десяток других. В ядре никогда не было решения для структурированных метаданных записей с грамотным UI редактора. В релизе 23.1 представлена ровно половина того, что нужно моделировщику контента: та половина, которая уже была самой простой.
Игорь Санс из WPSoul пошутил в X: «В 2035 году WP получит нативный пользовательский интерфейс для добавления произвольных метаданных». Это шутка. Серьезный подход заключается в том, что это реальный вопрос о текущей дорожной карте, и он заслуживает серьезного ответа.
Проблема контроля версий — это проблема ИИ
Мэтт Бек указал в статье Рэй на реальный регресс: новый интерфейс CPT хранит определения в базе данных, а не в файлах. Он прав, и синхронизация JSON в ACF была отличным выходом из ситуации: вы описываете свою модель контента в коде, делаете коммит, развертываете.
Решение проблемы, поднятой Беком, и ответ на мой вопрос «что по поводу произвольных полей?» сводятся к одному и тому же: декларативная конфигурация, которая хранится в файлах, а не в строках базы данных.
Как только ваша модель контента станет декларативной конфигурацией, одновременно будут выполняться три условия:
- Вы можете поместить ее в систему контроля версий.
- Вы можете детерминированно развернуть ее в разных средах.
- Агент ИИ может ее сгенерировать.
Последний пункт — это не просто маркетинговый ход. В 2026 году запрос «Мне нужен тип записей recipe с ингредиентами (список названий + количество + необязательный флаг), информацией о пищевой ценности (объект) и метками» должен представлять собой один промпт и файл конфигурации, а не занимать полдня работы с React. Сейчас в WordPress вы либо устанавливаете ACF и проходите пошаговые экраны, либо пишете собственный блок. Все это создает препятствия для ИИ-агентов, которые сегодня фактически проектируют сайт.
Новый критерий для определения того, что должно быть в ядре, больше не характеризуется вопросом: «Является ли это территорией плагинов». Теперь он звучит так: «Может ли агент настроить это от начала до конца без предварительной установки плагина»? Произвольные типы записей (CPT), добавляемые в ядро, хоть как-то проходят проверку; CLI или MCP-сервер могут вносить данные в базовые записи. Произвольные поля полностью проваливают тест.
Нижний слой хранения
Декларативная конфигурация в файлах — это половина решения. Другая половина — это то, что будет происходить с данными, которые генерируют эти поля. В прошлом месяце я писал о бессхемной модели данных WordPress: каждый фрагмент метаданных, независимо от типа, помещается в wp_postmeta как строка «ключ-значение», часто сериализованная. Если мы решим проблему со стороны редактора, не решив проблему со стороны хранилища, то мы получим очередной обходной путь. Каждому последующему потребителю (REST API, безголовые интерфейсы, ИИ-агенты) все равно придется восстанавливать структуру данных на выходе.
Решение должно охватывать весь процесс: типизированная конфигурация в файлах, типизированное хранилище в базе данных, типизированные ответы в REST-интерфейсе. WooCommerce уже доказал, что это осуществимо в экосистеме WordPress, с помощью своего High-Performance Order Storage. Произвольные поля — следующее очевидное место для применения того же подхода.
Кстати, это же решение открывает доступ к многоязычности. Типизированные, переводимые поля гораздо проще в использовании, чем перевод сериализованных блобов в wp_postmeta, и это одна из главных причин, почему WPML и Polylang до сих пор существуют как плагины.
Как выглядит хороший результат
Один из разработчиков нашей команды, Филип Илич, в прошлом месяце создал field-kit для EmDash. Это небольшой плагин, который отлично справляется с одной задачей: он прикручивает к типу полей json в EmDash полноценный интерфейс редактора, полностью настраиваемый через seed-config, без необходимости использования React. Филип уже работает над следующим дополнением, добавляющим visibleWhen, чтобы поля могли отображаться или скрываться в зависимости от значений других полей в той же записи.
Четыре виджета:
- object-form: встроенная форма для плоских объектов.
- list: упорядоченный массив с возможностью добавления/удаления/изменения порядка.
- grid: матрица из строк и столбцов.
- tags: ввод данных о чипе/теге.
Восемь примитивов подполей, используемых всеми виджетами: text, number, boolean, select, textarea, date, color, url.
Конфигурация поля выглядит следующим образом:
{
"slug": "ingredients",
"type": "json",
"widget": "field-kit:list",
"options": {
"itemLabel": "Ingredient",
"fields": [
{ "key": "name", "label": "Name", "type": "text" },
{ "key": "amount", "label": "Amount", "type": "text" },
{ "key": "optional", "label": "Optional", "type": "boolean" }
]
}
}
Вот и всё. Это JSON-файл. LLM может его создать. Конструктор сайтов может его прочитать. Удалите плагин, и базовые данные всё равно останутся чистым, корректным JSON в БД.
Здесь важны три свойства, и все они являются следствием одного и того же проектного решения:
- Декларативный подход. Конфигурация описывает структуру; для отображения редактора не требуется никакого кода.
- Компоновка. Виджеты и подполя можно комбинировать, поэтому небольшое количество примитивов охватывает большинство реальных контентных структур.
- Прозрачность структуры данных. Плагин не владеет вашими данными. Удалите его, и ваши записи всё равно будут обрабатываться.
Именно к такой структуре должно стремиться ядро WordPress.
То, о чём я прошу
В тикете проекта Gutenberg уже есть намек на это: «ввести выделенный REST-контроллер, переместить некоторые поля… в метаданные поста». Отлично. Давайте разовьем эту идею дальше:
- Стандартный примитив структурированных полей в ядре.
- Декларативная конфигурация, сохраняемая в файлах, а не в строках базы данных. Пользовательский интерфейс поверх этих файлов — это круто, синхронизация JSON в ACF уже показала, как это сделать, но фиксируется и развертывается именно файл.
- Небольшой набор компонуемых виджетов (список, объект, сетка, метки), охватывающий 80% случаев.
- Интерфейс, доступный для агента (REST, WP-CLI, в стиле Abilities), чтобы конфигурация не была заблокирована в wp-admin.
EmDash здесь не конкурент; это референс.
Мэтт Тейлор из Cloudflare отметил на WP Product Talk, что «странно», что CPT до сих пор нет в ядре. Он прав. В следующий раз, когда он скажет это о произвольных полях, он снова окажется прав.
Все это вполне можно реализовать в WordPress. Зачем наблюдать, как это делают другие? Команда, которая за четырнадцать дней превратила тикет в готовый код в плагине, думаю, сможет продвинуться и дальше. Дерзайте!
Источник: https://joost.blog
