Периодические обращения с проблемой, означенной в заголовке, и одинаковая причина, вылились в публикацию этого поста.
Итак, симптомы следующие: долгое (60 сек и выше) сохранение элемента/товара через админскую форму редактирования. При импорте и выполнении из консоли проблем не наблюдается. Клиент недоволен, техподдержка в панике. Анализ на стороне хостера выявляет долгий запрос вида:
UPD ATE b_iblock_element SE T
TIMESTAMP_X = TIMESTAMP_X,
SHOW_COUNTER_START = ifnull(SHOW_COUNTER_START, now()),
SHOW_COUNTER = ifnull(SHOW_COUNTER, 0) + 1
WH ERE ID=ИД_сохраняемого_элемента
В тяжелых случаях изменения не сохраняются вообще. В чем же причина?
Коллеги, недавно в коробку были выгружены обновления Главного модуля (main) 20.5.x. Текущий статус - бета. В этих обновления существенно переработан план выполнения страницы для повышения производительности и уменьшения времени отдачи контента браузеру.
Для поддержки этих возможностей был доработан компонент умного фильтра каталога (catalog.smart.filter). Измененный компонент доступен после установки обновления инфоблоков iblock 20.0.900. Однако, если на конкретном проекте компонент фильтра был кастомизирован (скопирован или перенесен в свое пространство имен), необходимо будет внести изменения в код самостоятельно.
Свежая связка обновлений закрыла несколько кейсов, по которым у нас было достаточно много "хотелок". Часть из них возникла после миграции магазина на Б24, часть - "старые долги" по БУС. Здесь вкратце обрисую то, что выпущено.
Исторически метод модуля iblockCIBlockElement::GetList может работать с данными товара (при наличии модуля catalog). Это подробно описано в и активно используется как в публичных компонентах, так и на административных страницах и скриптах. Однако архитектурные особенности реализации, равно как и неразумное (чаще всего) использование этих возможностей, приводят к резкому падению производительности.
Эта публикация написана после неоднократных обращений как клиентов, так и (к горести моей) партнеров. Темы обращений были разные, но причиной в итоге оказывался один и тот же сценарий, реализуемый как через админку, так и через api.
Самый частый вопрос, задаваемый начинающим разработчиком - "как". Как создать цены, как добавить в корзину, как вывести... Вопрос "почему" задается гораздо реже. Сдав три-четыре, а лучше пять-десять проектов, разработчик уже чувствует себя уверенней - есть стандартные наработки и приемы, стереотипные ходы, можно браться за реализацию задач поинтересней. Самое время для "почему". Но - те самые стереотипы, опыт (руль - он одинаковый и у легковушки, и у фуры), формирующий картину мира, время, которое деньги. Тем более, что все работает. "Почему" может и не прозвучать. А может прозвучать, но остаться без ответа.
Эта статья открывает серию "почему" и "зачем" для разработчиков магазинов. Темы будут определяться исходя из вопросов на форуме и в блогах, обращений в техподдержку, предложений сайта идей. За рамками публикаций сознательно будут оставлены вопросы, касающиеся причин тех или иных архитектурных решений.
В обновлении main 16.5.0 выпущен обновленный класс BX.PopupWindow. В нем полностью изменена верстка всплывающего окна и частично изменены входные параметры. К сожалению, полную совместимость сохранить не удалось - слишком велики изменения, необходимость в которых назрела давно.
Изменения базовых шаблонов компонент магазина, использующих этот класс, выходят в обновлениях 16.5.0 модулей iblock, catalog, sale. Тем же, кто кастомизировал шаблоны нижеперечисленых компонент под свои нужды, необходимо будет внести небольшие правки в script.js (естественно, если после кастомизации остались вызовы BX.PopupWindow или BX.PopupWindowManager.create).
Правки затрагивают шаблоны следующих компонент: iblock
Есть такой замечательный метод - CCatalogProduct::GetOptimalPrice. Его задача - выдать минимальную цену на товар. Начиная с обновления catalog 15.0.2 разработчикам доступны новые возможности изменения результатов этого метода. Рассмотрим их подробно.
Задача выполнения произвольного кода при изменении данных встречается сплошь и рядом. Это и разноообразные оповещения, и синхронизация таблиц, и сброс кеша - все, что угодно. При наличии событий, вызываемых после успешного обновления, задача решается достаточно тривиально. Все хорошо ровно до того момента, когда требуется выполнить код только тогда, когда данные ДЕЙСТВИТЕЛЬНО изменились (значения полей элемента таблицы до и после записи различаются). Этот момент почему-то порождает массу вопросов на форуме, не говоря уж об идеях перед обновлением записи подымать из базы старые значения внутри api ядра. Постараюсь закрыть эту тему.
Имеем достаточно распространенную задачу - при изменении элемента инфоблока модифицировать другой. Кейс может быть какой угодно - это и логирование, и деактивация основного товара, когда нет активных предложений, и изменение даты активности связаного элемента. Никаких проблем, скажете вы. За 10 минут пишется обработчик, использующий метод CIBlockElement::Update, вешается на событие OnBeforeIBlockElementUpdate / OnAfterIBlockElementUpdate, вызывается тестовый пример, сервер падает... Epic fail в чистом виде...
В обновлении catalog 11.5.2 вышел новый функционал - программы накопительных скидок. Кроме этого, обновление, как обычно, содержит исправление ошибок. Но обо всем по порядку.
Периодически встречается следующая задача: на основании значения свойства элемента или ряда других условия модифицировать какой-то конкретный тип цен при создании/изменении элемента. Первое, что приходит в голову - воспользоваться обработчиками событий OnAfterIBlockElementAdd и OnAfterIBlockElementUpdate. При использовании с API все работает отлично, однако при сохранении изменений в форме редактирования элемента в админке ничего не происходит. Создается впечатление, что обработчик не вызывается. Как результат - обращение в техподдержку и долгие поиски ошибок. В чем же причина?
В 11 версии были введены расширенные права на инфоблоки. Кроме всего прочего, есть возможность создавать свои комбинации прав. Постараюсь осветить этот вопрос, дабы не возникало проблем и недопонимания при работе с админкой, особенно с учетом обновлений 11.0.6 Торгового каталога и 11.0.13 Инфоблоков.
В обновлении 11.0.6 (выходит в ближайшее время) модуля Торговый каталог исправлен ряд ошибок и расширен функционал обработчиков для формирования своей логики цен.
В ближайшее время выходит обновление модуля Торговый каталог 11.0.5. В нем исправляется ряд ошибок и добавлены новые события, позволяющие реализовать свою логику работы с ценами.
В ближайшее время выходит небольшое обновление модуля Торгового каталога. В нем исправлен ряд ошибок и улучшена работа с профилями экспорта и импорта торгового каталога. Но обо всем по порядку.
В 10-й версии БУС добавилось новое свойство инфоблоков - Привязка к элементам с автозаполнением. Оно описано в документации (), но, похоже, прошло незамеченным. Постараюсь заполнить этот пробел.
В ближайших обновлениях выйдет интерфейс работы с торговыми предложениями в административной и публичной части. Речь идет о ситуации, когда цена товара зависит от его свойств. В этом случае удобно разнести описания товара и цены по двум инфоблокам. Идея использовалась давно, однако интерфейса для управления не хватало. Что нового?
