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

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

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

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

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

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

$ms2->cart->get();

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

$ms->cart->set();

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

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

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

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

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

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

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

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

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

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

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

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

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

Олег вы комментируете сообщение 5-летней давности. Шанс что вам ответят — невелик.

Речь идет только о фронте. В админке пока ничего не меняется, ждет своей очереди.
В части ORM тоже. Хотя есть конечно фантазии переключиться на Eloquent
На VESP только один Василий пишет. Из нашей команды — никто не пользуется этим.

В этом году весь JS будет полностью переписан на современный стиль. Без jQuery зависимости, возможно в модульном решении, при котором нужные модули подключаются по мере необходимости. Выбросим галерею, которой все равно никто не пользуется. Появится JS API. Будут, думаю, нативные события, а не колбэки. Ну и так далее. Не вижу смысла переписывать или как то модифицировать то, что есть сейчас. Там все целиком пора выбрасывать.

Вы без проблем можете использовать свою логику внутри собственного доработанного файл скриптов. Он подключается через соответствующую системную настройку.

Набросал небольшой рефакторинг этого кода
Упростил код плагина, перенес содержимое в компонент
github.com/biz87/iiko

Код по-прежнему хромает, но первый шаг к оптимизации сделан.