Gutenberg, Elementor и WPBakery над одним ядром: конец войны редакторов

# Gutenberg, Elementor и WPBakery над одним ядром: конец войны редакторов

Я наблюдал этот спор столько раз, что могу разыграть его по ролям без подготовки. Дизайнер сидит с ноутбуком, открывает Elementor, двигает секции мышкой, за пять минут собирает баннер с наложением текста на фото — и говорит: «Вот, смотри, я тебе сейчас всё сам сверстаю, зачем нам вообще программист для лендинга». Разработчик молчит минуту, потом произносит фразу, которую я слышал буквально с этими же словами на трёх разных проектах: «Через полгода на этой странице будет пятнадцать вложенных секций, из HTML торчать будут инлайновые стили, а мне потом чинить баг на проде, потому что Elementor сохранил разметку с закрытым тегом не в том месте». И оба правы. Дизайнеру действительно неудобно ждать разработчика ради того, чтобы подвинуть баннер на десять пикселей. А разработчику действительно неприятно разгребать наследие визуального редактора, когда контент годами обрастал правками поверх правок и превращается в кашу, которую страшно трогать.

Иногда в этот же разговор вклинивается ещё и владелец бизнеса, который вообще не понимает, почему взрослые люди спорят про инструмент, если ему нужен просто результат — работающий сайт, который приносит заказы. Он слышит слова «Elementor», «Gutenberg», «шорткоды» и честно не понимает, почему это вообще имеет значение, если покупатель на витрине видит одну и ту же картинку с товаром и одну и ту же кнопку «В корзину». И знаете, он в чём-то прав больше, чем дизайнер с разработчиком вместе взятые, — потому что для конечного покупателя действительно не важно, в каком редакторе была собрана страница. Важно только то, что видно на экране. Проблема лишь в том, что почти все существующие подходы к визуальным конструкторам страниц незаметно делают редактор и результат неразрывными — и когда бизнесу нужно поменять инструмент внутри, приходится трогать и то, что видно снаружи.

Третий участник этого спора обычно появляется чуть позже — это клиент, у которого старый сайт был сделан пять лет назад в WPBakery, и переезжать он с этого редактора не хочет, потому что «мы уже привыкли, и вебмастер, который умеет в WPBakery, у нас есть, а искать нового — время и деньги». И вот у вас на одном столе три разных требования, каждое обоснованное по-своему, и стандартный ответ рынка — «выберите один редактор и живите с его ограничениями» — на практике означает, что кто-то из трёх останется недоволен, а чаще всего недовольны все понемногу.

Обычно после таких споров зовут менеджера проекта — как «нейтральную сторону», которая должна принять волевое решение и закрыть тему. И менеджер, как правило, выбирает не то, что технически правильнее, а то, что политически безопаснее: у клиента уже есть договорённость с прошлым подрядчиком, значит остаёмся на WPBakery; новый разработчик громче всех настаивал на Gutenberg, значит уступим ему, лишь бы не потерять его на проекте. Это решение снимает конфликт здесь и сейчас, но не решает саму проблему — она просто переносится на следующий проект, следующего клиента, следующую смену подрядчика.

Я это видел настолько часто, что в какой-то момент задал себе прямой вопрос: а что, если сама постановка «какой редактор лучше» неверна с самого начала? Что, если проблема не в выборе билдера, а в том, что контент годами намертво прибивают к конкретному инструменту, вместо того чтобы дать контенту жить своей жизнью, а редактору — быть просто способом с этим контентом взаимодействовать? Именно из этого вопроса выросла архитектура, которую мы реализовали в COS WP Woo: семьдесят шесть блоков, которые работают одинаково в Gutenberg, в Elementor и в WPBakery, потому что за всеми тремя стоит один и тот же серверный рендер.

Почему смена редактора обычно означает переверстать сайт заново

