форуме создал. нигде в интернетах нет нормального решения этой проблемы на чистом битриксе без всяких модулей и костылей. https://dev.1c-bitrix.ru/support/forum/messages/forum6/topic146588/message707924/?result=new#message707924
Как ориентир посмотри аспровские шаблоны. Не помню точно в каких именно аспро, но там реализована региональность на одном сайте. Я как-то делал такую штуку, но мне хватило события onGetOptimalPrice и проброса в каталог нужного типа цен. Там был небольшой каталог и полностью вся инфа, включая скидки, приходила из 1с, поэтому никаких проблем не возникало.
onGetOptimalPrice использовать некорректно. у меня и сейчас используются скидки и в будущем начнут вводить какую нибудь акционность и придётся постоянно этот обработчик переделывать и получать люлей за косяки с ценами. я делаю так чтобы оно дальше без вмешательств работало с остальным функционалом битрикса.
Ограничить выбор типа цены с сохранением всего остального функционала - элементарная задача на этом событии. Из минусов только падение производительности при выгрузке в яндекс, например. Метод на вход цены получает. Вызовите его еще раз, передав только те цены, что нужно.
спасибо за совет. мне стандартный компонент где он вызывается перезаписать или где его вызвать повторно?
Вот теперь я не понял. Вам только в конкретном месте нужно ограничивать или общую работу модифицировать (чтобы везде действовало)?
сейчас у меня проблема только с оформлением заказа. в корзине применяется цена наименьшая. в каких других местах может ещё вызываться getoptimalprice я не знаю. ядро не изучал так глубоко.
Вот и сделайте обработчик, который сам будет вызывать этот метод, но с измененными параметрами. Как избежать зацикливания - давно изложено.
Спасибо. а как мне узнать чтобы мой вызов точно был последним и после него не вызвался ещё где-то этот метод? возможно переопределить этот метод в init.php и написать логику для выбора цены там? чтобы из любого места где он впоследствии будет вызываться он вызывался с моей исправленной логикой?
А зачем вам это знать? Про переопределение я вообще молчу.
ну чтобы после моего вызова не произошёл повторный расчёт цены. если потом какие то другие виды скидок подключат например
Абсолютно не нужно. Если ваш обработчик вернет цену, остальные не выполнятся.
зарегистрируйте свой метод к событию onGetOptimalPrice и распишите логику при каких обстоятельствах и где необходимо изменить цены событие по сути является перехватчиком, а также определяет этап, на котором можно изменить и другие глобальные параметры. если кто-то захочет накинуть что-то сверху, тому уже и логику выстраивать, куда именно он захочет накидывать
мне не нужно менять цены. мне нужно чтобы метод CCatalogProduct::GetOptimalPrice откуда бы он не вызывался в ядре, учитывал тип цены по моему условию (брал ID из кешированной сессии). а не собирал все типы цен доступные текущему пользователю. вот что мне нужно. переопределение цены в самом этом событии не подходит для случаев когда я хочу оставить рабочими все остальные механизмы скидок, уценок и т.п.
если я правильно понимаю onGetOptimalPrice, один раз определив его, вы уже замените updateUserHandlerOptimalPrice, и сможете собрать ваши цены, которые в дальнейшем будут обрабатываться и если кто-то захочет еще что-то к этому методу прикрепить, то это наложится сверху, или сначала кто-то заменит, а затем ваш метод отработает, в зависимости от сортировки регистрации в итоге в любом случае вы получите необходимый результат
Спасибо, завтра на свежую голову посмотрю ещё раз внимательно. Возможно я что то не правильно понял в этом обработчике.
Ты наверное путаешь вызов события и вызов метода. Метод CCatalogProduct::GetOptimalPrice может быть вызван гле угодно, сколько угодно раз, но каждый его вызов повлечёт вызов события OnGetOptimalPrice, на которое ты будешь подписан и твой обработчик вернёт из него нужный тебе тип цен, в зависимости от города, который сохранён в сессии. То есть твой обработчик в любом случае перехватит событие, откуда бы и сколько раз оно ни было вызвано.
Это я как раз понимаю. Вот только в обработчике я не видел возможности заменить входящий в метод список цен. Обработчик возвращает либо тру либо фолс либо массив с наименьшей ценой. И всё
Ну. Так ты внутри обработчика получи все типы цен, выбери из них нужный тебе и верни его.
И дальше что? На эту цену не применится никакая скидка из админки битрикса
Второй элемент возвращаемого массива - 'DISCOUNT' А в обработчик тебе прилетает одним из параметров $arDiscountCoupons Так что, скорей всего можно.
Я это всё делал и это не работает
Вот именно со скидками я не делал, поэтому не могу утверждать.
Обсуждают сегодня