Подготовка дополнения для работы в 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 лет- нет желания. Про то, что авторы желают сохранить совместимость с компонентами, не раз говорил Вася например.
Хотя мажорная версия не должна подразумевать совместимость, но и кардинально нового подхода к разработке дополнений нет.
                    Хотя мажорная версия не должна подразумевать совместимость, но и кардинально нового подхода к разработке дополнений нет.
                Это было в обсуждениях в Слаке, на Гитхабе и др. ресурсах. Марк даже алиасы классов пилил для этого.            
                    
                            Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.