Я не имею представления как именно реализован функционал поиска на вашем сайте сейчас, но думаю, что сначала необходимо восстановить модуль поиска до оригинального состояния и затем на базе штатного шаблона компонента поиска реализовать вашу задачу. Если в двух словах, то в шаблон компонента поиска с результатом приходят ID элементов, которые вы можете спокойно объеденить в фильтр и передать компоненту каталога, который уже и выведет вам страницу в нужном вам виде.
Максим Задубин пишет: сначала надо выбрать местоположение(что по дизайну тоже не задумывалось
Это очень распространенная ситуация с дизайном, когда сначала рисуется красивая картинка, а потом ее пытаются связать с реальными и часто необходимыми процессами при оформлении заказа, о которых дизайнер даже не пытался подумать. Стоимость и вообще возможность доставки обычно зависит от местоположения куда заказ нужно доставлять. Иногда еще доставка зависит от способа оплаты или наоборот. У вас не так?
Pavel Sementsov пишет: Есть какие-нить другие варианты решения данной проблемы?
Использовать возможности модуля поиска:
Если с фильтрацией по секции, то можно пробовать:
Код
// поисковый запрос
$sSearchQuery = 'land';
// ID инфоблока
$iIBlockID = 7;
// ID секций, к которым может принадлежать элемент
$arSections = array(
1,
2,
3
);
$arFilter = array(
'QUERY' => $sSearchQuery,
'MODULE_ID' => 'iblock',
'PARAM2' => $iIBlockID,
);
$arOrder = array(
'CUSTOM_RANK' => 'DESC',
'RANK' => 'DESC'
);
$arFilterExt = array(
'STEMMING' => true, // морфология включена
);
// дополняем фильтр по секциям
foreach($arSections as $iSectionID) {
$arFilterExt[] = array(
'URL' => '%IBLOCK_SECTION_ID='.$iSectionID.'%'
);
}
$obSearch = new CSearch();
$obSearch->Search($arFilter, $arOrder, $arFilterExt);
while($arItem = $obSearch->GetNext()) {
echo '<pre>'.print_r($arItem, true).'</pre>';
}
При таком способе необходимо учитывать, что элемент может принадлежать нескольким секциям, а в шаблоне пути участвует только один. Если такой способ связи используется, то будут "промахи". Тогда от фильтрации по ID секции при поиске нужно избавляться, получать все возможные элементы и уже фильтровать по полученному списку ID элементов выборку из инфоблока, дополнив фильтром по секции.
поэтому лучше использовать значение $ElementID, т.к. оно уже пройдет необходимую проверку, чтобы в частных случаях не получилось так, что новость не отображается, а комментарии к ней оставить можно.
Если компонент комплексный, то можно еще использовать $arResult['VARIABLES']['ELEMENT_ID'] или $_REQUSET['ELEMENT_ID']. Только эти два способа будут работать, когда в адресе используется ID элемента, а не символьный код.
И прежде чем подключать компонент комментариев нужно выполнить проверку на положительное значение $ElementID, $arResult['VARIABLES']['ELEMENT_ID'] или $_REQUSET['ELEMENT_ID'] соответственно.
В штатных шаблонах уже реализована поддержка вывода комментариев. Включение параметра "Разрешить отзывы" (USE_REVIEW) разве не добавляет форму для комментариев?
Stas Chirmin пишет: Возможно создание доп. свойства не нужно, т.к. сортировка по кол-ву работает, если сортировать по свойству "CATALOG_QUANTITY". Или я не прав?
Да, если вы будете в системном поле указывать 1 - есть, 0 - нет, тогда создавать не нужно и обработчики событий тоже не нужны будут. Но если в этих полях будут реальные остатки (больше единицы и разные), то сортировка будет работать сначала по остаткам, а потом уже по ценам. Т.е. получится, что сначала выведутся все товары с остатком 100, например, и среди них выполнится сортировка по цене, затем с остатком 50 и т.д.
Чтобы по двум полям сделать сортировку нужно уметь немножечко программировать на php и понимать как устроены компоненты. В ЧАВо есть вопрос: Как кастомизировать компоненты Также посмотрите статью о компонентах в блоге Евгения Жукова: http://dev.1c-bitrix.ru/community/webdev/user/2106/blog/1770/ Надеюсь, что найдете по приведенным ссылкам интересующую вас информацию.
P.S. Если там вам совсем ничего не понятно будет, то сообщите здесь
Вам придется сделать денормализацию и все же добавить служебное свойство, которое будет иметь два варианта значений: 1 - есть на складе, 0 - нет на складе. Далее в списочном компоненте сортировать по двум полям одновременно: по новому служебному свойству-флагу PROPERTY_<код свойства> => desc, а затем уже по цене CATALOG_PRICE_<ID типа цены> => desc/asc. Стандартный компонент не поддерживает два поля сортировки, поэтому придется его кастомизировать. Ну и для автозаполнения свойства-флага придется добавить обработчики событий.
Массив нужно сортировать по полю CONDITION от большей длины условия к меньшей, что за вас сделает редактор urlrewrite в админке если вы через него отредактируете. Т.е. первым должно быть правило с manufact.
А никто и не говорит, что совсем нельзя, но готовых штатных компонентов я не видел.
Реализации выборки самого алфавитного индекса (как пример):
Код
$sQuery = '';
$sQuery .= 'SELECT DISTINCT ';
$sQuery .= 'UPPER(LEFT(LTRIM(NAME), '.$arParams['CHARS_COUNT'].')) AS LETTER ';
$sQuery .= 'FROM b_iblock_element BE ';
$sQuery .= 'WHERE BE.IBLOCK_ID = '.$arParams['IBLOCK_ID'].' AND BE.ACTIVE = "Y" AND BE.WF_STATUS_ID = 1 AND BE.WF_PARENT_ELEMENT_ID IS NULL';
$sQuery .= 'ORDER BY LETTER ASC ';
$rsItems = $GLOBALS['DB']->Query($sQuery, false, __LINE__);
while($arItem = $rsItems->GetNext(false, false)) {
$arResult['ITEMS'][$arItem['LETTER']] = $arItem;
}
где: $arParams['CHARS_COUNT'] - сколько символов в алфавитном указателе $arParams['IBLOCK_ID'] - код инфоблока, по названиям элементов которого строится индекс алфавитного указателя
Ну и дальше для вывода списка элементов по выбранной посетителем букве уже можно использовать штатные компоненты с установленным внешним фильтром.