Стандартная ситуация, с которой сталкивается почти любое агентство: клиент когда-то заказал сайт на WPBakery, потому что в тот момент это был самый распространённый визуальный конструктор, а теперь хочет перейти на Gutenberg — потому что штатный редактор WordPress стал заметно удобнее, потому что не хочет зависеть от платного плагина, потому что новый разработчик просто не любит WPBakery и настаивает на смене. И тут выясняется неприятная вещь: контент не переезжает. Он прибит к конкретному билдеру намертво.

WPBakery хранит содержимое страницы как последовательность шорткодов вида `[vc_row][vc_column]...[/vc_column][/vc_row]`, где внутри — конкретные параметры конкретных виджетов этого конкретного плагина. Elementor хранит контент в собственном формате JSON, привязанном к своим виджетам и своей системе рендеринга. Переключить редактор — не значит просто поменять инструмент, это значит взять весь исторический контент и либо смириться с тем, что старые страницы отображаются криво или вообще не отображаются без выключенного плагина, либо пересобрать их вручную заново, блок за блоком, секцию за секцией. На практике это ровно та работа, которую делают заново с нуля — просто потому что переносить контент между несовместимыми форматами дороже, чем свёрстывать его заново глазами на новую разметку.

Я видел, как агентства оценивают такую миграцию в человеко-недели даже для сайта из тридцати-сорока страниц, и это не жадность — это реальная трудоёмкость ручного переноса. Возьмём конкретный пример: карточка категории в каталоге, где стоит промо-баннер, три плитки подкатегорий, карусель бестселлеров и блок с отзывами. В WPBakery это четыре-пять вложенных шорткодов с десятком параметров у каждого. Перенести это в Gutenberg вручную — значит открыть страницу, визуально сверить, что где стояло, пересобрать те же самые четыре-пять секций заново уже средствами нового редактора, подобрать те же самые изображения, вписать тот же самый текст, и на выходе проверить, что визуально ничего не съехало. На страницу с такой плотностью контента у опытного верстальщика уходит от двух до четырёх часов, и это без учёта случаев, когда исходные настройки WPBakery были не документированы и восстанавливать логику приходится по наитию. Умножьте это на тридцать-сорок посадочных страниц каталога — и получите ту самую человеко-неделю, а то и две.

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

Один рендер, три адаптера: как это устроено внутри

Мы решили эту проблему архитектурно, а не косметически. У каждого блока в нашей библиотеке есть единая схема — описание того, какие у него есть настройки: текстовые поля, переключатели, списки повторяющихся элементов вроде карточек в карусели, картинки, ссылки. И есть один серверный рендер-движок — функция вида `cwt_block_render_<id>`, которая принимает набор атрибутов и возвращает готовую HTML-разметку блока. Дальше эта схема прогоняется через три независимых адаптера.

Для Gutenberg адаптер регистрирует блок стандартным способом WordPress и подключает свой интерфейс редактирования — панель настроек, куда дизайнер вводит текст, выбирает иконку, добавляет элементы в повторяющийся список. Для Elementor у нас есть один общий класс виджета, который получает идентификатор конкретного блока в конструкторе и на основе той же самой схемы генерирует нужные контролы Elementor — текстовые поля превращаются в `TEXT`, переключатели — в `SWITCHER`, повторяющиеся списки — в `Repeater`. Для WPBakery всё то же самое происходит через `vc_map()` — механизм, которым WPBakery регистрирует собственные элементы, только рендер в итоге вызывает ровно ту же самую функцию, что и первые два редактора.

Смысл в том, что третьего рендера не появляется. Не так, что Gutenberg рисует одну версию баннера, а WPBakery — вторую, чуть-чуть отличающуюся, потому что писалась другим человеком в другое время с другим пониманием задачи. Есть один источник истины про то, как выглядит и ведёт себя блок, а редакторы — это просто разные способы собрать набор параметров и передать их туда. Дизайнер открывает Elementor, двигает мышкой, меняет текст в карусели брендов — на фронте отрисовывается та же самая разметка, которая получилась бы, собери он тот же блок в Gutenberg. Разработчик правит логику рендера в одном файле — и это меняет отображение блока сразу во всех трёх редакторах одновременно, а не в одном, оставляя два других жить со старым поведением.

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

