Сценарии работы¶

Package Builder поддерживает несколько сценариев разработки. Выбор зависит от того, есть ли у вас локальный MODX и как вы предпочитаете работать с элементами.

1. Headless — файловая разработка и сборка¶

Когда подходит: вы хотите разрабатывать пакет без установки MODX и MySQL. Весь код и элементы описываются в файлах, сборка происходит локально, а установка — на отдельном тестовом сайте.

Преимущества:

Не нужен сервер, MySQL, установленный MODX
Пакет можно спокойно устанавливать и удалять на тестовом MODX — все элементы создаются из transport-пакета и чисто удаляются при деинсталляции, ничего не затирается
Весь пакет под контролем git

Workflow:

modxapp setup                          # скачать ядро MODX (один раз)
modxapp create my-package              # создать структуру
# Написать код, описать элементы в файлах
modxapp extract-lexicons my-package    # извлечь ключи лексиконов
modxapp extract-settings my-package    # извлечь настройки
modxapp build my-package               # собрать transport.zip

Полученный transport.zip загружается на MODX-сайт через менеджер пакетов или вручную в core/packages/.

Доступные команды: setup, create, build, schema (генерация классов), extract-lexicons, extract-settings, templates, config, init

Недоступные команды: elements, export, schema-extract — требуют подключение к БД MODX

Безопасное тестирование

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

2. Файловая разработка + стандартная сборка¶

Когда подходит: у вас есть установленный MODX, но вы предпочитаете описывать все элементы в файлах, не используя админку.

Отличие от headless: сборка идёт через стандартный modPackageBuilder MODX, что гарантирует 100% совместимость transport-формата. Однако на практике standalone-сборщик генерирует идентичный результат, поэтому этот сценарий допустим, но не даёт преимуществ перед headless.

Workflow:

modxapp create my-package
# Описать элементы в файлах
modxapp build my-package               # сборка через modPackageBuilder

Как и в headless, при установке и удалении пакета на тестовом MODX ничего не затирается — элементы создаются из transport-пакета.

3. Файловая разработка + элементы в БД¶

Когда подходит: вы хотите видеть и тестировать элементы (сниппеты, чанки, плагины) в MODX во время разработки, а не только после сборки и установки пакета.

Преимущества:

Можно тестировать элементы прямо на сайте, не пересобирая пакет
Видны ошибки сразу — плагин не сработал, сниппет вернул не то
Финальная сборка гарантированно включает проверенный код

Workflow:

modxapp create my-package --elements
# Описать элементы в файлах
modxapp elements my-package            # добавить элементы в MODX
# Тестировать на сайте — сниппеты, плагины работают
# Исправить код, повторить elements
modxapp build my-package               # собрать финальную версию

Команда elements создаёт или обновляет элементы в БД MODX из ваших PHP-файлов. Это быстрее, чем каждый раз пересобирать и переустанавливать пакет. При этом build берёт элементы из файлов, а не из БД — вы всегда контролируете что попадёт в transport-пакет.

Не используйте build --install в этом сценарии

Команда elements создаёт элементы напрямую в БД. Если после этого выполнить build --install, transport-пакет установится поверх — и при последующем удалении пакета удалятся все элементы, включая те, которые вы создавали через elements. Тестируйте установку пакета на отдельном сайте, а не на том, где ведёте разработку.

elements vs build --install

elements добавляет элементы в БД для разработки. build --install собирает пакет и устанавливает его как transport — это разные процессы. При разработке используйте elements для быстрой итерации, а установку тестируйте отдельно.

4. Смешанная разработка — файлы + админка¶

Когда подходит: часть элементов удобнее создавать через админку MODX, а код писать в файлах.

Элементы, которые удобнее создавать в админке:

Системные настройки — визуальный интерфейс с выбором типа (textfield, combo-boolean и т.д.)
TV-параметры — настройка привязки к шаблонам
Меню — проверка порядка и вложенности
Шаблоны — визуальное редактирование
Системные события — регистрация кастомных событий
Таблицы в БД — создание через SQL или phpMyAdmin, затем извлечение схемы командой schema-extract

Элементы, которые лучше хранить в файлах:

Чанки — HTML-код удобнее редактировать в IDE с подсветкой и автодополнением
Сниппеты — PHP-код с типизацией, автодополнением, git-историей
Плагины — аналогично сниппетам

Workflow:

modxapp create my-package --elements
# Описать сниппеты, плагины, чанки в файлах
modxapp elements my-package            # добавить файловые элементы в MODX
# Создать настройки, TV, меню, шаблоны через админку MODX
# Создать таблицы через SQL
modxapp schema-extract my-package      # извлечь XML-схему из таблиц
modxapp export my-package              # извлечь ВСЕ элементы из БД в файлы
modxapp build my-package               # собрать пакет

Команда export извлекает все элементы категории из БД и записывает в файлы — как созданные через elements, так и добавленные вручную через админку. Контент элементов (код сниппетов, HTML чанков) сохраняется в отдельные файлы.

export перезаписывает файлы

export перезаписывает существующие файлы элементов. Если вы вручную редактировали elements/snippets.php и одновременно меняли элементы в админке — export затрёт ваши файловые правки данными из БД. Сначала убедитесь, что актуальная версия — в БД.

Не используйте build --install на рабочем сайте

Как и в сценарии 3, не устанавливайте пакет на тот же сайт, где создавали элементы через админку. При удалении пакета MODX удалит все элементы, включая созданные вручную. Тестируйте установку на отдельном сайте.

Сравнение сценариев¶

	Headless	Файловая + стандартная	Файловая + элементы	Смешанная
Нужен MODX	нет	да	да	да
Нужен MySQL	нет	да	да	да
Тестирование в процессе	нет	нет	да	да
Работа через админку	нет	нет	нет	да
Безопасное удаление пакета	да	да	на отдельном сайте	на отдельном сайте
Контроль через git	полный	полный	полный	после export
Простота старта	высокая	средняя	средняя	средняя

Сценарии работы¶

1. Headless — файловая разработка и сборка¶

2. Файловая разработка + стандартная сборка¶

3. Файловая разработка + элементы в БД¶

4. Смешанная разработка — файлы + админка¶

Сравнение сценариев¶

Рекомендации¶