21293 Posts in 5733 Topics by 2602 members
|Go to End||Next >|
10 November 2009 at 5:36am Last edited: 10 November 2009 5:38am
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!
10 November 2009 at 5:48am Last edited: 10 November 2009 6:10am
I just did some more poking around in the filesystem. We have an Elvis Presley image that has "disappeared". The URL is:
looking into the filesystem, there's an Elvis image, but with a different name:
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.
10 November 2009 at 5:49am
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.
10 November 2009 at 6:09am
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?
10 November 2009 at 8:00am
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.
10 November 2009 at 8:44am
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.
10 November 2009 at 9:11am
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 ? ;)
10 November 2009 at 9:47am
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.
|Go to Top||Next >|