Когда виджеты были добавлены к кастомайзеру в версии WordPress 3.9, пользователи были несказанно удивлены и обрадованы. Лайв-превью отлично вписались в процесс редактирования, вследствие чего разработчики стали задумываться о расширении роли кастомайзера во всех аспектах WordPress.

Ник Холси активно работал с кастомайзером, являющимся частью одного из его проектов на Google Summer of Code, и не так давно он опубликовал обновление, которое раскрывает запланированные улучшения для предстоящего релиза WordPress 4.0. Компонент trac под названием Appearance был переименован в Customize. Разъяснения терминологии, приведенные Холси, показывают, какую роль в данном проекте играет кастомайзер:

«Мы склоняемся к использованию «Customizer» вместо «Theme Customizer», поскольку кастомайзер не обязательно связан с темой (хотя в основном он используется именно для темы). «Customize» может описать все, что угодно. В этом суть; он может использоваться, чтобы изменить любую часть сайта. Кастомайзер может использоваться для всего, и мы хотели бы подтолкнуть людей к большим экспериментам с различным использованием кастомайзера»

WordPress 4.0 будет включать в себя массу изменений в UI кастомайзера, наряду с новым Panels API, который позволит разработчикам группировать средства управления в разделы.

Чтобы посмотреть интерфейс в действии, щелкните по изображению (gif-файл)

Предложенные изменения кастомайзера для версии 4.0 обеспечивают поддержку широкого спектра средств управления и параметров, что поможет разработчикам использовать кастомайзер для разных нужд, а не только для настройки темы. Контекстные средства управления также находятся в списке предложенных изменений – они позволят средствам управления быть видимыми или скрытыми в зависимости от страницы, которую просматривает пользователь.

Все на базе кастомайзера?

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

Мэтт Виб, Design Engineer в Automattic, недавно написал статью, в которой указывались некоторые самые критические проблемы в развитии кастомайзера, существующие на данный момент. Статья Мэтта демонстрирует сложности использования кастомайзера на мобильных устройствах, раскрывает проблемы производительности, указывает на запутанный UI и фундаментальные ограничения архитектуры:

«Это – JS-приложение, обернутое в публичный API на PHP, которое напоминает нечто, напоминающее ранний набег WP на плоскость JS. Однако эта фундаментальная зависимость от PHP делает невозможным быстрое переключение между состояниями при изменении просматриваемой темы: понадобится полная перезагрузка страницы»

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

«Кроме того, с нетерпением жду, когда кастомайзер станет клиентским приложением на базе WP-API. Все, что связано с представлением сайта, должно быть основано на API, а не на такой ограниченной вещи, как кастомайзер. WP-API откроет двери для, скажем, родного кастомайзера на Android, iOS или других платформах, которые пока не существуют, но которые могут стать важными»

WP API планируется включить в WordPress 4.1, который появится чуть позже в этом году. Между тем, разработка текущей архитектуры кастомайзера идет вперед.

Холси кратко отметил некоторые из этих проблем в заключении к своему предложению в разделе «future work». Он приводит в пример тикеты, которые указывают на то, что кастомайзер не является интуитивным на мобильных устройствах и нуждается в некоторой доработке в плане производительности. Тикеты, связанные с кастомайзером и намеченные на будущий релиз, раскрывают некоторые проблемы, которые могут быть решены путем изменений ядра.

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

Источник: wptavern.com