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

Ну, если ее по диагонали читать, то да, не описано.

Возможно. Вешаете на cron импорт.

Подробнее. Чей $arResult надо сохранить? Если "компонента_2", что мешает возвращать его ($arResult) в конце компонента?

Универсализм не дается бесплатно. Я , кста писал, почему не рекомендуют юзать чистый SQL.
Элементарно. То, что может быть затерто, проверяю после обновления. Но в ядро не лезу.Зайдите в свойства инфоблока. Если написано, что данные хранятся в общей таблице - это 1.0 (по умолчанию). Конвертация инфоблока с ~ 40 тыс. записей у меня заняла час-полтора. Все это время доступ к сайту посетителей, мягко говоря, нежелателен.
Как мне в свое время ответила ТП - под крупные проекты всегда идет заточка
Очень вероятно. Как вариант - неоптимальный кеш.Все, что нуждается в настройках и кешировании, должно быть в компонентах. Точка.
Любые другие варианты - чистой воды мазохизм, с этим к психиатру.
Нет. Сильно увеличит производительность тюнинг БД.

Весь код приведите.

Не поделитесь, откуда такие данные? У меня как-то все от 90% до 99% получается. Может, я их готовлю неправильно?

И заглядывал, и переписывал для своих нужд. Я понять не могу - откуда будут вызовы _ext.php, если меню УЖЕ закешировано?

Откуда Вы их вообще откопали? В компоненте? Значит, смотрите код шаблона или файл стилей для него.

Если инфоблок 1.0 - немедленно перевести в 2.0. Индексы по полям фильтра попробуйте, если еще не сделали.
Как вариант - фильтр на ajax попробовать, типа гуглового выпадающего списка фраз.А Вы посмотрите код класса CIBlockElement или генерируемые им sql-запросы Вопрос сразу отпадет.

А кеш на что?

Во-первых, можно не перебирать все для получения ID продавцов, а заполнять массив по мере получения информации о товарах. Во-вторых, не пытались оптимизировать запросы в GetList? Приведите пример кода - возможно, сумеем помочь. Ну и как вариант, попробуйте сменить структуру инфоблоков.

Как вариант - через отбор по свойству товара, лежащего в корзине.

По принципу "сказал, а потом подумал"? А для функции выборки - да, важно. Потому что по Вашему алгоритму надо выбрать все, а потом перебирать. Скрипт умрет.

Простите, а причем здесь страница сайта? Пользовательские поля задаются для юзеров, секций инфоблоков.
Если Вам надо задать для страницы какое-то свойство - $APPLICATION->SetPageProperty к Вашим услугам. Ну и настройки модуля "Управление структурой".

Сортировка при это должна идти по LEFT_MARGIN => ASC?

Ваш вариант не может работать. Положили Вы ДВЕ копии ОДНОГО компонента, который работает с ОДНОЙ корзиной. Там же фильтр есть. Через него только если, и то с трудом.

Успехов Вам на инфоблоке с хотя бы 1000 записей.
Посмотрите, как кавычки у вас в базе хранятся. После этого можно подумать.

Знак доллара в названии не нравится, видимо.

LEFT_MARGIN+1 = RIGHT_MARGIN - выполнение этого условия для секции означает, что подсекций нет.

Попонятней объясните суть проблемы.

Для меню из инфоблоков - писал компонент редиректа с кешированием. Для статики - разбирал меню и перекидывал на первый подраздел.

Восхитительная логика.

Таблица b_sale_user содержит идентификатор для привязки корзины к пользователю. Большое обилие записей с USER_ID = NULL означает, что у Вас на сайте шарилась куча неавторизованного народа (когда USER_ID не определен). Вы можете ее очистить (убрать записи с USER_ID = NULL), только если в таблице b_sale_basket нет привязок к соотв. записям из таблицы b_sale_user. А лучше написать в ТП и попросить совета.

да, действительно. Полностью проблему закроет Ваш вариант.

Этот функционал только в MySQL-версии. Архивы .tar.gz делает еще 7-Zip.

в отдельном поле прописать название раздела. Если это подраздел - два поля: раздел верхнего уровня и подраздел. И так далее.

Ыыыы... Снова идем в импорт. Видим, что 2 поля выделены красным цветом - XML_ID (оно же EXTERNAL_ID в терминологии класса CIBlockElement) и NAME. Раскрою страшную тайну. Так вот, если у Вас есть товары с одинаковым названием, но разным XML_ID - система их за один не посчитает, хоть Вы с ней дерись. И наоборот, два товара с разным NAME и одинаковым XML_ID будут сочтены одним и тем же товаром.

Резюмирую. Если других аргументов за то, чтоб юзер видел XML_ID (EXTERNAL_ID) в ссылках нет - используйте стандартные компоненты + импорт с XML_ID и не усложняйте себе жизнь.