Почему не работает модификация Tilda? Универсальный чек-лист

Вы добавили модификацию на страницу Tilda, опубликовали сайт, но ничего не произошло. Или произошло не совсем то: стиль не применился, кнопка не реагирует, эффект работает только иногда или вместе с нужным блоком неожиданно изменились другие элементы страницы. В такой ситуации легко начать менять код наугад: переставить HTML-блок, добавить !important, поменять класс, поставить задержку в JavaScript. Иногда после этого модификация действительно начинает работать, но понять причину уже невозможно.

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

1. Проверяйте опубликованную страницу

Начните с самого простого. Если пользовательский код добавлен через стандартный блок T123 «HTML-код», Tilda прямо указывает, что в режиме редактирования и предпросмотра код отображается как текст, а для его работы страницу необходимо опубликовать. В T123 можно размещать HTML, CSS внутри <style> и JavaScript внутри <script>.

Поэтому после изменения модификации:

сохраните изменения;
опубликуйте страницу;
откройте ее по опубликованному адресу;
обновите страницу в браузере.

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

2. Проверьте, куда должен быть вставлен код

Не весь пользовательский код подключается одинаково. Tilda позволяет добавлять код в тело страницы, например через T123, а также в <head> отдельной страницы или всего сайта. Для всего сайта это делается через «Настройки сайта → Ещё → HTML-код для вставки внутрь HEAD», а для конкретной страницы — через ее дополнительные настройки. Поэтому сначала перечитайте инструкцию именно к той модификации, которую устанавливаете.

Проверьте:

весь ли код скопирован;
не потерялись ли первая или последняя строки;
остались ли на месте <style>, <script> и другие необходимые теги;
не разделили ли вы код, который должен вставляться целиком;
не вставили ли часть для HEAD в T123 или наоборот;
заменили ли значения, которые автор модификации просил заменить;
не остались ли внутри кода демонстрационные ID, ссылки или значения.

Не стоит переносить код из одного места в другое просто в надежде, что «там он заработает». Место подключения может быть частью логики самой модификации.

3. Убедитесь, что модификация предназначена именно для вашего блока

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

Например, если в инструкции сказано, что код предназначен для конкретного блока из библиотеки Tilda, не стоит автоматически применять его к другому блоку только потому, что в нем тоже есть карточки, кнопки или изображения.

Проверьте:

номер блока, указанный автором модификации;
не заменили ли вы исходный блок другим;
не скопирован ли код из статьи о совершенно другом блоке.

Если модификация рассчитана на конкретную структуру, ее нельзя считать универсальной без отдельной проверки.

4. Проверьте ID блока `#rec...`

У блоков Tilda есть ID вида #rec.... Tilda использует именно такой формат ID блока, в том числе во встроенном поиске блоков на странице. ID можно найти через настройки блока или меню блока. В пользовательских модификациях #rec... часто используют, чтобы ограничить действие кода одним конкретным блоком.

Например:

#rec123456789 .my-element {
    opacity: 0.5;
}

Здесь #rec123456789 — пример ID блока, а .my-element — условный класс элемента внутри него.

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

5. Проверьте все значения, которые нужно было изменить

У готовой модификации часто есть несколько параметров:

#rec...;
ссылка;
цвет;
текст;
класс;
ID элемента;
длительность анимации;
числовое значение;
URL изображения;
название собственной переменной.

Проверьте их по инструкции еще раз. Особенно внимательно смотрите на похожие символы и мелкие опечатки:

my-button

my_buton

Для браузера это совершенно разные значения. То же самое относится к цифрам в #rec.... Если после копирования кода нужно было изменить пять значений, а изменены только четыре, визуально это часто выглядит как «модификация вообще не работает».

6. Если проблема в CSS, не начинайте с `!important`

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

Поэтому добавлять к каждому свойству:

!important

как универсальное исправление не стоит. !important действительно меняет приоритет объявления, но MDN отдельно рекомендует не использовать его просто для борьбы со специфичностью без необходимости.

