1. Если заказов много — такой сниппет не сможет выполнить свою работу. Лучше вешать задачу на планировщик
2. Использование getCollection. Это не лучший вариант. Этот метод загружает в ОЗУ сразу всю коллекцию объектов заказа, что не лучшим образом отражается на производительности и ресурсах. Лучше использовать итератор через метод getIterator. Такой метод загружает в память только список объектов, при переборе по очереди достает из базы информацию. Этот метод существенно быстрее работает и кушает меньше ресурсов. К слову итератор это не изобретение MODX. Это паттерн PHP. Да и не только PHP — он почти во всех языках используется.
Этот вариант, в отличие от $modx->getChunk обработает конструкции и MODX и феном.
5. Не ошибка. Даже не предупреждение. Скорее глаз режет. Использование прямых SQL конструкций.
Мы же в MODX работаем. Желательно использовать конструктор запроса. newQuery — его не просто так придумали. Помимо универсальности запроса, не привязанного к конкретной СУБД — это еще и выглядит красиво, аккуратно, профессионально. Сразу видно, что человек знает свое рабочее место.
А как эти товары потом разделить обратно, если соединил по ошибке? Разрешать делать что-то, без возможности отмены, мне кажется несовсем правильным.
Ну удаление из корзины у нас тоже всегда было без confirm. И ничего страшного. На данный момент то что сделано — это в любом случае прогресс. Сообщество у нас умное, накидает идей и правок, было бы куда.
Тот случай когда не нужно торопиться обновлять софт, просто потому что новое — лучше.
На всякий случай уточню. Большинство русскоязычных компонентов основаны на единой зависимости — библиотеке pdoTools. Она не заявлена в поддержке PHP8. В целом работает конечно, но ее никто, включая текущего владельца не тестировал основательно. Возможны проблемы как с самой библой, так и с отдельными компонентами.
Другое расположение элементов ядра, например моделей, процессоров
Другие процессоры в принципе
Обязательное использование namespace при обращении к классам (и при их создании)
По другому работает $modx->getService. Так больше писать нельзя
Ряд отличий в админке.
Я не видел каких то исчерпывающих инструкций. Но понемногу тут на форуме была информация. В том числе от меня. Мне кажется если очень захотеть то можно разобраться.
Опять же есть готовый компонент-шаблон ModExtra3 — можно пошагово посмотреть как он устроен и чем отличается от modExtra
Некоторые куски точно не будут работать. Местами есть существенные проблемы. Вплоть до того, что используемый функционал вырезан в версии 8.1
Подогнать конечно можно при желании, но для этого нужна квалификация.
А это как то мешает работе компонента? Ну да, чуть-чуть подправить верстку нужно. И Автор этим точно заниматься не будет. Но как будто в тему поста подобные баги не совсем ложатся. ИМХО.
1. Если заказов много — такой сниппет не сможет выполнить свою работу. Лучше вешать задачу на планировщик
2. Использование getCollection. Это не лучший вариант. Этот метод загружает в ОЗУ сразу всю коллекцию объектов заказа, что не лучшим образом отражается на производительности и ресурсах. Лучше использовать итератор через метод getIterator. Такой метод загружает в память только список объектов, при переборе по очереди достает из базы информацию. Этот метод существенно быстрее работает и кушает меньше ресурсов. К слову итератор это не изобретение MODX. Это паттерн PHP. Да и не только PHP — он почти во всех языках используется.
3. Это что за странная конструкция такая?
Зачем так? Почему? Есть же гораздо более корректный метод обращения к таблице
Так-то люди вполне могут переименовать таблицу, просто указав нужное имя в модельке. И приведенный метод гарантировано выдаст нужную таблицу.
4. Использовать getChunk я бы рекомендовал так:
Этот вариант, в отличие от $modx->getChunk обработает конструкции и MODX и феном.
5. Не ошибка. Даже не предупреждение. Скорее глаз режет.
Использование прямых SQL конструкций.
Мы же в MODX работаем. Желательно использовать конструктор запроса. newQuery — его не просто так придумали. Помимо универсальности запроса, не привязанного к конкретной СУБД — это еще и выглядит красиво, аккуратно, профессионально. Сразу видно, что человек знает свое рабочее место.
Я сейчас делаю модуль интернет-магазина MiniShop3 на 8.1 — ничего нигде не пукает
На всякий случай уточню. Большинство русскоязычных компонентов основаны на единой зависимости — библиотеке pdoTools. Она не заявлена в поддержке PHP8. В целом работает конечно, но ее никто, включая текущего владельца не тестировал основательно. Возможны проблемы как с самой библой, так и с отдельными компонентами.
- Другое расположение элементов ядра, например моделей, процессоров
- Другие процессоры в принципе
- Обязательное использование namespace при обращении к классам (и при их создании)
- По другому работает $modx->getService. Так больше писать нельзя
- Ряд отличий в админке.
Я не видел каких то исчерпывающих инструкций. Но понемногу тут на форуме была информация. В том числе от меня. Мне кажется если очень захотеть то можно разобраться.Опять же есть готовый компонент-шаблон ModExtra3 — можно пошагово посмотреть как он устроен и чем отличается от modExtra
Поддержки версий выше нет и не планируется.
Подогнать конечно можно при желании, но для этого нужна квалификация.