Разработка модуля управления редиректами 1С-Битрикс

Разработка модуля управления редиректами 1С-Битрикс

После переезда каталога на новую структуру URL поисковик начинает фиксировать тысячи 404-ошибок. Старые URL были вида /catalog/product-123.html, новые — /catalog/category/product-name/. Прописать 8 000 редиректов в .htaccess — технически работает, но Apache/Nginx перестают справляться с парсингом файла при больших объёмах, а редактирование в любом текстовом редакторе превращается в кошмар. Модуль управления редиректами решает задачу через БД с удобным интерфейсом.

Почему не .htaccess при большом объёме

Apache начинает заметно тормозить при количестве правил RewriteRule в .htaccess свыше 500–1000: файл парсируется заново для каждого запроса, если не настроено кеширование (директива AllowOverride). Nginx читает конфигурацию единожды при запуске — но перезапуск Nginx при добавлении каждого нового редиректа неприемлем в production.

Хранение правил в БД с обработкой на уровне PHP — компромиссное решение: чуть медленнее аппаратного Nginx-редиректа, но позволяет управлять правилами в реальном времени без рестарта сервисов и содержит весь инструментарий: история изменений, статистика срабатываний, импорт/экспорт.

Архитектура модуля

Таблица правил:

CREATE TABLE myvendor_redirect (
    id          SERIAL PRIMARY KEY,
    source      VARCHAR(500) NOT NULL,      -- /old/path/ или regex
    destination VARCHAR(500) NOT NULL,
    code        SMALLINT NOT NULL DEFAULT 301,
    is_regex    BOOLEAN DEFAULT false,
    priority    INT DEFAULT 100,
    hits        INT DEFAULT 0,
    active      BOOLEAN DEFAULT true,
    created_at  TIMESTAMP DEFAULT NOW(),
    created_by  INT
);

CREATE UNIQUE INDEX idx_redirect_source ON myvendor_redirect(source) WHERE NOT is_regex;
CREATE INDEX idx_redirect_active ON myvendor_redirect(active, priority);

Обработчик. Правила загружаются в обработчик события OnPageStart. Статические правила (точное совпадение URL) проверяются первыми через isset по ассоциативному массиву — O(1). Регулярные выражения проверяются только если статического совпадения нет — итерация по отсортированному по priority массиву.

AddEventHandler('main', 'OnPageStart', [\MyVendor\Redirect\Handler::class, 'handle']);

Кеширование правил. Весь список правил кешируется в Bitrix\Main\Data\Cache с тегом myvendor_redirect. При изменении любого правила кеш сбрасывается. TTL кеша — 1 час как защита от забытого сброса.

Детально: импорт из .htaccess и CSV

После миграции у клиента обычно есть либо старый .htaccess, либо Excel со старыми и новыми URL. Модуль включает парсер обоих форматов.

Парсер .htaccess:

// Пример строки: RewriteRule ^old/(.*)$ /new/$1 [R=301,L]
preg_match('/^RewriteRule\s+\^([^\$]+)\$?\s+(\S+)\s+\[([^\]]+)\]/', $line, $m);

Модуль извлекает source, destination, код редиректа и флаг регулярного выражения. Правила со сложными условиями (RewriteCond) импортируются с предупреждением — их нужно проверить вручную.

Импорт CSV. Формат: old_url;new_url;code. Перед импортом — валидация: дубли источников, проверка на циклические редиректы (A → B → A), проверка доступности destination-URL (опционально, через HEAD-запрос).

Обнаружение 404-ошибок

Модуль логирует 404-ответы в таблицу myvendor_redirect_404. В административном интерфейсе — список самых частых 404-адресов с количеством обращений, кнопкой «Создать редирект» прямо из этого списка. Это главный инструмент для работы с миграцией: видишь самые популярные несуществующие URL и создаёшь редиректы в один клик.

Статистика и аналитика

Каждое срабатывание правила увеличивает счётчик hits. В интерфейсе — сортировка правил по количеству срабатываний, выявление «мёртвых» правил (нет срабатываний за 90 дней — кандидаты на удаление).

Сроки разработки

Если на проекте Nginx с возможностью динамической конфигурации (например, через Nginx Plus или OpenResty с lua), стоит рассмотреть хранение правил в Redis с Nginx-чтением — это даст редиректы без PHP-обработки.