Правильный вопрос сначала другой: наш CSS вообще применяется к нужному элементу или нет? Если применяется, но проигрывает другому правилу, нужно разбираться с каскадом. Если не применяется вообще, !important не исправит ошибочный селектор.

7. Проверьте область действия CSS

Представим условное правило:

.my-button {
    border-radius: 0;
}

Оно относится ко всем элементам страницы, которые подходят под .my-button. Если модификация должна менять элемент только в одном блоке, область действия можно ограничить:

#rec123456789 .my-button {
    border-radius: 0;
}

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

8. Если проблема в JavaScript, учитывайте момент запуска

JavaScript может быть написан правильно, но запускаться тогда, когда нужного элемента еще нет. Например:

const element = document.querySelector('.my-element');

Метод querySelector() возвращает первый элемент, соответствующий селектору. Если совпадений нет, результатом будет null. То есть проблема может быть не только в неправильном классе. Возможны как минимум два варианта:

такого элемента действительно нет;
элемент существует, но в момент выполнения этого участка JavaScript еще не появился в DOM.

Один из стандартных ориентиров для запуска кода — событие DOMContentLoaded. Оно происходит после того, как HTML-документ разобран браузером и выполнены отложенные скрипты; при этом оно не ждет, например, завершения загрузки всех изображений или асинхронных скриптов.

Можно встретить конструкцию:

document.addEventListener('DOMContentLoaded', function () {
    // код
});

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

9. Не лечите проблему случайным `setTimeout`

Еще один популярный способ:

setTimeout(function () {
    // код
}, 1000);

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

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

10. Проверьте другие пользовательские модификации

Если на странице несколько T123, собственный CSS в HEAD и несколько JavaScript-модификаций, они могут влиять друг на друга. Один код может:

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

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

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

11. Если старая модификация перестала работать, не делайте вывод, что «сломалась Tilda»

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

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

12. Проверьте адаптивность

Модификация, которая работает на широком экране, еще не обязательно готова. Проверьте ее хотя бы на:

десктопной ширине;
планшете;
мобильном экране.

Особенно это важно, если код меняет:

ширину и высоту;
отступы;
позиционирование;
сетку;
display;
размеры текста;
карточки;
меню;
слайдеры;
изображения.

Если в CSS есть @media, отдельно проверьте условия, при которых включается каждое правило. Проблема может существовать только на одной ширине экрана.

13. Меняйте только одну вещь за раз

Представим, что модификация не работает, и вы одновременно:

заменили класс;
удалили #rec...;
добавили !important;
перенесли код;
добавили setTimeout.

После этого все заработало. Но определить причину уже невозможно. Гораздо полезнее:

проверить один возможный источник проблемы;
при необходимости изменить одну вещь;
опубликовать страницу;
проверить результат;
перейти к следующему пункту.

Так вы не просто чините конкретную модификацию, а начинаете понимать, почему она работает.

Универсальный чек-лист

Если модификация Tilda не работает, идите сверху вниз.

Страница опубликована?
Вы проверяете опубликованный URL?
Код скопирован полностью?
Он вставлен туда, куда требует инструкция?
Все переменные и настройки заменены?
Модификация предназначена именно для вашего блока?
Правильно указан #rec..., если он используется?
Не остались ли в коде чужие ID, ссылки или значения?
CSS ограничен нужным блоком или случайно действует шире?
Не пытаетесь ли вы исправить ошибочный селектор через !important?
Может ли JavaScript запускаться раньше появления нужного элемента?
Нет ли других пользовательских модификаций, которые могут конфликтовать с этой?
Не устарела ли модификация относительно текущей структуры блока?
Работает ли результат на разных ширинах экрана?

Уже этот алгоритм позволяет серьезно сузить круг причин даже человеку, который не пишет JavaScript самостоятельно. Вместо «Модификация не работает» вы постепенно приходите к более полезному выводу: «Код подключен, но работает не с тем блоком», «CSS действует, но переопределяется», «JavaScript не находит нужный элемент» или «Отдельно модификация работает, а вместе с другим кодом — нет». После этого проблему уже можно искать предметно.

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

