I am managing a website which require frequent changes(mostly front end). So i put component links in metadata of structure group and pages for css/javascript. A page called "meta" for designers is provided to publish all css/js files in broker. At presentation server each page render css/js from metadata of its parent structure group and the page itself.

can some let me know if this approach is good or it may results any critical issue in tridion because my each page request is using broker query for css/js.

Or i should go with some other approach?

  • Manoj, it would be useful to describe the business requirements - for example, do all CSS and JS files have to be published together (it seems they are published together above?), are these published as rendered pages/binaries - is there a specific business requirement being fulfilled in the selected method? Your description above infers all sections (SGs) have their own CSS - is that 'additional/theme' CSS or a complete version of CSS? - I agree with Rob that it's very interesting but would be interested in understanding the business req before denoting something a 'good' appriach Dec 8, 2013 at 10:12
  • 1
    @Dylan..MarkSaunders yes Dylan each section can have their own css/js. so that any change related to design/theme of any section or whole website(using Home SG) can be achieved by just make the change in css of that particular section(SG). Dec 8, 2013 at 17:10
  • @manoj - it's been a while since you asked this question, could you document your solution or the thoughts you've had an if one of the answers here helped, can you accept it :)
    – johnwinter
    Dec 19, 2013 at 0:52

3 Answers 3


Certainly an interesting approach.

You should read about the Tridion Object Cache and also consider caching in your application for the Broker query to retrieve the CSS/js.

I don't think it will cause a critical issue in Tridion as it sounds to me like you're using standard API calls. You just need to consider how you will handle high traffic in your application. DD4T requests all pages from the broker and performs extremely well due to a smart caching strategy.

I suggest load testing it using something like Apache Jmeter to see how it performs without caching and with caching before going live.


There's nothing wrong with the approach, if the client requirement(s) need these items to be delivered / stored in this manner. I've seen scenarios where development teams are able to spin up a new environment and not have to worry about dropping site assets in the correct place etc which makes a lot of sense. I also like the idea of having the version of SDL Tridion to have the ability to view file revisions.

I recently did some work using the DD4T binary distribution module, essentially this file writes the files from the file system so there's no need to worry about caching the content from the broker. The tool does a check to see the date/time of the file in the broker and keeps the local files updated as necessary.

I feel this being the best approach for this type of storage, essentially use the broker database for storage, but binary distribution to the file available on the local machine for faster serving of content. The code for Binary Distribution can be found here, even if you're not using the dd4t framework, or even .net i'm sure you can re-create the same inside your own web application, following this example.

  • That's a cool idea. Dec 9, 2013 at 11:51
  • 1
    +1 John it's not an uncommon pattern and if it achieves the client requirements then it's a reasonable approach indeed. Dec 9, 2013 at 16:50

First be sure to read considerations on CSS/JS as multimedia in: "What is the best way to manage Javascript and CSS withTridion (2011/2013)?." :-) Here are points on XPM, publishing, and your template logic.

Possible issue with XPM

The biggest issue I've had with multimedia for CSS is having the CSS blocked in IE for Experience Manager. I'm not sure it was a browser security or configuration problem, but be sure to check these binaries are delivered with the right mime type.

Publishing approach?

Aside from performance considerations that the other address, you also have to consider how you will publish these. Since they're in metadata,addbinary() or publishing them independently (with their "dynamic" component templates) are your main options (I don't think metadata links are automatically resolved, but check "items to publish" to be sure). I describe the basic publishing propogation scenarios in this post.

Confirm logic and handle duplicates

John Winter actually taught me a nice scenario that looks for, and removes duplicate CSS files, at different contexts (the queued page, template metadata, structure group metadata, etc) before adding a consolidated set to the rendered page. You may want to confirm what to do with duplicates in this sense as well as same-named multimedia files (which isn't necessarily a unique problem to your approach).

Functionally, I like the (recursive) fall-backs that come with this approach. You can quickly control a website section (SG) but have flexibility at the page level. Just be wary of abuse. :-)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.