Евгений Семашко (Все сообщения пользователя)

Я не очень понимаю один момент. Если я опишу такую сущность, у меня получится избыточность, если я правильно все понимаю. У меня будет каталог с книгами, в котором будут находиться элементы инфоблока, при этом дополнительно будет существовать таблица  "my_book_element", которая будет связана с элементами инфоблока  с помощью Вопрос зачем? Это поможет в будущем делать более сложные выборки, сортировки и так далее, в результате которых на основе полученных данных можно будет  выбирать инфоблоки по ReferenceField('IBLOCK_ELEMENT')? В целях экономии времени и расширения возможностей?
Заранее спасибо.

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

А список авторов например? Тоже лучше сделать хайлоад блоками? Т.е. в чем конкретная разница, например, для списка авторов будет?
Производительность, возможности и так далее?
Может быть есть, например, смысл список авторов сделать простым списком?...
Хотя, конечно, на будущее, туда можно и картинки засовывать и синонимы придумывать... это интересно должно быть.
В этом смысле может быть имеет смысл делать все просто инфоблоками 2.0? Или это будут дичайшие тормоза (~0,5 млн. позиций)?

Всем привет!
Хочу посоветоваться по такому вопросу.
У меня есть инфоблок товара. У товара есть некоторые свойства. Допустим это книги и у них есть свойство, например, "тип обложки". Это список, в котором могут быть указаны разные значения. Во внешней системе, с которой сайт забирает эти товары, список может меняться. Хочу понять как лучше и адекватнее будет сделать - простым списком с изменением его значений при синхронизации с внешней системой или может быть лучше хайлоад блоками с той же самой синхронизацией. По свойству планирую делать фильтр в дальнейшем.
Подскажите, как лучше организовать данный момент.

Смог добавить раздел только через API.

Всем привет.
Сделал инфоблок, в котором хочу добавить раздел с дополнительными свойствами. Добавил свойства. Пытаюсь создать раздел, заполнить свойства не могу - неактивны инпуты. При сохранении однако битрикс говорит, что надо их заполнить. Но как, если они неактивны?

Скорее всего, кастомизацией шаблона или добавьте свой result-modifier.php.

BLOG_POST_ID наверняка автоинкремент, не очень понятен вопрос.

С какими именно трудностями-то?

Проверьте, работает ли функция отправки почты в проверке системы.

А в чем вопрос-то?

Отредактируйте шаблон сайта (/bitrix/templates/ваш_сайт/footer.php или /local/templates/ваш_сайт/footer.php) и вставьте туда код.
А вообще лучше курсы учебные читайте. Там понятно.

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

Поддержка отвечает что никак, и надо менять параметры MySQL на сервере. Но мне это кажется не совсем соответствующим истине, т.к. кодотрабатывает корректно.

Как указать опцию MYSQLI_OPT_LOCAL_INFILE в настройках подключения к БД в рамках битрикс АПИ?

Не, не помогло.

Да, только там указано, что это не секунды а минуты. Поменял на 86400

Правьте через sftp/ftp лучше. А еще лучше пользуйтесь IDE какой-нибудь.

Может быть из-за кэширования? Вы кэш сбрасывали? Добавьте еще какой-нибудь код для проверки. выполняется ли он или нет.

Есть какие-нибудь идеи на сей счет?

Предлагаемые решения (поменять local-infile=1 для раздела [client] из my.cnf, прописать использование mysqli в .settings) - не помогают.

Поправьте, пожалуйста, я, возможно, не прав.

Все равно возник вопрос, в частности, про свойства элементов инфоблоков.
На сколько я понимаю, в сущность, унаследованную от Bitrix\Iblock\ElementTable, нужно добавлять их самому, предварительно описав сущности, которые маппят таблицы со свойствами. Но это как-то не особенно удобно. Либо использовать highload блоки, что пока тоже не очень удобно. В итоге получается, что нужно описать три сущности для b_iblock_element_property, b_iblock_element_prop_mX,  b_iblock_element_prop_sX + одну сущность для b_iblock_element, и из нее делать ссылки на остальные три, правильно я понимаю это?
Есть ли возможность каким-либо образом описывать сущность, унаследованную от Bitrix\Iblock\ElementTable, при этом не описывая другие, но имея все необходимые свойства элементов на вооружении?

Да, почитал в курсе разработчика, спасибо!

Приветствую.
Вопрос следующего плана.
У меня есть несколько разных таблиц (сконфигурированных для работы с внешней системой), в которых хранятся разные свойства товара.
Также у меня есть тип инфоблока товара, который позволяет описать соответствующие инфоблоки (со всеми описанными полями).
Мне очень импонирует идеология ORM D7, но не очень понятно как быть в этом случае.
Например, я создам сущность товар, и опишу ее поля как ссылки на другие сущности, предварительно описав сущности для каждой из таблиц. Но для того, чтобы создать элементы инфоблока, мне придется заводить таблицу же, с которой будет связана сущность "товар". Можно ли как-то обойтись без этой дополнительной таблицы, поскольку она по сути будет дублировать уже имеющиеся, только со своими плюшками?
Спасибо