Патчи к ядру 1С‑Битрикс: повтор после обновлений и хранение в git

Почему тема актуальна

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

Вариант 1: вставить правку «на лету»

Смысл простой: при каждом заходе в административную часть проверяем файл ядра; если наш маркер отсутствует (обновление перезаписало файл), аккуратно вносим нужный блок кода снова. Ниже — иллюстрация на случай ограничения числа строк в Excel‑выгрузке: маркер bz_sheet_export_soft_cap гарантирует однократность, а условие смотрит на режим экспорта в запросе.

Размещают такой блок, как правило, в bitrix/php_interface/admin_header.php. Минусы очевидны: хрупкая привязка к регулярному выражению под конкретную версию файла и необходимость иметь право на запись в каталог /bitrix.

$targetPath = $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/interface/admin_lib.php';
$blob = file_get_contents($targetPath);
$marker = 'bz_sheet_export_soft_cap';
if (strpos($blob, $marker) !== false) {
    return;
}
$rule = '#(function\s+GetNavSize\s*\([^)]*\)\s*\{)#s';
$note = '// ' . $marker;
$paste = '${1}' . "\n\tif (htmlspecialchars((string)($_REQUEST['mode'] ?? '')) === 'excel') {" . "\n\t\treturn 5000000; \n\t} " . $note . "\n\t";
if (preg_match($rule, $blob)) {
    $blob = preg_replace($rule, $paste, $blob, 1);
    file_put_contents($targetPath, $blob);
}

Вариант 2: сохранить дифф в репозитории

Второй путь надёжнее для аудита: вы правите файл ядра на копии, фиксируете коммит и снимаете текстовый патч или unified diff между коммитами. После обновления движка сравниваете новую версию файла со своим патчем, при необходимости поправляете контекст и накладываете снова.

Типичные команды сохранения:

• git format-patch --stdout -1 HEAD > patches/bitrix-soft-cap.patch — один последний коммит как патч.
• git diff <old> <new> -- path/to/file.php > patches/fragment.patch — ограниченный фрагмент.

Патчи живут под тем же git, что и сайт — либо в том же коммите что и правки, либо отдельным коммитом сразу после.

Вклеивание из файла

Классическая утилита patch с «мягкой» трактовкой пробелов и нулевым префиксом пути часто совпадает с тем, как Битрикс раскладывает дерево модулей:

patch -p0 -l --forward -i patches/bitrix-soft-cap.patch

С git можно сначала проверить наложение без записи:

git apply --check patches/bitrix-soft-cap.patch && git apply patches/bitrix-soft-cap.patch

Практика на продакшене

• После каждого накладывания патча просматривайте предупреждения patch/git apply и гоните короткий сценарий, который упирается в вашу правку.
• В идеале тот же патч прогоняется на staging с той же веткой обновления, что получит боевой стенд.
• Документируйте, зачем нужен патч и какой задаче сервиса он соответствует — через полгода по diff одному автору уже не восстановить мотивацию.

Соседний материал о росте свойств до LONGTEXT можно читать в связке с этим: сохранённые диффы и «рантайм‑вставки» дополняют друг друга, но не заменяют здравое стремление вынести логику в собственное пространство, пока платформа это позволяет.