Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Thumbnails do not show up

Go to End

5 Posts   2133 Views


Community Member, 3 Posts

12 December 2010 at 12:30pm

Edited: 12/12/2010 12:31pm

I've successfully deployed SilverStripe 2.4.3 on the following platform:

- PHP 5.3.3 with Suhosin running as FPM daemon
- Apache 2.2.16 connecting to PHP-FPM (essentially this is FastCGI)
- Varnish Frontend Cache

PHP is running as the user owning the files, so there are no permission problems.

However, uploading a new image works, I can even get it when pointing my browser to - so it was uploaded. But thumbnails and resized images do not show up - it seems they never get generated. It won't create the "_resampled" folder, manually creating it doesn't fix it.

I've commented "Deny from all" in "assets/.htaccess" but that only results in a 404 instead of 403 error.

I've tried accessing the URL as .htaccess should rewrite it, this also results in a 404 error.

I've enabled dev mode, it makes no difference.

Reuploading the file didn't make a difference.

Even the vendor supplied example image does not work (SilverStripeLogo.png).

I'm new to SilverStripe and it looks very promising, but not getting images to work is a real show stopper. I'm clueless how to debug this further. Please advice...


Community Member, 165 Posts

15 March 2011 at 9:54pm

Edited: 15/03/2011 10:33pm

I'm having what appears to be a similar problem.

I can see the resized images inside the CMS (in the text editor on the page) but they don't actually display on the site.

I can upload images (using the image gallery/dataobject_manager/uploadify/swfupload but the thumbnails don't get generated.

I've set the assets folder to 777 recurring but not even this helps.

What's wrong? I would suspect something to do with the server, but I've already given full permissions on the directory.

What else can I do?

Has anybody else had this problem?

Any ideas? Suggestions?

ADDED: I'm using 2.4.5, the image gallery/dataobject_manager/uploadify/swfupload software is the latest of everything (except the uploadify, which didn't work at all - the tabs weren't active - so I went back to 401 for that).

The problem happens on FF and Chrome and it's hosted on some sort of Linux server, running (AFAIK) suhosin, if that makes any sense.


Community Member, 3 Posts

15 March 2011 at 10:46pm

For some reason, this "magically" resolved itself for me. I hate it when that happenes. My only clue is, it could be a browser caching issue when the browser tried to get the image too early and cached a negative result - or a server side caching issue.

I just tried the next day again, removed the image, reuploaded again - and voilá it worked. I have not tried to upload another image yet, however.

BTW: I'm also running suhosin - I don't think this is the issue because it somehow works for me now. But my setup runs a varnish cache as frontend, with Apache being the backend server. This may explain the caching theory (although this shouldn't happen, I've tried to modify the URL to get around a seemingly cached object URL).


Community Member, 165 Posts

16 March 2011 at 11:48am

Edited: 16/03/2011 11:53am

Thanks for the reply, hurikhan77.

I finally contacted the hosting company, who came back with:

The issue was a configuration option (php_flag) in the .htaccess file that doesn't work on our shared hosting. It has been commented out in the file so it is no longer run.

Hope that helps someone! :)


Community Member, 3 Posts

16 March 2011 at 12:34pm

Well, for me this wasn't actually the problem. This is only an issue if not using the php apache module. I easily discovered that. The problem persisted. But then after all, maybe it was an artifact of exactly this previous problem.