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

настройка типа инфоблока работает только если не найден инфоблок с XML_ID
равным Ид Каталога в файле с каталога товаров выгруженного 1С.
Пара вариантов:
1) Удалите инфоблок (первого импорта) и повторите процедуру выгрузки.
2) Измените "Внешний код" инфоблока (в настройках модуля может понадобиться включить отображение внешних идентификаторов)

Настоятельно рекомендую переносить архивные статьи и отдельный инфоблок.
Очень положительно скажется на производительности (особенно с ростом объемов).

Если инфоблоки НЕ хранятся в отдельных таблицах, то:

компонент my:news.list получается копированием /bitrix/components/bitrix/news.list в /bitrix/components/my
и удалением фильтра по IBLOCK_ID (строка 145: "IBLOCK_ID" => $arResult["ID"],)

В версии модуля инфоблоков 6.5.7 была исправлена ошибка работы с кодировками при rss импорте.

Напишите , думаю в письме будет ответ.

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

Во вторых совершенно не понимаю зачем реализовывать пошаговую переиндексацию из под крона?
Это приводит к лишней нагрузке и не более того.
Именно из под крона эффективней всего не использовать шаги (настроив time_limit с запасом).

Тогда все сведется просто к:

Отключите морфологию или ищите в "57" или в настройках компонента выставьте галочку "Искать без учета морфологии (при отсутствии результата поиска):".

Морфологический поиск предполагает поиск по полному совпадению слова с запросом.
А по подстроке.... сами знаете, что будет.

Выйдет в обновлении модуля инфоблоков 6.5.7.
Потребуется полная переиндексация.

Если агенты не настроены на выполнение из cron'а, то они запускаются из пролога на хитах.
Проблему "моментальной отсылки" это не решает в любом случае.
Разве только усложняет логику работы и повышает потребление ресурсов.

Если очень напрягает использование БД и "отложенность" отправки, воспользуйтесь функцией mail по месту.

Функция определяется в модуле Информациооных блоков.
Если включите кеширование, опять перестанет работать.
Вот решение:

Привязка к разделам у элементов МНОЖЕСТВЕННАЯ.
В форме редактирования элемента список "Разделы:" является мультиселектом.
Используйте Ctrl для выбора нескольких разделов.
Копировать элемент не надо.

Не мог удержаться и провел очень простой эксперимент.
Создал MyISAM табличку и провел серию DML (insert/update/delete).
После выполнения каждого запроса смотрел содержимое файла MYD.
Любой может проделать это.

mysql> create table a(id int(11),name text);
Query OK, 0 rows affected (0.04 sec)
//Файл пустой (размер 0 байт)

mysql> insert into a values (1,'1111111111111111111111');
Query OK, 1 row affected (0.00 sec)
//В начале файла появились единички (36 байт)

mysql> insert into a values (2,'2222222222222222222222');
Query OK, 1 row affected (0.00 sec)
//В конец файла дописаны двоечки (72 байт)

mysql> update a set name = '333333333333333333333333333333333333333333333333333333333' where id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
//Единички пропали и часть троек заняли их место, а часть дописалась в конец файла.
//Значит у нас есть константа - начальный адрес строки который не меняется в течение ее жизни.
//При выборке такой строки будут сделаны дополнительные движения.
//Такое поведение мы наблюдаем и в Oracle. Называется row chain.

mysql> update a set name = '4444444444' where id = 2;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
//Двойки пропали на из место записаны четверки.
//Четверок меньше - остальное место записано нулями.

mysql> update a set name = '5555555555555555555555' where id = 2;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0
//Пятерок столько же сколько и было двоек.
//Они легли точно на их место.

mysql> delete from a where id = 2;
Query OK, 1 row affected (0.00 sec)
//На месте части пятерок появились FF

mysql> insert into a values (2,'2222222222222222222222');
Query OK, 1 row affected (0.00 sec)
//FF и остатки пятерок записаны двойками.

mysql> delete from a where id = 2;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into a values (2,'77777777777777777777777777777777777777777777777777');
Query OK, 1 row affected (0.00 sec)
//Все двойки стерты, а семерочный хвост дописан в конец файла.

Надо отметить, что размер файла менялся только при первых 3-запросах.

Итого: реальный вред могут приносить update'ы увеличивающие длину строки.
И вставки новых данных, также приводят в фрагментации на уровне строк,
но только в случае предварительного удаления данных.

Это скажется и на выборке и на последующих обновлениях данных.

Выводы: для MyISAM таблиц требуется регулярная дефрагментация.
За исключением приложений в которых отсутствуют update(полей с переменной длиной) и delete.

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

Почему бы вам не сделать в публичной части страницу на которой разместить компонент rss.out
выставить время кеширования 12 часов и настроить шаблон ?

Компоненты catalog.* (и компонент сравнения тоже) выпускаются в составе модуля информационных блоков, который входит в редакцию Старт.

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

И еще отсюда следует добавить /bitrix/wizards/bitrix ...

Смотрите в сторону обработки события OnSearchGetURL модуля search.
О технологии событий можно почитать тут: http://www.1c-bitrix.ru/bitrix/help/ru/source/main/help/ru/developer/general/tech­nology/events.php.html

Не забываем, что править можно только пользовательские шаблоны!
Файлы в каталогах /bitrix/modules и /bitrix/componenets/bitrix могут быть "перетерты" обновлениями!

Добавлю 2 копейки.
У редактора самая верхняя и самая правая кнопочка позволяет "схлопывать"/"расхлопывать" "на лету"...