Возможно, вы слышали об экспериментальной функции произвольных типов записей, которая появится в ядре WordPress — это один из множества вдохновляющих результатов проекта Radical Speed Month от Automattic.
Повествование ведется от лица Брайана Коордса.
Несколько недель назад я опубликовал свой прототип того, каким бы я хотел видеть моделирование контента, и было классно отметить, что команда Gutenberg развивает аналогичную идею. Сразу уточню: между моим прототипом и текущей разработкой нет никакой связи.
Этот эксперимент вызвал массу обсуждений: одни поддержали этот функционал, другие задались вопросом, зачем вообще произвольные типы записей нужны в ядре WordPress. Не будем забывать: произвольные типы записей являются базовой функцией WordPress уже более десяти лет. Разработчики могут создавать их с момента появления функции register_post_type() в WordPress 2.9, что случилось более пятнадцати лет назад.
Сейчас же ведётся работа над репозиторием Gutenberg по добавлению пользовательского интерфейса и слоя данных для произвольных типов записей.
Речь идёт не о разработчиках
Поскольку произвольные типы записей уже существуют и полностью расширяемы с помощью кода, добавление пользовательского интерфейса означает, что целевая аудитория этого нововведения — явно не разработчики. Да, многие конструкторы WordPress используют такие инструменты, как ACF или CPT UI, для удобства, но разработчики из агентств скажут вам, что они скрывают эту функциональность от конечных пользователей. Metabox осветили это в своем отличном ответном посте, но я не согласен с их выводом о том, что «текущая реализация слишком проста».
Да, произвольные типы записей играют значительную роль в создании и структурировании сайта. Это означает, что для их отображения в административной панели WordPress по умолчанию нам необходима упрощенная, удобная для пользователя версия. Мы не можем просто перенести существующие плагины в ядро, потому что эти плагины предназначены для другой аудитории: агентств, которым нужен детальный контроль и возможность настраивать параметры.
Если вам это нужно, просто прибегните к плагинам. Мы же говорим о другом. К сожалению, большая часть обсуждений в интернете сводится к тому, что люди переносят в эту тему другие претензии к WordPress (многие из которых обоснованы). Я думаю, это неправильный подход.
Abilities и API поверх UI
Сейчас для создания произвольных типов записей нужно писать PHP-код и развертывать его. Все это работает, но нам нужно пересмотреть свои представления о будущем WordPress. С появлением ИИ-агентов и таких инструментов, как WP-CLI и серверы MCP, нам нужны безопасные, программные способы взаимодействия с WordPress, не требующие написания кода.
Вы, вероятно, видели недавние опасения по поводу безопасности, связанные с тем, что плагины могут изменять вашу базу данных и писать исполняемый код, на что указывают такие проекты, как EmDash и другие. Если пользователи хотят создавать типы контента и прибегают к файловым менеджерам и плагинам для фрагментов кода, всё может быстро поломаться. Я бы предпочёл безопасный подход, основанный на пользовательском интерфейсе – который невозможно реализовать без API, Abilities и команд CLI.
Когда я создавал свой прототип для моделирования контента, я включил в демо-пример чат-агента специально для того, чтобы показать: вот что происходит, когда вы можете делать что-то через API. Агент, использующий WP-CLI или MCP, способен создавать типы контента, не затрагивая вашу файловую систему.
Произвольные поля и файлы конфигурации
Более того, для произвольных типов записей в действительности нужны и произвольные поля. Именно поэтому я намеренно использую термины «типы контента» и «моделирование контента». Произвольные типы записей — это функция, ориентированная на разработчиков, но моделирование контента — это то, к чему многие пользователи CMS, особенно на корпоративном уровне, привыкли, работая с такими платформами, как Sanity и Contentful.
Йост де Валк написал свой пост, согласившись с тем, что произвольные поля должны быть частью этого процесса — моделирование контента подразумевает совместную работу типов записей и полей в рамках единого пользовательского интерфейса. Но я хочу оспорить несколько других пунктов в его посте.
Во-первых, я не совсем согласен с призывом к использованию конфигурационных файлов. В последнее время я склоняюсь к отказу от лишних файлов. Подход «просто пишите PHP-код и используйте систему контроля версий для него» уже существует, а агенты отлично справляются с кодированием старой функциональности WordPress, которой уже десять лет. После нескольких лет работы с theme.json и десяти лет использования JSON-файлов синхронизации в ACF, я могу уверенно сказать, что меня вполне устраивает отсутствие JSON-конфигов в моей жизни.
WordPress следует двигаться в другом направлении — предоставлять людям, не являющимся разработчиками, возможность безопасно вносить изменения на свои веб-сайты. Именно эта мысль привела меня к желанию включить функционал «Future Revisions» в ядро.
Я понимаю, что аргумент заключается в необходимости убрать конфиги из базы данных, но я с этим не согласен. Я хочу, чтобы WordPress избавлял нас от необходимости в отдельных системах контроля версий и локальных средах разработки. Да, это важно для сложных сайтов, поддерживаемых разработчиками, но моделирование контента должно быть доступно не только разработчикам, но и опытным пользователям. Эти пользователи должны иметь возможность работать в своем продакшне. Нам нужно провести более четкую границу между пользователями и разработчиками в WordPress, и мы должны перестать требовать от опытных пользователей WordPress написания кода.
Также высказывались опасения по поводу структуры данных регистрации типов записей: в некотором смысле это мета-процесс — использование произвольного типа записи для управления вашими типами записей, — но именно поэтому он и работает. Привязка к существующей архитектуре WordPress дает множество преимуществ:
- Ревизии, отслеживание версий, планирование.
- Маршрутизация и административные экраны.
- Существующие хуки и фильтры ядра.
- Конечные точки REST API.
- Слой данных ядра.
И многое другое. Существует встроенный слой расширяемости, который пришлось бы перестраивать с нуля.
С другой стороны, я соглашусь с аргументом о том, что всем новым пользовательским интерфейсам на основе React в Gutenberg требуется большая расширяемость, но это также отдельная проблема, не связанная с данной конкретной функцией, и она характерна практически для всех аспектов новых компонентов административной панели WordPress.
Отдельные таблицы базы данных
Ещё одно предложение: зарегистрированные произвольные типы записей должны хранить контент в отдельных таблицах базы данных, а не в wp_posts.
Правильно это или нет, но это совершенно другая проблема, не связанная с добавлением нового пользовательского интерфейса. Её нужно решить для всех типов записей, обеспечить обратную совместимость и при этом сохранить все основные функции, команды, конечные точки REST API и возможности, которые предоставляют сами записи.
Мы видели, как WooCommerce решал эту проблему с помощью High Performance Order Storage. Это возможно, но сложно — большой объём данных, вопросы миграции, слои совместимости. Это масштабный архитектурный проект, независимо от того, существует ли пользовательский интерфейс для моделирования контента. Я понимаю аргумент, но я не уверен, что это окажет такое же прямое влияние на пользователей, как новый UI.
Этот проект направлен на внедрение моделирования контента в UI и обеспечение программного управления без написания кода. Архитектура базы данных не имеет отношения к этой цели.
Немного лицемерия с моей стороны
Ранее я жаловался, что каждый обсуждает в этой дискуссии свои собственные, не связанные с WordPress проблемы, но я не могу удержаться от того, чтобы не сделать то же самое. Поэтому я сразу скажу, что я тоже хочу более глубоких архитектурных изменений, и я настоящий лицемер, раз уж включаю это в обсуждение.
При создании произвольного типа записей у вас есть весьма ограниченные опции:
- Public: каждая запись получает свой собственный URL, плюс дополнительные страницы архива.
- Private: контент вообще недоступен для запросов в таких блоках, как Query Loop.
Но как быть, если вам нужно что-то среднее? К примеру, у вас есть коллекция часто задаваемых вопросов, которые вы выводите в фильтруемых списках на разных страницах, но при этом отдельным вопросам не нужны свои собственные URL. Или отзывы, которые появляются на вашем сайте, но не должны индексироваться как отдельные страницы.
Это очень распространенные сценарии использования, и на удивление сложно реализовать их корректно прямо сейчас. Поэтому я считаю, что одно архитектурное изменение крайне важно: возможность иметь публичные типы записей без отдельных URL-адресов.
Я нашел тикет в Trac десятилетней давности (от Джейсона Адамса из GiveWP, ныне директора по разработке ИИ в Automattic), в котором задавался именно этот вопрос. При регистрации типа записи сейчас можно выбрать, будут ли архивы. Почему нельзя выбрать, будут ли отдельные страницы?
Сегодняшний обходной путь крайне неудобен. Вам придётся:
- Скрыть тип записи из карт сайта
- Использовать template_redirect для инициирования ошибки 404
- Удалить ссылки View из панели управления
Всё это — обратная разработка, и она даже не охватывает всё.
Я провел тестирование, и оказалось, что исправить это сложнее, чем кажется. Вся суть публичного произвольного типа записей заключается в наличии постоянной ссылки. Удалите её, и WordPress (а также блоки и SEO-плагины) будет считать, что тип всё ещё существует. Вам потребуется внести изменения в:
- UI панели управления (удалить ссылки View)
- Query Loop, Post Title, Excerpt, Date и другие блоки (чтобы скрыть встроенные параметры постоянных ссылок)
- SEO-плагины, которые считают, что «public» означает, что пользовательский тип записей содержит отдельные страницы.
Но это изменение очень важно. Подумайте о вариантах использования: часто задаваемые вопросы, отзывы, ссылки для скачивания, любые табличные данные. Вы хотите запрашивать и отображать этот контент в списках и архивах, но отдельные записи не нуждаются в URL-адресах.
Я отправил патч, но, вероятно, для его корректной работы потребуется больше обсуждений в сообществе.
Другое архитектурное изменение, которое я хотел бы видеть, касается типов записей, вообще не использующих post_content или функционирующих не как записи блога или лендинги (включая примеры, которые я перечислил выше). В этом случае вы теряете доступ к интерфейсу блочного редактора Gutenberg. Редактирование контента будет напоминать WordPress образца 2015 года.
В своем прототипе я реализовал (очень неоптимальное) обходное решение для загрузки UI блочного редактора, скрытия самого блочного редактора и использования холста для отображения групп произвольных полей. Я ищу способы расширить возможности использования холста в блочном редакторе, исходя из предположения, что не каждый тип записей нуждается в визуальном редактировании.
Что нас ждёт в будущем?
Я слежу за развитием Gutenberg и оставляю отзывы. Если вы хотите увидеть по-настоящему перспективную версию моделирования контента в WordPress, вам следует обратить внимание на Cortex — проект, который берёт произвольные типы записей и поля и добавляет им интерфейс в стиле Notion — встроенное редактирование, расширенные таблицы данных, почти что прямой доступ к базе данных. Это будущее того, что можно сделать поверх WordPress.
Как только в ядре появится корректное моделирование контента, эти интерфейсы смогут базироваться на его основе. Подобно тому, как WooCommerce выигрывает от UI-компонентов Gutenberg для товаров и заказов, инструменты моделирования контента выиграют от использования общих фундаментальных элементов.
Если сформировать все это на основе произвольных типов записей (какой бы уникальной ни была архитектура), появятся шансы на связанное функционирование компонентов.
Как вы можете помочь
Эти элементы попадают в ядро благодаря общественному восприятию и вовлеченности. Кроме того, для реализации большего количества функций WordPress необходима конструктивная обратная связь от реальных пользователей. Если вы хотите увидеть моделирование контента в WordPress:
- Оставьте комментарий к проблемам Gutenberg
- Протестируйте прототипы
- Дайте конкретную обратную связь о ваших сценариях использования
- Расскажите, как бы вы это использовали
В противном случае создается впечатление, что никому это не интересно.
А когда вы все же решите вмешаться, не пишите комментарии типа «Я хотел этого 10 лет назад». Мы все хотели этого 10 лет назад. Вопрос в том, хотите ли вы быть конструктивными сейчас и помочь продвинуть WordPress вперед.
Источник: https://www.briancoords.com
