Pimcore 2026.3.1: five fixes that affect ownership costs

Pimcore released the 2026.3.1 point release without headline features. It allows object versions to be stored in different storage systems, speeds up asset loading, and adds sanitization to the class generator's descriptions.

Releases like these show what a data platform costs to run in production.

The full list of changes is published in release on GitHub.

Five changes from the release notes define its substance: -

A separate version store can be configured for each element type (object, asset, or document). Change author: @mcop1, PR #19504. -

Asset uploads now include an option not to create a version (PR #19433, author @cancan101). -

applies to cover transformations where positioning is not configured (PR #19470).

The update note for this was moved to 2026.3.1 (PR #19505). -

The class description is sanitized when the model's PHP class is generated (PR #19478, security section). - CI reports a conflict with phpunit 13.4, which Codeception does not yet support (@mcop1).

Additional maintenance branches have also been moved to 2026.3.

The release contains no new entities or rewritten subsystems.

Every save of an object or asset in Pimcore creates a version.

Consider a catalog with tens of thousands of SKUs and daily imports from 1C or ERP: over time, it can accumulate millions of versions.

These are serialized data and file copies that almost no one opens.

They are stored on the same disk as active assets and included in the same backups.

Version storage by element type makes it possible to separate these flows.

Object versions are small and frequent, while asset versions are large and rare.

Different storage media and retention policies can be selected: objects on fast storage, and versions of large files in object storage.

The option to skip version creation when uploading an asset solves a related problem: bulk photo uploads no longer create unnecessary copies.

The release includes no savings measurements, so the percentage reduction cannot be stated in advance.

The mechanism is straightforward, and you can test it on your own catalog in a day: calculate the share of versions in total storage before and after.

defines the area of the image that must not be cropped.

For a cover transformation without configured positioning, each transformation previously had to be configured manually or the images had to be edited.

The point is now taken into account even without explicit positioning.

For an online store, this reduces content managers' manual work for every new banner format.

The time savings depend on the number of formats and images in circulation.

A hypothesis to test: with a catalog containing hundreds of formats, the difference is noticeable during the first storefront update cycle.

Pimcore generates PHP model classes from definitions edited in the admin interface.

The class description is written to the generated file, and without sanitization the comment field could have become a code injection point. This change closes that entry point.

The takeaway goes beyond this single change: any user input that the platform turns into executable code is part of the attack surface.

Permissions to edit class definitions should be granted as cautiously as deployment access.

If content editors or contractors have them, review them regardless of the update date.

A point release like 2026.3.1 rarely makes it into plans: there is nothing to show management.

Yet releases like these determine the total cost of owning the platform.

They determine how much space versions use, how many hours are spent manually editing images, and who can safely receive access to model configuration. At KT.Team, the support branch is updated on a schedule for Pimcore projects.

Once a quarter, take the latest point release, run regression tests for the catalog and imports, and review what changed in storage and security.

A planned quarterly cycle costs less than an emergency update after an incident, while the risk of each step remains low.

We build the same regular procedures into Pimcore integrations with 1C, Akeneo, and ESB buses.

Seemingly simple operations rely on dull, repetitive tasks.

The release shows where maintainers of a mature platform invest their effort: version storage, generator security, and test compatibility.

If your update plan has no entry for point releases, technical debt accumulates and will surface in the storage bill or a security incident.

Check the volume of versions in production this week.

This check is cheaper than all the others and will show whether you need separate storage.