С самого начала редактор блоков всегда создавался как нечто большее, чем просто редактор основной области содержимого. На этапе 2 Гутенберга редактор блоков переносится в другие части сайта, включая виджеты, меню и другие аспекты настройки сайта. Матиас Вентура, один из ведущих инженеров проекта, рассказал о видении команды того, как редактор блоков будет выполнять редактирование всего сайта с помощью нового интригующего прототипа .
Вентура поделился видеодемонстрацией, представляя концепцию «блочных областей», которые, по его словам, будут включать в себя верхние и нижние колонтитулы, боковые панели и любую другую значимую часть шаблона за пределами содержимого сообщения, содержащего блоки.
Прототип не обязательно создавался, чтобы предписывать конкретную реализацию, а скорее показывает некоторые возможности того, как можно организовать блочные области на странице. Каждая область блока сохраняется отдельно, и любая часть шаблона может иметь собственное имя. Вентура предположил, что они могут быть сохранены как отдельные сообщения во внутреннем настраиваемом типе сообщений, которые можно изолировать и редактировать индивидуально или в рамках всей страницы. Это позволит использовать разные режимы просмотра и, возможно, даже режим дизайна с наложением сетки.
Прототип демонстрирует возможность детализации отдельных блоков, вложенных в шаблоны тем и контент публикации. Это предлагает пользователям лучшее понимание структуры страницы и позволяет им легко перемещаться по вложенным блокам.
Более пристальный взгляд на то, как области блока могут заменить настройщик
По мере того, как WordPress приближается к годовщине появления редактора блоков в ядре, интерфейс, представленный в прототипе блоковых областей, кажется сразу более знакомым, чем Customizer. Полное редактирование сайта в эпоху Гутенберга в корне изменит подход пользователей к дизайну своих сайтов. Редактор блоков предназначен для унификации интерфейсов настройки и содержимого, которые ранее не могли перейти в полноценное редактирование интерфейса.
«Слишком рано говорить наверняка, но в мире, где все является блоком, нет особой необходимости в текущем интерфейсе настройщика, в котором предварительный просмотр отключен от элементов управления в отдельном окне», – сказал специалист по обслуживанию компонента настройщика Уэстон Рутер. . «Если шаблоны тем полностью построены из блоков, поддерживающих прямое управление, то это, по сути, парадигма внешнего редактирования».
Рутер, который сыграл важную роль в создании архитектуры Customizer, сказал, что текущий интерфейс, который разделяет дизайн и элементы управления на отдельные окна, был необходим, поскольку многие элементы управления требовали перезагрузки всей страницы. Разделенный интерфейс гарантирует, что элементы управления не исчезают постоянно, пока страница перезагружается для отображения изменений.
«Лучшая интеграция Customizer – это живые элементы управления обновлением postMessage, которые не требуют перезагрузки (например, палитры цветов)», – сказал Рутер. «Совсем недавно возможность« выборочного обновления »также упростила темы и плагины для повторного создания частичных шаблонов без необходимости перезагружать всю страницу. Теоретически эти возможности действительно позволяли редактировать в реальном времени без необходимости перезагружать страницу ».
В то время как Customizer давал пользователям больше контроля над дизайном своих сайтов, компонент всегда изо всех сил пытался обеспечить мощные элементы управления и обновление в реальном времени в одном интерфейсе с ограниченным объемом страницы. Рутер выделил несколько преимуществ использования редактора блоков в качестве основного средства настройки в WordPress.
«Блоки предоставляют общий интерфейс, позволяющий выполнять такое встроенное редактирование для любой части страницы, а не только специальные области в предварительном просмотре настройщика, в которые добавляются дополнительные возможности пользовательского интерфейса», – сказал он. «Таким образом, с этим общим блочным интерфейсом с парадигмой прямого управления нет необходимости в отдельной панели управления и нет необходимости выполнять полную перезагрузку страницы для выполнения предварительных изменений. Таким образом, не будет необходимости в текущем интерфейсе Customizer ».
Хотя большая часть настройщика, вероятно, устареет в новую эру полного редактирования сайта с помощью Гутенберга, набор изменений Customizer является одной из ключевых концепций, которую, по мнению Рутера, можно сохранить. Это код, который позволяет пользователям планировать изменения дизайна в масштабах всего сайта .
«Это не зависит от текущего интерфейса Customizer и относится к базовой модели данных WordPress», – сказал он. «Если бы изменения, внесенные в блоки Гутенберга, были внесены в такой набор изменений до публикации, то эти изменения можно было бы предварительно просмотреть на сайте, прежде чем они будут запущены. Необходимость в этом не была так очевидна до сих пор, потому что изменения касались публикации контента. Но после того, как данные блока обрабатываются в различных объектах сайта, становится важным иметь место для внесения этих изменений до их запуска ».
Разработчики плагинов и тем захотят отслеживать обсуждения, связанные с реализацией блочных областей, для полного редактирования сайта. Когда этот прототип станет реальностью, он окажет значительное влияние на темы и плагины, которые в настоящее время расширяют Customizer. Многим разработчикам продуктов потребуется изменить архитектуру своих решений, чтобы они лучше подходили для настройки сайта с помощью редактора блоков. Вентура перечисляет все соответствующие проблемы GitHub в своем сообщении, в котором представлены области блоков контента .
