We have been plagued with missing / disappearing images on Pages. Simply put, the SRC attribute of the IMG element points to an image that does not exist. Here's what's in common:

+ Images have been uploaded to a subdirectory (or sub-subdirectory) of assets/Uploads using the "Files and Images" interface.
+ Images are added to Pages using the Image icon of the TinyMCE editor (one which opens the right sidebar to allow selecting of an image)
+ Images are sized, and thus have a SRC attribute of "assets/directory/_resampled/[resample_recipie]image.jpg

The images appear to the content editor, but magically get deleted sometime down the road. We are actively developing the site, and thus often running "/dev/build" as well as "?flush=1" on the front AND back-end.

Silverstripe version is 2.3.3 w/ the following extensions;

Auth_External, Dataobject Manager, Embargo Expiry, Google Analytics, Google Sitemaps, SWF Upload, and Userforms

I believe that this has been an ongoing problem since the onset of development. As a workaround, we have been backing up the assets directory every 5 minutes... and periodically restoring it. The resized image files ONCE DID exist...

I'm not sure what's causing this? Perhaps the flushing.. perhaps the user visiting the "Files and Images" (there's a HUGE AMOUNT of images in the "unused" tab).. Perhaps the dev/build??

The assets directory is owned by web user. Of note is that it appears a sudo-exec bit is set on folders that have been created?

e.g. "drwxr-sr-x 2 www-data www-data 4096 2009-11-09 00:34 _resampled"

Any ideas would be a huge help!

Thanks

I just did some more poking around in the filesystem. We have an Elvis Presley image that has "disappeared". The URL is:

assets/Uploads/Posters/ResizedImage110151-Elvis-Presley.jpg

looking into the filesystem, there's an Elvis image, but with a different name:

assets/Uploads/Posters/ResizedImage200274-Elvis-Presley.jpg

and the 1105151 image is NOT THERE. It does exist in our backup snapshot however...

Perhaps this provides a clue? Also -- perhaps the image is referenced somewhere else (e.g. on another page) and has been resized there also? I'll test this locally.

UPDATE: after testing, SS does indeed handle resizing the same image in multiple places.

I once read about a way to flush the images/assets folder - but I can not find it again. The problem described seemed similar though... But since I am not working with Silverstripe that long I might be totally mistaken.

yurigoul,

Thanks for the lead - the command is "http://yoursite/images/flush". This gives a very interesting result;

When I run the above on the SERVER, I get:
"0 formatted images from 0 items flushed" as a response after it runs for @ 10 seconds.

When I copy the database and assets directory, and run the above locally, I get:
"3378 formatted images from 2581 items flushed"

I disabled PHP's max_execution_time on the server, and still get the same results.

Any ideas? Perhaps this is the issue?

Following this thread....

This problem does exist : I noticed the exact same problem on 1 live site , twice.

Since I could not find a way to reproduce it , I just ignored it and repaired the content.

Fuzz,

Do you still have access to these servers? I am curious if "/images/flush" responds with "0 formatted images from 0 items flushed" vs. an actual # of images that have been reformatted / resized.

Yeah.. I still have access...

I'll try tomorrow, because I'd like to make a backup before I try that (I'm at home right now)... Have never flushed the images before and don't want any unwelcome results ... ;-)

Or are you absolutely positive that flushing the images will not break anything ? ;)

Fuzz,

I haven't lost any images during image/flush -- but have done a backup each time we have run it. I definitely recommend a backup first :) -- and wouldn't want to be responsible for any data loss. Then again, if you want to live dangerously -- by all means.