Николай Савин

Не рекомендую писать одно и то же в разных темах. Это чревато санкциями.

Может jquery не подключен в шаблоне?

Дополню. В планах адаптировать ms2 под тройку, чтобы он работал сразу на обеих платформах. И далее уже спокойно работать над отдельной версией которая точно будет, и своим выходом похоронит и второй минишоп, и modx 2. План работ и конкретные изменения для ms3 давно составлены.

Откуда у вас информация про такую версию? Кто бы ее делал?
В официальном репозитарии компонента последняя версия 1.13 выпущенная два года назад.

Здравствуйте. Компонент Tickets не работает с MODX3.

Я на всякий случай уточню. Вообще, то есть метод

$ms->cart->remove($key);

Но в вашем конкретном случае мне показалось, что больше подойдет приведенный выше код.
Потому что все равно корзину перебирать и проверять наличие товара.

Пожалуйста. Пользоваться поиском довольно полезно.

Товары находятся не в заказе, а в корзине.
Корзина это массив данных. Получить его можно через метод

$ms2->cart->get();

Далее просто удалите ненужный элемент массива и обновите корзину через

$ms->cart->set();

Ну в целом выполнение задачи не меняется. Подберите событие, которое срабатывает перед созданием заказа, напишите плагин, реагирующий на такое событие.

У вас некорректная логика. Такую ошибку нужно выводить при попытке положить товар в корзину и не давать это сделать изначально.
Здесь этот вопрос обсуждался неоднократно. Воспользуйтесь поиском.
Вот например modx.pro/help/9381

Функционал ошибок есть. Основан на плагинах. На каждое действие (почти) есть свое событие.
Список событий найдете в документации. Создаете плагин на нужное событие. Выполняете проверку — возвращаете нужный ответ

Куда вернуть ошибку? Клиенту вывести на экран в момент добавления товара в корзину? Тогда товар нужно удалять не из заказа, а из корзины.
Или же удалить из уже созданного заказа? Тогда совсем не понятно куда вернуть ошибку.
Это разные сущности, и реализация разная будет.

Изучать исходный код компонентов. Читать схожие вопросы и инструкции здесь на форуме.

это полноценный маркетплейс дополнений для CMS (тут просится MODX, но на самом деле не обязательно), со всеми сопутствующими сервисами вокруг него: управление пакетами, управлением ключами и лицензиями, техническая поддержка, арбитраж спорных вопросов, биллинг и многое другое, что обычно бывает скрыто под капотом

В MODX3 уже есть. По плану обещают релиз стабильной версии через два дня.

Добрый день. Да доработку можно заказать, напишите в телеграм мне. Обсудим.
Здесь главная забота — отсутствие площадки для тестов. Нужен клиент для подключения.

А чем принципиально отличается разработка админки под slim от разработки простой админки под MODX?

Лучше собрать чужой опыт в одном удобном руководстве, чем не размещать свое вообще нигде.
Мы все учимся на чужом. Я до сих пор подсматриваю какие то технические решения в чужом коде. И использую удачные решения. Плюсь правда все чаще с каждым годом, но это уже другая история.

Я бы зашел со стороны токена.
При авторизации юзера куку сохраняю как токен в базе. При выходе — затираю.
Соотвественно если нода имеет доступ к этой куке — достаточно простым запросом проверить есть ли юзер с таким токеном. Если есть — он залогинен. Если нет — значит не залогинен и куку можно зачистить.

Докер под виндой никогда нормально не работал. Это нормально такая скорость. Он просто не предназначен для винды.

Под виндой небось работаете?