☕ Кофе && Код 📝

Обновление свойств и количества товаров в корзине Bitrix через Sale API

Проблема
При разработке на 1С-Битрикс часто возникает задача программного изменения товаров в корзине.

Решение
Необходимо использовать современное API модуля sale и объектную модель Bitrix\Sale\Basket. Сначала загружается корзина текущего пользователя по его FUser ID. Затем в коллекции находится нужный элемент BasketItem. Через методы объекта можно безопасно менять количество товара и управлять его свойствами с помощью коллекции PropertyCollection. Завершающим этапом является вызов метода save(), который автоматически запускает все необходимые внутренние пересчеты системы.

Итог
Работа через объектную модель BasketItem обеспечивает целостность данных и корректную работу маркетинговых правил при любых манипуляциях с составом корзины.

Читать полностью с примерами кода: https://bxmax.ru/coffee-code/obnovlenie-svoystv-i-kolichestva-tovarov-v-korzine-bitrix-cherez-sale-api

«Совет на обед» 🍽️ #4: Используйте миграции для изменения структуры БД

«Я создал свойство в инфоблоке на локалке, а на проде забыл» — классика боли в Bitrix-разработке. Миграции нужны всегда, даже если вы работаете в одиночку. Как только у проекта появляется больше одного окружения (local, dev, prod), ручное управление базой данных превращается в кошмар.

Почему миграции — это мастхэв:

1. Синхронизация состояний БД — каждый разработчик просто запускает команду, и его база обновляется до актуального состояния. Никаких «скинь дамп БД».

2. Версионирование изменений — вы точно знаете, когда и зачем было добавлено то или иное поле, создана таблица или изменён Highload-блок.

3. Автоматизация деплоя — миграции накатываются автоматически при деплое. Это исключает человеческий фактор: забыли нажать галку — сломали сайт.

💡 Решение:

К сожалению, в Bitrix до сих пор нет штатного механизма миграций «из коробки». Поэтому sprint.migration на сегодняшний день — это стандарт де-факто. Он умеет версионировать почти всё: инфоблоки, свойства, HL-блоки, пользовательские поля, почтовые события и даже настройки модулей.

Модуль на Маркетплейсе

🎯 Золотое правило: Всегда реализуйте `up()` и `down()`

Многие пишут только метод up(), считая, что откат не понадобится. Это ошибка.

- Зачем нужен `down()`: Если вы переключились на другую ветку, где этой структуры ещё нет, или если деплой пошёл не так и нужно быстро откатиться к предыдущему стабильному состоянию.
- Дисциплина: Если вы не можете написать откат для своей миграции, возможно, она делает слишком много. Разделяйте сложные изменения на несколько простых.

Используйте конструктор миграций в админке sprint.migration. Он сам сгенерирует код для создания инфоблока или свойства, вам останется только проверить его и закоммитить. Для сложной логики или кастомных случаев - пишем руками.

Миграции — это не дополнительная работа, это страховка вашего спокойствия.


#bitrix #битрикс #разработка #совет_на_обед #бд #миграции #sprintmigration

Где название свойства?

Один из подписчиков у меня сегодня спросил: есть стандартный код на D7 для получения элементов с множественным свойством (например, «Автор»):

use Bitrix\Iblock\Elements\ElementNewsTable;
use Bitrix\Iblock\Elements\EO_ElementNews_Entity;
use Bitrix\Main\Loader;

Loader::includeModule('iblock');

$elements = ElementNewsTable::getList([
    'select' => [
        'ID',
        'NAME',
        'CODE',
        'AUTHOR' // Множественное свойство
    ],
    'filter' => [
        'ACTIVE' => 'Y'
    ]
])->fetchCollection();

/** @var EO_ElementNews_Entity $element */
foreach ($elements as $element) {
    $authors = $element->get('AUTHOR')->getAll();
    foreach ($authors as $author) {
       echo $author->getValue() . '<br/>';
    }
}

Значения мы получаем без проблем. Но как красиво вытащить название самого свойства («Автор»), не делая при этом отдельный запрос к таблице свойств по ID?

Очевидный путь — дёрнуть PropertyTable::getList, но это лишнее обращение к БД. Я крутил варианты полчаса, чтобы найти способ сделать это через уже имеющийся объект сущности.

Оказывается, можно пролезть через такую цепочку:

$fieldTitle = $element->entity->getField('AUTHOR')->getIblockElementProperty()->getName();

