Может кто-нибудь объяснить логику работы компонента? Сначала выбирается Местоположение, а потом Способы доставки. В чем здесь логика? Если я выбираю способ доставки - Самовывоз - зачем мне местоположение? Но не выбрав местоположение, я не могу выбрать способ доставки. Все ведь должно быть наоборот. Сначала выбираем способ доставки, а потом, если это не самовывоз, выбираем местоположение - куда доставлять. Что-то я совсем запуталась с этим компонентом.
Вы "местоположение" в "Город" переименуйте. Тогда все станет понятнее. Дело в том, что службы доставки и платежные системы завязаны на это свойство. Если оно не выбрано - может возникнуть ошибочная ситуация.
Константин Сотников написал: расскажу как я развернул все блоки, т.к. вопрос актуальный и я на него так и не нашел нормального ответа:редактируем файл order_ajax.js
Константин, спасибо, пока Ваше решение наиболее продвинуло меня к результату. Но возникла сложность: почему-то в этом случае блок выбора доставки обязательно должен быть вверху. Если пытаюсь опустить его вниз любым способом (через шаблон, или через настройки компонента), все вообще пропадает. Подскажите, пожалуйста, почему это может быть?
Максим Ляпцев написал: Может есть у кого-нибудь есть более-менее нормальный шаблон? Давайте выложим на гитхаб и будем вместе его дорабатывать и развивать,. С этим же нереально работать. Или может есть документация где-то, разбор этого монстра? Как думаете что проще сделать, если оформление заказа вообще никак не похоже на стандатный шаблон? Делать свой шаблон с нуля или все же пытаться кастомизировать?
Сделать с нуля. Смоделировать поведение под штатную логику не так уж и сложно, хоть и кропотливое занятие. Но зато сделав один раз можно не зависеть от шаблона. Главное чтобы вдруг в одночасье не сменили логику самого компонента.
Я кстати так и сделал. Взял штатный компонент, скопировал в свою область. И настроил логику в публичке под новый компонент и все нормально работает.
Здравствуйте. Стоит задача от директора интернет магазина сделать вывод "Служб доставки" (у нас их порядка 10-15) плиткой не вертикально строчно, а именно плиткой например 4 на 4. * * * * * * * * * * * * * * * *
не подскажите как привести их к такому выводу? оч надо. В js не силен(((.
Приветствую. А ни кто не подскажет как запустить в компоненте геолокацию? В sypexgeo зарегистрировался, ключ их прописал в настройках. Тестовый код корректно возвращает определенное местоположение:
Еще одна проблема обнаружилась с этим компонентом. После обновления системы перестали оформляться заказы. То есть, вообще перестали - страница обновляется, и ничего не происходит - ни сообщений об ошибке, ничего. Пришлось вернуться к дефолтному шаблону. Хотя кастомизация была очень поверхностная, только стили некоторые чуть изменили. Его что теперь, вообще нельзя редактировать?
Доброе утро, Андрей. Спасибо большое за шаблон sale.order.ajax ! Андрей, подскажите пожалуйста я скопировал стандартный компонент sale.order.ajax в /bitrix/templates/eshop_bootstrap_black/components/bitrix/sale.order.ajax/main, удалил оттуда все файлы и вставил ваши, но он так и не изменился (Вернее на внешний вид заметил что исчезла кнопка "изменить", а все остальное выглядит так же). Подскажите, что я сделал не так?
У вас включена в настройках Главного модуля галочка Подключения минифицированных файлов js. Варианты: 1. Отключить галочку (не рекомендую); 2. Удалить файл order_ajax.min.js в шаблоне (рекомендую); 3. Вручную минифицировать файл.
Народ, может быть, у кого-то есть верстка оформления заказа, которую не жалко дать мне для научных опытов? Я хочу поиграться с новым шаблоном, максимально его упростить и затем написать статью, как переваривать этого монстра.
Пытаюсь кастомизировать новый sale.order.ajax, скопировал его себе в шаблон(естественно прописал, чтобы вызывать его из шаблона), но выдает такую ошибку
Fatal error: Call to undefined method CBitrixComponent::scaleImages() in /home/vaznov_sites/marketplace24.ru/test1/bitrix/templates/fb2shop/components/pplus/sale.order.ajax/.default/result_modifier.php on line 10
по ошибке можно понять, что ему не нравяится метод на строке 10 в result_modifier.php :
Судя по сообщению об ошибке - вы скопировали не только сам шаблон компонента, но и компонент целиком в свое пространство имен. Проверьте корректность этой операции.
Коллеги, добрый день. Перечитала всю тему. Уже неоднократно поднимался вопрос о том, что нужно перенести поле "адрес доставки" в блок с доставками. Перенести его мне удалось, но очень коряво работает вывод ошибок - то отображается в нужном блоке, то в "покупателе", то слипается с другими ошибками покупательских полей. Возможно, у кого-то был опыт подобной кастомизации? По переносу полей в другой блок, если нужно, своими костылями поделюсь)) она в целом нормально работает, если поля не являются обязательными.
Коллеги, в виду отсутствия информации пришлось во всём разбираться самостоятельно. Просто не могу оставить это неопубликованным. Возможно, кому-то поможет мой опыт кастомизации. Описала у себя в блоге: http://bitrixoved.blogspot.ru/2017/12/saleorderajax.html
Обнаружили в компоненте sale.order.ajax интересный баг (обновления довольно свежие - за ноябрь, поэтому, вряд ли что то поменялось).
Проблема: Даже при не установленном флаге в параметра компонента "Рассчитывать сразу доставки с внешним доступом к сервисам:" при заходе на страницу с компонентом sale.order.ajax отправляются запросы на расчет стоимости разными службами доставки(даже, если эта служба доставки не первая в списке). Даже, если мы на самом первом шаге, когда еще и города/индекса нету. Проверял для СДЕК и для Почты России ( у которой расчет через api pochta.ru). (Подробнее, неизбежность данного процесса можете проследить внутри компонента: executeComponent()->doAction()->processOrderAction()->createOrder()->getOrder())
На небольших ИМ эти бесполезные лишние запросы не критичны, а при высокой посещаемости, дают существенную нагрузку + выедают лимиты.
Долго не могли понять, почему так происходит, пока не добавили логирование. Скриншот для примера: Ссылка на скриншот
P.S. подумал, что проблему можно решить кастомизацией шаблона. Но нет... Даже убрав шаблон полностью, паразитные запросы остаются. Может быть, эта информация кому то окажется полезной.
"Это не баг, это фича" (С) Советы по эффективному маркетингу.
Версия 17.5.4 "main" и 17.0.32 "sale".
В дефолтном компоненте sale.order.ajax есть вот такая настройка. Для тех, кто не открывает левые ссылки при чтении основной статьи: настройка "Когда рассчитывать доставки с внешними системами расчёта". Настройка имеет селект-поле выбора с 3 вариантами выбора:
Не рассчитывать (вариант "угадай сам")
Учитывать настройки доставки
Рассчитывать сразу
Вторая опция (Учитывать настройки доставки) работает с обработчиками доставок, сконструированными с применением высокотехнологичных методов d7. Это значит, что обработчик должен быть унаследован от базового класса Bitrix\Sale\Delivery\Services\Base и быть в пространстве имён Sale\Handlers\Delivery. Подробности в курсе. Больше подробностей в классной статье.
Модуль же ipol.sdek, который на скриншоте у Алексея, написан в соответствии с Ветхим Заветом старым положением вещей и ядра. Без использования неймспейсов вообще, что можно посмотреть в include.php модуля.
В новом варианте описания обработчиков есть метод isCalculatePriceImmediately():bool, который как раз и используется при отмеченной опции "Учитывать настройки доставки".
Ещё подробности для новой системы: 1) Если рассчитываемая внешними сервисами доставка стоит первой в списке, то в самом начале метод рассчёта (calculateConcrete()) будет вызван трижды: при initDelivery(), для recalculatePayment() и из calculateDeliveries(). Поэтому в дополнительных рекомендациях к курсу и есть непрозрачно-однозначный намёк на организацию кэширования. Также это повод переместить нерассчитываемые внешне службы, вроде самовывоза и статического рассчёта, в списке в самый верх.
2) Помимо написания непосредственно обработчика доставки можно написать к нему профили и дополнительные услуги. Как пример - СПСР. Комментариев в коде кот наплакал, но они уже есть!
3) Метод проверки совместимости isCompatible() вызывается до calculateConcrete(), что логично. Но если, например, нужно рассчитывать совместимость, исходя из полей ответа внешнего сервиса, то всегда можно вызвать в переопределяемом методе тот, что нужен. В некоторых случаях этим можно даже заменить ограничения служб доставки, связанные с внешними факторами.
Цитата
Алексей написал: На небольших ИМ эти бесполезные лишние запросы не критичны, а при высокой посещаемости, дают существенную нагрузку + выедают лимиты.
Если есть возможность и время, то возможно Вам поможет кэширование.
Just Ahmed написал: На небольших ИМ эти бесполезные лишние запросы не критичны, а при высокой посещаемости, дают существенную нагрузку + выедают лимиты.
Есть ещё интересный вариант отключения ненужного насовсем (неявно из курса). Если в папку /bitrix/php_interface/include/sale_delivery/ положить пустой файл с именем имеющейся, но ненужной службы доставки (в точности как в /bitrix/modules/sale/delivery/ ), то запросов не будет вообще: т.е. пустые файлы /bitrix/php_interface/include/sale_delivery/delivery_pecom.php /bitrix/php_interface/include/sale_delivery/delivery_cpcr.php
Ребят, еще столкнулся с интересным моментом. Переносил свойства из блока "пользователь" в блок "доставка". Было не просто, но в итоге получилось) Но проявился баг, где его не ждали - отвалились службы доставки с пунктами самовывоза. Мб, кто уже сталкивался и может дать подсказку? А то, чувствую ,еще день ковырять и пытаться внести изменение в одном месте так, чтобы в другом не развалилось.
Юрий Поляков написал: Есть ещё интересный вариант отключения ненужного насовсем (неявно из курса). Если в папку /bitrix/php_interface/include/sale_delivery/ положить пустой файл с именем имеющейся, но ненужной службы доставки (в точности как в /bitrix/modules/sale/delivery/ ), то запросов не будет вообще: т.е. пустые файлы /bitrix/php_interface/include/sale_delivery/delivery_pecom.php /bitrix/php_interface/include/sale_delivery/delivery_cpcr.php
Если при копировании не изменить имя (оставить /bitrix/php_interface/include/sale_payment/yandex), то в настройках платежных систем можно будет использовать только кастомный обработчик. Системный (тот, который копировался) не будет доступен, то есть кастомный обработчик подменяет системный.