Domus Grand запущен: что начинается после «сайт готов»
В предыдущей части проекта визуальная страница уже была доведена до рабочего демо, а следующим шагом стало отделение содержимого от кода и создание простой мини-CMS.
Теперь этот этап завершён. Сайт размещён на рабочем поддомене https://domusgrand.marketit.ru/, а редактируемый контент и административная часть работают отдельно от конструкции страницы.
Что изменилось после готового лендинга
Экспортированный проект был перенесён в локальное окружение и зафиксирован как визуальный эталон. Задача дальнейшей разработки состояла не в новом дизайне, а в том, чтобы сохранить утверждённый интерфейс и сделать сайт удобнее для эксплуатации.
Редактируемый контент вынесли в data/content.json. В нём хранятся тексты, контакты, пункты меню, изображения, данные калькулятора, тарифы, формы, модальные окна и другие данные, которые могут меняться со временем. При этом DOM-структура, JSX, JavaScript, CSS, размеры, точки адаптива и анимации остаются частью шаблона и не редактируются через CMS.
Такое разделение позволяет менять содержимое без правки React-компонентов и повторной сборки страницы. Для дополнительной устойчивости предусмотрена fallback-копия контента: ошибка загрузки JSON не должна превращать сайт в пустой экран.
Мини-CMS без базы данных
Для управления содержимым собрана собственная flat-file CMS на PHP. База данных и Composer не используются: рабочие данные хранятся в JSON, а пользовательские изображения — в отдельной папке uploads.
При этом CMS не превращает сайт в визуальный конструктор. Редактор работает только с заранее разрешёнными полями. Серверная allowlist-схема охватывает более 150 полей: тексты, контакты, ссылки, цены, существующие элементы списков, изображения и другие данные. Произвольно менять HTML, CSS, JavaScript или структуру блоков через админку нельзя.
Для сохранения данных добавлены серверная валидация, блокировка записи и резервные копии. Система хранит до 20 последних копий JSON. Для изображений разрешены JPEG, PNG и WebP, а потенциально опасные типы файлов, двойные расширения и поддельный MIME отклоняются.
Почему маленькая CMS перестала быть только редактором контента
Первоначальная задача выглядела заметно проще: вынести данные из компонентов и сделать небольшую админку. Но после появления рабочего редактора начались задачи, которые относятся уже к эксплуатации продукта.
Понадобился сценарий первого запуска: после распаковки владелец открывает /admin/, создаёт администратора и настраивает восстановление доступа. Затем появились сессии, CSRF-защита, ограничение попыток входа, восстановление пароля по email и отдельный аварийный путь через файловый менеджер хостинга.
Для служебной почты CMS добавлен SMTP. В реальном окружении проверялись REG.RU и Яндекс — отправка работала. Mail.ru/VK WorkSpace в конкретной конфигурации вернул ограничения авторизации, что ещё раз показало разницу между локальной реализацией функции и её проверкой с реальными внешними сервисами.
Обновления и rollback
Ещё одной отдельной задачей стало обновление уже установленной CMS. Простое распаковывание нового ZIP поверх сайта оказалось ненадёжным: при таком подходе легко затронуть пользовательский контент, загрузки или конфигурацию.
Поэтому появился собственный updater. Он принимает релизный ZIP, проверяет архив, защищает от path traversal, заменяет application-файлы и сохраняет persistent-данные: конфигурацию, runtime-хранилище, content.json и пользовательские загрузки. Перед обновлением создаётся snapshot, позволяющий откатить последний релиз.
Именно updater дал один из наиболее показательных production-багов проекта. На одном из первых обновлений временные файлы переносились с правами 0600. В локальных тестах проблема не проявилась, а на хостинге публичный сайт и CMS начали возвращать 403 Forbidden. После диагностики механизм был исправлен: обычные файлы приложения получают корректные права, а закрытые runtime-файлы сохраняют более строгий режим доступа.
Где AI ускорил работу, а где не заменил инженерию
Codex хорошо справился с задачами, которые можно точно формализовать: переразметкой контента в JSON, типизацией, созданием CMS, серверной схемой разрешённых полей, проверками загрузок, тестами, упаковкой релизов, updater, восстановлением пароля и технической документацией.
Но архитектурные границы пришлось задавать отдельно. Нужно было решить, нужна ли база данных, какие поля можно отдавать пользователю, что считать частью шаблона, какие данные должны переживать обновление и каким должен быть аварийный сценарий восстановления доступа.
Не менее важной осталась проверка реального окружения. Права файлов, SMTP, отображение favicon и поведение обновлений оказались примерами задач, где технически корректный код ещё не означает, что функция действительно работает на production-сервере и в обычном браузере.
Что работает сейчас
На текущем этапе работает публичный лендинг, адаптивная версия, калькулятор, модальные окна, загрузка контента из JSON и собственная PHP CMS. В административной части доступны авторизация, создание администратора при первом запуске, восстановление доступа, резервные копии, загрузка изображений, SMTP для служебной почты и защищённое обновление с rollback.
Есть и важная граница текущего этапа: публичные формы пока остаются демонстрационными. Клиентская валидация и маска телефона работают, но server-side отправка заявок в email, CRM или Telegram ещё не подключена. Поэтому этот функционал не относится к уже завершённой части проекта.
От прототипа к эксплуатации
Первый этап Domus Grand показал, насколько быстро AI может собрать убедительную визуальную основу. Второй — что готовый лендинг можно сравнительно быстро отделить от контента и снабдить собственной небольшой CMS. Третий оказался уже про другое: как превратить результат генерации в систему, которую можно устанавливать, обновлять, восстанавливать и проверять в реальном окружении.
Именно после фразы «сайт уже готов» начинается большая часть вещей, которые пользователь обычно не видит: безопасность, права файлов, резервирование, обновления, восстановление доступа и совместимость с хостингом. Вэйбкодинг ускоряет разработку этих механизмов, но не отменяет необходимость решить, как они должны работать и проверить их после запуска.
Рабочий сайт: https://domusgrand.marketit.ru/
Подробный кейс проекта: https://www.marketit.ru/projects/sajty-i-digital-resheniya/domus-grand-kejs-razrabotki-pilotnogo-sajta-market-it
Смотрите другие материалы
Joomla закрыла несколько уязвимостей: почему обновление CMS лучше не откладывать
Domus Grand запущен: что начинается после «сайт готов»
MAX открывает API для альтернативных клиентов — зачем это бизнесу замечать