Один и тот же кирпич в трёх руках: конкретные блоки, а не абстракция

Абстрактное «один рендер, три адаптера» звучит красиво, но я хочу заземлить это на конкретных примерах, потому что именно конкретика показывает, зачем вообще нужна такая архитектура, а не просто три отдельных набора виджетов под три отдельных плагина. Библиотека блоков строилась не «из головы», а на основе разбора того, из каких секций реально собраны современные витрины на популярных темах WooCommerce — плитки категорий со счётчиком товаров, карусель брендов, блок сравнения характеристик, товар дня с таймером и прогрессом «продано N из M», полоса преимуществ с иконками (доставка, гарантия, поддержка, оплата), сворачиваемый SEO-текст внизу категории, витрина одного товара крупным планом с полной выкладкой параметров.

Возьмём для примера блок «товар дня» — секцию с обратным отсчётом до конца акции и прогресс-баром «раскуплено 42 из 50». В Gutenberg дизайнер вставляет блок через инсертер, заполняет панель настроек сбоку — выбирает товар, задаёт дату окончания акции, включает прогресс-бар. В Elementor этот же блок появляется в перетаскиваемой панели виджетов, и настройки — те же самые поля, просто нарисованные контролами Elementor: выбор товара через `SELECT`, дата — через текстовое поле, переключатель прогресс-бара — через `SWITCHER`. В WPBakery он встаёт в список доступных элементов конструктора, и точно те же параметры собираются диалоговым окном самого WPBakery. Во всех трёх случаях итоговая карточка на фронтенде — один и тот же HTML с одним и тем же таймером, одной и той же логикой подсчёта прогресса, потому что за кнопкой «сохранить» во всех трёх редакторах стоит вызов одной и той же функции рендера с одними и теми же параметрами.

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

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

Единый скин поверх трёх редакторов

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

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

Цена, которую платит агентство при разных клиентах в разных редакторах

Вот сценарий, который я наблюдал вживую на реальном проекте, только слегка обобщу детали. Агентство ведёт несколько клиентов одновременно. У одного клиента штатный контент-менеджер, который прекрасно освоился в Elementor и категорически не хочет учиться чему-то новому — ему нужно быстро публиковать акции и сезонные баннеры без участия разработчика. У второго клиента сайт достался в наследство от прошлого подрядчика, и там всё сделано на WPBakery, переезжать страшно, потому что это ещё и денег стоит, и рискованно для действующих продаж. У третьего клиента разработчик агентства настоял на Gutenberg, потому что хочет версионировать содержимое страниц через git и не любит закрытые форматы данных.

В классической ситуации, когда каждый плагин с блоками для WooCommerce жёстко привязан к одному конкретному редактору, агентству пришлось бы содержать по сути три параллельных набора инструментов, три разных обучения для новых сотрудников, три разных подхода к отладке одной и той же логики — скажем, карусели брендов или блока «товар дня» с таймером. Изменение в дизайне карточки распродажи нужно было бы вносить трижды, тремя разными способами, с риском, что где-то забудут и разъедутся визуально.

С единым рендер-ядром агентство работает с одной библиотекой блоков и просто подключает нужный адаптер под конкретного клиента. Разработчик один раз спроектировал блок «товар дня» с таймером как данные — и дальше неважно, что первый клиент собирает страницу в Elementor, второй правит существующую вёрстку в WPBakery, а третий пишет содержимое прямо в Gutenberg. Внутри это один и тот же вызов рендера с разными параметрами. Обучение новых сотрудников агентства сводится к «вот наша библиотека блоков», а не к «вот три разных набора виджетов трёх разных вендоров, у каждого свой синтаксис и свои баги».

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

Почему динамические блоки лучше сохранённой разметки

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

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

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

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

