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

Что-то на моем радаре прямо сейчас – это сторонние плагины, у которых есть настройки в Настройщике. То, что я собираю из друзей, которые являются разработчиками, работающими над настройщиками и интерфейсными материалами в нескольких компаниях, занимающихся плагинами, – глобальные стили и стили блоков еще не в их поле зрения. Так что же произойдет, если кто-то установит 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 должен автоматически обнаруживать фильтры или действия на хуках, связанных с настройщиками. Это должно активировать флаг «настроить поддержку» и поддерживать ссылки меню администратора и панели инструментов на экран настройки. Это даст разработчикам время наверстать упущенное, не запутывая пользователей в процессе. Может быть несколько ложных флагов или пропущенных интеграций, но он должен эффективно улавливать большинство случаев использования.