Перейти к содержимому

Domus Grand запущен: что начинается после «сайт готов»

Проект Domus Grand начинался как эксперимент с вэйбкодингом: по референсам был собран лендинг для компании по ремонту квартир и домов в ChatGPT Sites.
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

30 августа 2026

Смотрите другие материалы

Joomla закрыла несколько уязвимостей: почему обновление CMS лучше не откладывать
18 августа Joomla выпустила версии 6.1.3 и 5.4.8 с несколькими исправлениями безопасности. Этот…
Domus Grand запущен: что начинается после «сайт готов»
Проект Domus Grand начинался как эксперимент с генерацией лендинга в ChatGPT Sites. После готового…
MAX открывает API для альтернативных клиентов — зачем это бизнесу замечать
MAX объявил о запуске программы для разработчиков альтернативных клиентских приложений. Это…
Почему редизайн без данных часто меняет не то
Редизайн может заметно улучшить сайт, но сам по себе не показывает, почему пользователи уходят или…