Самый частый вопрос, задаваемый начинающим разработчиком - "как". Как создать цены, как добавить в корзину, как вывести... Вопрос "почему" задается гораздо реже. Сдав три-четыре, а лучше пять-десять проектов, разработчик уже чувствует себя уверенней - есть стандартные наработки и приемы, стереотипные ходы, можно браться за реализацию задач поинтересней. Самое время для "почему". Но - те самые стереотипы, опыт (руль - он одинаковый и у легковушки, и у фуры), формирующий картину мира, время, которое деньги. Тем более, что все работает. "Почему" может и не прозвучать. А может прозвучать, но остаться без ответа.
Эта статья открывает серию "почему" и "зачем" для разработчиков магазинов. Темы будут определяться исходя из вопросов на форуме и в блогах, обращений в техподдержку, предложений сайта идей. За рамками публикаций сознательно будут оставлены вопросы, касающиеся причин тех или иных архитектурных решений.
В обновлении main 16.5.0 выпущен обновленный класс BX.PopupWindow. В нем полностью изменена верстка всплывающего окна и частично изменены входные параметры. К сожалению, полную совместимость сохранить не удалось - слишком велики изменения, необходимость в которых назрела давно.
Изменения базовых шаблонов компонент магазина, использующих этот класс, выходят в обновлениях 16.5.0 модулей iblock, catalog, sale. Тем же, кто кастомизировал шаблоны нижеперечисленых компонент под свои нужды, необходимо будет внести небольшие правки в script.js (естественно, если после кастомизации остались вызовы BX.PopupWindow или BX.PopupWindowManager.create).
Правки затрагивают шаблоны следующих компонент: iblock
Имеем достаточно распространенную задачу - при изменении элемента инфоблока модифицировать другой. Кейс может быть какой угодно - это и логирование, и деактивация основного товара, когда нет активных предложений, и изменение даты активности связаного элемента. Никаких проблем, скажете вы. За 10 минут пишется обработчик, использующий метод CIBlockElement::Update, вешается на событие OnBeforeIBlockElementUpdate / OnAfterIBlockElementUpdate, вызывается тестовый пример, сервер падает... Epic fail в чистом виде...
Периодически встречается следующая задача: на основании значения свойства элемента или ряда других условия модифицировать какой-то конкретный тип цен при создании/изменении элемента. Первое, что приходит в голову - воспользоваться обработчиками событий OnAfterIBlockElementAdd и OnAfterIBlockElementUpdate. При использовании с API все работает отлично, однако при сохранении изменений в форме редактирования элемента в админке ничего не происходит. Создается впечатление, что обработчик не вызывается. Как результат - обращение в техподдержку и долгие поиски ошибок. В чем же причина?
В 11 версии были введены расширенные права на инфоблоки. Кроме всего прочего, есть возможность создавать свои комбинации прав. Постараюсь осветить этот вопрос, дабы не возникало проблем и недопонимания при работе с админкой, особенно с учетом обновлений 11.0.6 Торгового каталога и 11.0.13 Инфоблоков.
В 10-й версии БУС добавилось новое свойство инфоблоков - Привязка к элементам с автозаполнением. Оно описано в документации (Детальное редактирование свойств инфоблока), но, похоже, прошло незамеченным. Постараюсь заполнить этот пробел.
В ближайших обновлениях выйдет интерфейс работы с торговыми предложениями в административной и публичной части. Речь идет о ситуации, когда цена товара зависит от его свойств. В этом случае удобно разнести описания товара и цены по двум инфоблокам. Идея использовалась давно, однако интерфейса для управления не хватало. Что нового?