Фильтр для отключения кастомайзера был отклонен на WordPress Trac
В некоторых ситуациях, включающих, к примеру, работу с клиентами, кастомайзер может стать огромной проблемой; также кастомайзер вряд ли будет полезным дополнением к произвольным админкам WordPress.
Гейб Шэкл, разработчик приложений и интерфейсов в Risdall, создал тикет на WordPress Trac на прошлой неделе, попросив ввести фильтр для отключения кастомайзера. Его патч предлагает разработчикам простой способ для добавления класса no-customizer-support в тег body.
«Учитывая тот факт, что класс customizer-support добавляется через JavaScript на этапе рендеринга страницы, им не получится управлять посредством каких-либо базовых фильтров или действий.
Задав значение фильтра в false, кастомайзер будет скрыт в панели администратора, и ссылки, которые вели раньше на кастомайзер (виджеты, темы и т.д.), будут вести к стандартным местам консоли»
В данный момент разработчики, которые хотят отключить кастомайзер, должны использовать комбинацию разных методов, чтобы эффективно удалить все то, что кастомайзер вносит в панель администратора.
«Достаточно простого логического фильтра, чтобы разработчики, которым не требуется кастомайзер, могли легко удалить его», говорит Шэкл.
Ведущий разработчик WordPress Дион Халс ответил на тикет, объяснив, что, хотя он сам не использует кастомайзер, он не считает, что пользователи WordPress смогут извлечь какую-то выгоду для себя в результате отключения кастомайзера.
«Я не так часто работаю с кастомайзером, но я считаю, что введение фильтра, который бы отключал кастомайзер, вряд ли будет отвечать интересам пользователей WordPress.
Кастомайзер, хоть многие и ненавидят его, является важным компонентом будущего опыта взаимодействия в WordPress – именно поэтому он должен остаться».
Халс предложил в качестве альтернативного решения удаление возможности customize для произвольных пользовательских ролей.
Шэкл далее разъясняет, что он последовал прецеденту с админ-баром, который также является, по его мнению, подобным типом компонента UX (опыта взаимодействия).
«Админ-бар может быть отключен не только с помощью фильтра, но и при помощи глобальной переменной, функции ядра, а также параметра пользовательского профиля», отметил он. «Кастомайзер не имеет ни одной из этих опций».
Ник Холси, разработчик плагина Menu Customizer, который появится в версии 4.3, ответил на комментарий Шэкла:
«Для того чтобы вводить такой фильтр, мы должны иметь определенные основания. В большинстве случаев желание запретить пользователям обращаться к кастомайзеру следует из того, что вы просто не хотите предоставить им определенные возможности. И возможность customize может вполне использоваться для отключения кастомайзера, если вы действительно так этого хотите.
Конечно, вы всегда можете просто удалить возможность customize, однако поступать так только потому, что вы не хотите обучать пользователей или не желаете использовать кастомайзер, делает медвежью услугу вам и вашим пользователям. Как уже говорил dd32, значимость кастомайзер со временем будет только увеличиваться. Кроме того, пользовательское тестирование показало, что опыт взаимодействия с кастомайзером гораздо проще для пользователей, нежели обращение к страницам в панели администратора, что по большей части основано на наличии лайв-превью. Мы потратили очень много времени на улучшение кастомайзера, осуществляя активные пользовательские тесты, чтобы оптимизировать его юзабилити»
Холси быстро закрыл тикет после этого обмена репликами. Я решил обратиться к Шэклу напрямую, чтобы узнать, почему предложенная альтернатива по удалению возможности customize не подошла ему.
«Я надеялся, что кастомайзер можно будет рассматривать как админ-бар, который имеет три метода для его отключения», отметил Шэкл. «Наличие явного фильтра, по моему мнению, является более понятным решением, нежели изменение пользовательских возможностей. PHP-разработчик, который не имеет знаний в области WordPress, быстрее бы понял, что делает фильтр enable_customizer_support, чем map_meta_cap.
Безусловно, далеко не все тикеты и патчи являются допустимыми для участников ядра WordPress, однако Шэкл был разочарован такой оборонительной позицией разработчиков.
«Честно, если бы действительно ответом на мой вопрос было: ‘вам достаточно просто использовать возможность customize для достижения того же самого эффекта’, я бы и не ставил этот вопрос», отметил Шэкл.
«К несчастью, оказалось, что любой подход, отличающийся от ‘кастомайзер для всех вещей!’, автоматически говорит о том, что я оказываю своим клиентам плохие услуги, и что я такой ленивый разработчик, не хочу переучить своих клиентов тому, как надо управлять внешним видом их сайтов.
Такое чувство, что команда кастомайзера придерживается категорического подхода к проекту, и что любой, кто подвергает это сомнению, неправ, вне зависимости от приведенной аргументации»
Данное обращение демонстрирует, что, поскольку разработчики ядра рассматривают кастомайзер как основную часть будущего WordPress, этот компонент вряд ли будет сделан более модульным. Отключение поддержки для кастомайзера будет по-прежнему основано на использовании map_meta_cap – именно эту методику используют создатели плагина Customizer Remove All Parts.
Источник: wptavern.com
