Unconditional mtime update on parent media item when saving related properties
Forum rules
Always add your TYPO3, Aimeos and PHP version as well as your environment (Linux/Mac/Win)
Spam and unrelated posts will be removed immediately!
Always add your TYPO3, Aimeos and PHP version as well as your environment (Linux/Mac/Win)
Spam and unrelated posts will be removed immediately!
Unconditional mtime update on parent media item when saving related properties
Hello Aimeos Team,
We are working with Aimeos 25.4.1 in a TYPO3 13.4.13 environment and have encountered a behavior with mtime updates that we would like to clarify.
Our Goal:
We have an asynchronous image processing system that is triggered by changes to a media item's mtime. This works perfectly for direct changes to the media file itself. However, we also need to trigger this process when a media item's related data, such as its properties (media.property), changes.
The Observation:
We've noticed that when saving a product, the mtime of any associated media item is updated on every single save, regardless of whether the media item or its properties have actually changed. This triggers our image processing unnecessarily, causing significant overhead. This behavior only occurs if the media item has at least one property attached to it.
Our Analysis:
After digging into the core code, we believe we've pinpointed the source of this behavior in the Aimeos\MShop\Common\Manager\Base::saveBase() method, specifically around this logic:
// in Aimeos\MShop\Common\Manager\Base::saveBase()
if( !$this->isModified( $item ) ) {
return $this->object()->saveRefs( $item );
}
Our investigation suggests the following sequence of events:
When saving a product, a media item object is loaded.
Its properties are set on the object, likely via a set('media.property', $propertyCollection) call.
The Aimeos\MShop\Common\Item\Base::set() method compares the new property collection object with the existing one. Due to how PHP handles object comparison (==), this comparison often evaluates to true even if the content of the properties is identical.
This marks the media item as "modified" by calling setModified().
Consequently, in saveBase(), isModified() returns true, causing the entire save logic to execute, which includes an unconditional update of the mtime field.
The Aimeos\MShop\Media\Item\Standard::saveRefs() method is empty, confirming that the property saving logic is handled elsewhere, reinforcing our theory that the isModified() flag is being set prematurely.
Our Question:
Is this unconditional update of the parent media item's mtime—even when only its properties are saved without actual changes—the intended and expected behavior?
If it is intentional, could you please explain the reasoning behind it? This would help us design a proper and efficient workaround.
If this is not the intended behavior, would you consider it a bug? We believe a more precise change detection mechanism within the Item::set() method (e.g., comparing a canonical representation or "fingerprint" of properties instead of the objects themselves) could resolve this.
Thank you for your time and clarification. We appreciate the great work you do on Aimeos.
We are working with Aimeos 25.4.1 in a TYPO3 13.4.13 environment and have encountered a behavior with mtime updates that we would like to clarify.
Our Goal:
We have an asynchronous image processing system that is triggered by changes to a media item's mtime. This works perfectly for direct changes to the media file itself. However, we also need to trigger this process when a media item's related data, such as its properties (media.property), changes.
The Observation:
We've noticed that when saving a product, the mtime of any associated media item is updated on every single save, regardless of whether the media item or its properties have actually changed. This triggers our image processing unnecessarily, causing significant overhead. This behavior only occurs if the media item has at least one property attached to it.
Our Analysis:
After digging into the core code, we believe we've pinpointed the source of this behavior in the Aimeos\MShop\Common\Manager\Base::saveBase() method, specifically around this logic:
// in Aimeos\MShop\Common\Manager\Base::saveBase()
if( !$this->isModified( $item ) ) {
return $this->object()->saveRefs( $item );
}
Our investigation suggests the following sequence of events:
When saving a product, a media item object is loaded.
Its properties are set on the object, likely via a set('media.property', $propertyCollection) call.
The Aimeos\MShop\Common\Item\Base::set() method compares the new property collection object with the existing one. Due to how PHP handles object comparison (==), this comparison often evaluates to true even if the content of the properties is identical.
This marks the media item as "modified" by calling setModified().
Consequently, in saveBase(), isModified() returns true, causing the entire save logic to execute, which includes an unconditional update of the mtime field.
The Aimeos\MShop\Media\Item\Standard::saveRefs() method is empty, confirming that the property saving logic is handled elsewhere, reinforcing our theory that the isModified() flag is being set prematurely.
Our Question:
Is this unconditional update of the parent media item's mtime—even when only its properties are saved without actual changes—the intended and expected behavior?
If it is intentional, could you please explain the reasoning behind it? This would help us design a proper and efficient workaround.
If this is not the intended behavior, would you consider it a bug? We believe a more precise change detection mechanism within the Item::set() method (e.g., comparing a canonical representation or "fingerprint" of properties instead of the objects themselves) could resolve this.
Thank you for your time and clarification. We appreciate the great work you do on Aimeos.
Re: Unconditional mtime update on parent media item when saving related properties
Not intentionally. This is a side effect in the code but it's not required and we can change it in the next version.
It's a bit different. It all relates around the modified flag of the media item, but adding/removing properties doesn't set this flag: https://github.com/aimeos/aimeos-core/b ... Traits.phpdaan wrote: ↑16 Jul 2025, 10:32 Our investigation suggests the following sequence of events:
When saving a product, a media item object is loaded.
Its properties are set on the object, likely via a set('media.property', $propertyCollection) call.
The Aimeos\MShop\Common\Item\Base::set() method compares the new property collection object with the existing one. Due to how PHP handles object comparison (==), this comparison often evaluates to true even if the content of the properties is identical.
This marks the media item as "modified" by calling setModified().
Consequently, in saveBase(), isModified() returns true, causing the entire save logic to execute, which includes an unconditional update of the mtime field.
The Aimeos\MShop\Media\Item\Standard::saveRefs() method is empty, confirming that the property saving logic is handled elsewhere, reinforcing our theory that the isModified() flag is being set prematurely.
Nevertheless, there's one call "$mediaItem->set('property', [...])":
https://github.com/aimeos/ai-admin-jqad ... d.php#L362
This is due to the array that is handed over to fromArray() whose properties are all added to the item, even if not saved afterwards and using unset($entry['property']) fixes the problem.
There are other places which causes an mtime update, e.g. for the product item itself and all list items due to setConfig() and setConfigValue().
Professional support and custom implementation are available at Aimeos.com
If you like Aimeos,
give us a star
If you like Aimeos,