Мы обращаемся к полю сущности, из него получаем объект свойства инфоблока и уже у него берём имя. Работает быстро и без «костылей» в коде. Хотя цепочка неоднозначно длинная получилась 🥴

Я, честно говоря, первый раз столкнулся с необходимостью именно такого пути. Если кто-то знал такой вариант или знает, как сделать ещё проще/правильнее — поделитесь в комментариях?

Битрикс × ИИ: Anthropic: Claude Opus 4.5

Пребываю немного в шоке от продолжения эксперимента.

Вчера пытался добиться хоть каких-то результатов от свежевыпущенной день назад китайской Z.AI: GLM 4.7. В итоге она проработала 17 минут над модулем, создала франкенштейна, которого сама же не смогла исправить за 10 итераций.

Аналогично запустил на этом тесте OpenAI: GPT-5.1 Codex Max. Работал быстрее и, примерно минут через 7, выдал хоть и нерабочий, но более адекватный результат. Однако и он не смог исправить проблемы за 10 итераций.

Поэтому обе модели не попали в рейтинг.

Мой фаворит (до выхода Gemini 3 Flash) в разработке Claude Opus 4.5, самая топовая модель Anthropic, прошёл тест довольно неплохо. Однако, если учитывать его цену (5$ / 20$ за млн токенов на ввод/вывод) и кол-во правок - он значительно уступает Gemini 3 Flash (54 балла против 79).

Я считаю, что он хорошо подходит для режима планирования задачи. А рабочей лошадкой использовать Gemini 3 Flash.

Смотрим подробный разбор на сайте: https://bxmax.ru/bitrix-ai/claude-opus-4-5

А что используете в повседневной работе вы? Может есть предложение протестировать конкретную модель?

В ближайших планах: Grok Code, Gemini 3 Pro, GPT-5.2, Claude Sonnet 4.5

«Совет на обед» 🍽️ #5: Техдолг — когда «костыль» становится памятником архитектуры

«Мы это потом поправим, сейчас нужно, чтобы просто заработало» — самая большая ложь, которую разработчик говорит себе и заказчику. В проектах такие «временные» решения имеют свойство превращаться в костыли, на которых спустя год держится вся архитектура.

Чем опасен бесконтрольный техдолг:

1. «Эффект зыбучих песков» — каждая новая фича внедряется всё дольше и сложнее, потому что вам приходится обходить старые костыли.

2. Страх рефакторинга — код становится настолько запутанным, что команда боится его трогать: «Работает — не лезь». В итоге система перестает развиваться.

3. Сложный онбординг — новый разработчик тратит недели на то, чтобы понять, почему данные передаются через глобальный массив или почему инфоблок используется не по назначению.

💡 Как с этим жить:

Полностью избежать техдолга невозможно (бизнес требует скорости), но его нужно инвентаризировать:

* Помечайте костыли в коде: Используйте @todo с указанием даты и фамилии. Современные IDE легко соберут вам список всех таких мест.
* Заводите задачи в бэклог: Если вы написали грязный хак, чтобы закрыть дедлайн — создайте задачу на рефакторинг сразу же. Опишите, что именно сделано плохо и как должно быть.
* Правило «Бойскаута»: Оставляйте код чище, чем он был до вас. Если вы пришли править баг и увидели рядом мелкий техдолг — исправьте его по пути.

🎯 Золотое правило: Костыль без документации — это мина замедленного действия

Если пришлось сделать «грязно» — напишите в комментарии ПОЧЕМУ это было сделано (например: «API Битрикса в версии 25.0 выдает ошибку X, ждем патча»).

Лайфхак: Раз в квартал устраивайте «день уборки». Выбирайте самые раздражающие куски техдолга и вычищайте их. Это сильно поднимает моральный дух команды и ускоряет будущую разработку.

#bitrix #битрикс #разработка #совет_на_обед #техдолг #clean_code

Проблема двух ядер: Как не сойти с ума? 🤯

Почему в 2025 году мы всё еще видим $DB->Query() в Битрикс-проектах? И как разработчику писать современный код, когда вокруг «легаси-болото»?

В новом посте-мнении разбираем:
• Почему старое ядро никак не умрет (спойлер: это экономика).
• Стратегию выживания: правило бойскаута и изоляция легаси.
• Как Service Locator помогает строить мосты между «старым» и «новым».

Если вы устали от спагетти-кода и хотите стать настоящим архитектором, этот текст для вас.

🔗 https://bxmax.ru/blog/problema-dvuh-yader-kak-ne-soyti-s-uma-pri-podderzhke-bitriks-proektov-v-2026-godu

