smilingcheater, это платформа InSales. У заказчика есть шаблон ( там он именуется "дизайн"), который тянет те самые упакованные скрипты из чужого CDN. В эту упаковку, как я уже сказал, запихана lodash версии 4.17.15 . В конфиге шаблона не был подключен дополнительный функционал InSales , который теперь понадобился. Этот функционал называется common.js , но он требует lodash версии 4.17.21, сам же её подключает, и сам же ругается на второе подключение.
В итоге получается так:
1) если lodash подключена дважды, функционал common.js фактически не работает, но ошибок не выдаёт;
2) если более старую версию lodash подменить, то common.js работает. Но я сделал подмену слишком грубо, и это этого частично сломался шаблон.
Разработчиков шаблона уже нет, у них вместо сайта заглушка.
вот только "разворачивать штатными средствами" не выйдет. Насколько знаю, кодирование в Zend Encoder (Zend Optimizer) - это односторонний процесс; там перевод исходного кода в байт-код виртуальной машины ZendEngine. Я вроде слышал о декодерах, но результат у них плачевный; только чтобы почитать алгоритм, если очень-очень надо.
Так что без исходников это можно только в рамочку на стенку повесить.
Первое: если у Вас есть ID элементов, зачем вообще указывать раздел? Ставьте везде, где надо "SECTION_ID" =>0, "INCLUDE_SUBSECTIONS" => "Y",
Если нужно фильтровать и по разделам, укажите их в том же фильтре
Кстати, не очень удачные названия для переменных: $sectId - предположительно, здесь должно быть число, единственный айдишник. $sectIdList лучше. И можно не сокращать, современные редакторы кода умеют дополнять на лету; $sectionIdList читается легче, а код пишется для людей.
$arrFiltrId - аналогично, я бы предположил, что здесь Id какой-то сущности, обозначенной как $arrFiltr. И вот эти дурацкие приставки "arr" из псевдовенгерской нотации - выкиньте их. Битриксоиды не могут, они уже насквозь испорчены этим, а Вам ещё не поздно исправиться.
$elementIdList читабельнее. ( я даже не против $tovarIdList , хоть и не сторонник русификации )
Иван, моя гипотеза:
1) берёте событие OnBeforeBasketAdd
2) читаете статью: https://it-svalka.ru/blog/bitrix/rabota-s-korzinoy... - фиг знает, когда он а была написана, но вроде годится. Оттуда видно 2 направления работы:
а) подмена класса в PRODUCT_PROVIDER_CLASS на свою реализацию,
б) CUSTOM_PRICE
добавляется 65 р. независимо от того, сколько "штучных" товаров в корзине? То есть, если я взял пачку этой бумаги, и пачку другой бумаги, то это всё равно +65 р, а не +130 р?
Задача сложная, и решается не там, где Вы смотрите, не в коде компонента. Раньше бы для этого пригодился обработчик GetOptimalProductPrice, который можно было назначать при добавлении товара в корзину. Сейчас - не знаю.
Кто-то решал подобную задачу за счёт назначения товару двух цен; при определённых условиях пользователь добавляется в особую группу, которой доступна вторая, более низкая цена. Ещё можно попробовать "перевернуть" ситуацию - основную цену назначить выше, но давать скидку при покупке от 5 штук; я уверен, что это можно делать через "правила работы с корзиной". У "правил" есть недостаток: их не может быть много, и они не могут быть слишком объёмными, иначе сайт начинает тормозить
junior_www, точно так же. В старом API это CIBlockElement::GetList() , в новом - Bitrix\Iblock\ElementTable::getList() ( или можно задать "Символьный код API" инфоблока и работать с ним как с объектом)
переключение табов - это JS. Варианта я вижу два:
1) код, связанный с "Clipart" , содержит сломанный JS и на фронтенде ломает заодно и табы.
2) код, связанный с "Clipart", кривой и из-за него почему-то не выводится JS, который обспечивает работу табов.
Смотрите консоль браузера, смотрите инспектор.
.. и похоже на то, что это ссылка лежит в корне DOCUMENT_ROOT и указывает на текущий каталог ( то есть www -> . ).
Встречал на одном из проектов, выглядит как вредительство
советую давать какие-то осмысленные имена. Не arrFilter , а catalogSearchFilter , например. Иначе легко напороться на то, что какой-то другой компонент подхватит ненужный ему фильтр и начнёт работать некорректно
Вы не путайте ID сессии ( то, что прилетает на клиента) с тем, что в сессии хранится (и остаётся на сервере. Уязвимость может быть только в случае, если злоумышленник доберётся до хранилища сессий ( в самом просто случае это каталог с файлами) и сможет читать оттуда.
В итоге получается так:
1) если lodash подключена дважды, функционал common.js фактически не работает, но ошибок не выдаёт;
2) если более старую версию lodash подменить, то common.js работает. Но я сделал подмену слишком грубо, и это этого частично сломался шаблон.
Разработчиков шаблона уже нет, у них вместо сайта заглушка.