Иван Иванов (Все сообщения пользователя)

Главное не запутаться, потому что IS_PARENT может быть true и для дочерних айтемов, если у них тоже есть субайтемы.

Например через апи (см класс CFile).
А кстати, не лучше ли не сохранять абстрактные картинки в элементах иблоков, а вместо этого делать проверку в шаблоне? Есть картинка - выводим картинку, нет картинки - выводим изображение, которое по умолчанию.

Кажется я вас обманул, они указываются у каталога, а не у каталог.секшн. Поэтому надо наверное получить переменную вручную перед вызовом компонента, например так:
if (preg_match('~/(\d+)/\d+~',$APPLICATION->GetCurUri(),$m)) $section_id = $m[1];

К сожалению, метод СSite::InDir() не документирован. Было бы неплохо иметь описание подобных методов.

Можно попробовать перехитрить имеющийся сайт (переместить его в папку и сделать в .htaccess реврайт в папку по условию - домен от старого сайта), а на его место поставить битрикс с другого домена, который привязан сюда же?

Может, лучше вписывать айди существующего в системе файла?

С чпу $_REQUEST вроде не работает.
А "SEF_URL_TEMPLATES" и "SECTION_ID_VARIABLE" правильно указаны?

Ну, суть то вроде не меняется. Вам нужно, чтобы переменная #SECTION_ID# корректно доставалась в компоненте из запроса и присваивалась в  $_REQUEST["SECTION_ID"], раз вы его указали в качестве фильтра.

Можно ведь проще
if (substr($APPLICATION->GetCurUri(),0,9)=='/e-store/')

Однако, это для элемента (каталога), потому что вы писали "шаблон для элемента".
Если же вам надо менять дизайн не компонента, а всего сайта, то делается это в настройках сайта (в админке), применив соответствующий фильтр.

А на странице детального просмотра передается в адресе &SECTION_ID=#SECTION_ID#? Если нет, то добавьте в настройках иблока.

Можно сделать например в месте вызова:

Можно также создать отдельный шаблон компонента "каталог", который будет по похожему условию выбирать разный шаблон для подкомпонента просмотра раздела в зависимости от секции.

Конечно можно, и нужно. Отдельные иблоки тоже можно, но это по-моему менее удобно и менее гибко, потом сложности начинаются с переходом на "иблоки 2.0".

Если вы о том, как подстраивать фильтр - например, сохранять выбранный фильтр в сессии, и выдавать список значений зависимых свойств в зависимости от полноты сохраненного фильтра (CIBlockElement::GetList() с группировкой по нужному полю).

Вариант 1. Создать обработчик события OnAfterIBlockElementAdd и добавлять вою картинку, если не добавлена.
Вариант 2. Сделать "Файл для редактирования элемента, позволяющий модифицировать поля перед сохранением".

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

Переменные в почтовом событии определены (в поле "Описание")?

Если артикул - это привязка к элементам другого иблока, которая называется к примеру ARTICLE, попробуйте отбор в фильтре по "PROPERTY_ARTICLE.NAME".

Сделайте свой компонент, в шаблоне напишите то, что вам нужно, а в component.php - только вызов шаблона, а потом вызывайте его в любом месте. Плюс это будет очень полезно, если вы вдруг потом захотите оживить "блок с картинкой" дополнительным функционалом.

Линукс тоже во многом превосходит винду, но мы же почему-то покупаем и используем винду? Кроме функционала есть еще немаловажные вещи, такие как наличие документации, порог вхождения, простота, поддержка, пиар.

При таком подходе можно делать рейтинг пользователей, но нельзя будет получить рейтинг отдельной статьи, или делать для нее отдельное свойство рейтинга, а хранить два разных несвязанных рейтинга (элемента и юзера) как-то не совсем хорошо, нарушается целостность данных. К примеру, модератор изменит в админке вручную рейтинг статьи, но это не отразится на рейтинеге автора. Придется писать дополнительные триггеры. Это все неоправданно усложнит проект. Может, проще и эффективнее написать свой механизм со своей табличкой и кешем?

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

Отбирать элементы иблока, группируя по привязке к пользователю (Например, если пользователь в поле CREATED_BY) и суммировать свойство, в котором рейтинг.

Используйте .тип.menu_ext.php, он как раз предназначен для динамической модификации массива меню.

В том и проблема. Кнопки "взять и перенести сайт" или "объединить базы" нет, все очень зависит от специфики. Если сайт просто "визитка" и состоит из статических страниц, перенести не проблема, достаточно создать новый сайт, перенести страницы, перенести шаблон, применить его, перенести пользователей и выдать им права как на переносимом сайте. Если же сайт сложный, который много работает с БД (иблоками, магазином), содержит пользовательские компоненты и функционал, переносить сложнее, без помощи опытного битрикс-программиста не обойтись. Это также очень зависит от того, придерживался ли разработчик сайта строгой дисциплины и стиля "битрикса", то есть писал ли он без "облегчалок", вроде прямого прописывания IBLOCK_ID в коде компонентов, собственных таблиц, файлов и т.д.

$rs = CIBlockElement::GetList(
array(), // сортировка
array('IBLOCK_ID'=>$id), // фильтр
array('PROPERTY_CM_WEIGHT'), // группировка
false,
array('PROPERTY_CM_WEIGHT') // поля
);
while($ar=$rs->GetNext()) {
var_dump($ar);
}