Форум

[QUOTE]Назар Сурыев пишет:
[QUOTE]pepadura пишет:
[QUOTE]comptech57 пишет:
А как размер стека увеличить не подскажите?
[/QUOTE]мне вот тоже интересно.
[/QUOTE]
[CODE] ulimit -s unlimited [/CODE]
[/QUOTE]CentOS 6, Bitrix ENV 4.2.
Куда вставлять эту строку, напишите конкретный путь.

-------------------------

Что за ошибка без описания, при тестировании сайта:
2013-Aug-05 22:13:40 (check_groupdav): Warning Ошибка

Причем без описания.

[QUOTE]stvbox пишет:
Раз каталог впринцыпе бездарно организован, тогда настройте компонент на пути:
/catalog/<код раздела>/
/catalog/<код элемента>.html
А в хлебные крошки пхайте чего нужно по обстоятельствам.

И они эникеют сайты
[/QUOTE]Вы бы, заодно, просветили неучей, правильной организации каталога и другим на пользу будет.

[QUOTE]Александр Семеритов пишет:
используйте rel="canonical" если беспокоитесь о сео
[/QUOTE]Интересное решение, рассмотрю возможность его применения.

[B]Задача[/B]: нужно определить из какого раздела вышли на этот элемент, что бы правильно нарисовать хлебные крошки (навигационный путь).
[B]Условие[/B]:
- Элемент содержится в нескольких группах.
- Используем шаблон: site\product\element_code\
- Соответственно у нас не должно быть 2 путей для элемента, так как это плохо влияет на SEO.


[B]Решение 1[/B]:

Хранить в сессионной переменной список последних посещенных разделов и при открытии карточки товара, используя шаблон site\product\element_code\, получать родительский раздел из сессионной переменной.

Плюсы относительно второго решения:
+Никакого мусора в адресе.
+Не надо задавать исключения для поисковиков в robots.txt

Недостатки:
- Не однозначное определение родительского раздела. В теории возможно создать ситуацию с неверным отображением раздела, на практике это сводится к 0.
- Если пользователь открыл ссылку  site\product\element_code\ и для него это новая сессия, то однозначно определить родительский раздел не получится.

[B]Решение 2[/B]:

Использовать переменные в адресе
site\product\element_code1\?section_id=123 где "section_id=123" ID родительского раздела.

Пример для 2 разделов:
site\product\element_code1\?section_id=123
site\product\element_code1\?section_id=124

Плюсы относительно 2 решения:
+ Однозначное определение родительского раздела.
+ Однозначное определение раздела для новой сессии.

Недостатки:
-Требует добавления исключений для поисковиков в robots.txt
- Не совсем красивый адрес, хотя это очень субъективно.


Товарищи, какой из вариантов вы считаете наиболее правильным.
Заранее всем спасибо за ответы.

Поклон Вам до пола за разъяснения.

[QUOTE]Николай Ефремов пишет:
Сложнее сделать, если надо, чтобы разные инфоблоки находились на разных уровнях иерархии каталога.
[/QUOTE]Вот этот момент меня как раз и волнует. В примере который я привел, инфоблок должен находится на 2 уровне вложенности.Если я правильно понял, не получится построить красивый путь к группе: группа1 -> группа 1.2 -> группа 1.2.1, если группа 1.2.1 является инфоблоком. Как поступать в таком случае?


Еще вариант. Предположим что у нас все инфоблоки находятся в корне.
[CODE]Инфоблок 1 (Содержит список всех свойств со всех вложенных групп)
    Группа 1
          Фильтр со своими свойствами
    Группа 2
           Фильтр со своими свойствами[/CODE]В данном случае, можно ли как то к группе привязать определенные свойства для фильтрации. И как это лучше сделать?

Видел у группы вкладку пользовательские свойства. В каком случае их используют?
[QUOTE]Николай Ефремов пишет:
В целом, делать правильно так, как себе представляет работу сайта разработчик (если он при этом думает о пользователях :))[/QUOTE]Ни каждый разработчик может правильно выбрать архитектуру каталога, подумав при этом об оптимизации производительности.

Схема каталога товаров которую необходимо построить на сайте.

[CODE]Группа 1
   Группа 1.1
              Свой фильтр по свойствам
   Группа 2.2
               Свой фильтр по свойствам[/CODE]
Перед запуском сайта хочу понять, как правильно строить каталог товаров.

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

2) Выгружать группы товары по инфоблокам. Последняя версия обмена в 1с позволяет это делать.
Получим индивидуальный фильтр с возможностью хранения свойств в различных таблицах.

Хотелось бы плюсы и минусы этих реализаций. Возможно есть еще какие либо реализации.

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

Во 2 варианте для меня не понятно, каким образом делать иерархию из каталогов?
Как управлять этой иерархией из 1с? Каким образом будет работать поиск?
Зато с хранением свойств нет проблем и как следствие быстро работающие фильтры.

Жду ваших ответов.

p.s. Готов оплатить разумные деньги специалисту, хорошо разбирающегося в интеграции с 1с, за консультацию.