Антон Пилецкий (Все сообщения пользователя)

К сожалению такая конструкция работает не должным образом. Уже вот тут обсуждалось - http://dev.1c-bitrix.ru/community/forums/messages/forum6/topic54959/message289537­/
SQL формируется так, что данная логика не работает.
Условие в SQL выглядит примерно так:Из-за этого получается пустая выборка. Напишите в ТП Битрикса о проблеме.

Временное решение.
Выбрать товары по логике ИЛИ, а потом в цикле отобрать товары, у которых одновременно есть указанные значения. Взять ID полученного множества товаров и подставить в фильтрПонимаю, говнокод. Но будет работать.

Когда возникают проблемы с определением правильного формата выгрузки каталога, я делаю экспорт инфоблока в XML-файл (http://site.com/bitrix/admin/iblock_xml_export.php) и смотрю правильный формат выгрузки нужного свойства или поля товара.

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

Константин Сергеев, написал в личку.

Тоже сижу на Eclipse. Пока нормальных альтернатив не вижу.
Перешел на данную IDE после этой статьи http://dev.1c-bitrix.ru/community/webdev/user/107077/blog/6582/
После подключения вот этого:
https://github.com/matiaspub/bxApiDocs
https://github.com/matiaspub/bxCompSnpt
https://github.com/pilezkiy/bxLiveTemplates4Eclipse
наступает рай.
А фильтры в FTP/SFTP клиенте (работаю в основном удаленно без выкачивания проекта целиком) вообще киллер-фича

В шаблоне компонента можно прописать всё, что угодно.

Для товаров раздела, где стоимость выводится за квадратный метр, нужно сразу указывать цену в специальной валюте. И для этой валюты указать специальный формат вывода (# руб/м2). Делать это желательно либо сразу при выгрузке из 1С (если такая есть), либо при помощи обработчиков сохранения цены OnBeforePriceAdd/OnBeforePriceUpdate подменять валюту. Если же задание цены идет руками, то сразу выбирать правильную валюту.
В шаблоне стоимость нужно выводить так:

• $arItem["MIN_PRICE"]["PRINT_VALUE"] - отформатированная цена без скидки
  
• $arItem["MIN_PRICE"]["PRINT_DISCOUNT_VALUE"] - отформатированная цена со скидкой
  

В этом случае никаких проверок $arResult['IBLOCK_SECTION_ID'] в шаблоне не будет.

А вы уверены, что $arResult['IBLOCK_SECTION_ID'] установлено?

Читайте документацию
http://dev.1c-bitrix.ru/user_help/content/iblock/components_2/news/news_list.php
http://dev.1c-bitrix.ru/user_help/content/iblock/components_2/news/news.php
Обратите внимание на параметры "ACTIVE_DATE_FORMAT", "DETAIL_ACTIVE_DATE_FORMAT" и "LIST_ACTIVE_DATE_FORMAT".

То есть при задании даты всегда придется указывать точную дату. А вот при выводе формат можно регулировать.
Если вас данный подход не устраивает, всегда можно написать своё свойство элемента инфоблока.

Если брэнд - это элемент инфоблока, то все просто.
Кидаете в раздел site.com/brands/ компонент bitrix:news, выводящий брэнды.
На детальной странице бренда (файл detail.php в шаблоне комплексного компонента bitrix:news) формируете фильтр по ID бренда и выводите список товаров по этому фильтру с помощью компонента bitrix:news.list или bitrix:catalog.section.

Копать сюда:
http://bxapi.ru/src/?module_id=search&name=CSearch::Index
http://bxapi.ru/src/?module_id=search&name=CSearch::Add
http://bxapi.ru/src/?module_id=search&name=CSearch::Update

На обновление вроде можно воспользоваться обработчиком "OnBeforeIndexUpdate", а при добавлении "OnAfterIndexAdd".

Функция отправки пароля выглядит так: http://bxapi.ru/src/?module_id=main&name=CUser::SendPasswordЦепочка вызовов:
http://bxapi.ru/src/?module_id=main&name=CUser::SendUserInfo
http://bxapi.ru/src/?module_id=main&name=CEvent::SendImmediate

Нужно копать в сторону обработчиков:

• OnSendUserInfo
  
• OnBeforeEventSend
  
• OnBeforeEventAdd
  

Дык в фильтр нужно подставлять ID соответствующего раздела:

Александр Вареников, вы привязываете свойства к разделам на вот этих вкладках?
http://i.imgur.com/idV5wEd.png
http://i.imgur.com/g4nobUW.png
Если да, то свойства в этом случае "отвязываются" от инфоблока и "привязываются" к разделу только в рамках работы умного фильтра.
В карточке товара "привязанное" только к определенному разделу свойство продолжает так же отображаться и для других товаров.
Это я говорю про штатную форму редактирования товара.
Возможно у вас для инфоблока указана кастомизированная форма редактирования товара, где список свойств выводится в соответствии с привязками к разделам.
Возможно я не знаю о какой-то дополнительной настройке, которая позволяет заставить штатную форму выводить список свойств соответственно привязкам к разделам. Прошу вас написать здесь о такой возможности. Я не нашел.

В любом случае свойства ВСЕГДА остаются привязаны к инфоблоку.
Указанный вами класс CIBlockSectionPropertyLink работает с MySQL таблицей `b_iblock_section_property`, а сами свойства хранятся в `b_iblock_property`.
Другими словами привязка к разделам - это лишь косметика. Архитектурно же свойства привязаны к инфоблоку.

Дык и правильно.
У вас же срабатывает правило "RULE" => "ELEMENT_CODE=\$1", которое и добавляет параметр ELEMENT_CODE в GET.
Если хотите от него избавиться, то перед компонентом просто удалите его.

Да хрен бы его знал))
Есть подозрение, что у вас выполнение не доходит до кода эпилога, а там вроде происходит закрепление всех SQL-транзакций.

Не вводите человека в заблуждение.
Свойства привязываются только к инфоблоку. То, о чем говорится в приведенной вами статье, относится только к умному фильтру и отображению в нем свойств в разных разделах.

При большом количестве свойств есть два типа реализации:

1. Разбиение всего каталога на несколько инфоблоков (по типам товаров).
   
2. Вынос свойств в отдельные инфоблоки (или HL-блоки). О чем-то подобном рассказывали на недавней партнерской конференции http://www.youtube.com/watch?v=6GtmK2JWnus
   

У меня было дело положил сервер бесконечной рекурсией
Еще может в шаблоне/компоненте каком-то есть тяжелые вычисления.
Мимо кэша - сервер вешает, потом когда из кэша читается - все нормально работает.

Хотя возможно я вас не понял.

Что имеется в виду? Список ТОВАРОВ определенного свойства или список ЗНАЧЕНИЙ определенного свойства?
Выше я писал про второй вариант.

Насчет вот этого:К сожалению сквозных выборок при текущей реализации API сделать невозможно (идея).
Поэтому придется в цикле для каждого инфоблока выбрать уникальные значения свойства и потом их сгруппировать средствами PHP.

Говнокод детектед!))
Внимательно читаем вот это https://dev.1c-bitrix.ru/api_help/iblock/classes/ciblockelement/getlist.php
И изучаем работу параметра arGroupBy.

И еще в обработчике вы учли, что на вход функции приходит просто ID элемента, а не массив со всеми полями?

А попробуйте после обновления свойства сделать:

Видимо что-то недоинтегрировали)
Пишите в ТП, а не тут - поправят.