Если вы хотите использовать bitrix:news или bitrix:news.detail, чтобы организовать раздел со списком элементов и их детальных страниц - вам следует знать, что использование ЧПУ вида /razdel/#ELEMENT_CODE#.php может вызывать некоторые проблемы. В частности, детальная страница может выводить вам совсем не тот элемент, что вы запросили.
Опишу свою историю.
Я делал раздел брендов каталога на сайте (с помощью bitrix:news), когда заметил, что на детальной странице одного из брендов выводится какая-то хрень. Другой элемент, из инфоблока товаров.
Полез я в недра, и наткнулся на такой код в bitrix/components/bitrix/news.detail/component.php
Логично, что когда компоненту приходит url вида /brands/blablabla.php, он парсит его, извлекает blablabla как символьный код. Затем прогоняет его через CIBlockFindTools::GetElementID и получает первый попавшийся элемент с симкодом blablabla.
На беду (или к счастью), первым попавшимся был элемент из каталога, а не ожидаемый бренд.
Но вот что странно - у компонента news.detail имеется замечательная настроечка $arParams['IBLOCK_ID'], и почему-то разработчики компонента не захотели ее включать в фильтр выборки элемента. А жаль.
Поправить это легко, если перенести компонент в свое пространство имен. В новом компоненте достаточно поправить инициализацию $arFilter следующим образом:
UPD:
Опишу свою историю.
Я делал раздел брендов каталога на сайте (с помощью bitrix:news), когда заметил, что на детальной странице одного из брендов выводится какая-то хрень. Другой элемент, из инфоблока товаров.
Полез я в недра, и наткнулся на такой код в bitrix/components/bitrix/news.detail/component.php
$arFilter = array( "IBLOCK_LID" => SITE_ID, "IBLOCK_ACTIVE" => "Y", "ACTIVE" => "Y", "CHECK_PERMISSIONS" => "Y", "IBLOCK_TYPE" => $arParams["IBLOCK_TYPE"], "SHOW_HISTORY" => $WF_SHOW_HISTORY, ); if($arParams["CHECK_DATES"]) $arFilter["ACTIVE_DATE"] = "Y"; //Handle case when ELEMENT_CODE used if($arParams["ELEMENT_ID"] <= 0) $arParams["ELEMENT_ID"] = CIBlockFindTools::GetElementID( $arParams["ELEMENT_ID"], $arParams["ELEMENT_CODE"], false, false, $arFilter ); |
Логично, что когда компоненту приходит url вида /brands/blablabla.php, он парсит его, извлекает blablabla как символьный код. Затем прогоняет его через CIBlockFindTools::GetElementID и получает первый попавшийся элемент с симкодом blablabla.
На беду (или к счастью), первым попавшимся был элемент из каталога, а не ожидаемый бренд.
Но вот что странно - у компонента news.detail имеется замечательная настроечка $arParams['IBLOCK_ID'], и почему-то разработчики компонента не захотели ее включать в фильтр выборки элемента. А жаль.
Поправить это легко, если перенести компонент в свое пространство имен. В новом компоненте достаточно поправить инициализацию $arFilter следующим образом:
$arFilter = array( "IBLOCK_LID" => SITE_ID, "IBLOCK_ACTIVE" => "Y", "ACTIVE" => "Y", "CHECK_PERMISSIONS" => "Y", "IBLOCK_TYPE" => $arParams["IBLOCK_TYPE"], "IBLOCK_ID" => $arParams["IBLOCK_ID"], "SHOW_HISTORY" => $WF_SHOW_HISTORY, ); |
UPD:
Малков Евгений 20.09.2011 11:34:51 Еще bitrix:news.detail не учитывает SECTION_CODE при ЧПУ /news/#SECTION_CODE#/#ELEMENT_CODE#/. Если у вас в разных разделах есть элементы с одинаковым кодом, то не зависимо от раздела, он всегда будет показывать первый попавшийся элемент. Не понятно что мешало разработчикам его учитывать? Для этого достаточно передать в функцию CIBlockFindTools::GetElementID третий и четвертый параметр (SECTION_ID и SECTION_CODE) и все. |