Как я похоронил Drupal и не потерял пятнадцать лет истории небольшого города

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

Его ценность давно не в новостях — кому интересна заметка о ремонте теплотрассы десятилетней давности. Ценность в другом: это слепок целого периода жизни города, зафиксированный так, как его больше никто не зафиксирует. А современный интернет плохо хранит память: сайты закрываются, домены не продлеваются, и целые пласты локальной истории исчезают без следа. Бросить такое я не мог.

Когда старый движок начинает мстить

Беда в том, что время безжалостно к техническому долгу. Движок сайта — Drupal шестой ветки — не обновлялся много лет, потому что обновляться там некуда: ветка мертва, сообщество давно ушло вперёд. При этом сайт оставался объёмным и старым, а значит — привлекательной целью для поисковых ботов, скрейперов и прочих автоматических клиентов, которые особенно любят архивные ресурсы с богатой историей ссылок.

Начинался замкнутый круг. Боты нагружали сайт без перерыва, таблица кеша разрасталась до неприличных размеров, таблица сессий переполнялась, сервер время от времени падал под нагрузкой — и я в очередной раз шёл чинить то, что сломалось без единого моего действия. Вывод напрашивался сам: содержать это дальше в прежнем виде дорого, бессмысленно и с каждым годом только хуже. Но и бросить сайт умирать не хотелось.

Почему очевидные решения не подходили

Раз обновлений не предвидится, значит, движок вообще не нужен — нужна статика. Логично. Но как её получить — вопрос не такой тривиальный, как кажется.

Самый простой путь — выкачать сайт целиком, страница за страницей. Быстро, но криво: на старом Drupal обязательно накопилась гора дублей — одни и те же материалы доступны по нескольким адресам, с разными параметрами, через таксономии и без. При таком подходе поиск по сайту перестанет работать, а любая мелкая правка в будущем с высокой вероятностью что-нибудь сломает, потому что структура окажется непрозрачной массой скачанного HTML.

Второй вариант — перенести содержимое на новый движок целиком, с базой, таксономиями и нормальной моделью данных. Звучит правильно, но по трудозатратам это отдельный полноценный проект, а не вечер работы. И главное — риск потерять самое ценное: структуру ссылок. На такой архив годами ссылались соцсети, форумы, другие сайты и поисковая выдача. Сломать адреса — значит уничтожить ту самую память, ради которой всё затевалось.

Решение нашлось на стыке анализа и автоматизации

В итоге я поручил Claude Code разобрать сайт по частям: проанализировать шаблоны отображения, структуру базы данных и логику формирования адресов, а затем перевести всё это на Hugo — лёгкий генератор статических сайтов, которому не нужны ни сервер приложений, ни база данных, ни PHP.

Работа заняла несколько часов в полуавтоматическом режиме: модель разбирала дамп базы, извлекала материалы, восстанавливала связи между сущностями, генерировала шаблоны, максимально близкие к оригинальным, и раскладывала всё в структуру, которая один в один повторяет старые адреса. После первого прохода понадобилось несколько итераций правок — где-то поехала вёрстка, где-то таксономия отобразилась не так, как нужно, — но это уже было похоже на обычную вычитку, а не на разработку с нуля.

Что получилось на выходе

Результат превзошёл ожидания. Вместо тяжёлой связки MySQL и древнего PHP-кода — лёгкий и быстрый сайт, внешне почти неотличимый от старого. Нагрузка на сервер по памяти и процессору упала на порядки: nginx просто отдаёт статические файлы. Объём данных сократился на порядок: вместо гигабайтов малопонятного кеша Drupal в базе теперь набор лёгких HTML-файлов, которые можно скопировать на флешку и хранить хоть двадцать лет — для жизни им не нужен ни один работающий процесс.

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