SF 4.1 does not server static images properly (404 error)

We just tried installed SF4.1 and ran into issues displaying static images (see attached). Only images generate the 404 errors. The images are in /images folder and the project stopped working correctly under both Visual Studio and IIS7.

I'm having the same problem on multiple sites. Images that are served up from css and the images are under app_data folder display ok, but the simplest html like <img src="/images/test.jpg"/> gives a 404 error.

It would also appear that SF 4.1 has broken my jquery scripts that previously worked file in 4.0, still need to investigate more as to what's going on here but it worked fine before the upgrade and broke after, the only thing I did was upgrade.

There's gotta be a simple fix for this because if this is intended behaviour or a bug that missed testing someone needs to be fired for sure!

I know everyone at Telerik is probably exhausted but would love a fix for this one asap!

Regards,
Phill

Static image files work fine when served out of anything except an "images" folder in the root.  The "images" folder is used in URLs for serving Image content, so I imagine the changes under the hood with the virtual path provider are responsible for this.  Anyway, I hope there's a simple way around this.  :)

The route handler which  serves images, documents and videos from the Sitefinity libraries detects the request to the image containing /images in the path and tries to find the file in the images and documents. Since it does not find it there it throws 404.

I would suggest that you use the approach mentioned by Michael

Hello,

Using a dir such as /img/ instead of /images/ does work.

Thanks
-Noah

You've got to be kidding me!!! "images" has to be the most commonly used name for a folder to store images when building a site and you're now telling me that I can't use it anymore because you decided to hard code it into your image handler?? I have to update master pages, embedded widget templates (find and replace won't work here), user controls, css files and who knows where else across multiple sites???? Not to mention that I have to re-educate clients to tell them they can't use a folder called "images" even though they've used a folder like that since the beginning of the internet?

Seriously this has to be a joke! I can zip up 3 sites, all templates and databases so you can do it for me if you think this is a realistic fix and you can also contact my clients to tell them why they can't use this folder.

So common, what's the real fix here, one that actually makes sense in the world of web development.

So far SF 4.1 is one step forward and 2 steps back for me. I have upgrade 3 sites and none of them are working yet...

Phill

I sadly am also on 3 attempted updates with 0 working :/. One was volatile so just blew it away and created a new project...that all worked great... ;). I'm not going to try anymore, killed too many hours tonight.

Hi Steve,

“Images” is the default root mapping for images stored in Sitefinity’s Libraries module. In version 4.1 the Sitefinity’s virtual paths cannot match with physical paths for Libraries. This is necessary for performance reasons. To avoid this conflict you have to rename the physical folder or change the virtual root in Libraries configuration. To change the configurations please go to:~/Sitefinity/Administration/Settings/Advanced>Libraries>Images>UrlRoot  and change the value to something like “sf-images”.

Sorry that we missed this from the release notes - we will make it a KB article.

Dear Georgi

Is there  a way you change the default for the next SP

~/Sitefinity/Administration/Settings/Advanced>Libraries>Images>UrlRoot  and change the value to something like “sf-images”.

Or will this cause to much trouble for those who have not amended before starting the project. Otherwise this 'error/problem' will carry on for generations :-)

Markus

@Georgi

I am not sure if your tip realy is the best ever.

See image. Run into problems.

Deleted the one and only image and uploaded again - not showing.

Markus

@Georgi, I agree with Markus. This fix may allow for images to be stored in images folder but it also breaks all images already stored in albums. So what's the second part of the fix? Why do you allow users to change settings that don't actually update the data? You can't actually expect someone to change a setting and then to have to start their entire site from scratch each time can you?

Still struggling to get a single site upgraded to 4.1 so I have no idea if there are any improvements as I keep running into problems.

Issue is extremely critical at this point. I'd like to see a complete and tested and various configurations solution.

Hi,
I changed ~/Sitefinity/Administration/Settings/Advanced>Libraries>Images>UrlRoot to "sf-images" but the images are not showing up. Am I missing something?

Georgi,

I also agree with Markus.  I'm fortunate enough to be dealing with a site that isn't live yet so I didn't run into the same error he did, but seeing that Sitefinity assumed "images" for its default location worries me.  Am I going to be running into other unnecessary issues like this when upgrading in the future?

I realize assuming defaults like this helps those using Sitefinity out of the box, but working around Sitefinity's assumptions has been a nightmare as a developer.

Hi Jeff,

Alright guys - do you have any suggestions what URL can be reserved for Sitefinity library images? It can be something like sf-images, sf-documents, library-images?

Dear Georgi

1) sf_ or sf- would be fine with me

Since sf_ is used in the tables you could argue

a) It is consisten to use sf_
b) it would be better to use sf- to distinguish

2) I think a change is defenitely needed away from images. Just make sure its a smoot transaction and/or bring it as early as possible so the mess would be as small as possible.

Kind regards
Markus

@Georgi, I'm glad you're reacting to this fast as I think this is a serious issue, it could be minor now but down the road you'll get endless support requests from people wondering why their images folder doesn't work. I'm also fine with the "sf-" or "sf_" prefixes. It may not be possible but I think an even cleaner solution would be to differentiate by having everything through a filtered parent folder. So all images (and videos, docs and any future items that might be allowed in a libary) are always served from a special SF library folder. So instead of having /sf-images/imagename.jpg you'd have "/sitefinity/images/imagename.jpg" or even better "/library/images/imagename.jpg" with "library" being the only reserved folder/file name. This would allow for easy addition of anything else like "/library/pdfs/file.pdf", "/library/videos/file.mov" They would all have a very standard naming convention and no need for customizing folder names as new data types are added.

That's my 2 cents.

Thanks again!
Phill

