Хорошо, я действительно понимаю, что возможно я не прав на счет включения этого функционала в магазин, т.к. нужно оно не всем. Но тем не менее важность этой штуки для меня сейчас, все же не уменьшается. Думаю очень полезно было бы выложить внешний вид чанка и класса для реализации этой задачи в «готовых решениях». Тем более подобные вопросы в сообществе уже были. Просто действительно не понятно как это правильно организовать(
Да, такой вариант возможен. Но есть менеджер, который это все дело как раз и должен проверить и уточнить. При необходимости он свяжется с пользователем. И все же это меньшинство случаев. Но если не сделать данное поле, то связываться придется абсолютно с каждым пользователем и в каждом заказе исправлять его конечную стоимость — что, согласитесь, еще хуже.
Да и где это все требуется как раз и используется то, о чем говорит Василий. Я же говорю о самом стандартном варианте, где вся эта логика не требуется. Система скидок то же ведь не идет «из коробки», хотя она и требуется в очень большом количестве случаев, мы ее отдельно прикручиваем. Но тем не менее простая логика например умножения стоимости товара на его количество все же идет как раз «из коробки».
Есть адрес магазина, либо склада. Естественно этот вариант будет использоваться только для доставки по городу, либо за город. Неужели пользователь не в курсе как далеко он от этого места? Не думаю.
Такой примерчик очень нужен в базовом дистрибутиве, был бы полезен и очень удобен! Ну ведь есть же функционал по фиксированному добавлению стоимости за доставку и все пользуются — ну ведь прав да же стандартно и нужно… Хотя кому-то нужно чтоб до 10000 р. стоимость доставки такая-то, после 10000 р. такая-то, после 30000 например и вообще бесплатно, ну либо еще что там — вот тут и нужны классы, да, согласен! Но почему с километражем так ситуация не обстоит — непонятно(
Да, я это все видел. Это готовые сложные компоненты, которые в моем случае не нужны совершенно. Мне всего-то нужно чтоб две цифры друг на друга перемножались, одна мной указанная, одна пользователем и потом это плюсовалось к общей стоимости… Вроде как дважды два звучит, но как это реализовать совершенно непонятно. Какие плейсхолдеры в чанке должны добавиться, как их значение в класс-обработчик должно попадать и выводиться… Нужно просто пару строк готового решения, а не здоровенный компонент
Да и вообще я думаю это самое стандартное использование этого параметра, так сказать в базовом варианте. Наверное в этом виде бы его и в пакет minishop'а стоило бы включить, а дальше если вдруг заморочки какие-то более сложные — тогда уже чтоб через кастомные классы можно было б менять
Ну а хотяб банальный примерчик с самым простым использованием можно? Чтобы выводился инпут для юзера, он вносил значение в км, а оно уже умножалось на стоимость ед/рст из настроек способа доставки.
Что у вас за класс msDeliveryHandler_free10 в первом коде?
Как только все подключаю страница с доставкой и способами оплаты просто перестает грузиться… Видимо в приведенных примерах ошибка где-то в php
Испытываю некоторые проблемы в этой же области. Все способы оплаты не активны (увязка с доставкой выставлена). Все это происходит на фоне ошибок js (причем не суть мой это 1.8.3 jquery или тот что с минишопом идет — одинаково)
Проблема решена путем добавления политики доступа в группе пользователей. Кроме положенной там изначально web — Member — 9999 — TicketUserPolicy добавил еще web — Member — 9999 — Load, List and View
Почему в моем кастомном классе не получается достать его вот так?
В таблице modx_ms2_orders создал соответствующую колонку, но туда тоже ничего не попадает.
Как увязать всю эту систему?
Как только все подключаю страница с доставкой и способами оплаты просто перестает грузиться… Видимо в приведенных примерах ошибка где-то в php
т.к. там потом идет подставка данных и тоже в двойных кавычках, типо «1»,«2» и т.д., что приводит к конфликту в default.js