Евгений Жуков (Все сообщения пользователя)

Традиционные вопросы - инфоблок 1.0, я так понимаю? И в другом инфоблоке есть еще одно свойство IN_STOCK, но не списочное?
Фильтр поменяйте с
наCIBlockElement::GetList не обрабатывает полностью конструкцию =IBLOCK_ID для свойств.

Где IBLOCK_ID в select? И NAME, кстати, тоже - т.к. у вас сортировка по этому полю.

Можете. Только зачем?

Пожалуйста. Метод "ментального дебага" выручил.

Пишите в ТП тогда. Сразу с доступом и сценарием (куда смотреть и что нажимать).

Означает, что Одно противоречит другому. Эта ошибка показывается, если изменения в базу не прошли. Создайте обращение в ТП.

Значит, данные некорректны в базе. Если используется фасета - я бы удалил и создал заново.

Нет, этого я не говорил. На примерах:

Следующий набор товаров:

• Больше 200, просмотров 2
  
• Нет в наличии, просмотров 5
  
• Нет в наличии, просмотров 100
  
• Меньше 200, просмотров 40
  
• Меньше 200, просмотров 80
  
• Больше 200, просмотров 500
  
• Больше 200, просмотров 200
  

будет отсортирован (согласно вашим условиям) так:

1. Больше 200, просмотров 500
   
2. Больше 200, просмотров 200
   
3. Больше 200, просмотров 2
   
4. Меньше 200, просмотров 80
   
5. Меньше 200, просмотров 40
   
6. Нет в наличии, просмотров 100
   
7. Нет в наличии, просмотров 5
   

Нет. Во-первых, в вашем примере на первых позициях позиции с наименьшим значением свойства QUANTITY:
Во-вторых сортировка работает так: отбираются наборы позиций, у которых значение поля первой сортировки одинаково. Внутри каждого такого набора выполняется сортировка по второму параметру.

Вам ответят в тикете

В Подробном описании разве нет переключения html/текст?

При такой проверке?

Через торговые предложения.

Создайте обращение в ТП, посмотрим.

Как это не трогаете? А отгрузки?
НЕ НАДО вызывать save для подчиненных сущностей.

А почему вы сохраняете корзину, когда должны заказ?

А сколько товара вообще?

Коэффициент единицы измерения товара скорее всего 1. Количество в заказе кратно ему.

В шаблонах, которые мы поставляем , например с демо-данными, этот вызов присутствует. Все остальные шаблоны - зона ответственности разработчика сайта.

Укажите в вызове catalog.section

"SHOW_ALL_WO_SECTION" => "Y"

должно получиться ~ -30% времени выполнения запросов
если убрать фильтр по разделу (SECTION_ID и INCLUDE_SUBSECTIONS) - не все ли равно, как глубоко лежит элемент? У топик-стартера именно эта проблема.

При таком условии вы либо отказываетесь от кеширования списка товаров, либо объем кеша вырастет в N раз, где N - число пользователей магазина.

Если кастомизация была сделана ранее апреля - 100%-я гарантия, что отсутствуют последние правки по оптимизации (iblock 18.6.200)

Нет.
На текущий момент - нет. Могу в таком случае предложить кастомизировать catalog.section, убрав обработку ключей SECTION_ID, SECTION_CODE, INCLUDE_SUBSECTIONS

Вы мне показываете вызов компонента, причем из шаблона комплексного (судя по всему). Из того, что вижу:
Вам нужна сортировка в случайном порядке? В таком случае вторая сортировка по доступности лишь ухудшает ситуацию
Выборка из всего инфоблока (в INCLUDE_SUBSECTIONS, видимо, прилетает Y - это и приводит к появлению столь озадачившего вас куска запроса). В таком случае нужно использовать не catalog.section, а catalog.top

Что в глобальной переменной arrCollectionFilter? Какой фильтр туда загоняется?

Покажите вызов CIBlockElement::GetList со всеми входными параметрами.