Pimcore 2026.3: Three Small Changes That Affect PIM Pricing

Pimcore released version 2026.3.0 (release on GitHub).

There are no headline features in the changelog.

The developers added co-author data to object versions, provided a workflow slot for custom extensions, and moved the thumbnail cache lifetime into configuration.

If a company has a Pimcore catalog with tens of thousands of products, this list deserves close attention: these changes will affect the cost of maintaining PIM three years from now.

Pimcore stores each object's history as versions. PR #19235 adds co-author information to each version.

A product card is usually edited by several people.

The integration imports attributes from 1C, the content manager writes the description, the AI generator adds SEO text, and the category manager changes the price and images.

When a marketplace error is found in a product attribute, the first step is to determine where it came from.

If the history records only the last person who saved the product card, the team reconstructs what happened from chat messages.

Our interpretation (not stated in the release notes): version co-authorship makes it possible to distinguish the contributions of a person and a model.

This is needed for quality control in projects where a model generates item records.

When it is clear which fields the agent filled in, validation is configured only for those fields, so the editor does not reread the entire product card.

A workflow in Pimcore describes an object's lifecycle.

Statuses (draft, enrichment, review, published) are called places, permitted transitions between them are transitions, and actions available in any status are global actions. PR #19237 adds a shared `custom_extensions` slot to all three entities. Statuses almost always need their own data: stage completion time, responsible role, and whether an AI check is mandatory before publication.

Previously, they were stored alongside the workflow in a separate configuration file or bundle, and each update required checking that they still matched the process.

This data now resides in the `custom_extensions` slot directly in the process definition, and Pimcore itself supports this format. Here is an example from our practice.

Before moving to “publication,” the product card is checked through the LLM & Security Gateway: the model compares the description with the attributes and looks for contradictions.

“Check required” flag

is now recorded in the transition itself, so a separate settings table is no longer needed.

Pimcore generates thumbnails from source images and delivers them with HTTP caching headers. PR #19255 makes this cache lifetime configurable.

In a large catalog, this small setting makes a noticeable difference.

Product photos change once a year: a long cache lifetime reduces requests to the Pimcore server and speeds delivery through the CDN.

Banners and promotions change weekly: a short cache lifetime ensures that buyers do not see an outdated promotion. Previously, separating these scenarios required rewriting headers at the web server or proxy level.

The release also includes a refactoring of GEE log parsing (Generic Execution Engine—the Pimcore engine for background tasks such as exports and bulk operations).

We expect long-running job logs to become easier to read and incidents to be investigated faster. We will verify this with real exports.