Одним щелчком пальцев — нет нельзя. docs.modx.pro/komponentyi/minishop2/snippetyi/mscart
Вот тут можно почитать, что на страницу оформления заказа передаются две переменные total и products и какие данные в них лежат. Скидки там нет.
Но если вам нужно, то вы можете посчитать ее сами, ведь массив products у вас есть, соответственно идентификаторы всех товаров заказа есть, по ним можете получить для каждого цену основную. Умножить на количество каждого товара и найти сколько бы стоил заказ без скидки.
Но это самое примитивное решение и у него есть минус — при динамическом изменении товаров в корзине (количества товаров или же удаление товара) это стоимость без скидки пересчитывать не будет.
В нашей нет. Есть директор, зам директора и программист.
Но когда я пятничным вечером закончив работу позволяю себе помечатать, то я представляю так
— директор заключает договор с клиентом
— проект менеджер берет на себя общение с заказчиком, понимание того что ему нужно, грамотно формулирует задачу программисту
— программист решает задачу так, как ему позволяет опыт, знания, нахальство.
— проект менеджер презентует готовое решение.
На мой взгляд программист не должен общаться с заказчиком. Хотя по факту я 60% времени этим занимаюсь. Но что делать — у нас бедная компания. Но в идеале — не должен. И для этого проект менеджер и нужен.
Да сайт может быть простым или сложным, может быть микросервисным, может иметь интеграции с десятками сторонних сервисов, но все равно это — сайт.
Я вот не очень люблю слово — проект! От него веет пафосом и амбициями.
В моем понимании раз уж мы общаемся на сайте посвященном modx — то тут все делают сайты и только сайты, а ни какие не проекты)
МОжет быть сейчас кто-то найдет страницу в википедии и бросит в меня страницей, на которой очень четко дано определение, что такое — проект)) Как когда-то я написал здесь что jquery это фреймворк, поскольку под фреймворком я лично понимаю любую надстройку над любым языком, которая позволяет писать код на упрощенном синтаксисе, а мне все громко кричали что jquery это библиотека!
Лично в моем понимании — все что мы видим в браузере и взаимодействием через него — это сайт. Проект — это что то такое, что работает на сервере
, делает кучу полезного, но ему веб интерфейс и не нужен то совсем)
Но это что-то Остапа понесло, простите.
А конструктор позволяет не нести затраты на дизайн, верстку, программирование. ИИ генерит качественный html, css, js и плюсом микроразметку за бесплатно. Стильно выглядящий магазин, с разными вариантами оплаты, доставки, хорошо оптимизированный в плане сео — можно получить за 100 рублей (это я утрирую, не знаю цен но очень не дорого).
Да конечно сложные проекты будут, но их не так много.
Но та же тильда или wix через год два догонят. 95 процентов желаний заказчика можно будет организовать просто двигая блоки по экрану в визуальном редакторе. И только 5 ну максимум 10 процентов проектов, которые будут иметь ну очень мудренную логику — будут обращаться к программистам.
Ведь по сути, я не ошибусь если скажу, что все мы делаем на том же modx совершенно однотипные задачи — сайты услуг, лендинги, простые магазины.
Все это и намного больше уже можно за 3 клика наделать в конструкторе — подключать большинство существующих оплат, доставок, сторонних сервисов. А есть американские конструкторы сайтов типа shopify — так это вообще мощнейший инструмент, радует только что им пока не очень интересен рынок России.
docs.modx.pro/komponentyi/minishop2/snippetyi/mscart
Вот тут можно почитать, что на страницу оформления заказа передаются две переменные total и products и какие данные в них лежат. Скидки там нет.
Но если вам нужно, то вы можете посчитать ее сами, ведь массив products у вас есть, соответственно идентификаторы всех товаров заказа есть, по ним можете получить для каждого цену основную. Умножить на количество каждого товара и найти сколько бы стоил заказ без скидки.
Но это самое примитивное решение и у него есть минус — при динамическом изменении товаров в корзине (количества товаров или же удаление товара) это стоимость без скидки пересчитывать не будет.
Насколько я знаю в терминологии минишопа такого термина не существует.
Если вы используете для создания скидок на товары какой-то сторонний или самописный функционал, то отталкиваться нужно от него.
Ну как — «жить», «существовать» конечно будет долго и на радость нам. Но если пытаться понять, а что такое жизнь в целом, то приходиться признать — это изменения, это движение, это размножение. А все что остановилось, оно просто существует.
Мне кажется их нельзя назвать конкурентами даже с натяжкой, их даже сравнивать нельзя.
Я не помогу вам, потому что наверное вы читали о каких то имеющихся сниппетах авторизации типа login или office.
Я ими не пользуюсь и пишу личные кабинеты и авторизацию с нуля под каждый проект отдельно.
Первым делом хочется спросить — зачем. Ведь плейсхолдер — это переменная которую можно получить на странице.
Но и идентификатор пользователя можно сразу получить на странице. Зачем его записывать еще и в плейсхолдер. На фронтенде например так {$_modx->user.id} через феном.
Или в сниппете php через $modx->user->get('id')
Но если уж правда необходимо записать зачем то идентификатор пользователя в плейсхолдер, то как-то так
Ну вы и сравнили, vk над которым работает около 150 программистов всех уровней и направлений и CMS ку простую.
Заводите сначала конфигурацию migx у которого скажем всего два поля — name и likes
называете конфигурацию — nameAndLikes
Создаете ТВ с именем nameAndLikes типы migx с конфигурацией nameAndLikes.
Привязываете этот ТВ к шаблону. Создаете ресурс с этим шаблоном.
Далее js который отслеживает клики по каким то иконкам на фронтенде. Если клик по + то ajax запрос на файл в котором подключили основной index.php для инициализации объекта приложения $modx
Получили нужный ТВ исходя из вашей логики. Хорошо расписано у Уткина ilyaut.ru/xpdo/xpdo-for-dummies-part-4/
Изменили значение, сохранили ресурс.
migx это json для хранения данных.
Хотите сделать какие-то лайки — заведите у migx кроме основных данных еще и свойство — likes.
Напишите js скрипт, который будет на фронтенде реагировать на нажатия чего либо, пусть js шлет ajax запрос на какой-то php, который получает значения migx, находит нужный например по migxId и изменяет его значение likes.
Ну тогда я напишу глупость.
Эдак год назад я в каком-то комментарии позволил себе написать, что modx умирает за что получил сотни минусов и кучу негативных ответов.
А ведь был не так уж неправ.
А вам Василий спасибо за работу и кучу полезных инструментов.
Нет, честно говоря не совсем понял вашу идею.
Попробую более подробно описать как будет строиться проект.
ИМ будет представлять из себя соединитель сторонних сервисов, поскольку у заказчика на данный момент уже по всем миру обычные магазины офлайновые и у них уже заключены договора на обслуживание с множеством различных компаний. Так например данные о товарах в электронном виде хранятся в одной компании, отдельно заключены договора с компанией которая предоставляет услуги «программы лояльности» которая уже ведет учет покупателей, выдачу им бонусных карт, построение сложных акций и так далее. Сейчас это все работает в их офлайн магазинах — данные передаются на кассовые аппараты и когда человек покупает товар, кассовый аппарат получает от сервиса по хранению товаров базовую стоимость товара, потом клиент дает карточку лояльности и по ней идет запрос от кассового аппарата на сервис по работе с лояльностью. Тот сервис проверят что за клиент, сколько у него бонусов, проверяет нет ли для него индивидуальных скидок и возвращает в кассовый аппарат данные — для него товар стоит столько то, если купит получит на бонусный счет столько-то и прочую инфу. Тоесть Цена товара для клиента оказалась индивидуальной и купи этот же товар другой — для него цена была бы другой.
Эту логику нужно соблюсти и в интернет магазине.
У нас у товара будет базовая цена, полученная от сервиса по хранению товаров. Она более менее стабильна (обновляется раз в полчаса). А есть цена которую нужно показать конкретному покупателю. Авторизовался человек на сайте, перешел в какой-то раздел с товарами, видит например 50 товаров в списке и у каждого товара уже стоимость конкретно для этого покупателя. И особо проблем тут нет — для начала представим самый простой путь — в момент открытия страницы сайт будет отсылать запросы на сервер который занимается программой лояльности и получать в ответ цену каждого товара — да это трудозатратно но пока представим такой вариант. И на фронтенде ему отрисуется страница с товарами и с его индивидуальными ценами. Но с ценами нужно же работать и на бекенде. Товар он может добавить в корзину, увеличить его количество и прочее и это все должно работать с его индивидуальной ценой. И так у каждого пользователя — к примеру на сайте одновременно 1000 покупателей и каждый должен работать со своей стоимостью товара.
Ну вот отсюда и мои вопросы и сомнения.
— если каждый пользователь при каждом открытии страницы будет отсылать по каждому товару запросы на сервер хранящий данные о покупателях, их скидках, то это будет очень высокая нагрузка на их сервер. Возможно это делать заранее, для каждого покупателя пару раз в день получая все цены, но дело в том, что информация меняется очень динамично — к примеру акция может закончиться в 23 часа ночи, а обновление цен запланировано на 3 часа ночи, значит покупатель сделавший заказ в час ночи вызовет сбой в ценах — купит не по той цене.
— ну и плюс не совсем пока представляю где правильнее хранить такие объемы данных, чтобы они были индивидуальны у каждого пользователя и доступны как для фронтенда так и для бекенда.
Я конечно придумаю решение, но в мире много умных и опытных людей и их помощь важна.