Apex Code Development You need to sign in to do that
Don't have an account?
alphacap Can't access files in a zipped static resource
We've been struggling with getting a zipped static resource to work for weeks now. We got Salesforce Support involved from the beginning, but they've gotten us nowhere. If we can't get a resolution to this issue soon, we might just find a platform that wastes less of our time...
Here is the situation - we are trying to upload a portion of the YUI library as a static resource, but no matter what we try, we can't get the files to render in our VisualForce pages. Salesforce Support can get it to work (sometimes), but we can't. The difference seems to be around the MIME Type that is set when the file is uploaded. When we upload the file, it gets set to a MIME Type of 'application/zip', but when SFDC Support uploads the file, it gets set to a MIME Type of 'application/x-zip-compressed' or 'application/octet-stream'. Salesforce can't explain to us exactly why or how these different MIME Types get set. They're looking into why our uploads don't work, but I'm not expecting much from them at this point.
To reproduce our steps:
- Download "Full developer kit"
- Open zip and remov the documentation and examples folders (to reduce size)
- Change file name from "yui_3.0.0.zip" to "yui.zip"
- Upload as a static resource named "testyui"
- In component "header" (where all other JS files are included) add:
- <apex:includeScript value="{!URLFOR($Resource.testyui, 'yui/build/yui/yui-min.js')}" />
- If we refresh the page we get a 404 error for this resource.
Hi,
I followed the steps you outlined below exactly and my static resource uploaded as application/zip into static resources. When using the includeScript tag and URLFOR, I got the following JS include in my code:
I am using XP / Firefox 3.5. So it seems to be working for me - are you trying to do something else with the static resource after loading like calling functions, drawing content areas etc? If you want to post the full code for the page you working on with the YUI, I can take another look.
-- Matt
Interestingly, I just Tweeted having this same issue http://twitter.com/dlog/status/7732034243
No idea what's causing uploaded ZIP files to have a MIMEType of application/octet-stream , but it's preventing use of resources in my markup as well.
I'm using WinRAR to zip the files. When you "Open zip" in step 2, what utility are you using?
I wonder if the static resource uploader is getting confused by file headers (not necessarily HTTP headers)?
-Mike
This is apparently still an open issue. I switched to another laptop using Firefox and static resource uploads of ZIP files are still getting tagged as MIMEType application/octet-stream.
Anyone else having this problem or know of a consistent workaround?
-Mike
I do not believe the different mime type is causing a problem. FWIW, the static resource uploader just saves whatever the browser told it for the mime type. So the differences you are seeing depend on browser or browser settings.
But accessing the static resource should work regardless of the mime type specified, as long as the file is in fact a valid zip file and the path you specifiy is correct.
The most common problem with zip file static resources are either corrupted files (e.g. binary files that have been copied as test files at some point), or incorrect paths (e.g., some zip file creation processes include the root directory name as part of the path and some do not).
On this issue I've discovered that:
a) The zip MIME type is only retained when using IE8 (Chrome not at all. Firefox is inconsistent)
b) Only zip MIME types can be packaged. So 'yes', URLFOR will still work but the files cannot be packaged.
-Mike
Cubic Compass and aballard thanks for your replies. We've continued to press the issue with Salesforce Support since we are still experiencing inconsistent behavior with Static Resources. They are finally taking it to the R & D team now that we've finally convinced them that the problem is not us but rather an issue with the platform. We'll post an update if/when we get a conclusive answer.
(Sorry for the delay in replying, for some reason we aren't getting email notifications from replies to our posts despite having email notificaitons turned on for our DFC account)
Any updates on this one? We're still running into errors accessing files in zipped static resources using the direct URL
(e.g. https://na7.salesforce.com/resource/1267226345000/CampaignsAddOnStyle/main.css )
If uploaded to SF using Firefox, the mime type is set to application/x-zip and cannot be accessed from Chrome. If uploaded in Chrome, the mime type is set to application/zip and cannot be accessed from Firefox.
Thanks,
- Ron
I think you need to enter support case, if you haven't already.
As mentioned previously, the mime type really shouldn't be relevent, since the VF code that extracts elements from zip files pays no attention to it. Something else is going wrong.
I know this thread is fairly old, but I had this same issue and figured out what the problem was. I was using a .zIp file as a Static resource, with a .jpg as the file I was looking to display on a Visualforce page. The file could not be identified unless the EXACT file name was identified in the code. (I had been using .jpg, and my file was named .JPG). Once I changed the name, it worked. Hopefully this will help if you are having a similar issue!
Dan Sweeney
Etherios
<apex:image value="{!URLFOR($Resource.SiteSamples, 'SiteSamples/img/customlogo.png')}" />
Spent about 2 hours trying to get this working for a client and by trial and error got it to work (in the NA7 server, uploaded with Chrome for Mac).
Hope that helps someone out there!
Sounds like there is an error in the help text (where did you see this? -- I just looked through the doc and it all looks correct to me)
But whether you need the "first folder" in the path depends entirely on how you produced the zip file. You need to use the path name of the file as it appears in the zip. That may or may not include the folder from which the file came. You can produce it either way with most zip tools.
There was indeed a typo in the component reference documentation for <apex:image>. I forget if it was an extra "$" or "!", but if you copied and pasted from there, it would have bitten you.
It's fixed in the next release of the docs.
This solution worked for me.
I had the same problem with the resources, I realized that I had changed the zip name and when you reference the file from static resources, you also have to reference the parent folder.
IE:
I have "jQueryUI.zip" on my Desktop which unzips to "jQueryUI" folder.
I thought that the import should be
<apex:includeScript value="{!URLFOR($Resource.jQueryUI, 'js/jquery-ui-1.10.3.custom.min.js')}"/>
However, you have to reference the parent folder "jQueryUI"
<apex:includeScript value="{!URLFOR($Resource.jQueryUI, 'jqueryUI/js/jquery-ui-1.10.3.custom.min.js')}"/>
For example, if I compress the folder:
This code will give a 404 error on the Visualforce page:
<apex:stylesheet value="{!URLFOR($Resource.resources, 'css/form.css')}"/>In this case, the tag should be:<apex:stylesheet value="{!URLFOR($Resource.resources, 'resources/css/form.css')}"/>But if you compress the files directly:You can use:
<apex:stylesheet value="{!URLFOR($Resource.Archive, 'css/form.css')}"/>that will work.