#bitrix #legacy #architecture #d7 #development

«Совет на обед» 🍽️ #6: Логи в «одном окне» — прекратите играть в детектива

Поиск причины ошибки в Bitrix-проекте часто превращается в квест: что-то упало в системном error_log, что-то записалось в bitrix/modules/main.log, а что-то разработчик интеграции заботливо сложил в log_txt_123.log в корне сайта. Если у вас больше одного источника правды — у вас нет ни одного.

В чем боль разрозненных логов:
1. Потеря времени: Вы тратите 20 минут на поиск места, где залогирована ошибка, вместо того чтобы её чинить.
2. Игнорирование критических багов: Если ошибка пишется в файл, который никто не открывает, она «не существует», пока не позвонит разгневанный клиент.
3. Разрыв контекста: Тяжело сопоставить события в БД с событиями в файловой системе.

💡 Как навести порядок штатно:

Многие забывают, что в D7 уже есть полноценная поддержка стандарта PSR-3. Не нужно изобретать велосипеды или сразу тащить Monolog:

* Используйте `Bitrix\Main\Diag\Logger`: Это штатный механизм. Вы можете настроить разные логгеры (файлы, syslog) для разных модулей прямо в .settings.php.
* Забудьте про `AddMessage2Log`: Это легаси-путь. Современный подход — получать логгер через Logger::create('имя_канала').
* Контекст решает: Штатные логгеры позволяют передавать массив контекста. Пустая фраза «Ошибка оплаты» бесполезна. Передавайте ['orderId' => 123, 'user' => 45], и Битрикс сам разложит это в читаемый вид (или в JSON, если настроите `JsonLinesFormatter`).
* Безопасность прежде всего: Никогда не храните файлы логов внутри DOCUMENT_ROOT. Даже если вы назвали файл log_hidden_123.txt, его можно подобрать или найти через индексацию. Храните логи на уровень выше корня сайта. Если это невозможно — закройте директорию через .htaccess или настройки Nginx.

🎯 Золотое правило: Логи — это инструмент мониторинга, а не свалка «на всякий случай»

Лайфхак: В .settings.php можно настроить логгер так, что он будет писать ошибки в разные файлы в зависимости от уровня (например, debug.log для всего и critical.log только для проблем, требующих срочного реагирования). Это позволяет не тонуть в мусоре при разборе полетов.

#bitrix #битрикс #logging #PSR3 #разработка #совет_на_обед #D7 #clean_code

Битрикс × ИИ: OpenAI: GPT-5.2

Сегодня прогнал 2 модели: Grok Code Fast был очень быстр, но сгенерил аццкую жуть с require_once файлов классов внутри модуля. Остановил его на полпути - там править бесполезно.

Следующим был запущен OpenAI GPT-5.2 — новый рекордсмен по качеству кода, но с очень дорогим «процессорным временем». Модель выдала отличные 94 балла за качество (89 в итоговом зачете), филигранно реализовав сложные вещи вроде шифрования кук (CryptoCookie) и синхронизации кнопок в JS.
Однако за интеллект приходится платить: 14 минут на генерацию, 4 итерации правок и стоимость в $1.20 за задание.

Вердикт: GPT-5.2 — это «хирург» для сложных архитектурных узлов и проверки безопасности. Но основной «рабочей лошадкой» по-прежнему остается Gemini 3 Flash: по соотношению цена/скорость/результат она всё ещё вне конкуренции

Подробный разбор на сайте: https://bxmax.ru/bitrix-ai/openai-gpt-52

В ближайших планах: Claude Sonnet 4.5, Gemini 3 Pro, Kimi K2 и Claude Haiku 4.5

🔥 От хаоса к контролю: как ServiceLocator в Bitrix спасает от спагетти-кода и позволяет управлять зависимостями

Я джва месяца писал!.. И добил-таки)

О чём статья

Практическое руководство по ServiceLocator в Bitrix — от проблемы до решения. Разбираем DI-контейнер фреймворка, три способа регистрации сервисов, autowire и типичные ошибки.

Что узнаете

- Как работает ServiceLocator и чем он лучше new
- Три способа регистрации: className, constructorParams, constructor
- Автоматическое разрешение зависимостей через рефлексию
- Интеграция с компонентами, агентами, событиями
- Антипаттерны, которые превратят ваш код в спагетти

https://bxmax.ru/blog/bitrix-servicelocator-di-advanced-guide

Исходники демо-модуля в первом комментарии.

Буду рад фидбэку в комментариях!