Is the solution suggested below for changing the virutal root of libraries working in the current Q1, we can't get this to work even after restarting the site? Any ideas?

@AmrElsayed the fix worked for me but it also meant that any images that were stored in libraries were then broken. So it fixed one thing and broke another. They've now updated the knowledge base article with a script for fixing the broken libraries.

See here: http://www.sitefinity.com/devnet/kb/sitefinity-4-x/static-files-are-not-served-from-images-or-videos-folders.aspx

Hope that helps.
Phill

I like Phills idea but would prefer to have it under
sitefinity/libraries

so everything is within the sitefinity folder

What about once the files can be storred on the server instead of the db. Is this something to be considerd now?

At the moment if I am correct they are storred in app_data/Files/Libraries as binary files in 3.7

Regards Markus

PS: I would love the file provieder to save each library in a own folder and the files in real format - mydoc.doc instead of binary.

Thanks Phil, that works.

My understanding is that Sitefintiy 4.1's implementation of the Virtual Path Provider does not allow for same path to be used as both physical and virtual for 'performance' reasons. This leads me to think that there could be issues with using /sitefinity/images or whatever, same way there is issues with 'images' today...

IMO, the Virtual Path Provider needs fixing so folder names are not involved at all.

I am glad a new convention for the default library path is being discussed. I like Phill's idea of using /library/images/ or /sitefinity/images/ as a convention. /library/... is perhaps more straight-forward.

@Georgi, thank you for writing that KB and addressing this. @Phill, thank you for posting the link.

@Pavel

My understanding is not so high as yours but there will not be a sitefinity/images folder. So there would not be a problem. To me having it all under sitefinity makes it a bit more enduser proof. Kind of don't touch anything in the Sitefinity folder.

Markus

@Phill
Thanks for the link

@Georgi
Thanks for the file

@all
Thanks for your engagement.

Markus

I'm starting with a blank SF 4.1 site where I tried setting the UrlRoot for Images to a different path. I tried library/images, and while this seemed to build the path correctly, it 404'd. I tried simplifying and just using images_library for the UrlRoot, but that failed too. In both cases I removed any existing albums and re-uploaded my images. I also tried running the script from the KB article, but no luck.

I am wondering if anyone can confirm what worked for them.

Also, +1 to the physical storage option that Markus suggested. I remember this was discussed previously but I don't recall what was going to happen. There are definitely scenarios when having a physical storage option is useful. Using the real extensions would be important too.

@Will

I think Q2 was the schedule for FileSystem storage (and cloud providers too?)...I have a 300M database so far due to DB storage of PDFs so Georgi please look into some code to allow us to extract that out when the other storage options hit :)

Can anyone confirm if changing the UrlRoot worked for them, and what path they used?

Thanks!

@Will I can confirm the UrlRoot worked for us (we chose sf-images). However, we reverted back and chose to rename the original static 'images' folder  to 'i' and let the Sitefinity module continue use '/images/' because our client already had created about 300 pages and inserted Image module content in them. Because of that the pages content either has to be updated or Image Urls have to be recompiled via script shown in the recent KB article (which did not exist at the time we were working on the issue).

Hope it helps.

Hi,

@Steve - we will have copy/move group operations, so you will be able to move your data between the providers. This is coming in Q2 indeed.

@Pavel - thanks for helping to community members!

@Will - let us know if Pavel's info is sufficient for you to find the issue.

I'm still having issues so I opened a support ticket. Tihomir is walking me through the database and file permissions to see what the problem is. If I think it might be helpful to share the solution I'll post back when we figure it out. Thanks!

I have tried this change  to the url root for image library to "imagelib" and my static images work. However, any existing library images work now. When viewing an album in the backend tools, the images appear as broken image links. If I right click a broken image link and view the image properties, the image url still contains the "images" root instead of "imagelib" as I was expecting. :(

The solution that Phil suggested worked great for me. I've changed the root url for images in the Image Library from "images" to "imagelib" and ran the script he referenced here:

http://www.sitefinity.com/devnet/kb/sitefinity-4-x/static-files-are-not-served-from-images-or-videos-folders.aspx

Kudos Phil

Hey Rick,

Thanks for the follow up. Perhaps everything worked after you restarted the application - we have to add this requirement to the KB article. 

I am glad that you have it working. 

All the best,
Georgi
the Telerik team

@Rick, I'd just like to point out that credit should go to Georgi for this fix, not me ;) I only pointed you to the KB.

the 4.1 sp1 doesn't fix this.  I changed the image url root as instructed but the images still cause 404 errors.

Hello Thelyrist,

Have you restarted the application after the change in the settings, and running the code?
Phil, the kudos is for pointing the right solution at the right time, to the right person :) 

Hello Craig,

Yes, there is a code that should be run, so that the new URLs are updated:

I deleted all the images prior to me making the change to imageslib. After the change I tried image upload again with no success.

Hi Craig,

The Image Upload is not related to this problem. Here, we discuss the serving from a physical directory, named Images.

Could you please post the exact error you are getting, and let us know if the problem is in Libraries, or in the Images from the file system?

I do have the same issue. I am unable to see the images after uploading to the library. When I preview the images got 404 error. I changes the images to imageslib. Help me to resolve this issues.

Well it works fine on local with no issues but it wont on the other server.

@Ishtiyaq are you using the FileSystem provider to store them?

I have attached the Files you clearly see why I am not having the images on another server with same settings. Well runs fine on Local and other server. But really don't why its not working. Please find the attachment and check what Exactly I need to do. I am using images module to upload the images.

Even though this thread is old I wanted to add that the script on the knowledge-base article page does NOT fix/recompile image references inside content block controls in a sitefinity page.