Как проверить модификацию через инструменты разработчика

Инструменты разработчика позволяют посмотреть страницу такой, какой ее видит браузер после публикации. Для нашей задачи особенно важны две части: Elements — HTML-структура страницы и применяемые CSS-правила, и Console — выполнение небольших JavaScript-команд, диагностические сообщения и ошибки. В разных браузерах названия и расположение панелей могут немного отличаться.

Проверяем, существует ли нужный `#rec`

Предположим, в модификации используется:

#rec123456789 .my-element {
    opacity: 0.5;
}

Здесь .my-element — условный пример, а #rec123456789 нужно заменить на реальный ID проверяемого блока. В Console выполните:

document.querySelector('#rec123456789')

Если браузер возвращает HTML-элемент, такой ID найден. Если результат:

null

совпадения нет. По спецификации querySelector() именно так и работает: возвращает первый найденный элемент либо null, если ничего не найдено. Значит, сначала проверяем правильность #rec.

Проверяем нужный элемент внутри блока

Теперь можно проверить селектор целиком:

document.querySelector('#rec123456789 .my-element')

Если браузер возвращает элемент, селектор соответствует чему-то на странице. Если результат — null, браузер не нашел такой элемент внутри указанного блока.

Возможные причины:

неправильный #rec;
неправильный класс;
код рассчитан на другой блок;
нужного элемента пока нет;
структура блока отличается от той, на которую рассчитывает модификация.

Это уже гораздо полезнее, чем просто знать, что «CSS не сработал».

Считаем количество элементов

Если модификация должна работать сразу с несколькими элементами, выполните:

document.querySelectorAll('.my-element').length

querySelectorAll() возвращает список всех элементов, соответствующих селектору. Если совпадений нет, возвращается пустой список, поэтому его length будет равен 0. Например, результат 6 означает, что найдено шесть элементов, а 0 — что ни одного совпадения нет.

Считаем элементы только внутри конкретного блока

Чтобы не учитывать одинаковые классы в других частях страницы, используйте:

document.querySelectorAll('#rec123456789 .my-element').length

Это один из самых полезных приемов при работе с Tilda. Если на всей странице найдено 12 элементов, а внутри нужного #rec — 0, проблема становится очевиднее.

Как узнать реальный класс элемента

Если вы не знаете, какой класс установлен у кнопки, текста или карточки, не угадывайте. Откройте панель Elements и выберите нужный элемент непосредственно на странице. Вы увидите его фактический HTML, например:

<a class="example-button example-button_active">

Здесь классы example-button и example-button_active — условный пример. В реальной странице нужно использовать те значения, которые вы действительно увидели в DevTools. Это принципиально важно: классы стандартного блока нельзя надежно определять по внешнему виду элемента или придумывать по аналогии с другим блоком.

CSS есть, но визуально не работает

Выберите элемент в Elements и найдите нужное правило в панели Styles. Здесь возможны две принципиально разные ситуации.

Правила вообще нет. Тогда нужно проверять, подключился ли CSS, правильный ли селектор и правильный ли #rec.

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

Можно проверить итоговое CSS-значение через Console

Для более точной диагностики есть еще один прием:

const element = document.querySelector('.my-element');
getComputedStyle(element).display;

getComputedStyle() возвращает вычисленные браузером значения CSS-свойств элемента после применения активных стилей. Например, можно проверить:

getComputedStyle(element).color

или:

getComputedStyle(element).opacity

Это полезно, когда визуально непонятно, какое значение в итоге победило. Если document.querySelector() вернул null, сначала нужно исправить поиск элемента. Вызывать getComputedStyle() для несуществующего элемента смысла нет.

Проверяем, запускается ли JavaScript

Иногда проблема находится еще раньше: нужный JavaScript вообще не доходит до своей основной логики. Для проверки временно добавьте:

