Подготовка дополнения для работы в MODX 3.
Добрый день!
Возникает много вопросов как обновить дополнения для работы в MODX 3.
Предлагаю вашему вниманию заметку от разработчика theboxer, на примере дополнения Collection
Cхема
Так как Collection расширяет основной класс Revolution `modResource` и этот класс должен появиться в списке, возвращаемом `$modx->getDescendants('MODX\Revolution\modResource')`, то схема должна измениться.
Заменить:
На:
CollectionContainer
`collectioncontainer.class.php` также должен измениться, потому что он переопределяет основные процессоры и требует файлы из старых мест.
Удалить старые зависимости
Из-за недавно введенной автозагрузки composer, следующие требования больше не нужны (а также они указывают на неправильные файлы при их перемещении). Необходимо удалить их все.
Используйте полную версию классов в пространстве имен для расширения `CollectionContainer`, `CollectionContainerCreateProcessor` и `CollectionContainerUpdateProcessor`.
В помощь: Изменение имен классов
Возникает много вопросов как обновить дополнения для работы в MODX 3.
Предлагаю вашему вниманию заметку от разработчика theboxer, на примере дополнения Collection
Так как Collection расширяет основной класс Revolution `modResource` и этот класс должен появиться в списке, возвращаемом `$modx->getDescendants('MODX\Revolution\modResource')`, то схема должна измениться.
Заменить:
<object class="CollectionContainer" extends="modResource">
<!-- Columns remain unchanged -->
</object>
На:
<object class="CollectionContainer" extends="MODX\Revolution\modResource">
<!-- Columns remain unchanged -->
</object>
Что также изменит `metadata.mysql.php` файл, как только схема построена.CollectionContainer
`collectioncontainer.class.php` также должен измениться, потому что он переопределяет основные процессоры и требует файлы из старых мест.
Удалить старые зависимости
Из-за недавно введенной автозагрузки composer, следующие требования больше не нужны (а также они указывают на неправильные файлы при их перемещении). Необходимо удалить их все.
require_once MODX_CORE_PATH . 'model/modx/modprocessor.class.php';
require_once MODX_CORE_PATH . 'model/modx/processors/resource/create.class.php';
require_once MODX_CORE_PATH . 'model/modx/processors/resource/update.class.php';
Также изменения распространяются наИспользуйте полную версию классов в пространстве имен для расширения `CollectionContainer`, `CollectionContainerCreateProcessor` и `CollectionContainerUpdateProcessor`.
- `modResource` -> `MODX\Revolution\modResource`
- `modResourceCreateProcessor` -> `MODX\Revolution\Processors\Resource\Create`
- `modResourceUpdateProcessor` -> `MODX\Revolution\Processors\Resource\Update`
В помощь: Изменение имен классов
Поблагодарить автора
Отправить деньги
Комментарии: 11
Вот у меня только один вопрос — ну и где та самая обратная совместимость, на сохранение которой потрачено несколько лет?
Не напоминайте им об этом. А то опять застрянут в каменном веке.
А вы делаете сайты на MODX?)
Делаю.
Ну она есть же. К примеру, некоторые пакеты ставятся и работают, типа TinyMCE, может в консоли будут информационные сообщения, но визуально все ок.
У нас явно разное понятие обратной совместимости.
А ведь если я не ошибаюсь, это была одна из главных задач при разработке MODx 3.
Ребят. А где MODx обещал обратную совместимость (какая формулировка). Есть ли информация на официальном сайте. Что идет полумаштабный дискусс согласен, а где первоисточник.
А вообще какие плюсы от перехода на модкс 3?
Искать эту инфу в первоисточнике за 5 лет- нет желания. Про то, что авторы желают сохранить совместимость с компонентами, не раз говорил Вася например.
Хотя мажорная версия не должна подразумевать совместимость, но и кардинально нового подхода к разработке дополнений нет.
Хотя мажорная версия не должна подразумевать совместимость, но и кардинально нового подхода к разработке дополнений нет.
Это было в обсуждениях в Слаке, на Гитхабе и др. ресурсах. Марк даже алиасы классов пилил для этого.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.