Accessing Local Static Resources from a Managed Package

Question

I keep seeing conflicting information about whether this is possible, so hoping the supreme court of StackEx can definitively rule!

I have a managed package that queries a field on the campaign object containing the name of a Static Resource. It then uses a dynamic reference on a VF page to display that SR as an image. In the packaging org, it works great, and in an installed org, it works for any static resource I have include in the package (so is in same namespace). But if I directly load a new SR into my installed org, and add that name, I get an error saying the resource is not found. I can see why a package wouldn't be allowed to access a local SR, but I keep seeing posts suggesting it is possible, so hoping I am just missing a step...

The code is similar to this though I get the resource name from a field on a campaign via a query. If I include KWLogo in the package, I can reference it this way, but if I install the package, upload a local resource called something like KWLogo1 into the target org, and try and reference it on the page, I get a resource not found error:

<apex:page controller="StaticRTest" >

  <apex:image rendered="{!NOT(ISNULL(sImageSource))}" url="{!$Resource[sImageSource]}"/>
  <br/>
  <br/>
  <h1>Congratulations</h1>
  This is your new Page

</apex:page>

public with sharing class StaticRTest {

public String sImageSource {get;set;}

public StaticRTest () {
    sImageSource = 'KWLogo';
}

}

e.g.

This link suggests it can be done (though not how), but this link suggests otherwise?

Answer 1

Yes you can! It is possible to access the resource using a static URL of this pattern

/resource[/timestamp]/YourStaticResourceName

How it will look like exactly in the end depends much on what kind of resource it is (js, css, image and even zipped resources will work) and where you use it.

• in your given use case and for an image it should be <img src="/resource/1402932484000/{!sImageSource}" />
• to include a js in a custom button you go with {!REQUIRESCRIPT("/resource/1402932484000/YourStaticResourceName")}
• or in a visualforce page you can add a script like that <script src="/resource/1402932484000/YourStaticResourceName"></script>
• or for a css it is <link href="/resource/1402932484000/YourStaticResourceName" type="text/css" rel="stylesheet" />
• and if you have a zipped resource you can use the path /resource/1395393292000/jquerymobile130/images/ajax-loader.gif

The numbers in the examples above are optional timestamps. You can also omit them and just go with only /resource/YourStaticResourceName instead of /resource/1402932484000/YourStaticResourceName. If you use the timestamp and create it dynamically (e.g. via JS) you can prevent old versions from being used out of the browser's cache. This is useful if you update the resource and want to make sure that everyone immediately get the most recent version without clearing the browser cache.

This approach is not perfect, since Salesforce may change the URL-pattern at some point in the future. But it's stable for years now and even if it would be changed, it's very easy to fix.

In my opinion there is a bunch of use cases, where this approach could bring you a great flexibility and additional value - even if the platform-architects may have had a more separatistic philosophy in their minds.

But unless someone comes up with a URLFOR()-or-similar solution, you have to ponder the tradeoffs.