«Тильда головного мозга» в MODX: как экспорт Zero Block превращает жизнь разработчика в ад

«Тильда головного мозга» в MODX: как экспорт Zero Block превращает жизнь разработчика в ад

Представьте ситуацию: вам прилетает задача «поправить логотип и контакты в футере» на сайте с MODX. Вы открываете шаблон, ожидая увидеть привычный HTML и пару чанков, но вместо этого проваливаетесь в кроличью нору из бесконечных data- атрибутов, классов-монстров и инлайновых стилей, которые живут своей жизнью. Сегодня столкнулся с такой.

Добро пожаловать в мир «импортированной Тильды».

Как рождаются такие мутанты?

Обычно сценарий такой: дизайнер отрисовал крутой футер в Zero Block на Tilda. Клиенту понравилось, но основной сайт работает на MODX.

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

Анатомия катастрофы

Когда вы открываете DevTools, вы видите не верстку, а результат работы тяжелого JS-движка.

  1. Классы-криптограммы. Забудьте про .footer-logo. Готовьтесь работать с чем-то вроде .tn-elem__2077772271593677753194. Если таких блоков на странице десять, ваш файл стилей превращается в зашифрованную депешу.
  2. JavaScript вместо CSS. Видите в инспекторе top: 123px;? Не пытайтесь изменить его в CSS. При обновлении страницы скрипт заново прочитает data-field-top-value="-20", сопоставит его с высотой артборда и пересчитает координату на лету.
  3. Абсолютное позиционирование всего. В таком коде нет «потока». Элементы не знают друг о друге. Если вы удалите верхний блок, нижний не поднимется — он останется висеть на своих координатах, оставляя после себя огромную белую дыру.

Почему это плохо для бизнеса?

Для клиента это кажется экономией, но на деле это «технический долг» с огромными процентами:

  • Скорость загрузки: Чтобы отобразить один несчастный футер, браузер должен скачать и выполнить библиотеку скриптов Тильды.
  • Дорогая поддержка: То, что в нормальной верстке правится за 5 минут (через одну строчку в CSS), здесь требует от разработчика дешифровки логики data- полей под каждое разрешение экрана (320, 480, 640...).
  • SEO и доступность: Здесь всё — это нагромождение div, в котором роботам сложно ориентироваться.

Что делать?

Если вы встретили такой код в проекте:

  1. Для мелких правок: Не трогайте CSS. Ищите в HTML-шаблоне атрибуты data-field-top-value, data-field-left-res-320 и меняйте их. Помните, что axisy-value="bottom" инвертирует логику отступов.
  2. Для глобальных изменений: Сносите это всё. Переверстать один блок на Flexbox или Grid с нуля выйдет быстрее и дешевле, чем пытаться «приручить» экспортированный Zero Block.

Мораль: Инструменты хороши там, где они уместны. Тильда прекрасна для лендингов, MODX — для гибких систем. Но их гибрид через «Copy-Paste» — это костыль, который обязательно сломается в самый неподходящий момент.

А как часто вам приходилось поддерживать такие «франкенштейны»? Пишите в комментариях свои истории боли.

Начать дискуссию