console.log('Modification started');

После публикации страницы откройте Console и обновите страницу. console.log() выводит диагностическое сообщение в консоль браузера. Если сообщение появилось, эта строка выполнилась. Если нет — нужно проверять подключение кода и участок, внутри которого находится сообщение. После диагностики такие временные сообщения лучше удалить.

Определяем место, где останавливается скрипт

Предположим, есть код:

console.log('step 1');

const element = document.querySelector('.my-element');

console.log('step 2');

element.classList.add('active');

console.log('step 3');

Если в Console появились:

step 1
step 2

но нет:

step 3

значит, выполнение остановилось между второй и третьей контрольными точками. Теперь вместо проверки всего скрипта нужно исследовать одну строку:

element.classList.add('active');

Например, element мог оказаться равен null. Проверяем:

console.log(element);

Если видим null, становится понятно, что скрипт пытается работать с элементом, который не был найден.

Смотрим ошибки в Console

JavaScript-ошибки — еще один важный источник информации. Браузерные инструменты разработчика позволяют увидеть ошибки выполняемого JavaScript, а console.log() и console.error() используются в том числе для диагностики. Не обязательно сразу понимать длинное сообщение полностью.

Начните с трех вещей:

какая ошибка появилась первой;
какой файл или пользовательский код указан;
на какой строке возникла проблема.

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

Модификация работает через раз

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

document.querySelector('.my-element')

в момент, когда код должен работать. Если иногда получается элемент, а иногда null, проблема может быть связана с моментом появления элемента. Тогда случайный setTimeout() способен замаскировать проблему, но не обязательно исправит ее надежно.

Если элемент действительно добавляется в DOM позднее, для отслеживания таких изменений существует MutationObserver. Но сначала установите сам факт динамического появления элемента. Не усложняйте простой код без необходимости.

Проверяем конфликт двух модификаций

Если код работает отдельно, но перестает работать после подключения другой модификации:

оставьте только первую модификацию;
опубликуйте страницу;
проверьте результат;
подключите вторую;
опубликуйте снова;
проверьте Console;
посмотрите, работают ли оба скрипта с одними элементами или классами.

Это намного эффективнее, чем переписывать обе модификации одновременно.

Минимальный набор команд Console

Проверить элемент:

document.querySelector('.my-element')

Проверить блок:

document.querySelector('#rec123456789')

Проверить элемент внутри блока:

document.querySelector('#rec123456789 .my-element')

Посчитать элементы:

document.querySelectorAll('.my-element').length

Посчитать их только внутри блока:

document.querySelectorAll('#rec123456789 .my-element').length

Посмотреть найденный элемент:

console.log(document.querySelector('.my-element'))

Проверить, выполняется ли участок вашего кода:

console.log('Reached this point');

Посмотреть итоговое значение CSS-свойства:

const element = document.querySelector('.my-element');
getComputedStyle(element).display;

Для большинства базовых проверок этого уже достаточно.

Как диагностировать модификацию с нуля

Если перед вами незнакомый код, используйте один порядок каждый раз:

проверьте инструкцию к модификации;
опубликуйте страницу;
убедитесь, что код подключен в правильном месте;
проверьте все значения, которые нужно было заменить;
проверьте #rec, если он используется;
найдите реальный элемент через Elements;
выполните его селектор через querySelector();
если элементов несколько, проверьте количество через querySelectorAll(...).length;
если проблема в CSS, найдите свое правило в Styles;
если проблема в JavaScript, проверьте Console;
при необходимости поставьте временные console.log() перед подозрительными участками;
отключите другие пользовательские модификации и повторите проверку;
после исправления снова протестируйте опубликованную страницу на разных ширинах.

Главное здесь не количество команд, которые вы знаете. Нужно каждый раз отвечать на вопросы последовательно: код подключился? Нужный блок существует? Нужный элемент существует? Селектор его находит? CSS действительно применяется? JavaScript доходит до нужной строки? Другой код не вмешивается?

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