Честный разбор: где три редактора всё-таки не полностью равны

Я не хочу создавать впечатление, что три редактора дают абсолютно идентичный опыт во всём, потому что это было бы нечестно, а нечестные обещания в технической статье выглядят особенно плохо, когда читатель сам всё проверит через час после прочтения. Рендеринг на фронтенде — то, что видит покупатель, — действительно идентичен вне зависимости от редактора. А вот опыт редактирования различается, и я скажу прямо, в чём именно.

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

Ещё честный момент — есть небольшая группа блоков, у которых основная правка происходит прямо в холсте Gutenberg, интерактивно, а не через отдельную панель настроек сбоку. Для таких блоков в Elementor и WPBakery контролы всё равно существуют и работают, но описаны отдельно, специально для этих двух редакторов, поэтому required-поддержка чуть более рукотворная, чем для остальных шестидесяти с лишним блоков, которые целиком описываются одной общей схемой. Это не баг, а следствие того, что сама механика Gutenberg позволяет редактировать контент прямо на месте показа, а два других редактора традиционно работают через боковую панель — и мы сознательно сохранили этот привычный для Gutenberg способ работы там, где он даёт лучший пользовательский опыт, вместо того чтобы искусственно унифицировать всё в ущерб удобству.

И последнее, что стоит сказать прямо: адаптер для WPBakery — самый молодой из трёх, и у него есть архитектурное ограничение, о котором нужно знать заранее, если вы планируете сложные вложенные структуры. Механизм повторяющихся групп полей в WPBakery не поддерживает вложенность одной группы внутрь другой — то есть список, где каждый элемент сам содержит ещё один список, там не заработает так же гладко, как в Elementor или Gutenberg, и такие структуры приходится разворачивать в более плоскую форму. Для подавляющего большинства блоков библиотеки это ограничение вообще не проявляется, потому что у них нет настолько глубокой вложенности данных, но для нескольких сложных составных блоков это реальный компромисс, который я предпочитаю проговорить сразу, а не обнаруживать вместе с клиентом постфактум.

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

Зачем вообще нужен WPBakery в 2026 году

Кто-то из читателей наверняка подумает: WPBakery — это редактор из прошлого десятилетия, зачем вообще тратить силы на адаптер под него, если есть Gutenberg и Elementor. Отвечу так же честно, как и в предыдущем разделе. Когда мы вживую разбирали восемь витрин на популярных темах WooCommerce, чтобы понять, из каких блоков реально собираются современные магазины, оказалось, что из восьми демонстрационных сайтов три построены именно на WPBakery. Не один, не случайный аутсайдер — три из восьми, наравне с Elementor и собственными блочными решениями тем. WPBakery жив, он массово используется в темах, на которых уже сидят реальные покупатели, и говорить владельцу такого магазина «переезжайте на Gutenberg, а то мы не поддерживаем ваш редактор» — значит закрыть себе дорогу к заметной доле рынка, причём не по техническим причинам, а из-за нежелания поддерживать три формата вместо двух.

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

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

Переключение редактора — это настройка, а не развод

Отдельная деталь, которая на практике снимает огромную долю тревожности при выборе редактора, — переключение между режимами устроено как обычная настройка в админке, а не как необратимое архитектурное решение, вбитое на старте проекта. Владелец магазина выбирает режим — Gutenberg или Elementor — переключателем на странице настроек темы, и это решение можно менять сколько угодно раз по мере того, как меняются обстоятельства: сменился разработчик, контент-менеджер попросил более привычный интерфейс, агентство перешло на нового подрядчика с другими предпочтениями.

Более того, система страхует вас от собственной ошибки: если вы включили режим Elementor, а сам плагин Elementor на сайте не активен или был случайно отключён, настройка автоматически откатывается обратно на Gutenberg, вместо того чтобы оставить сайт в состоянии, когда редактор выбран, а инструмента для него нет. Это тот тип мелкой инженерной аккуратности, который не заметен, пока не окажешься в ситуации, когда он тебя спас — например, кто-то по ошибке деактивировал платный аддон, и вместо сломанной админки с невозможностью редактировать вообще что-либо, сайт просто тихо продолжает работать в резервном режиме.

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

