В документации метода CCatalogProduct::Add(), есть непонятные моменты.
Начнем обсуждение с ключа TYPE
TYPE - тип товара (значения по умолчанию зависят от вида торгового каталога);
А какие же типы типы продукта можно использовать?
Обычный продукт (простой)
В ключе TYPE укажите \Bitrix\Catalog\ProductTable::TYPE_PRODUCT
Ключи у этого типа, описаны в документации
Комплект или набор
В ключе TYPE укажите \Bitrix\Catalog\ProductTable::TYPE_SET
Чем отличается, в коде, комплект от набора не удалось понять, если знаете - напишите. Какие ключи надо использовать у этого типа, также нигде не смог найти. Если знаете, пишите в коментах.
Товар с торговыми предложениями
В ключе TYPE укажите \Bitrix\Catalog\ProductTable::TYPE_SKU
Ключи также НЕ описаны в документации.
Торговое предложение
В ключе TYPE укажите \Bitrix\Catalog\ProductTable::TYPE_OFFER
Ключи у этого типа, описаны в документации
В коде есть еще 2 типа TYPE_FREE_OFFER и TYPE_EMPTY_SKU, но когда их лучше всего использовать не понятно. Знаете - пишите!
@darkfriend: Битрикс сохраняет свой пофигизм к разработчикам. Если вы хотите, чтоб за продукт платили, в первую очередь ДОЛЖНА быть качественная полная документация. Битрикс на протяжении всего своего существования второстепенно относится к этому.
Гаврилов Евгений написал: Я понимаю, что хочется идеальную документацию, но битрикс сделан для обычных клиентов, а не для программистов.
Обычным клиентам очень сложно использовать битрикс))) Потому что UX у коммерческой платформы на 3/5. Мне лично приходилось 100500 раз объяснять и даже делать скринкасты разным людям, о том как и что юзать. Есть наработки для улучшения UX и возможно мы как нить найдем время, чтоб закатать их в модуль.
Любой платформе нужно ориентироваться и на клиентов, и на разработчиков. Многие клиенты думают, что на битриксе можно создать только магазин (причем не крупный), лендинг или не сложный сайт-компании. Мы же делаем достаточно сложные вещи на битриксе, расковыривая и изменяя логику, тем самым показывая гибкость платформы.
Гаврилов Евгений написал: Фичи у битрикса выходят очень быстро согласно требованиям рынка клиентов
Фичи выходят очень даже не быстро)
Гаврилов Евгений написал: Пример полезной статьи - https://dev.1c-bitrix.ru/community/web...log/19963/ Человек разобрался с тем, как это работает и написал статью. он помог многим, кто нашёл его статью. А чем плачь помогает другим (это не касается нового функционала и конкретных багов. Тут плачь поможет быстро отреагировать сотрудникам битрикса и исправить ситуацию или хотя бы что-то объяснить)? Ещё была статья, в которой подробно описывались все типы товаров очень подробно.
Хорошие статьи, которые улучшают понимание фреймворка, нужно ссылками крепить в документации, чтоб без устаревших поисковых систем, можно было найти.
И это не плачь, это критика. Без критики, никогда не будет прогресса. Вам нужно перестать думать о том, что вам плачутся или ноют.
При работе с битриксом, постоянно втыкаешся во множество не описанных моментов. Яб не критиковал, если это было фришно, но в коммерции извольте следить за документацией. Сделали новое - описали, еще новое - описали и т.д. Это не сложно, сложнее потом вспоминать и описывать все за раз.
Со многими неописанными моментами битрикса просто разобраться, с другими только с бубном. А постоянно лезть в базу, не верный подход к разработке и тем более не верный совет.
Гаврилов Евгений написал: Рынок с вами категорически не согласен. Я не говорю, что это правильно или неправильно. Я говорю лишь, что в данном случае рынку плевать на это.
Я не знаю про какой рынок вы говорите, но в нашем колхозе документация очень важный фактор.
Теперь вы можете указать страницы на которых не нужно выводить теги OpenGraph. Пути до страниц указывать от корня.
Пример 1:
Задача: Нужно запретить вывод мета-тегов OpenGraph для страницы "/catalog/auto/audi/a8/", а также запретить вывод для главной страницы. Решение: Указываем в поле "catalog/auto/audi/a8/", а в другом поле "index" (index, от корня, это ключевое значение, которое модуль воспримет за главную страницу).
Добавлена возможность указать OpenGraph в элементах инфоблока
Выводятся все поля, которые указаны в настройках модуля. Поле description - выводится как textarea Поле image- выводится как fileinput Все остальные поля выводятся, как input
Поля которые не выводятся, но значения проставляются автоматически:
url - текущая отображаемая страница
image:width - ширина картинки, которая сейчас в og:image
image:type - тип картинки (png,jpg, etc.), которая сейчас в og:image
image:height - высота картинки, которая сейчас в og:image
site_name - название сайта из настроек сайта
Добавлена возможность указать OpenGraph в разделах инфоблока
Выводятся все поля, которые указаны в настройках модуля. Поле description - выводится как textarea Поле image- выводится как fileinput Все остальные поля выводятся, как input
Поля которые не выводятся, но значения проставляются автоматически:
url - текущая отображаемая страница
image:width - ширина картинки, которая сейчас в og:image
image:type - тип картинки (png,jpg, etc.), которая сейчас в og:image
image:height - высота картинки, которая сейчас в og:image
site_name - название сайта из настроек сайта
Добавлена настройка вывода OpenGraph полей в элементах и разделах
Добавлена загрузка картинки для OpenGraph, по умолчанию
Как интегрировать поддержку OpenGraph
Мы сделали автоматический вывод Open Graph для:
title - из заголовка страница
description - из описания страницы
url - текущая страница
site_name - название из настроек сайта
type - по умолчанию website
Для всего остального и собственных полей мы сделали 2 способа интеграции
Способ #1
Указать на нужных страницах названия полей добавляя впереди "og:"
Примеры:
Переписать поле og:title
$APPLICATION->SetPageProperty('og:title','Новое значение');
// или
// $APPLICATION->SetDirProperty('og:title','Новое значение');
Установить значение в og:image
$APPLICATION->SetPageProperty('og:image','http://rockisfest.ru/upload/resize_cache/iblock/5a9/380_9999_1/5a9163ca1aca97d620d6640dd271a7f6.jpg');
// или
// $APPLICATION->SetDirProperty('og:image','http://rockisfest.ru/upload/resize_cache/iblock/5a9/380_9999_1/5a9163ca1aca97d620d6640dd271a7f6.jpg');
Установить любое своё свойство, допустим og:custom
Предварительно нужно проверить добавлено ли поддержка custom в настройках модуля, если нет, то добавить
$APPLICATION->SetPageProperty('og:custom','Новое значение');
// или
// $APPLICATION->SetDirProperty('og:custom','Новое значение');
Если нужно сделать установку значений из элементов и разделов, то необходимо прописывать в result_modifier.php используемого шаблона. После чего сбросить кэш.
Способ #2
Этот способ наиболее проще первого, но, в данной версии, представляет меньше гибкости. Этот способ мы сделали для более удобной интеграции Open Graph в компонентах.
Необходимо в result_modifier.php или component_epilog.php прописать вызов метода:
\Dev2fun\Module\OpenGraph::Show($refId,$type);
Где $refIf - идентификатор элемента или раздела Где $type - тип объекта element или section.
element - вывод для элементов инфоблока section - вывод для разделов инфоблока
В результате result_modifier.php должно получиться следующее:
dev2fun написал: мы вам настоятельно не советуем делать инлайновую логику во входящих файлах. Столкнетесь с большими проблемами. Но дело конечно же за вами.
Обычно проблемы начинаются с задавания вопроса, а "на кой" разработчки кастомизировал компонент? И когда он закостылил, и с какой целью? исходники изменились даже в стандартном компоненте, даже дифа не получить, кому охото рыться в этом, из за того, что причиной кастомизации было нештатное поведение бизнес логики, которую можно было обойти не сменой части системы, а сменой входящих данных, при прочих равных условиях, учитывая то, что решение закостылить компонент - неадекватное, решается оно не так.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».