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

Ну логично. Минишопом пока никто не занимался. Это же все по цепочке зависимостей нужно делать.
Сначала MODX3, за ним PDOTools, далее ms2 (или может быть уже ms3) и потом еще всю экосистему подключаемых к минишопу модулей до ума доводить.

Здравствуйте. Нет такого не предусмотрено.

Обновился минишоп, без спроса, при обновлений другого приложения

Так не бывает.

Выше всё написано, всё точно также.

Еще раз… хотите получить решение конкретной проблемы — создайте issue в репозитарии проекта на github. Это нормальное поведение для IT разработки.
Мне важно увидеть, что вы не просто бубните на форуме, а делаете хоть что-то, чтобы поддержать БЕСПЛАТНЫЙ труд других людей.

Насколько я знаю — о такой проблеме никто не заявлял. Issue не создавали.
Будет больше пользы — если Вы расскажите о проблеме в репозитории miniShop2. Создайте Issue, опишите суть проблемы, и то какое поведение ожидается. Расскажите как такую проблему воспроизвести — и шансов на исправление станет гораздо больше.
Обычно проблемы именно так решаются в мире IT.

Tickets передан под управление нашей GitHub организации modx.pro github.com/modx-pro/Tickets
Им и правда сейчас никто не занимается, но это не потому что, не хочется. Задач очень много по всем направлениям. Банально не успеваем. На подходе MODX3 — к нему нужно готовить экосистему
Конкретно сейчас идет работа над pdoTools, над минишопом, надо сайтом сообщества, где мы сейчас находимся.

Изменил раздел на «Готовые решения», так как здесь речь не о компоненте MODX

Не скорее, а так и есть. CMF MODX это фреймворк!

Сначала написал потом, подумал о контексте вопроса. Конкретно в обсуждаемом компоненте не видел как сбрасывается кэш, и сбрасывается ли вообще.

Это на самом деле очень просто делается
Вот такой метод есть у кэш менеджера для очистки кэша конкретного ресурса (товар это же ресурс)

$modx->cacheManager->delete($product_id, array(xPDO::OPT_CACHE_KEY => 'resource/web/resources'))

Виктор не нужно дублировать один и тот же комментарий в разных топиках

Перенес в вопросы

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

if ($msOrder->delivery === 1) {

Попробуйте заменить

{$msOrder->payment}

На

{$msOrder->Payment->name}

Обратите внимание, что Payment теперь с большой буквы.
Та же история с доставкой

{$msOrder->Delivery->name}

Для этого кто-то должен оплатить, скажем 10 тысяч человеко-часов. И уже завтра можно начинать писать админку.

Это компонент extJS встроенный в modx — по идее не к минишопу вопросы. ms2 просто вызывает компонент

Вам нужно выполнить вот этот код для решения вопроса

$modx->removeExtensionPackage('amocrm');

Его можно выполнить в консоли MODX (есть такой популярный компонент)
либо создав сниппет и вызвав его где-то на произвольной странице

@Илья Уткин обрати внимание пожалуйста

modxPro и modStore — Это разные организации. С подобными пожеланиями вам на info@modstore.pro

Можно просто очистить валидацию этого поля и спокойно работать.
Оставьте какую нибудь простенькую санитизацию и все.

Вопрос решается достаточно просто.
Вам нужно расширить класс заказа своим классом, и перезаписать метод validate который и фильтрует входящие буквы. Там есть такая конструкция

$tmp = preg_replace(
                    array('/[^-a-zа-яёґєіїўäëïöüçàéèîôûäüöÜÖÄÁČĎĚÍŇÓŘŠŤÚŮÝŽ\s\.\'’ʼ`"]/iu', '/\s+/', '/\-+/', '/\.+/', '/[\'’ʼ`"]/iu', '/\'+/'),
                    array('', ' ', '-', '.', '\'', '\''),
                    $value
                );