Александр Юрин (Все сообщения пользователя)

CentOS 6, Bitrix ENV 4.2.
Куда вставлять эту строку, напишите конкретный путь.

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

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

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

Вы бы, заодно, просветили неучей, правильной организации каталога и другим на пользу будет.

Интересное решение, рассмотрю возможность его применения.

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


Решение 1:

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

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

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

Решение 2:

Использовать переменные в адресе
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
- Не совсем красивый адрес, хотя это очень субъективно.


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

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

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


Еще вариант. Предположим что у нас все инфоблоки находятся в корне.
В данном случае,  можно ли как то к группе привязать определенные свойства для фильтрации. И как это лучше сделать?

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

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


Перед запуском сайта хочу понять, как правильно строить каталог товаров.

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

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

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

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

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

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

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