Разработчики на платформе 1С-Битрикс нередко сталкиваются с сообщением об ошибке $strError: «Пустой поисковый запрос (запрос не содержит букв или цифр)». Эта ошибка возникает при работе с модулем поиска (search) при попытке выполнить запрос‚ который система считает невалидным. В данной статье подробно разберем‚ почему это происходит‚ как отладить проблему и какие есть способы её устранения.

Понимание механизма ошибки

Модуль поиска Битрикса имеет встроенную валидацию входящего запроса. Перед тем как обратиться к индексу или базе данных‚ система проверяет строку запроса на наличие алфавитно-цифровых символов (букв и цифр).

Если после очистки от спецсимволов‚ стоп-слов и лишних пробелов строка оказывается пустой‚ выбрасывается исключение или возвращается ошибка $strError с текстом: «Пустой поисковый запрос (запрос не содержит букв или цифр)».

Ключевые моменты валидации:

• Проверяется наличие символов‚ подходящих под регулярное выражение типа [a-zA-Zа-яА-Я0-9] (с учетом локали).
• Спецсимволы (!‚ @‚ #‚ $‚ %‚ ^‚ &‚ *‚ (‚ )‚ -‚ _‚ =‚ +‚ [‚ ]‚ {‚ }‚ |‚ ‚ ;‚ :‚ '‚ "‚ ‚‚ .‚ /‚ ?‚ ~‚ `) и пробелы игнорируются при подсчете «веса» запроса.
• Стоп-слова (предлоги‚ союзы‚ частицы вроде «и»‚ «в»‚ «на»‚ «не») удаляются на этапе парсинга‚ если они не входят в состав фразового поиска.

Типичные сценарии возникновения

Сценарий А: Пользователь ввел только спецсимволы или пробелы

Самый частый кейс. Посетитель сайта вводит в строку поиска: «!!!»‚ «...»‚ « » или просто нажимает Enter в пустом поле.

Сценарий Б: Автоматические запросы от ботов/сканеров

Поисковые боты или вредоносные сканеры могут обращаться к компоненту поиска с пустыми параметрами (?q= или ?q=%20%20)‚ что провоцирует запись ошибок в лог.

Сценарий В: Некорректная передача параметра в компоненте

При кастомизации bitrix:search.title или bitrix:search.page разработчик может случайно передать пустую переменную $arParams["QUERY"] или некорректно обработать $_REQUEST["q"] до вызова компонента.

Сценарий Г: Фильтрация через $userFilter (ссылка на форум)

Как указано в обсуждении на форуме разработчиков‚ ошибка может возникать при попытке использовать массив $userFilter для уточнения поиска‚ если итоговый сформированный запрос к индексу оказывается пустым после применения всех фильтров.

Диагностика и поиск источника

Прежде чем исправлять‚ нужно точно локализовать‚ где именно генерируется ошибку.

1. Логи ошибок (/bitrix/php_interface/error.log или настройки логирования в .settings.php): Ищите стек вызовов (stack trace). Обычно ошибка инициируется в методе CSearch::Search или внутри компонента bitrix:search.page.
2. Панель производительности (Bitrix Debug Panel): Включите режим отладки‚ выполните поиск с пустой строкой и посмотрите‚ какой компонент и какой параметр передается.
3. Проверка $_REQUEST: Добавьте временный var_dump($_REQUEST['q']) (или ваш параметр запроса) в header.php или в result_modifier.php компонента поиска.

Способы решения

Решение 1: Клиентская валидация (Frontend) — Рекомендуемое

Не дайте пустому запросу долететь до сервера. Добавьте проверку в JavaScript формы поиска.

<form action="/search/" method="get" onsubmit="return validateSearch(this)">
 <input type="text" name="q" id="search-input" placeholder="Что ищем?">
 <button type="submit">Найти</button>
</form>

<script>
function validateSearch(form) {
 var query = form.elements['q'].value.trim;
 // Удаляем всё‚ кроме букв и цифр для проверки "сути" запроса
 var meaningful = query.replace(/[^a-zA-Zа-яА-Я0-9]/g‚ '');
  if (meaningful.length === 0) {
 alert('Введите поисковый запрос (минимум 1 буква или цифра)');
 form.elements['q'].focus;
 return false; // Отменяем отправку
 }
 return true;
}
</script>

Решение 2: Серверная валидация в result_modifier.php компонента

Если вы используете стандартный компонент bitrix:search.title или bitrix:search.page‚ лучшее место для перехвата — файл result_modifier.php в шаблоне компонента (или .parameters.php / кастомный класс).

<?php
if (!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED !== true) die;

// Получаем исходный запрос
$rawQuery = isset($_REQUEST['q']) ? trim($_REQUEST['q']) : '';

// Проверяем на наличие алфавитно-цифровых символов
if ($rawQuery === '' || !preg_match('/[a-zA-Zа-яА-Я0-9]/u'‚ $rawQuery)) {
 // Вариант А: Показываем пустой результат / сообщение‚ не вызывая ядро поиска
 $arResult["ITEMS"] = array;
 $arResult["ERROR"] = "Пустой поисковый запрос. Введите слово для поиска.";
 // Важно: прерываем дальнейшую обработку компонентом‚ если это возможно‚
 // или просто возвращаем пустой массив результатов.
 // Для bitrix:search.page часто проще проверить в template.php
 return; 
}

// Если запрос валиден‚ компонент продолжит работу стандартным образом
?>

Решение 3: Обработка в template.php (для bitrix:search.page)

Компонент bitrix:search.page часто уже выполнил запрос к БД к моменту рендеринга шаблона. Чтобы избежать лишнего запроса к БД и ошибки в логах‚ проверку лучше делать в result_modifier.php (см. выше). Но если нужно просто скрыть ошибку $strError в шаблоне:

<?php if (!empty($arResult["ERROR"])): ?>
 <div class="search-error alert alert-warning">
 <?= $arResult["ERROR"] ?>
 </div>
<?php elseif (empty($arResult["ITEMS"])): ?><?php else: ?>
<?php endif; ?>

Решение 4: Настройка .settings.php (подавление логирования)

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

'exception_handling' => 
array (
 'value' => 
 array (
 'debug' => false‚
 'handled_errors_types' => E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED‚
 'exception_handlers' => 
 array (
 // Можно добавить свой обработчик для CSearchException
 )‚
 )‚
 'readonly' => true‚
)‚

Лучше исправить логику‚ чем подавлять ошибки.

Особенности работы с $userFilter (API)

Если вы пишете кастомный поиск через API (CSearch::Search)‚ и используете параметр USER_FILTER (как в теме на форуме)‚ помните:

• Фильтр применяется после парсинга текстового запроса.
• Если текстовый запрос (QUERY) пуст или состоит только из стоп-слов/спецсимволов‚ поиск не выполнится‚ даже если USER_FILTER содержит валидные условия (например‚ фильтр по ID раздела).
• Workaround: Если нужно искать только по фильтру (без текстового запроса)‚ передайте в QUERY любой валидный символ (например‚ * — звездочка часто работает как wildcard‚ но лучше передать редкое слово или сгенерированный токен)‚ либо используйте прямой запрос к CIBlockElement::GetList без модуля поиска.

Чек-лист предотвращения ошибки

Резюме

Ошибка «Пустой поисковый запрос (запрос не содержит букв или цифр)» — это защитный механизм 1С-Битрикс‚ предотвращающий бесполезную нагрузку на поисковый индекс и БД. Она не является критической для работоспособности сайта‚ но засоряет логи и ухудшает UX (пользователь видит «системную» ошибку вместо понятного сообщения).

Главное правило: валидируйте запрос на клиенте (для UX) и на сервере в result_modifier.php компонента (для безопасности и чистых логов) до вызова ядра поиска.

Статья подготовлена на основе документации 1С-Битрикс и обсуждений на форуме разработчиков (dev.1c-bitrix.ru). Актуально на 2026 год.