Регистрация пользовательских типов записей в админ-системе WordPress: Наш отчет о хакатоне CloudFest
Давайте обсудим: что, если бы вы могли зарегистрировать пользовательские типы записей и пользовательские поля непосредственно в администраторе WordPress?
Сегодня в WordPress вам нужно использовать пользовательский код или плагин для создания пользовательского типа записей, например “Книга” или “Участник”. Это распространенная потребность, и существует множество подходов; однако одна из проблем заключается в том, что взаимодействие с конечным пользователем может быть запутанным и нестандартизированным.
Несколько недель назад мы с несколькими специалистами по автоматизации отправились на 7-й хакатон CloudFest в Русте, Германия, чтобы найти решение для этой задачи. Мы начали взламывать глубоко заурядный проект “Формы и поля схемы JSON” и в итоге нашли интересный подход к извечному вопросу: что, если бы вы могли зарегистрировать пользовательские типы записей и пользовательские поля непосредственно в админ-системе WordPress?
Сорок восемь часов превращают идею в реальность
Это мероприятие, которое позволяет разработчикам со всего мира брать идеи и воплощать их в реальность.
Во время хакатона команды разработчиков из различных систем управления контентом и хостинговых компаний собираются вместе, чтобы внести свой вклад в проекты, соответствующие основным принципам мероприятия: проекты должны быть некоммерческими, совместимыми и с открытым исходным кодом.
В прошлом году мы работали над проектом, который позволил нам встроить WordPress непосредственно в VS Code. Мы создали приложение поверх . Оно использует WebAssembly для запуска WordPress полностью в браузере и it .
В этом году мы сосредоточились на . В то время как большинство из нас изучали использование JSON-схемы для динамической регистрации административных форм и полей, Деннис Снелл и Адам Зелински решили продвинуться в проекте еще на один шаг вперед! Они совместно взломали плагин, который предоставил возможность регистрировать пользовательские типы записей и настраиваемые поля непосредственно из администратора WordPress. Более того, все происходит в редакторе блоков — вы должны это увидеть, чтобы поверить в это:
Эта работа открывает некоторые интересные возможности для реализации пользовательских типов записей и пользовательских полей, поскольку она может коренным образом изменить способ, с помощью которого пользователи WordPress могут изменять свои сайты без использования кода.
:
Должен ли WordPress позволять вам регистрировать пользовательские типы записей и пользовательские поля от администратора?
— Дэниел (@dbchhbr)
Я получил довольно много ответов, начиная от “Черт возьми, да! Сейчас это уже должно было стать основной функцией. Такая неотъемлемая часть любого другого сайта ” для “администратора должна быть предназначена только для управления контентом и пользователями. Все остальное должно быть настроено в коде и контролироваться версиями”.
Так почему же такой разброс в ответах? Давайте обсудим это.
Это оказалось довольно просто
Деннис и Адам создали наш прототип, используя следующие соглашения:
- Пользовательский тип
записиwp_data_type содержит шаблоны для пользовательских типов данных. - Заголовок записи в
wp_data_typeопределяет название нового типа данных. Сама запись является шаблоном отображения и содержит любой набор обычных блоков. Для выбора атрибутов блоков в записи задаются имена, и эти имена сопоставляются с типом данных. - При создании новых записей для данного типа данных заблокированный шаблон копируется из
шаблона wp_data_type, а аннотации атрибутов блоков сохраняются. - Наконец, при рендеринге
шаблона wp_data_type атрибуты извлекаются из отдельного сообщения данного типа данных и объединяются в шаблон.
Интересная идея заключается в том, что нам не нужно думать о полях формы; блоки уже обеспечивают визуализацию и возможность модального редактирования. Мы можем положиться на фундаментальный принцип работы блоков и использовать тот же пользовательский опыт для создания пользовательских типов данных способом, с которым пользователи уже знакомы при редактировании публикации или сайта.
Пользовательские типы записей определяют пользовательские типы данных, поэтому мы используем шаблон не только для определения типа данных, но и для предоставления шаблона отображения по умолчанию. У каждого атрибута данных в типе записи есть поле, для которого можно определить это поле с помощью свойства JSON-LD.
Например, предположим, что у вас есть пользовательский тип записи “Книга”. Некоторые из них вы могли бы определить с помощью пользовательских полей:
описаниеГод защиты авторских прававторИздание книгиФормат книгиisbnКоличество страниц
Мы также решили сохранить копию каждого атрибута блока в атрибутах JSON для этого блока. Поскольку WordPress теперь может предоставлять функцию преобразования записей в JSON, которая объединяет извлеченные атрибуты с именами, присвоенными в пользовательском шаблоне типа записи, этот шаблон мог измениться с момента создания пользовательской записи. Это означает, что для отображения обновленной версии публикации не требуется перенос базы данных.
Что самое интересное? Уже существующая инфраструктура WordPress (она же Gutenberg!) определяет тип данных. Поскольку эти пользовательские записи являются обычными записями, и поскольку они используют заблокированный шаблон для определения типа данных, они, по сути, отображаются сами по себе! Даже если шаблон был обновлен и отображена только сама запись, она все равно будет отображать значимое представление типа данных в том виде, в каком оно было при создании.
В то время как наш первоначальный проект хакатона был ориентирован на разработчиков и UX-дизайнеров, которые хотели бы видеть API форм и полей в WordPress, этот прототип предоставляет больше возможностей пользователям WordPress, которые не используют код.
Это также открывает целый мир возможностей для отображения любых структурированных данных. Представьте, что вы загружаете CSV-файл и сопоставляете имена столбцов с атрибутами блоков или подключаетесь к базе данных или JSON API для сопоставления записей таким же образом.
Например, если у вас есть CSV-файл с названиями компаний, адресами, рейтингом и описанием, мы могли бы взять этот шаблон публикации и вставить в него блок карты, блок заголовков, блок звездочек и блок абзацев и настроить атрибуты для сопоставления со столбцами CSV. По сути, это мгновенный рендеринг структурированных данных!
Но даже если мы сможем определить пользовательские типы записей и поля в редакторе, должны ли мы, как сообщество WordPress, рассмотреть возможность добавления этого в core?
Главный вопрос: должен ли он существовать?
Добавление такого рода функционала в ядро WordPress может открыть массу возможностей для обычного пользователя WordPress. Вместо того, чтобы привлекать разработчика для добавления пользовательского типа записи на свой сайт, пользователь мог бы просто сделать это самостоятельно и определить необходимые поля и атрибуты структурированных данных.
С другой стороны, предоставление обычным пользователям, которые, возможно, не имеют полного представления о том, как должны работать пользовательские типы записей и структурированные данные, возможности самостоятельно создавать эти типы данных может негативно сказаться на работе пользователей их веб-сайтов. Неуклюжая или неправильная реализация разметки структурированных данных также может привести к проблемам с тем, как поисковые системы сканируют эти сайты, что может привести к непреднамеренному негативному воздействию на поисковый трафик.
Более того, на данный момент, если пользовательский тип записи случайно удален, весь контент, размещенный в этом пользовательском типе записи, больше не будет доступен администратору (даже если он по-прежнему будет храниться в базе данных). Пользователь может подумать, что он “потерял” свои данные.
Давайте поговорим об этом
Что вы думаете? Вы за то, чтобы предоставить владельцам веб-сайтов возможность изменять и настраивать свои собственные типы публикаций и атрибуты? Или есть какие-то функции веб-сайта, которые всегда требуют более квалифицированного специалиста и разработчика?
Мы хотели бы поделиться с вами вашими мыслями в комментариях ниже.
Еще одно интересное исследование по схожей идее можно найти здесь.
Спасибо Ларсу Герсманну за то, что он руководил проектом JSON Schema вместе со мной, и всем сотрудникам команды по синтаксическим ошибкам: Адаму Зелински, Деннису Снеллу, Джулиану Хаупту, Майклу Шмитцу, Анье Ланг, Томасу Роузу, Марко Фельдманну, Фабиану Генсу, Майклу Шмитцу, Яну Фогту, Люцису, Максимилиану Андре, Марселю Шмитцу и Шапочка Миланы.
