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

Ну так эта строчка фигачит все запросы в один контроллер. А логику в контроллере кто будет разбирать?

Ну кто то больше к blade привык. Ведь Laravel по популярнее будет

Ну я вам примерно это и написал. Все верно.

Подставляйте расчетную цену в скрытый параметр option
Далее в плагине (msOnAddToCart наверное) или в классе корзины который можно перезаписать по своему, ловите этот параметр — записывайте его в цену, а сам параметр уничтожайте за ненадобность.

Да как обычно.

Напишите мне в телеграм biz87 — скину контроллер посмотреть

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

Я со своей стороны тоже попробую сделать и написать практический обзор, чтобы более подробно рассказать о потенциальной пользе компонента.

Здравствуйте. Поддержка должна сидеть возле компьютера круглосуточно, отходя только на обед?
Я видел ваш вопрос в магазине. Отвечу как будет возможность.

Касательно вашего вопроса здесь. Я вот ни слова не понял из вопроса.

Предлагаю вынести PayPal в отдельный компонент, как это сделано для всех платежных систем. Никогда не понимал зачем он нужен в коробке.

Так же как и в любом другом случае.

$msOrder = $modx->getObject('msOrder', array('id' => $id));
$msAddress = $msOrder->getOne('Address');

Судя по тому что вы знаете название классов вы в курсе как это делается.

Полезнее создать issue на github.

Готов забрать bannerY, Jevix и HybridAuth

тупо без аргументации

Тебе уже два человека прямо на пальцах показали где проблема и к чему она может привести. Какая еще аргументация нужна.

Не хочешь слушать — ради бога.

Так не в этом дело что можно не включать. Это мы участники дискуссии понимаем.
Проблема в том, что щас молодые неопытные увидят крутой компонент и без раздумья будут все подряд туда пихать.

А сидеть без ajax'a в 2к20

Сидеть на jquery в 2020 тоже так себе. Попахивает.

Нет тут никакой альтернативы. Потому что подход в принципе неверный, ведущий только к плохому.
ВСЕГДА на каждый необходимый функционал пишется свой отдельный запрос. Либо на коннектор, либо на плагин. И там уже вся логика, скрытая от посторонних глаз.

Поставил минус — обязан объяснить.
Этот компонент действительно дыра в безопасности.
Доступ к, например, pdoResources позволяет получить любую информацию из любой таблицы, включая личные данные пользователей, заказы, промо-коды и любую другую коммерческую информацию. А также любые системные настройки, где часто хранятся логины-пароли к платежным системам, апишкам и т.п.

Ответственный программист конечно улыбнется и не будет использовать такой компонент, но найдутся десятки неопытных ребят, которым надо проще и быстрее. А потом начнется… MODX дырявый

Добрый день. Я так понимаю речь о неполадках внутри самой CRM?
Мой компонент не имеет к этому никакого отношения. Он работает ТОЛЬКО на сайте.

компонент оцененный специалистом по разработке компонентов в 120тр именно в моём исполнени основанном на моём 30ти летнем опыте программирования на разных языках

А можно поинтересоваться кто именно из специалистов по разработке компонентов оценил стоимость? Их немного в общем то.

а так хорошо

да наверное. Вообще на моем опыте в счетчиках всегда let используют. Здесь как раз срабатывает правило — показать читающему что эта переменная где то далее изменится. Здесь не техническая особенность а скорее общепринятое написание.

Ну скорее значение?

 Неа. Именно тип. Значение двух типов менять можно. Это массив и объект. Мы запросто можем манипулировать их внутренностями.

1. Объект user просто определен выше по логике кода. Он не существует сам по себе. Читаем цикл for in
2. Переменные имеют область видимости. Она ограничена круглыми или фигурными скобками. Читаем область видимости. Попробуй вызови в консоли element за пределами ближайшей фигурной скобки
3. Как только область видимости заканчивается — сборщик мусора уничтожает переменную и ее можно объявить заново. В цикле можно заново объявлять переменные на каждой итерации. Читаем про сборщик мусора.
4. Есть такое правило ВСЕГДА использовать const при объявлении переменной. Это связано с тем что далее нельзя будет изменить ее тип и при объявлении четко понятно какого типа переменная. Исключение — если изначально понятно что переменная ниже будет перезаписана. И это объявление тоже служит сигналом для читающего код что где то ниже переменная будет перезаписана. Таким образом const и let это еще и информация о судьбе переменной. Будет ли ниже ее изменение.