This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Forums » General » image path of image attributes -...

image path of image attributes - intended behavior?

image path of image attributes - intended behavior?

Thursday 06 March 2014 7:59:25 pm - 2 replies


I've an article with an image attribute - dfs cluster environment.

I publish the article with an image, version 1.

The image got a path at var/storage and an entry in the cluster table.

Now, I am doing following actions:

I edit the article, change some content, but not the title and the image and publish it.
The image path remains the same.

Now I am editing the article and give it a new name.
The image path is being changed and is including the new name.

Now I am moving the article to a new location:
The image name remains the same as before the moving. - the mtime entry in the cluster table also remains the same.

Now I am uploading a new image to the article:
The image path is changing, includes the new version and the new name.

So, my question:

Why is the image path not being changed when the content is moved to a new location? Is this intended?

I've tested it with ez 4.5.

Friday 07 March 2014 8:38:30 am

All of it sounds about right.

I can't really explain the decisions that led to this, since they wrer taken really long ago, but it matches what I know of this part.

Anything here thate is causing issues, or are you just curious ?

Modified on Friday 07 March 2014 8:42:42 am by Bertrand Dunogier

Tuesday 11 March 2014 9:48:57 am

Quote from Bertrand Dunogier :

Anything here thate is causing issues, or are you just curious ?

Hi Bertrand,

yes, there are some troubles with syncing the storage content.

There is a big site with 18M images (inc. variations). Keeping the production site and the backup site in sync we can't use rsync. It lasts too long and produces too much load.

So, there is a little script which checks the cluster table and copy new entries (checking mtime) to the backup cluster.

If a content is renamed on the production site, we are getting 404 image errors at the backup site because the mtime of the changed image isn't changed too and the image with the new path is missing at the backup system.

All in all there should be a better way managing the sync. of prod and backup system.

So, my original question is wrong. We don't care if the image is not changed. But we care if the path is changed but the mtime isn't.



You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from