Vapor появился из вполне конкретной инженерной задачи: существующий MODX-проект нужно было уметь переносить как целостную систему, а не собирать заново вручную из базы данных, файлов, элементов и настроек.

При этом исходная механика создания snapshot уже существовала внутри самого MODX и использовалась в инфраструктуре MODX Cloud. Но это была именно встроенная часть MODX, жёстко связанная с его внутренней реализацией. Она не существовала как самостоятельный универсальный Extra, который можно было просто установить на любой сайт и использовать как отдельный инструмент миграции.

Работа над Vapor заключалась именно в том, чтобы разобраться в этой внутренней механике, извлечь её из MODX, отделить от окружения, в котором она изначально использовалась, и собрать в самостоятельный переносимый компонент.

То есть Vapor нельзя корректно описывать как «готовый чужой пакет, который Fi1osof только упаковал». Исходная логика snapshot действительно опиралась на код и идеи, существовавшие внутри MODX и связанные с работой команды MODX, но самостоятельного универсального компонента полного цикла в таком виде не было.

После обособления механизм пришлось сделать пригодным для обычных MODX-установок. В результате Vapor мог снять состояние существующего сайта в transport package, а затем развернуть этот снимок на другой MODX-системе.

Это было принципиально шире сценария MODX Cloud. Vapor можно было использовать для переноса между обычными MODX-сайтами: создать snapshot на одном проекте и накатить его на другую установку MODX. Целевая система могла быть чистой либо уже содержать данные; во втором случае импорт мог перезаписать существующее содержимое, о чём инструмент явно предупреждал.

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

В итоге Vapor превратился не просто в экспортёр, а в инструмент полного цикла:

существующий MODX-сайт → snapshot → transport package → другая MODX-установка.

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

С инженерной точки зрения Vapor интересен ещё и как пример общего подхода Fi1osof к MODX: если полезный механизм уже существует внутри платформы, не обязательно писать параллельную реализацию с нуля. Можно разобраться в существующей архитектуре, выделить нужную часть, убрать жёсткие привязки, сделать её самостоятельной и повторно используемой.

Именно поэтому Vapor занимает отдельное место в экосистеме компонентов Fi1osof: он решал уже не задачу frontend или бизнес-логики, а задачу переносимости самого проекта как системы.

Позднее вокруг Vapor возникали споры об авторстве, поскольку часть базовой логики действительно происходила из внутреннего кода MODX. Но это не отменяет сути выполненной работы: превращение встроенного и специализированного механизма в отдельный устанавливаемый компонент, его универсализация для обычных MODX-сайтов и добавление полноценного сценария импорта.

Историю обсуждения и пояснения по происхождению кода можно найти в архиве MODX-сообщества: https://modx.pro/reviews/22794

Исходный исторический репозиторий механизма snapshot сохранился здесь: https://github.com/modxcms/vapor