Цитата |
---|
12.12.2019 12:11:36
|
|||
|
31.07.2018 13:38:32
ну и я добавлю
в sections.php и section.php и там где нужна плашка сравнения
пример вызова catalog.item
|
|||||||||
|
31.05.2018 12:44:40
/bitrix/components/bitrix/sale.basket.basket/ajax.php менял и то и другое. файл ajax не знает о параметрах там же $params = array(); а via_ajax я не передаю соотвественно подключается дефолтный шаблон с пустыми параметрами а вот передать в запросе дополнительно action_var - да в компоненте есть проверка
|
|||||||
|
21.05.2018 10:50:58
все оказалось проще. старый шаблон вполне рабочий.
в ajax запросе вместо action надо писать basketAction переименовали переменную по умолчанию в старой корзине $action_var = (isset($_POST["action_var"]) && strlen(trim($_POST["action_var"])) > 0) ? trim($_POST["action_var"]) : "action"; в новой корзине if ( empty($params['ACTION_VARIABLE']) || !preg_match('/[a-zA-Z0-9_-~.!*\'(),]/', $params['ACTION_VARIABLE']) ) { $params['ACTION_VARIABLE'] = 'basketAction'; } |
|
|
09.05.2018 17:34:59
аххахах
встречайте sale.basket.basket - еще один компнент на js при этом совместимость со старыми шаблонами удалили полностью обновил битрикс и теперь запрос по/bitrix/components/bitrix/sale.basket.basket/ajax.php с запросом recalculate возвращает не json а шаблон... "спасибо". вот из за таких сюрпризов проект оценивался в 30 часов. а тут на тебе 10к скриптов. изучай. при этом ни разу. вот ниразу не использовали дефолтный шаблон какой либо. вообще. придется вытаскивать с какого то сайта старую корзину, надеюсь заработает... но если такая тенденция сохранится и в будущем. то может уже тогда ReactJS/AngularJS/VueJS используете? хотя бы будет ради чего менять шаблоны на js |
|
|
24.05.2017 15:39:13
я хз кто писал этот компонент, но я просто фигею, пригорает очень сильно
это что за бред где то завязано на id - ок через две строчки идеть проверка на наличие класса. че? а в другой функции проверка на тег. чего??? а чего не все сразу? чтоб и тег был нужный и id тот что требуется и класс не заменен. все функции настолько связаны и несамостоятельны что просто капец какой то. правишь в 1 месте отваливается еще 10. и сиди по связям, и вызовам ковыряй а где же отвалилось. черти че. но за привязку к tagName жирный минус. итого на правка шаблона оформления заказа более 40 часов...отличная оптимизация. |
|
|
13.05.2016 18:44:33
Можно ли на d7 создать подобное условие WHERE без и спользования runtimeField?
|
|||
|
08.04.2016 18:12:54
Добрый день
Пишу модуль на Д7. по другому никак - куча связей между инфоблоками. Столкнулся с дилеммой Если хранить свойства инфоблока в отдельной таблице. то для описания связи с этими свойствами нужно учитывать 2 таблицы 1 b_iblock_element_prop_m#id_iblock# 2 b_iblock_element_prop_s7#id_iblock# Казус в том что если свойство множественное то в b_iblock_element_prop_s7#id_iblock# нет намека на то что смотри таблицу с множественными есть ли способ выбрать все свойства кроме как такого варианта?
просто каким образом потом различать есть ли мультисвойство или нет...проверять на пустоту. а потом проверять 2ой столбец..бред какой то... может есть более удобный способ? |
|||
|
31.03.2016 14:26:04
Доброго времени суток.
Какой путь реализации лучше выбрать, спрашиваю потому что о D7 практически ничего не знаю Суть задачи Есть несколько инфоблоков, элементы которых связаны друг с другом Например Инфоблок Адреса Инфоблок Типы домов К каждому адресу привязан тип дома Инфоблок Планировки К каждой планировке привязан тип дома Инфоблок - Дизайны Каждый дизайн привязан к планировке Инфоблок Товары Дизайны состоят из товаров (с учетом количества) ищем дизайны. фильтровать можно по любому свойству указанных инфоблоков. Как вижу я Вариант 1 Делать через D7 новые сущности и проставлять нужные связи. Написать компонент который будет реализовывать логику фильтра по этим связям Вариант 2 Написать скрипт импорта который будет привязку по xml_id в файле импорта (csv) переводить в привязку к элементу (id) Далее стандартный функционал использовать В первом варианте - я не знаю про D7, написание модулей и компонентов ровным счетом ничего (писал модули для MODX но это врятли тут поможет) Так же не понятно что делать с админской частью Во втором варианте - скрипт импорта будет уж очень мудреный, и непонятно какие будут подводные камни при повторном импорте, и хватит ли связей между инфоблоками для реализации фильтра. З.Ы. реально ли сделать множественное поле где 1 столбец будет привязкой к элементу, а остальные строками, т.е. нужно выбирать элемент и указывать его количество например. будет ли множественное свойство подобного типа учавствовать в фильтре? или оно сохраниться как json и лучше делать кастомную таблицу для подобных свойств? |
|
|
03.12.2015 18:22:45
вот с такой сортировкой работает
|
|||||
|