Фильтр для отключения настройщика, сбитого на WordPress Trac

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

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

@pollyplummer очень интересно. Я не против новых обновлений, но кастомайзер — это ад в мире агентств.

— Эдвард Макинтайр (@twittem) 24 июня 2015 г.

Гейб Шекл , разработчик приложений и инженер пользовательского интерфейса в Risdall , на прошлой неделе создал тикет на WordPress trac, запрашивая фильтр для отключения настройщика. Его патч предлагает разработчикам простой способ включить класс «no-customizer-support» в теге body.

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

Если установить для фильтра значение false, настройщик по существу скрыт от администратора, а ссылки, которые в настоящее время указывали на настройщик (виджеты, темы и т. д.), возвращаются к своим предыдущим пунктам назначения на панели инструментов.

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

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

Ведущий разработчик WordPress Дион Халс ответил на тикет, сказав, что, хотя он сам мало использует настройщик, он не думает, что пользователям WordPress будет полезен простой способ отключить его.

Хотя лично я не использую настройщик много времени, я думаю, что предлагать фильтр для его отключения, вероятно, не в интересах пользователей WordPress.

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

В качестве альтернативы Халс предложил , что лучший способ отключить это — удалить эту customize возможность из ролей.

Далее Шекл объяснил, что он пытался следовать прецеденту панели администратора, которую он считает похожим типом UX-компонента.

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

Ник Хэлси, разработчик подключаемого модуля Menu Customizer, который объединяется с 4.3, ответил , исходя из предположений о том, почему Shackle может запросить фильтр для отключения этой функции:

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

Хотя вы можете удалить мета-возможность настройки (или переназначить ее или что-то еще), делая это просто потому, что вы не хотите обучать пользователей или не хотите использовать настройщик, вы оказываете себе и своим пользователям огромную медвежью услугу. Как упоминалось в dd32, важность Customizer в WordPress будет только возрастать. Кроме того, пользовательское тестирование показало, что пользователям, как правило, легче понять работу с Customizer, чем администратору, что в значительной степени связано с ценностью наличия предварительного просмотра в реальном времени. Мы уделяем много времени настройщику каждого выпуска, чтобы продолжать его улучшать, часто проводя пользовательские тесты для оптимизации удобства использования.

Холзи сразу же закрыл тикет после этого обмена. Я связался с Шеклом, чтобы выяснить, почему предложенный вариант удаления customize возможности не подходит для его целей.

«В основном я надеялся, что настройщик можно будет рассматривать как панель администратора, которая имеет более 3 методов для его отключения», — сказал Шекл. «Иметь четко обозначенный фильтр, на мой взгляд, более разборчиво, чем изменять возможности пользователя. Разработчик PHP, практически не знакомый с WordPress, скорее всего, мог бы гораздо быстрее понять, что происходит с фильтром с именем «enable_customizer_support», а не с «map_meta_cap».

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

«Честно говоря, если бы ответ был просто чем-то вроде «Вы должны просто использовать customizeвозможность для достижения того же эффекта», у меня действительно не было бы никаких проблем», — сказал он.

«К сожалению, кажется, что любой другой подход, кроме «Настройщика для всего!» означает, что мне несколько раз говорят, какую медвежью услугу я оказываю своим клиентам и какой я ленивый разработчик, потому что не просто переучу своих клиентов тому, как управлять внешним видом их сайтов.

«Создается впечатление, что у самой команды Customizer подход к проекту по принципу «все или ничего», и что любой, кто сомневается в этом, ошибается, независимо от их аргументации», — сказал Шекл.

Этот обмен мнениями демонстрирует, что, поскольку основные участники рассматривают настройщик как основную часть будущего WordPress, это одна из функций, в отношении которой будет мало желания поддерживать усилия, направленные на то, чтобы сделать его более модульным. Отключение поддержки настройщика по-прежнему потребует использования map_meta_cap, того же метода , который использовали создатели плагина Customizer Remove All Parts .