Проблема обычно всплывает не в момент настройки формы, а уже после запуска: пользователь открывает страницу, а браузер подставляет в поля чужой e-mail, старый телефон или адрес из другого аккаунта. Для контактной формы это раздражает, для заявки на услугу — уже риск ошибки в данных. В WordPress и WPForms это решается не одним переключателем, а набором мер: отключение автозаполнения, корректная разметка полей и проверка того, что браузер действительно перестал подставлять сохранённые значения.
Когда это действительно проблема
Сценарий легко узнать по симптомам:
- в поле имени или телефона появляется значение, которое пользователь не вводил на этой странице;
- после очистки формы браузер снова подставляет старые данные;
- на мобильных устройствах автозаполнение конфликтует с маской телефона или маской e-mail;
- в заявке уходит неверный контакт, хотя форма визуально выглядит заполненной правильно.
Важно не путать автозаполнение браузера с автоподстановкой данных из плагина, cookie или пользовательского профиля. Если значение приходит из PHP-фильтра или JavaScript, отключение autocomplete в HTML может не помочь.
Диагностика: откуда берутся лишние значения
Сначала проверьте, кто именно заполняет поле. Это можно сделать без сложной отладки:
- Откройте страницу в режиме инкогнито.
- Очистите сохранённые данные автозаполнения в браузере, если тестируете в обычном окне.
- Сравните поведение в Chrome, Firefox и Safari — они по-разному трактуют атрибуты
autocomplete. - Посмотрите исходный HTML формы: есть ли у полей корректные
name,idи атрибуты автозаполнения.
Если в инкогнито всё чисто, а в обычном окне значения подставляются, значит проблема именно в браузерном автозаполнении. Если же данные появляются всегда, ищите код темы, сниппет или плагин, который подставляет значения программно.
Что делать в WPForms: пошаговое решение
1. Отключить автозаполнение на уровне HTML
WPForms не всегда даёт тонкую настройку для каждого поля через интерфейс, поэтому надёжнее добавить фильтр и принудительно выставить autocomplete="off" для нужной формы. Ниже пример для конкретной формы по ID.
<?php
add_filter( 'wpforms_frontend_field_properties', function( $properties, $field, $form_data ) {
$target_form_id = 123;
if ( (int) $form_data['id'] !== $target_form_id ) {
return $properties;
}
if ( empty( $properties['inputs'] ) || ! is_array( $properties['inputs'] ) ) {
return $properties;
}
foreach ( $properties['inputs'] as $key => $input ) {
if ( isset( $input['attr'] ) && is_array( $input['attr'] ) ) {
$properties['inputs'][ $key ]['attr']['autocomplete'] = 'off';
}
}
return $properties;
}, 10, 3 );Если у вас в конкретной версии WPForms структура свойств поля отличается, не пытайтесь «угадать» массив наугад. Сначала выведите $properties в лог и проверьте, какие атрибуты реально доступны для поля, которое нужно изменить.
2. Задать более точные значения для чувствительных полей
Браузеры часто игнорируют общий autocomplete="off" для логина, e-mail и телефона. В таких случаях помогает не запрет, а более точная семантика. Для e-mail и телефона можно использовать значения, которые браузер понимает корректнее, а для полей, где автозаполнение нежелательно, — нестандартные значения, если это не ломает UX.
<?php
add_filter( 'wpforms_frontend_field_properties', function( $properties, $field, $form_data ) {
if ( (int) $form_data['id'] !== 123 ) {
return $properties;
}
if ( isset( $field['type'] ) && $field['type'] === 'email' ) {
$properties['inputs'][0]['attr']['autocomplete'] = 'email';
}
if ( isset( $field['type'] ) && $field['type'] === 'phone' ) {
$properties['inputs'][0]['attr']['autocomplete'] = 'tel';
}
return $properties;
}, 10, 3 );Это не «отключение» в буквальном смысле, но на практике помогает избежать странной подстановки старых значений в неподходящие поля. Особенно это полезно, если форма используется на странице с несколькими похожими полями и браузер путает их назначение.
3. Сбросить значения при загрузке формы через JavaScript
Если браузер упорно восстанавливает значения после рендера, можно очистить поля на клиенте. Делать это нужно аккуратно: не трогайте поля, которые пользователь уже начал заполнять, и не сбрасывайте скрытые поля, если они нужны для логики формы.
<script>
document.addEventListener('DOMContentLoaded', function () {
var form = document.querySelector('.wpforms-form[data-formid="123"]');
if (!form) return;
var fields = form.querySelectorAll('input[type="text"], input[type="email"], input[type="tel"], textarea');
fields.forEach(function (field) {
if (field.value && field.dataset.keepValue !== '1') {
field.value = '';
}
});
});
</script>Этот вариант имеет смысл только если вы точно знаете, что форма не должна подхватывать значения из предыдущего сеанса. Для личного кабинета или формы редактирования профиля такой сброс будет ошибкой.
Сравнение подходов
| Подход | Когда использовать | Минус |
|---|---|---|
HTML autocomplete="off" | Обычные контактные формы, заявки, обратная связь | Не все браузеры строго соблюдают |
Точные значения autocomplete | E-mail, телефон, адресные поля | Нужно понимать семантику поля |
| JavaScript-сброс | Когда браузер всё равно восстанавливает значения | Можно случайно очистить нужные данные |
Проверка результата после внедрения
После правок не ограничивайтесь одним тестом в текущем браузере. Проверьте минимум три сценария:
- открытие формы в инкогнито;
- открытие формы в обычном окне после сохранённых автозаполнений;
- отправка формы с телефона, где автозаполнение часто ведёт себя иначе, чем на десктопе.
Что считать успешным результатом:
- поля не подставляются сами при загрузке страницы;
- браузер не предлагает старые данные в неподходящих местах;
- отправка формы проходит без ошибок валидации и без пустых обязательных полей.
Если вы меняли HTML через фильтр, откройте исходный код страницы и убедитесь, что атрибут действительно присутствует у нужного input. Если использовали JS-сброс, проверьте, что значения очищаются только после рендера и не ломают маски ввода.
Частые ошибки и как их исправить
Отключили автозаполнение только у контейнера, а не у input
Браузер ориентируется на сам элемент ввода. Если атрибут стоит на обёртке, а не на input, он может его проигнорировать. Проверяйте именно разметку поля.
Сбросили значения у всех полей подряд
Так часто ломают скрытые поля, nonce, prefill из CRM и пользовательские подсказки. Ограничивайте код конкретной формой и конкретными типами полей.
Путают автозаполнение браузера и автоподстановку из темы
Если значение приходит из cookie, localStorage или PHP-фильтра, отключение autocomplete ничего не изменит. В этом случае ищите источник данных в теме, сниппетах и плагинах.
Тестируют только в одном браузере
Chrome может игнорировать часть настроек иначе, чем Safari. Для форм с телефоном и e-mail это особенно заметно.
Безопасность и производительность
Само по себе отключение автозаполнения не нагружает сайт, но есть два практических момента. Во-первых, не храните в форме лишние персональные данные, если они не нужны для обработки заявки. Во-вторых, не используйте агрессивный JavaScript-сброс на всех страницах — это лишний код на фронтенде и дополнительный риск сломать другие формы.
Если форма критична для бизнеса, лучше держать правку в маленьком mu-plugin или в отдельном сниппете, а не в functions.php активной темы. Так проще сопровождать изменения после обновления темы.
Когда лучше не отключать автозаполнение полностью
Полный запрет не всегда полезен. Для формы авторизации, восстановления доступа или повторного заказа автозаполнение может экономить время и снижать число ошибок. В таких сценариях лучше точечно управлять полями, а не ставить универсальный запрет на всю форму.
Если нужна именно защита от подстановки неверных данных, начните с диагностики, затем ограничьте автозаполнение на уровне конкретных полей и только потом добавляйте JavaScript. Такой порядок обычно даёт предсказуемый результат без побочных эффектов.