Хак с Form API в Drupal 7: создаём HTML5‑поля (number, email, tel) без лишних модулей

Drupal 7 предлагает мощный Form API для построения форм. Однако при работе с HTML5‑атрибутами можно столкнуться с неожиданным ограничением: если вы попытаетесь задать тип поля numberemail или tel стандартным способом, Drupal проигнорирует ваше значение и оставит тип text (или тот, который определён через #type).

Рассмотрим ситуацию: нам нужно поле для ввода числа с шагом 10 и ограничениями от 0 до 100. Логично использовать HTML5‑тип number:

Но на выходе мы получим <input type="text" ...>. Почему? Потому что Drupal при рендеринге элемента проставляет тип, основываясь на #type (в данном случае textfield), и атрибут type из #attributes перезаписывается внутренним значением.

Опытные разработчики Drupal 7 знают небольшой хак: если добавить пробел в начало ключа атрибута, Drupal не сможет его сопоставить со своим внутренним списком и просто склеит все атрибуты в итоговом теге. В результате в HTML появятся два атрибута type.

После рендеринга получится примерно такой HTML:

Когда мы добавляем в #attributes элемент с ключом ' type' (с пробелом), Drupal воспринимает его как обычный атрибут, но из-за пробела в имени ключа внутренний механизм Form API не распознаёт его как атрибут type, подлежащий перезаписи. Однако при финальном рендеринге функция drupal_attributes() обрабатывает массив атрибутов и обрезает пробелы в именах ключей. В результате в итоговой разметке атрибут появляется уже без пробела, как обычный type="number".

Как это работает?

Можно заметить интересную деталь: в реальном HTML-коде, который генерирует Drupal, наш атрибут type="number" появляется до стандартного type="text", а не после, как можно было бы ожидать. При этом поле всё равно работает как числовое. Давайте разберёмся почему так происходит, и почему хак не перестаёт работать из-за повторяющихся атрибутов.

Формально это невалидный HTML — атрибут не должен повторяться. Однако браузеры при разборе HTML достаточно либеральны и, как правило, применяют первое встретившееся значение атрибута, игнорируя последующие. В нашем случае браузер видит сначала type="number" и создаёт числовое поле, а второй type="text" просто не оказывает влияния. Именно поэтому хак работает, даже если стандартный type идёт после.

Конечно, поведение браузеров в такой ситуации чётко не специфицировано, и разные версии или браузеры могут теоретически обрабатывать это иначе. Но многолетняя практика использования этого приёма в Drupal 7 показывает, что во всех современных браузерах (Chrome, Firefox, Safari, Edge) поле становится именно того типа, который указан первым.

Мало букафф? Читайте есчо !

Использование cache API Drupal 7

Май 14, 2019 г.

Изучение API удобно начинать с шаблонов кода, которые демонстрируют технику использования. Пример логики использования/создания элемента кеша [crayon-6a26d67e7f451115201488/] Обратите внимание на дополнительные скобки вокруг $cache = cache_get($cache_id). ...

Читать

Глюк модуля transliteration в php 7.3.

Октябрь 20, 2019 г.

Столкнулся со следующим неприятным багом, при использовании модуля pathauto, совместно с модулем транслитерации: Drupal генерирует "обрезанные" синонимы адресов страниц. Длина получаемого синонима плавала от 40-70 символов, и я никак не мог понять ...

Читать

Возможные проблемы Invalid form POST data

Октябрь 24, 2019 г.

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

Читать

Получить имя текущей темы по дефолту в Drupal

Январь 21, 2019 г.

Theme API к сожалению не даёт прямого метода, чтобы прочитать это значение. Как его получить? Иногда программно нужно установить, что именно видит пользователь на фронт-енд (какую тему использует движок). Необходимость возникает из-за того, ...

Читать
 

Комментарии к «Хак с Form API в Drupal 7: создаём HTML5‑поля (number, email, tel) без лишних модулей»

Понравилась статья? Есть вопросы? - пишите в комментариях.



Комментарий: