Pimcore 2026.3.1: пять мелких правок, которые решают цену владения

Pimcore выпустил точечный релиз 2026.3.1 без громких функций. В нём версии объектов можно хранить в разных хранилищах, загрузку ассетов можно ускорить, а генератор классов начал санитизировать описания.

Такие релизы показывают, во что обходится платформа данных в продакшене.

Полный список изменений опубликован в релизе на GitHub.

Из заметок релиза пять изменений определяют его содержание: -

Для каждого типа элемента (объект, ассет, документ) можно задать своё хранилище версий. Автор правки: @mcop1, PR #19504. -

При загрузке ассета появилась опция не создавать версию (PR #19433, автор @cancan101). -

применяется к трансформациям типа cover, где позиционирование не настроено (PR #19470).

Заметку об обновлении для этого перенесли в 2026.3.1 (PR #19505). -

Описание класса санитизируется при генерации PHP-класса модели (PR #19478, раздел security). - В CI зафиксирован конфликт с phpunit 13.4, пока Codeception его не поддерживает (@mcop1).

Ещё ветки обслуживания переведены на 2026.3.

Новых сущностей и переписанных подсистем в релизе нет.

Каждое сохранение объекта или ассета в Pimcore порождает версию.

Возьмём каталог на десятки тысяч SKU с ежедневными импортами из 1С или ERP: версий в нём со временем набираются миллионы.

Это сериализованные данные и копии файлов, которые почти никто не открывает.

Они лежат на том же диске, что и рабочие ассеты, и попадают в те же бэкапы.

Хранилище версий по типу элемента позволяет разделить эти потоки.

Версии объектов небольшие и частые, версии ассетов тяжёлые и редкие.

Для них можно выбрать разные носители и политики хранения: объекты на быстром диске, версии крупных файлов в объектном хранилище.

Опция пропуска версии при загрузке ассета решает соседнюю задачу: массовая заливка фотографий перестаёт создавать копии, которые никому не понадобятся.

Замеров экономии в релизе нет, поэтому процент сокращения объёма заранее назвать нельзя.

Механизм при этом понятен, и проверить его на своём каталоге можно за день: посчитать долю версий в общем объёме хранилища до и после.

задаёт область изображения, которую нельзя обрезать.

Для трансформации cover без настроенного позиционирования раньше приходилось вручную настраивать каждую трансформацию или править картинки.

Теперь точка учитывается и без явного позиционирования.

Для интернет-магазина это снижает ручную работу контент-менеджеров на каждом новом баннерном формате.

Выигрыш в часах зависит от числа форматов и картинок в обороте.

Гипотеза для проверки: на каталоге в сотни форматов разница заметна уже в первый цикл обновления витрины.

Pimcore генерирует PHP-классы моделей из определений, которые редактируются в админке.

Описание класса попадает в сгенерированный файл, и без санитизации поле комментария могло стать точкой внедрения кода. Правка закрывает этот вход.

Вывод шире одной правки: любой пользовательский ввод, который платформа превращает в исполняемый код, входит в поверхность атаки.

Права на редактирование определений классов стоит выдавать так же осторожно, как доступ к деплою.

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

Точечный релиз вроде 2026.3.1 редко попадает в планы: показать руководству там нечего.

Но именно такие релизы определяют цену владения платформой.

От них зависит, сколько места занимают версии, сколько часов уходит на ручную правку изображений и кому безопасно давать доступ к настройке моделей. В KT.Team на проектах с Pimcore ветку поддержки обновляют по расписанию.

Раз в квартал берём последний point-релиз, прогоняем регрессионные тесты каталога и импортов и смотрим, что изменилось в хранении и безопасности.

Плановый квартальный цикл обходится дешевле аварийного обновления после инцидента, а риск каждого шага остаётся небольшим.

Те же регулярные процедуры мы закладываем в интеграции Pimcore с 1С, Akeneo и ESB-шинами.

Простая на вид эксплуатация держится на скучных повторяющихся операциях.

Релиз показывает, на что мейнтейнеры зрелой платформы тратят силы: хранилище версий, безопасность генератора, совместимость тестов.

Если в вашем плане обновлений нет строки про point-релизы, технический долг копится и проявится в счёте за хранилище или в инциденте с безопасностью.

Проверьте объём версий в продакшене на этой неделе.

Эта проверка дешевле всех остальных и покажет, нужен ли вам раздельный сторадж.