class TwoForTwo extends \CSaleActionCtrlGroup
имеем 3 раздела в каждом одинаковые товары в первом дожна быть сортировка 321 во втором - 231 в третьем 132 в остальных 123 Поле SORT - обеспечит общую 123 как нам поможет одно единственное свойство PROPERTY_SECTION_SORT в 3 разделах если элемент во всех трех есть и должен по разному сортироваться? не понял. |
|||
|
|
|
|
Как предложил Илья, заведите свойство отдельное.
Вам нужно вывести где-то в середине текста или уже после содержимого? 1. в середине текста, тогда в месте где нужно выводить блок внесите метку #BLOCK# далее в шаблоне вывода статьи сделайте замену
2. после содержимого тут еще проще, меток в тексте не нужно никаких просто проверяете пустое новое свойство или нет и выводите свой блок |
|||
|
|
|
те кто перекрещивают, они не думают, они говорят хотим видеть и все. А думать как это реализовывать и настраивать мне. Вы предлагаете обойтись 2 типами, без учета разделов, а мне нужно именно чтоы учитывался раздел. На текущий момент имею примерно 60 разделов первого уровня каждый из которых имеет примерно в два раза больше второго уровня. товары пересекаются. и вот мне нужно примерно для 50 разделов свои сортировки не совпадающие с общей сортировкой. Возьмем 3 соседних раздела, в которых товары могут пересекаться, должны иметь свои сортировки: в первом линия 5 на первом месте, во втором линия 66 и затем линия 5, в третьем линия 200 и линия 66 в четвертом уже не линия, а бренд 88 должен сначала идти кроме того есть общая на весь каталог сортировка 1. распродажный товар или нет, 2. новинка или нет 3. по цене с точки зрения маркетинга такие желания понятны: хотим чтобы сегодня трусы линии интим были на первом месте, а в бюстгалтерах, на первом шли другой линии, а в трусах красных на первые строчки попадали уже не интим, а линия специализирующаяся на не знаю там на кружевах Насколько я понял можно решить мою задачу костомизировав компонент через \Bitrix\Iblock\ElementTable::getList 'runtime' => array( new \Bitrix\Main\Entity\ExpressionField() ) но пока не понял как |
|||
|
|
|
|
Тем что мне для каждого раздела своя нужна.
т.е. у меня есть куча разделов каталога(скажем так, много), для ряда разделов нужно сделать свою сортировку, в одном одну линию вверх поднять, в другом другую и т.д. А для каталога в целом должна своя сортировка настроенная идти. и создавать кучу дополнительных свойств не вариант( их и так не один десяток. По мере проведения акций и просто желаний маркетологов сортировка будет менятся(вплоть до каждодневной) В sql это можно сделать при помощи ORDER BY FIELD() как быть тут не знаю. вариант с 'ID' => [3,21...] не подходит тоже, просто по той причине ,что модуль инфоблоков не обновлен до версии когда эта возможность появилась и обновить нет возможности. |
|
|
|
|
|
это если достаточно именно категории, а не самого товара. и то не слишком удобный способ, так как придется дублировать службы доставки.
В остальных случаях только писать код. Самым оптимальным было бы написать свое ограничение, примеры в сети есть. или если это разовый вариант, можно воспользоваться событием
|
|||
|
|
|
|
Есть товары у которых заполнено свойство OTHER в котором указан XML_ID другого товара
Нужно вывести товары у которых свойство пустое, но если количество товара с XML_ID=PROPERTY_OTHER второго товара, то тогда вывести второй товар Фильтр исключить товар с заполненым свойством не проблема
А вот как второе условие прописать, по логике через подзапрос, но не соображу как |
|||
|
|
|
|
Ситуация такая: Из 1С выгружается товар одежда. По идеалогическим правилам есть просто товар, а есть больших размеров - разный артикул, разные ТП.
Нужно отобразить одну карточку, первую,которая объединит в себе обе. При заказе соответсвенно если выбрали размер от второй должен в корзину отправится именно 2 товар. При этом в каталоге 2 карточка не должна отображаться. Поиск должен вести на первую карточку при указании артикула или других поисковых запросов от второй. но вторая должна остаться доступной при прямом заходе на нее У кого есть опыт или идеи как подойти к такой задаче буду рад услышать |
|
|
|
|
|
так все верно работает. Поле XML_ID еще называется внешний код, по этому полю идет сравнение наличия такого элемента иначе было бы нельзя обновить товары и всегда генерировались бы новые. Если необходимо чтобы стандандарттный функционал импорта так не работал, придется написать свой обработчик, и не использовать стандартный.
Еще как вариант попробуйте событие OnBeforeIBlockElementUpdate в котором запретить изменние элементов в заданном инфоблоке. Не знаю есть ли событие именно на импорт. Поэтому если нет то завести глобальную переменную которая бы разрешала/запрещала обновление и на событии проверять. Т.е. перед запуском импорта включаете запрет, после импорта его выключаете и правите свой инфоблок. |
|
|
|
|
|
то что вы привели это полная фигня.
подключается на страницах где не нужно подключение шаблона сайта, но нужны будут модули и прочее, обычно для отдельных обработчиков
это подключение шаблона и уже должны в себе содержать
|
|||||||
|
|
|
Данные которые которые нужны только для меньшей части людей в коробке отсутствует. Ну как-то так. К тому же битрикс предполагает, что человек поставит сам так как есть, а на остальном должны свой куш получить разработчики. Если продумают ооочень много всего изначально, то разработчикам не на чем будет зарабатывать. |
|||
|
|
|
|
Досконально не получится.
Если через PHP, то предполагается, что вы можете на основании каких-то данных переданных на страницу проверить равен ли он каким-то данным на текущем сайте, если равен, то сделать редирект на новый адрес, который вы так же формируете налету. т.е. у вас старый адрес к примеру был какой-нибудь /tovar/telek-123/cvet-green/?dop=12 и по нему перешли на новый сайт соответсвенно каждая часть такой ссылки что-то да значит, разбиваете на составляющие и проверяте есть ли товар/раздел/новость или еще что-то что можно из БД/файла получить значения. Если есть делаем редирект
|
|||
|
|
|
|
в теме указано
Хотя я на одном из проектов вообще по другому делал, подключил старую базу дополнительно к новой и по коду из 1С сравнивал там и в новой товары и на основе сравнения делал редирект. Но такой способ требует знания структуры старой базы и место на сервере для нее(на полгода) |
|||
|
|
|
|
Нету. У каждого свое понятие как хранить и использовать такое понятие как бренд или артикул товара. К примеру вот вы говорите:
|
|||
|
|
|
Порадовали, спасибо.Теперь серьезно: Ничего такого нет, каждый сам решает, что ему и как нужно. Я как раз именно таким глупым решением "Прописывание правил-редиректов в htaccess для хоть сколько-то большой базы товаров является глупым и безуспешным занятием." и занимался всегда. Есть еще вариант через PHP сделать редирект, но обычно только когда есть откуда сформировать пути, например как вы предположили
|
|||||
|
|
|