function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
alphacapalphacap 

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 the file from here after clicking the radio button labeled "Full developer kit":

Steps:
  1. Download "Full developer kit"
  2. Open zip and remov the documentation and examples folders (to reduce size)
  3. Change file name from "yui_3.0.0.zip" to "yui.zip"
  4. Upload as a static resource named "testyui"
  5. In component "header" (where all other JS files are included) add:
    • <apex:includeScript value="{!URLFOR($Resource.testyui, 'yui/build/yui/yui-min.js')}" />
  6. If we refresh the page we get a 404 error for this resource.
 
If anyone has experienced a similar issue, any help you could provide would be greatly appreciated.
mattdarnoldmattdarnold

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:

 

<script src="/resource/1263409248000/testyui/yui/build/yui/yui-min.js" type="text/javascript">

 

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

Mike LeachMike Leach

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 
Mike LeachMike Leach
... FWIW I'm working on NA7, which appears to have some other subtle bugs (like this one) that I'm not seeing on other orgs.
Mike LeachMike Leach
OK. Using Firefox to upload static resource ZIP files appears to be the workaround (I was using Chrome).
Mike LeachMike Leach

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

 
aballardaballard

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). 

 
Mike LeachMike Leach

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 
alphacapalphacap

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)

Ron WildRon Wild

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

 

 
aballardaballard

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.  

 
DanSweeneyDanSweeney

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
timNimtimNim

<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). 

 

  1. The help text has the URLFOR and Resource both having an "!" .  It should only go on the "!URLFOR" not the Resource parameter. 
  2. Include the name of the first folder in the path

 

Hope that helps someone out there!
aballardaballard

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. 

 
Alderete_SFDCAlderete_SFDC

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.
Sky KSky K

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')}"/>

 
Andrew B. DavisAndrew B. Davis
The most common reason for getting a 404 error trying to access a file inside a zipped static resource is that you're not using the right syntax, or don't have the filename exactly right. Nevertheless, we just experienced an issue where we had valid references to files inside a zipped static resource and they started returning 404 errors after one update to that static resource. We tried a variety of fixes and were able to determine that the individual components inside zip file static resources are cached and de-duplicated by Salesforce, so that Salesforce does not have to store 1,000 copies of jquery.js from 1,000 customers. Salesforce encountered some problems with one or more of the files that were in our zipped static resource with the result that any zipped static resource that included those files would return 404 errors for all it's contents (even if the files were re-named and put individually into new static resources). The resolution for us was to make minor changes to the constituent files and then re-upload them, this way Salesforce recognized them as being changed files. Any zipped static resource that contains the original versions of those files is still broken, and we're reporting this to Salesforce support. 
dbrucedbruce
Back to the original post in this thread, I've got a similar problem. On my PC the folder zips to application/x-zip-compressed whereas it zips to application/zip on my colleagues mac. My workaround is to give the folder to her to zip and upload.
Wladimir BotonWladimir Boton
I had a similar problem and the solution was to select the files and archive instead of archive the folder that contains the files. 

For example, if I compress the folder:
User-added image
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:
User-added image
You can use: 
<apex:stylesheet value="{!URLFOR($Resource.Archive, 'css/form.css')}"/>
that will work.




 
Charles ThompsonCharles Thompson
[@Wladimir Boton]  You got it!  That got me out of a hole.  Thanks.
Charni WigginsCharni Wiggins
@Wladimir Boton Thank you so much - also got me out of a hole! 
Cem Kolukisa 2Cem Kolukisa 2
@Wladimir Boton I would have never thought that would be the solution in a million years, thank you for helping me out!