Тихое преимущество, о котором редко говорят на демонстрациях: вес страницы

Есть ещё один аспект, который редко всплывает в спорах о редакторах, но напрямую бьёт по деньгам через скорость сайта и позиции в поиске. Многие визуальные конструкторы страниц тянут за собой собственные объёмные наборы CSS и JavaScript на каждую страницу, где используется хотя бы один их виджет, — и чем больше уникальных виджетов на странице, тем толще становится этот довесок. Я видел страницы, собранные в популярных визуальных builder'ах, где сама разметка контента весит меньше, чем обвязка стилей и скриптов конструктора вокруг неё.

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

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

Что это меняет для тех, кто ставит плагин на чужую тему

Отдельный сценарий, о котором я хочу сказать честно, — это установка плагина поверх темы, которая не является нашей собственной. Многие покупатели уже имеют готовый сайт со своей темой и хотят получить именно библиотеку блоков и логику магазина, не меняя визуальную оболочку целиком. Тут единое рендер-ядро тоже играет на руку: блоки не завязаны намертво на конкретную тему, они несут собственный слой стилей с низкой специфичностью и опираются на контейнерные, а не оконные media-запросы, чтобы корректно адаптироваться внутри любой сетки колонок, которую диктует чужая тема. Идеал тут — чтобы блок брал цветовую палитру из нашей темы, когда она активна, и переходил на разумные дефолтные значения, когда её нет, не разваливаясь визуально ни в том, ни в другом случае.

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

Настоящая цена: спроектировать блок как данные дороже, чем сверстать HTML один раз

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

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

Вместо вывода: спор был не про редакторы

Возвращаясь к сцене, с которой я начал: спор дизайнера и разработчика на самом деле никогда не был про то, какой редактор объективно лучше. Это был спор о том, кто владеет контентом и кто несёт ответственность за то, что происходит на сайте через полгода после публикации. Пока контент прибит к конкретному билдеру, эти два человека обречены тянуть одеяло каждый на себя — дизайнер хочет свободы правок без оглядки на код, разработчик хочет предсказуемости без риска, что визуальный редактор сохранит что-то непредвиденное в базу данных.

Как только контент становится данными, а редакторы — просто разными окнами в эти данные, спор рассасывается сам собой, потому что предмета спора больше нет. Дизайнер получает свою свободу, разработчик получает свою предсказуемость, а клиент со старым сайтом на WPBakery получает возможность постепенно наращивать новую библиотеку блоков поверх того, что уже работает, не переписывая всё с нуля просто потому, что где-то в компании решили, что «Gutenberg — это будущее».

Я иногда думаю, что вся история противостояния редакторов страниц в WordPress — это в миниатюре та же самая история, которая много раз повторялась в других областях разработки: спор о хранении данных путают со спором об инструменте просмотра этих данных. Базы данных давно научились отдавать одну и ту же информацию через веб-интерфейс, мобильное приложение и консольную команду, потому что данные и интерфейс разошлись на разные уровни архитектуры ещё десятилетия назад. Контенту сайтов понадобилось больше времени, чтобы прийти к тому же самому разделению, но, кажется, это тот путь, по которому индустрия рано или поздно идёт в любой достаточно зрелой системе.

Если вы ведёте магазин на WooCommerce и устали от того, что каждая смена подрядчика или каждое обновление любимого конструктора страниц превращается в мини-переезд, посмотрите на архитектуру, где контент и способ его редактирования — это два разных, независимых друг от друга слоя. В COS WP Woo это работает именно так, и, честно говоря, после того как один раз перестраиваешь мышление в эту сторону, возвращаться к жёсткой привязке контента к одному редактору уже не хочется.