Будущее WordPress без кода?

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

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

Этот выбор имеет значение, поскольку он во многом определяет конечный продукт. Будет ли он работать так, как нам нужно? Будет ли это выглядеть так, как мы хотим? Насколько гибкими будут изменения в будущем? И, пожалуй, самое главное: привязывает ли это нас к конкретному продукту?

В этом выборе есть своего рода практический результат. По сути, мы решаем, хотим ли мы (или должны ли) писать собственный код .

Это большое дело. И поскольку WordPress и его экосистема продолжают развиваться, возникает вопрос, будет ли больше дизайнеров выбирать решения без кода. Но если да, то каковы последствия?

Конструкторы страниц становятся лучше

Мы пришли к этому в немалой степени благодаря сообществу разработчиков WordPress. Например, плагины для создания страниц существуют уже много лет.

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

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

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

Gutenberg добавляет блоки в установку по умолчанию

Сам WordPress перешел на более визуально ориентированный способ создания контента. Когда редактор блоков Gutenberg был представлен в WordPress 5.0, он стремился обеспечить более единообразный пользовательский интерфейс. Отчасти это было ответом на специальные методы, которые разработчики использовали, чтобы обойти ограничения Classic Editor.

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

Хотя Gutenberg не обязательно конкурирует с полноценными конструкторами страниц, он предлагает гораздо более легкую альтернативу. И по мере того, как станет доступно больше блоков, это, вероятно, приведет к тому, что больше дизайнеров будут использовать собственный инструмент редактирования.

Кроме того, редактор блоков со временем позволит редактировать сайт целиком. Это означает, что в дополнение к созданию контента у нас будет возможность визуально создать весь веб-сайт — и все это в стандартной установке WordPress.

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

Хорошее и плохое

Переход на опыт создания сайтов без кода имеет некоторые потенциальные положительные и отрицательные стороны:

Положительные стороны

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

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

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

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

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

Отрицательные

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

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

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

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

Наконец, также стоит задаться вопросом, не отпугивает ли это новых разработчиков от возни с кодом. Разработка тем — это обычная отправная точка для изучения PHP, CSS и JavaScript.

Правда, создание пользовательских блоков — это возможность писать код. Но не все пойдут по этому пути. Было бы обидно, если бы этот жизнерадостный дух ушел.

Развивающийся ландшафт

Тот факт, что WordPress движется к визуально-ориентированному процессу проектирования, был очевиден в течение некоторого времени. С момента первого знакомства с блочным редактированием Гутенберга или даже с появлением Настройщика несколькими годами ранее казалось, что цель состоит в том, чтобы выполнять больше дизайнерских задач, не касаясь кода.

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

Это откроет целый новый мир возможностей для многих людей. Что это будет означать для веб-профессионалов? Эта история до сих пор пишется.