We have a Managed Package that works with the Community product and so has a site template. The components and controllers for the template are going to be marked Global to allow clients to create their own site template (for the purpose of modifying images and styles referenced in the site header/footer).

The idea is, there is a static resource that provides the standard theme content the product comes with (CSS, JS, Images) and if clients want to modify it they will have access to an copy of the resource which they can work with their own developer to modify. Once the client copy of a resource is appropriately modified, clients then clone the Site template we provided and include their own variable naming the appropriate static resource.

Obviously it would be nice to provide ways for clients to more declaratively brand the product but it seems like a questionable investment in development resources at this time. Also, providing declarative ways to do this would seem to require a number of custom settings and storage/naming conventions - which at some point would be more convoluted than simply modifying your own resource (IMO).

Alternatively, I've considered making the Static Resource more flexible by turning all of it's components into VF pages. On the PRO side, it would make changing style at least minimally more natively editable (via the page editor), AND you can then use dynamic linking between VF pages to provide dynamic linking between theme components. CON - this all seems more like a 'cool trick' than a sound approach (of course tricks are fun :)

  • Pages involve extra CPU time and possibly bandwidth. I'd advise against pages unless the clients might need dynamic styles, etc. On the flip side, static resources come from a different domain, so CORS could affect scripting. Should you use pages, make sure you enable caching.
    – sfdcfox
    Apr 14, 2015 at 18:23
  • thanks @sfdcfox, definitely would need to enable caching. Given it's a universal asset I figure its worth the one time cost of loading it on login. I was concerned about CORS with the Static Resource, I actually had a tough CORS hurdle in prior role creating integration between eLearning Modules with a custom Salesforce rest service (fixed thanks to advice I got from @metadaddy! ). But right now everything is working, even in deployed test org Community with its own domain...so far. Still am leaning towards former solution for now, then more declarative in v2 Apr 14, 2015 at 21:01
  • Follow up note - turns out the theme we picked only uses 4 colors so I'm going to replace just the css page with a VF component and use 4 settings to allow client customizations to those colors. We're also going with a few images that can be swapped out, otherwise they'll have the option to replace the entire resource with a modified clone (at their own peril). Apr 15, 2015 at 14:10

1 Answer 1


If you're just looking to theme your template (i.e. CSS and images only), you should be able to avoid having the subscriber clone the actual VF Site Template and instead just provide a configuration option for them to select which StaticResource they want injected as a stylesheet.

public MyTemplateController{
  public String getCustomResource(){
    return MySetting__c.getInstance().CustomResource__c;

<apex:page controller="MyTemplateController">
  <apex:stylesheet value="{!$Resource.DefaultResource}/>
  <apex:stylesheet value="{!$Resource[customResource]"/>
  • Thanks @daveespo - super simple, we started our discussion on branding in a different place (settings for everything vs. total customization of the resource) so I think I missed the obvious. Guess we tighten it up one step more and just do a post install script to fill in the 'StaticResource' custom setting with the name of the default (Package) resource - then we could leave that single dynamic include in our managed header component. Apr 15, 2015 at 15:36
  • We include our 'base' stylesheet and then include the user-defined one below it so that it overrides our base styles. That way, we can add more styles in the future and it will fall back to our defaults unless the user overrides it with their own selectors. Having said all that, if you know that there are really only going to be a few customization spots, giving the user full latitude with CSS might make your life difficult down the road when they get clever and introduce selectors with more specificity that preclude your defaults from working. Custom Settings might be better for that reason
    – daveespo
    Apr 15, 2015 at 17:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .