Модуль импорта товаров в Битрикс
В данном посте мы хотели бы поделиться нашим опытом разработки модуля импорта в Битрикс с сообществом разработчиков.
Наш модуль импорта имеет следующие особенности:
- Работает с MySQL БД Битрикс напрямую (т.е. внутри воссоздана вся объектная модель CMS Битрикс для товаров).
- Соединяться с БД можно следующими способами:
- Прямое соединение;
- SSH;
- HTTP Bridge connection.
Требования
К модулю было предъявлено несколько требований:
Скорость наполнения
Модуль должен отрабатывать максимально быстро. Во-первых, клиент всегда хочет увидеть результат «здесь и сейчас», а ещё лучше «уже вчера». И это правильно. Мы часто делаем наполнение нескольких тестовых товаров непосредственно при обращении клиента, чтобы он мог оценить, как это работает и, если нужно, сразу определиться, какие правки нужны.
Во-вторых, если товаров и их комбинаций очень много, то и загрузка данных может идти весьма долго. Особенно долго идёт загрузка фото, т.к. у каждого товара могут быть десятки фото, несколько комбинаций (торговых предложений) в разном цвете, к каждой соответственно тоже несколько фото, плюс каждое фото должно иметь несколько размеров для корректного отображения на сайте. Однако постоянные изменения на сайте и снижение скорости сайта из-за импорта нежелательны.
Устойчивость к изменениям среды
Модуль должен быть максимально устойчив к изменениям в самом сайте. Битрикс тоже не стоит на месте. Регулярно появляются новые версии, новые расширения. Также сайт может быть в процессе доработки дизайнером и веб-программистом (вплоть до того, что некоторые страницы бывают недоступны в текущий момент). Но мы не можем ждать, нам нужно выполнять нашу работу здесь и сейчас и двигаться в светлое будущее.
С учетом данных требований оптимальным решением была разработка собственного независимого модуля, который позволяет загружать данные напрямую в базу, минимизировав использование дополнительных компонент.
Процесс наполнения
Вот мы и добрались до самого вкусного =)
Упрощённая схема данных Битрикс в режиме магазина выглядит следующим образом
Краткое описание этих таблиц:
- b_iblock — справочник инфоблоков
- b_iblock_section — справочник категорий
- b_iblock_element — справочник товаров и их комбинаций
- b_iblock_section_element — справочник соответствия категорий и товаров. Один товар может быть в нескольких категориях.
- b_iblock_property — справочник характеристик
- b_iblock_element_property — характеристики продукта
- b_file — таблица, хранящая данные о фото и дополнительных файлах (например даташитах) для товаров. В контексте Битрикса все файлы — это просто ещё одна характеристика, только особого типа (VALUE_TYPE = ‘F’). Сами же файлы физически хранятся отдельно от БД, на диске.
- b_iblock_34_index — фасетный индекс для инфоблока №34.
- b_iblock_34_index_val — таблица значений для фасетного индекса инфоблока №34.
Процесс наполнения магазина выполняется в следующем порядке:
- Создание нужных инфоблоков
- Наполнение категорий
- Наполнение товаров
К каждому товару также необходимо заполнить характеристики, комбинации, фото и поисковые индексы.
Создание инфоблоков
Обычно для торгового каталога отводится всего один инфоблок, который должен быть соответственно настроен (наименование, где и как отображается, нужен ли ему дочерний инфоблок для торговых предложений). Таково поведение по умолчанию. Но некоторые клиенты делают более сложную структуру: у них инфоблок по сути является категорией верхнего уровня и приходится совмещать данные из инфоблоков с данными из таблицы категорий, чтобы корректно построить полное дерево магазина.
Наполнение категорий
Вложенные множества (Nested Sets)
Дерево категорий базируется на вложенных множествах. Аналогичные применяются в PrestaShop и ShopScript. Они позволяют делать очень красивое, с алгоритмической точки зрения, ветвление, позволяют делать быстрые удобные выборки из базы данных.
Вложенное множество — это древовидная структура, в которой помимо самого элемента хранится его область вложения, выраженная через два числовых поля, обычно называемых в литературе LEFT и RIGHT. В Битрикс они названы LEFT_MARGIN и RIGHT_MARGIN. Они позволяют одним запросом получить все дочерние элементы, независимо от количества подкатегорий, в уже отсортированном порядке либо всех родителей. Нам не нужно рекурсивно обходить каждую категорию, чтобы получить её связи, что значительно уменьшает время и ресурсы сервера затраченные на эти операции.
Вот пример простейшей выборки из двух категорий на живом проекте. Хорошо видно порядок сортировки и уровень вложенности, можно наглядно оценить как связаны поля LEFT_MARGIN и RIGHT_MARGIN со стандартными DEPTH_LEVEL (глубина), SORT (порядок сортировки) и IBLOCK_SECTION_ID (ссылка на категорию-родителя).
В выборке две категории верхнего уровня и их подкатегории. В виде дерева эта структура выглядит примерно следующим образом:
“Люстры” и “Бра” — категории первого уровня и представляют собой две соседние ветви. Левая цифра в блоке категории — это LEFT_MARGIN, а правая — RIGHT_MARGIN. У родительской категории LEFT_MARGIN является минимальным ключом для текущей ветви, RIGHT_MARGIN — максимальным. Всё что выпадает из диапазона между LEFT_MARGIN и RIGHT_MARGIN — не относится к нужной нам ветви. Вы можете видеть, что у двух соседних (и отображаемых подряд) категорий одного уровня нумерация индексов идёт подряд: левый ключ следующего элемента всегда на единицу больше правого ключа текущего элемента. Если категории должны идти подряд, но вы видите, что значения ключей не подряд — это первый признак проблем с построением ключей.
Всё это выглядит красиво и работает нормально ровно до тех пор, пока индексы идеально заполнены. Как только с индексом что-то случилось — в лучшем случае ваши категории начнут «плясать», в худшем — ломается вёрстка или категории пропадают. С ними нужно работать очень аккуратно, ведь если категория пропадает, пользователь не увидит продуктов в ней и работа пойдёт насмарку.
А испортить эту структуру очень легко. Вам больше не достаточно просто вставить или просто удалить запись в БД. Если вы вставили, удалили или перетащили запись (изменив порядок сортировки) — вам придётся перестроить дерево категорий, чтобы индексы остались консистентными. Очень часто новички увидев понятные поля DEPTH_LEVEL, SORT и IBLOCK_SECTION_ID считают, что их заполнения достаточно, а про Nested Sets вообще не в курсе, соответственно индексы не перестраиваются и дерево категорий медленно, но верно превращается в фарш. Когда там всего несколько не сильно меняющихся категорий — это доставляет минимальные проблемы, часто народу проще удалить всё и пересоздать, чем разобраться. Но когда магазин после доработок загружается рабочими данными с тысячами категорий — проблема становится поперёк горла.
Ещё хуже, если проект достался новому разработчику уже битым — очень много времени тратится на выяснение причин проблем.
Вот вам полезных SQL запросов для проверки вашей БД, они помогут вам проверить корректность Nested Sets и не тратить время на гадание на кофейной гуще в поисках проблем.
Наполнение товаров
Полноценное отображение товаров “из коробки” не работает
Такая вот “фича”. Независимо от того, что и как вы импортировали и видите в админке, вы не увидите свойств во фронтэнде пока дополнительно, руками, не разрешите их отображение через режим правки.
При первом знакомстве с этой CMS такое поведение несколько сбивает с толку, и я не помню ни одной другой CMS с аналогичным поведением по умолчанию. Хотя дизайнер настройки инфоблоков у них мощный, но по умолчанию про него никто не знает, и нужно либо тратить уйму времени на чтение документации, либо тратить уйму денег на специалиста по Битрикс который будет тратить время за вас, либо искать CMS попроще (что опять же отнимает время).
Фасетные индексы
Фасетный индекс предполагает создание индекса для каждой характеристики товаров, по которому можно делать очень быстрый поиск. В базу данных на каждый инфоблок добавляется две таблицы вида b_iblock_
_index и b_iblock_ _index_val в которых каждому продукту описываются характеристики, по которым его можно искать. В схеме выше эти две таблицы шли с индексом 34, т.к. для описания торговых предложений в взятой базе данных использовался 34-ый инфоблок. Таких блоков может быть много и соответственно на каждый инфоблок будет создана пара таблиц с фасетными индексами. Запись добавляется для каждой категории в ветви. Т.е. чтобы продукт искался по заданным полям во всех нужных категориях, нужно дублировать записи для каждой категории в которой вы хотите находить этот продукт. Как правило, это категория нижнего уровня — с продуктом, и все категории выше по этой ветви (все родители), чтобы например в категории верхнего уровня можно было найти продукты из подкатегорий. Появление фасетных индексов было для нас неприятной неожиданностью. После одного из зимних обновлений товары во фронтэнде пропали. Никаких ошибок. Всё видно в панели администрирования. Но во фронтэнде новых товаров не было. Сквозь образовавшуюся тишину было слышно, как седеют программисты. Оказалось, что отныне и навсегда продукты, для которых не заполнены фасетные индексы, не отображаются. Даже если эти самые фасетные индексы никто не хотел, никто не включал намеренно и более того никто ничего не выбирал во фронтэнде. Т.е. фильтр почему-то работает даже если поля для фильтрации пользователем не заполнены. Поведение странное. Последствия таких внедрений — у людей умирали магазины. Люди несли убытки. Независимо от способа наполнения.
Отдельно стоит упомянуть про вычисление идентификатора характеристики. Вы верите в магию? Вот это и есть магия. Во-первых, согласно документации это поле должно не соответствовать идентификатору из общего списка характеристик (что было бы логично для фильтра по характеристикам), а являться идентификатором из общего списка характеристик умноженным на два. Внятного ответа на вопрос “В чём смысл этой магии” мы так и не нашли. Кажется, умножение на 42 работало бы гораздо лучше, в нём есть хоть какой-то смысл. Во-вторых, неоднократно замечалось, что наполнение сайта через админку могло не соблюдать эту, казалось бы, тривиальную магию.
Реализация магии описана здесь, там же есть ссылка на документацию, по которой должно было быть описано что на что и зачем умножается, но увы, на момент написания статьи там опять магия чисел с четвёркой.
Почитать подробнее про фасетные индексы и как с ними бороться можно на форуме разработчиков Bitrix в теме Умный фильтр весь такой фасетный и няшный.
Прочие нюансы
Чрезмерное кэширование вредно
Битрикс по умолчанию имеет собственный включенный кэш. Изменения на сайте могут не отображаться до тех пор, пока этот кэш не будет принудительно сброшен. С этим всё понятно, для сброса можно использовать API самой CMS. Но иногда народ включает дополнительные кэширующие средства, также их может включить хостинг-провайдер, а в завершении усугубить ситуацию может и кэш хрома например.
Системные требования растут вместе с магазином
Мы максимально оптимизировали наш модуль, но это не всегда спасает клиентов от необходимости увеличивать мощности сервера. При большом росте количества и характеристик товаров Битрикс требует и роста серверных мощностей, в особенности ОЗУ для нормальной работы. В конфигурации с самым дешёвым хостингом на котором CMS запустилась и работала с десятком демонстрационных товаров всё успешно сложится, если залить 10000 товаров. Стоит понимать, что это всё-таки мощная многофункциональная CMS для бизнеса, соответственно и хостинг ей нужен серьёзнее, чем для сайта-визитки.
К чему мы пришли
Битрикс дал нам много интересного опыта, как в рамках работы с CMS, так и в рамках взаимодействия с клиентами. Несомненно, это хорошая CMS с огромными возможностями. Но он слишком тяжёлый, слишком перегруженный для новичков. Да что там для новичков, даже программисты могут потратить уйму времени и нервов, чтобы запустить полноценно сайт «из коробки», если работают конкретно с этой CMS впервые. Слишком много нюансов. Если Вы только-только начинаете своё дело и у вас в штате нет опытного Битрикс-программиста, возможно стоит выбрать какую-то более понятную CMS или хотя бы попробовать демонстрационную версию прямо в их сервисе Виртуальная лаборатория до покупки.
Если же вы уже купили Битрикс, первое, что вам нужно сделать — заполнить его контентом и сделать полную резервную копию. Уже позже можно заказать дизайнеру вёрстку, выполнить настройку отображения товаров и прочие правки. Плюс такого подхода в том, что человек дорабатывающий магазин сразу будет иметь возможность визуально оценить последствия правок на живом товаре, с описанием, всеми нужными атрибутами, комбинациями и фото. Неоднократно были случаи, когда сначала сайт отдавали на растерзание дизайнерам, а уже потом нам, и клиент в последний момент перед запуском магазина сталкивался с проблемами в вёрстке.Также мы сделали небольшой бенчмарк скорости импорта в Битрикс через наш модуль. В тестовом наборе участвовало 1495 товаров с 23298 фото, а так же с комбинациями.
Фасетные индексы инфоблоков что это
Нашли ошибку? Выделите мышкой и нажмите Ctrl+Enter
Фасетные индексы
Одному каталогу соответствует один фасетный индекс. Он нужен для того, чтобы поиск по каталогу осуществлялся максимально быстро. После того, как вы внесли изменения в настройки умного фильтра, проверьте состояние фасетных индексов (особенно если заметили, что внесенные вами изменения не отобразились).
В административном разделе перейдите в Рабочий стол → Контент → Инфоблоки Фасетные индексы
Если состояние индекса «Работает» и горит зеленый индикатор, то все в порядке. Если же индикатор красный и появилась кнопка «Создать», то нажмите «гамбургер» и выберите соответствующий пункт.
В списке «Информационный блок» выберите «Каталог товаров». В поле «Шаг» можете оставить значение по умолчанию.
Вы можете при необходимости отключить фасетный индекс, но делать это не рекомендуется.
Фасетные индексы инфоблоков что это
Курс предназначен для администраторов интернет-магазинов, работающих на базе системы «1С-Битрикс: Управление сайтом». Изучение курса необходимо при работе с продуктом редакции Малый бизнес и выше при организации торговых операций через Интернет.
Курс Администратор. Бизнес завершает группу административных курсов по Bitrix Framework.
Начальные требования
Необходимый минимум знаний для изучения курса:
- базовые навыки компьютерной грамотности и навыков работы с ОС Windows;
- базовые знания о WWW и организации доступа к веб-серверу;
- знание системы в рамках курса Контент-менеджер Мы считаем, что вы этот курс уже прошли и знаете многое о Битриксе. Поэтому подсказок во всплывающих окнах будет намного меньше, чем в курсе Контент-менеджер.
Подробнее. , чтобы банально не путаться в интерфейсе. - знание системы в рамках курса Администратор. Базовый Мы считаем, что вы этот курс уже прошли и знаете многое об администрировании «1С-Битрикса». Поэтому подсказок во всплывающих окнах будет намного меньше, как и объяснений о том где и как выполнять общие задачи администрирования.
Неплохо было бы иметь базовые навыки установки и администрирования *nix-систем.
У нас часто спрашивают, сколько нужно заплатить
Курс полностью бесплатен. Изучение курса, прохождение итоговых тестов и получение сертификатов — ничего из этого оплачивать не нужно.
Ещё у нас есть Академия 1С-Битрикс, где можно обучиться на платной основе на курсах нашей компании либо наших партнёров.
Баллы опыта
В конце каждого урока есть кнопка Прочитано! . При клике на неё в Вашу итоговую таблицу опыта добавляется то количество баллов, которое указано в прочитанном После нажатия кнопки Прочитано! появится
окно подтверждения:
уроке.Периодически мы заново оцениваем сложность уроков, увеличивая/уменьшая число баллов, поэтому итоговое количество набранных Вами баллов может отличаться от максимально возможного. Не переживайте! Отличный результат — это если общее число набранных Вами баллов отличается от максимального на 1-2%.
Тесты и сертификат
После изучения курса вам будет предложено пройти итоговые тесты на сертификацию.
Для доступа к итоговым тестам данного курса необходимо успешно сдать итоговые тесты курсов Администратор. Базовый и Администратор. Модули.
При успешной сдаче последовательности тестов на странице Моё обучение можно просмотреть результат обучения и загрузить сертификат в формате PDF.Также Вы можете поделиться ссылкой на страницу со своими сертификатами. Для этого на странице Моё обучение отметьте опцию Разрешить публичный доступ к резюме студента
и скопируйте ссылку на страницу резюме 
. Страница с Вашим резюме будет доступна всем, кому Вы отправите ссылку на неё.Комментарии к урокам
На каждой странице курса авторизованный на сайте посетитель может дать комментарий к содержимому страницы. Комментарий — не форум, там не ведётся обсуждений или разъяснений. Это инструмент для сообщений нам об ошибках, неточностях. Для отправки комментария воспользуйтесь расположенной в правом нижнем углу окна браузера кнопкой: 
Для преподавания офлайн
Если данный курс берётся в качестве основы для офлайного преподавания, то рекомендуемая продолжительность: 2 дня (16 академических часов).
Если нет интернета
Скачать материалы курса в формате EPUB. Файлы формата EPUB Чем открыть файл на
Android:
EPUB Reader
CoolReader
FBReader
Moon+ Reader
eBooxiPhone:
FBReader
CoolReader
iBook
BookmateWindows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google ChromeiOS
Marvin for iOS
ShortBookLinux:
Calibre
FBReader
Cool Reader
Okular обновляются периодически, поэтому возможно некоторое отставание их от онлайновой версии курса. Версия файла — от 09.03.2023.Компоненты Битрикс
Компоненты используются для переработки данных, с помощью которых строятся публичные части сайта. В нашей компании есть группа разработчиков, и они ежедневно работают с компонентами, которые мы создали на основе API битрикса. В этой статье мы привели список самописных компонентов Битрикс. Список будет дополняться новыми компонентами. Если у вас есть предложения по статье, можно оставить комментарий ниже.Будем рады получить обратную связь!
Elements
Компонент для вывода списка элементов инфоблока. Основан на CIBlockElement::GetList. Имеет настройки для вывода цен продуктов, нарезки изображений.
Можно передать стандартные параметры CIBlockElement::GetList:
- sort — параметр arOrder для методаCIBlockElement::GetList
- filter — параметр arFilter для методаCIBlockElement::GetList
Если в фильтре есть свойства, они должны обязательно отображаться в параметре props
Также можно передать параметры:
- props — массив свойств символьных кодов, которые надо достать для элементов.
- page — текущая страница пагинации Подробнее
- count — количество элементов на странице Подробнее
- pagn_id — название шаблона для пагинации (для компонента bitrix:main.pagenavigation). Подробнее
- show_all — если true, подгрузятся все элементы (если нет настроек других, см. пагинации )
- load_section — если правда, то для элементов будет использоваться информация о задействовании секции элемента (в том числе в регионах)
- images — набор настроек для обработки изображений .
- price_ids — массив ID цен ( правила работы с ценой ).
- load_discounts — если правда, то для снижения цен в price_ids будут предлагаться скидки ( правила работы с ценой ).
- load_urls — включение обработки шаблонов ссылок из настроек инфоблока. Эта настройка включает подгрузку раздела, как параметр load_section
- load_catalog_fields — под поиск / не под поиск стандартные поля каталога (CATALOG_QUANTITY и т.д.)
- CACHE_TIME — время кеширования в секундах. Если параметр передан, в компоненте кузова автокеширование на заданное время
Поддержка работы с торговыми предложениями
Если необходимо достать торговые предложения, то все параметры, возврат выше ( кроме изображений ) используются для инфоблока торговых предложений. Для инфоблока товаров, можно передать дополнительный параметр товара :
Обратите внимание, все коды свойств продукта нужно писать с префиксом PROPERTY
Работа с ценами
Начало с версии 18.6.200 битрикс умеет работать с ценами «красиво». Для получения цены надо в arSelect функции GetList передать ключ PRICE_<price_id>. где price_id — ID типа цены. Посмотреть ID можно в админке: Магазин — Цены — Типы цен
В нашем комплекте цены передаются соответствующим параметром price_ids , который является массивом ID-шников (не PRICE_<price_id>, а только <price_id>), которые необходимо достать.
Сортировки и фильтры работают также — передачи ключа PRICE_<price_id>, где price_id — id типа цены. Но есть нюанс — не попадается скидка . Но это нормально, так как стандартный компонент битрикса тоже не умеет сортировать со скидками.
Если использовать скидки и их необходимо достать, необходимо добавить дополнительный параметр load_discounts со значением true . Однако надо помнить, что при получении скидок битрикс очень много поступил. Для 50 элементов делается около 1000 запросов к БД. Поэтому доставать скидки нужно только при необходимости.
В результирующем массиве всегда в ключе PRICE находится актуальная цена (с учетом скидок). Если есть скидка для данного товара, то добавится ключ OLD_PRICE, в котором будет старая цена без учета скидок.
Настройка обработки изображений.
Массив изображений — обязательно ассоциативный, где
ключ — код поля, который надо обработать. Ключи DETAIL_PICTURE и PREVIEW_PICTURE автоматически воспринимаются как стандартные выходы и детальная картинка. Остаются поиски в массиве свойств.
значение — массив настроек для изображения. Это тоже обязательно ассоциативный массив, где
ключ — код, с предметами будет добавлена картинка в результирующий массив картинок
значение — массив, в котором в первые два значения — ширина и высота для обрезания картинки — их необходимо передать в обязательном порядке. Кроме того, можно передать параметр третий — тип обрезания resizeType (см. документацию по обрезанию картинок ).
Коды свойств, которые передаются в изображениях, обязательно необходимо передать так же в реквизит , иначе они не будут подгружены и соответственно не обработаны.
Коды свойств товара переданы без префиксаPROPERTY_
Пагинацию можно получить с помощью компонента bitrix:main.pagenavigation . Нормальной документации не нашел, но про подключение можно почитать тут , так же есть пример шаблона вместе с описанием в этой репозитории (bitrixComponetns)
В $arResultесть ключ NAV_OBJECT, который необходимо передать при подключении.
Пример подключения пагинации в шаблоне odva:elemetns:
Естественно необходимо создать шаблон для пагинации, и вывести там данные. Пример шаблона (с многоточиями: 1 2 . 10) есть в этом же репозитории.
Логика прослушивания параметров пагинации:
1. Если передается pagn_id:
- игнорируем параметр show_all
- параметр page берется либо из arParams, либо с URL страницы
- создаем объект пагинации и записываем его в arResult
- берем все данные для пагинации из URL
- количество элементов ставим либо из count, либо 20
- передаем в getlist параметры iNumPage и nPageSize, значения которых берем из объекта nav
2. Если pagn_id не передан:
- объект пагинации не создаем
3. Если есть page:
- передаем в getlist параметры iNumPage и nPageSize
- iNumPage берем из page
- nPageSize либо из count, либо 20
4. Если нет page:
- если есть count
- передаем в getlist параметр nTopCount
- если нет count
- если есть параметр show_all
- оставляем параметры навигации пустым массивом
- если нет параметра show_all
- передаем в getlist параметр nTopCount
Element
Element-компонент для вывода детальной информации элемента или простого продукта (торговые предложения не поддерживаются)
- idилиcodeилиfilter- соответственно, ID или CODE элемента или массив для фильтрования.Один из этих параметров надо передать обязательно.Если переданы несколько,то отбираются по приоритету id -> code -> filter.
- IBLOCK_ID- ID инфоблока, в котором лежит элемент.Обязателен, если не передается в параметре filter
- props- массив CODE свойств, которые нужно достать (если в массиве будет элемент *, то загрузятся все поля)
- load_product_fields- подгружать / не подгружать поля товара
- load_section- подгружать / не подгружать информацию о разделе
- price_ids- массив ID типов цен, которые нужно достать. Посмотреть ID можно в админке:Магазин — Цены — Типы цен
- images — массив настроек для обработки изображений.
- set_code_404- если значение отличается от «N» или не задано, то при неудачном поиске будет отдаваться 404
- кодshow_errors- если значение не установлено или не равно «N», при неудачном поиске будет показываться текст «Элемент не найден», иначе будет подключаться шаблон
- SET_CANONICAL_URL- установить канонический URL для страницы
- SET_TITLE- установить заголовок страницы
- SET_BROWSER_TITLE- установить заголовок окна браузера
- ADD_ELEMENT_CHAIN- добавить элемент в breadcrumb
- SET_META_KEYWORDS- вывести meta-тег keywords
- SET_META_DESCRIPTION- вывести meta-тег description
Настройка обработки изображений
Массив images — обязательно ассоциативный, где:
- ключ- код поля, которое надо обработать. Ключи DETAIL_PICTURE и PREVIEW_PICTURE автоматически воспринимаются как стандартные анонс и детальная картинка. Остальные ищутся в массиве свойств.
- значение — массив настроек для изображения. Это тоже обязательно ассоциативный массив, где ключ — код, с которым будет добавлена картинка в результирующий массив картинок; значение — массив, в котором первые два значения- ширина и высота для обрезания картинки (их нужно обязательно передать). Кроме того можно передать третий параметр — тип обрезания resizeType (см.документацию по обрезанию картинок).
Коды свойств, которые передаются в images, обязательно нужно передать так же в props, иначе они не будут подгруженны и соответственно не обработаны.
Smart Filter
Этот компонент предназначен для парсинга строки с ЧПУ фильтром и генерации массива фильтров. Сгенерированные фильтры можно передавать в GetList без дополнительной обработки.
Результирующий массив состоит из двух ключей — products и offers. Offers заполняется автоматически, если инфоблок продуктов — это инфоблок, являющийся каталогом и имеющий инфоблок с торговыми предложениями.
Работа фильтра основана на фасетном индексе — по сути это просто sql индексы, просто немного сложнее и с использованием API битрикса. Для нормальной работы фильтра надо создать фасетные индексы, настроить свойства и правильно передать параметры.
Параметры фильтра:
1. IBLOCK_ID-обязательныйпараметр, указывается ID инфоблока, с которым будет работать фильтр;
2. FILTER_URL- строка вида «test/1/test2/2-3/», в которой передаются фильтры. Множественные значения (чекбоксы, радио кнопки, цена от и до) разделяются знаком «-«;
3. PRICE- массив для настройки работы с ценами.Без этого парамтера цены игнорируются. В этот параметр могут входить следующие ключи:
- TITLE- подпись поля в фильтре (обычно «Цена»)
- FIELD- название поля с ценой — ключ, по которому будет искаться цена в строке URL. Этот же ключ будет передаваться в результирующий массив с фильтрами.
- SORT- сортировка, для остальных полей задается в админке в настройках инфоблока
4. SECTION_IDилиSECTION_CODE- ID или CODE раздела соответственно. На сколько я понял, ни на что не влияют, но в фасетном индексе битрикса используются.
Фасетные индексы
При создании свойств инфоблока (возможно еще в каких то случаях) битрикс начинает показывать предупреждение, что надо создать новый фасетный индекс. Надо нажать на ссылку в предупреждении и создать этот индекс. Так же можно перейти в админке на страницу /bitrix/admin/iblock_reindex_admin.php?lang=ru и создать там индексы. Эти индексы надо создавать каждый раз, когда создается свойство (возможно и в других случаях, в общем, каждый раз, когда битрикс этого требует).
Подключение свойств в фильтр
Чтобы свойство отображалось в фильтре, надо его настроить — в админке, в настройках свойств инфоблока зайти в расширенные настройки конкретного свойства (нажать «. «) и поставить галочку «Показывать в умном фильтре».
Также можно выбрать, в каком виде будет отображаться это свойство — флажки, радиокнопки, выпадающий список.
Чтобы свойство работало, обязательно нужно указать свойству символьный код (CODE).
Если, есть свойства, которые необходимо отобразить в фильтре, но для них нельзя включить фасетные индексы, то их можно передать в параметре ADDITIONAL_PROPERTIES
Сортировка значений свойств фильтра
Для сортировки необходимо при получении значений методом getValues(), передать массив вида
- PROP — свойство для сортировки
- ORDER — SORT_ASC для сортировки по возрастанию, или SORT_DESC для сортировки по убыванию.
Пример подключения фильтра:
Визуальное отображение фильтров, в том числе получение возможных значений для каждого свойства, получение типа отображения и т.д. можно посмотреть в шаблоне .default, расположенном вместе с компонентом.
Odva Form
Odva Form- это компонент предназначен для обработки форм и сохранения отправленных данных в инфоблок.
- IBLOCK_ID — ID инфоблока, в который нужно сохранять данные, обязательный параметр
- ELEMENT_NAME — название нового элемента инфоблока, по умолчанию будет ставиться «Новый элемент»
- PROTECTED_PARAMS — параметры, которые нужно защитить от подделки пользователем. Как работает — описано ниже
- REQUIRED_FIELDS — определяет, какие поля формы обязательны для заполнения
Как передавать данные на сервер.
Запрос отправляется к отдельному файлу, путь к нему хранится в переменной $arResult[‘PATH_AJAX’] в шаблоне.
На сервер данные должны приходить с такими же именами, какими названы свойства инфоблока. То есть, если у инфоблока есть свойство NAME, то в форме поле ввода должно называться NAME (или параметр при сборке данных в ajax-запросе).
Кроме данных на сервер надо обязательно отправлять параметр TOKEN. В нем хранится набор защищенных параметров. Без этого параметра форма будет возвращать ошибку.
Как работает защита параметров.
Параметры, которые нужно защитить от подделки пользователем, нужно передать в параметр PROTECTED_PARAMS. Из этих данных сформулируется специальный хеш, который в $arResult доступен как ключ TOKEN. Его надо обятально отправлять на сервер.
По умолчанию там уже зашиты параметры IBLOCK_ID и ELEMENT_NAME. Кроме них можно отправлять какие то свои параметры. Самый простой пример — защита параметра REQUIRED_FIELDS. Но можно передавать любые параметры, которые есть в $arParams.
Sections
Компонент для вывода разделов инфоблока. Копирует функционал метода CIBlockSection::GetList с небольшими дополнениями.
- sort — параметр arOrder для методаCIBlockSection::GetList
- filter — параметр arFilter для методаCIBlockSection::GetList
- element_cnt — параметр bIncCnt для методаCIBlockSection::GetList
- select — параметр Select для методаCIBlockSection::GetList
- count — количество доставаемых секций (по умолчанию достаются все)
- load_urls — если указан параметр, то будут загружаться ссылкиLIST_PAGE_URLиSECTION_PAGE_UR
Рrofile
Компонент для вывода информации пользователя в личном кабинете. Есть возможность редактирования данных пользователя, изменения пароля и авторизация через социальные сети с помощью сервиса ulogin.
Можно передать параметры:
- NEED_FIELDS — массив обязательный полей профиля
- LOGIN_IS_EMAIL — со значением Y, если логин и емайл совпадают
Переменные, которые нужны для ajax:
Section
Используются для вывода детальной информации о разделе инфоблока. Работает на основе метода CIBlockSection::GetList.
Можно передать некоторые стандартные параметры CIBlockSection::GetList:
- sort — параметр arOrder для метода CIBlockSection::GetList
- filter — параметр arFilter для метода CIBlockSection::GetList
Также можно передать параметры:
- id или code — соответственно, ID или CODE раздела. Один из этих параметров надо передать обязательно. Если переданы несколько,то отбираются по приоритету id -> code
- IBLOCK_ID — ID инфоблока, в котором находится раздел___Обязателен
- props — массив CODE свойств, которые нужно достать (если в массиве будет элемент *, то загрузятся все поля)
- show_element_cnt — количество элементов у раздела
Orders
Компонент предназначен для вывода списка заказов. С помощью компонента Orders мы видим следующую информацию: