Спросите бармена: что происходит с настройщиком, когда тема блока активна?

Что-то на моем радаре прямо сейчас — это сторонние плагины, у которых есть настройки в Customizer. Что я знаю о друзьях, которые являются разработчиками, работающими над Customizer и внешним интерфейсом в нескольких компаниях, производящих плагины, глобальные стили и блочные стили еще не находятся на их радарах. Итак, что произойдет, если кто-то установит Twenty Twenty Two или другую блочную тему? Левого меню администратора для Customizer нет. Самый простой способ сделать это — через «Внешний вид» > «Темы» > «Настройщик». Но ожидается, что сторонние плагины и темы должны переносить настройки. На самом деле, это больше похоже на то, что им нужно какое-то время дублировать настройки в обоих местах.

Анонимный

Для тех, кто не в теме, позвольте мне кратко освежить в памяти эту тему. Когда выйдет WordPress 5.9, мы ожидаем, что он будет поставляться с новым редактором сайта и интерфейсом глобальных стилей. Однако большинство пользователей не увидят этот экран, если они не используют блочную тему.

Учитывая, что грядущая Twenty Twenty-Two также поставляется с WordPress 5.9 и, судя по популярности прошлых тем по умолчанию, мы можем ожидать, что многие тысячи пользователей перенесутся в этот совершенно новый мир. Для некоторых это может быть таким же шоком, как запуск редактора блоков в 5.0.

Когда тема блока активна, ссылки для доступа к старому и знакомому настройщику исчезнут из пользовательского интерфейса. Виджетов и экранов навигационного меню тоже не будет. Однако они по-прежнему будут доступны, если вы знаете URL-адрес экранов.

Мы впервые узнали об этом в прошлом году в рамках выпуска Gutenberg 9.3. Существует также нерешенная проблема, связанная с тем, чтобы редактор сайта имел паритет функций с некоторыми основными настройками WordPress.

Это нормально, что эти функции постепенно отключаются для пользователей блочной темы. Все они были ранними, разрозненными попытками создания отдельных частей того, что позволит редактор сайта. WordPress объединяет все эти концепции в более целостный пользовательский интерфейс. Это стандарт, который участники могут постоянно повторять. Он не будет идеальным с самого начала, но эта первая версия на основной платформе должна способствовать получению отзывов, необходимых для ее улучшения, поскольку все больше пользователей начинают устанавливать блочные темы.

Представленная здесь проблема больше связана с рынком плагинов. Настройщик изначально создавался как инструмент настройки темы и в основном использовался для этой цели. Но многие плагины привязывали к нему различные настройки за свою девятилетнюю историю. Поиск wp_customize в каталоге плагинов дает более 1400 результатов. Хук customize_register показывает более 1900. Это не обязательно точное соответствие тому, сколько плагинов на самом деле добавляют панели, разделы, настройки или элементы управления. Тем не менее, это показатель того, что многие полагаются на него для предоставления вариантов конечным пользователям.

Итак, мы вернулись к рассматриваемому вопросу. Что происходит, когда пользователь устанавливает блочную тему, такую ​​как грядущая Twenty Twenty-Two, при использовании плагина, основанного на настройщике?

По-разному.

Некоторые плагины, такие как WooCommerce, уже удобно разместили прямую ссылку на свою панель/раздел настройки в меню администратора. Это не будет проблемой для их пользователей. Однако для всех остальных настройщик исчезнет полностью.

В течение нескольких недель после 5.9, в зависимости от того, насколько быстро произойдет внедрение Twenty Twenty-Two, мы можем увидеть тысячи сбитых с толку пользователей. Конечно, все это может измениться за время, предшествующее релизу. Тем не менее, это разговор, который должен состояться сейчас.

«Здесь беспокоят конечные пользователи», — сказал анонимный собеседник. «Они будут просматривать статьи базы знаний, инструкции по настройке плагинов и многое другое, указывающее, где искать настройки».

По крайней мере, на данный момент ответственность за решение этой проблемы для своих пользователей лежит на авторах плагинов. Тем не менее, есть несколько путей, которыми они могут захотеть пойти вниз.

Самый простой способ — последовать примеру WooCommerce. Плагин проверяет gutenberg_is_fse_theme() (обратите внимание, что имя этой функции может измениться). Если он возвращает true , плагин добавляет ссылку непосредственно на свою панель настройки.

Связать с панелью настройки, разделом или элементом управления очень просто. Авторы плагинов могут найти URL-адреса в руководстве разработчика. Они также могут просто скопировать технику, которую использовала команда WooCommerce.

Это быстрый способ гарантировать, что пользователи не потеряют доступ к своим параметрам, если авторы плагинов не смогут внести изменения до выхода WordPress 5.9.

В долгосрочной перспективе это не идеальное решение. Настройщик будет существовать еще долгое время, но авторам плагинов придется иметь дело с двумя группами пользователей: теми, кто работает как с блочными, так и с классическими темами.

Поскольку каждый плагин отличается, решения должны быть разными. Многие могут просто использовать API настроек для создания настраиваемого экрана параметров. Если это работоспособное решение, не будет иметь значения, какую тему использует пользователь.

Однако реальность может заключаться в поддержке двух систем для обеих групп пользователей. Один интегрируется с настройщиком, а другой загружает параметры в редактор сайта. Если у плагина есть функции, связанные с дизайном, пользователи блочной темы ожидают увидеть настройки в новом интерфейсе.

Что касается тематики, то проблем должно быть меньше. В любом случае блочная тема ничего не делает с настройщиком. Одной из нерешенных проблем будет преобразование начального контента, и есть открытый билет, чтобы перенести его в полнофункциональное редактирование сайта.

Более всего, поддержание открытых линий связи с пользователями поможет облегчить переход. Часть этого должна исходить от ядра WordPress. Тем не менее, многим пользователям необходимо услышать это от разработчиков своих плагинов и тем. Это могут быть сообщения в блогах, обновления базы знаний или руководств, а также поддержка.

Затем есть окончательное решение, которое мог бы реализовать сам WordPress. Это также путь наименьшего сопротивления.

WordPress должен автоматически обнаруживать фильтры или действия в хуках, связанных с настройщиком. Это должно активировать флаг «настроить поддержку» и сохранить ссылки меню администратора и панели инструментов на экран настройщика. Это дало бы разработчикам некоторое время, чтобы наверстать упущенное, не путая при этом пользователей. Может быть несколько ложных флагов или пропущенных интеграций, но он должен быть в состоянии эффективно отловить большинство вариантов использования.