I've always wondered if there's a "preferred" way to manage CSS and Javascript files in Tridion. I have mine (do whatever is best for the customer's requirement) but maybe there's some kind of "best practice" that I am not aware of.

So, should I store the css and js within Tridion or managed them (deploy them) using a different mechanism? Should a treat them as binaries or content?


6 Answers 6


I'm not sure there is a correct answer here... i think it's based on the client needs.

Here's an opinion...

It's now possible to store binaries in the broker database, it makes a great case for managing them in the CMS, so that external 'consumers' (development teams, partner websites, load balanced machines, etc) can consume / store these files and receive instant updates when published.

If you store files outside of the CMS, you'd have to ensure your local 'consumers' are constantly receiving the latest files and manually deploying them to the file system.

  • 1
    Whilst I agree - to a certain extent with some comments regarding code being in code repositories I think the answer to this should rely more on the real client requirements and not how a technical team may traditionally manage these 'technical' files (note I wouldn't make this same comment on c# files etc!). One additional case to Johns comment above is where the assets used within these files need to be Content Managed and thus related to the files directly. Using binary publishing we can easily achieve this for the client. Commented Dec 4, 2013 at 15:11

I agree with John that it would be based on the clients needs, but also in relation to what development and deployment model you have chosen.

When looking at the different implementation options, I like the simplicity of having HTML in your (DWT) Templates and then often will go for Publishing CSS and JS as Pages (personally hate the idea of using Multimedia Components for them). In one of my last workshops I showed two options for that:

  1. Using a Component with a single Text field for the JS, so you had the option to combine multiple JS scripts (as Component Presentations) on a single JS Page.

  2. Using a Page Template for the CSS, the CSS was directly in a DWT TBB, and all the image links are resolved by the default TBBs (so using a single PT per CSS file and an 'empty' Page to Publish it).

But while this works in a training and demo very well (also is easy to explain to people), I would not necessarily choose that model for a large production website. When looking at that, you probably choose a web application model, say for instance DD4T and there you deploy CSS and JS as part of your web application, so it will stay completely outside of the CMS.

  • I agree with you Bart, I like your option 2 especially since the best practice is to limit the number of CSS files referenced by a given web page for minimum number of HTTP requests, it means that the Tridion implementation would only contain a manageable number of "Css Pages". Publishing the Css and javascript files from Tridion also has the advantage that you can leverage publishing templates to minify them. Commented Dec 3, 2013 at 17:23
  • Not so sure that the default templates will do. Mostly, the people responsible for CSS will work only reluctantly in the CM, and they will want to avoid doing more than pasting code unmodified from their sample site on disk, so your image references are going to be wrong. It's easy enough to manage, just not with the default templates. Commented Dec 3, 2013 at 21:50
  • @DominicCronin If you have your image references work in your CSS editor, and upload them via WebDAV to a similar location on your CMS, it will all work with the Default Templates. This is also demonstrated in the 2013 SP1 Getting Started guides (requires login) although there the CSS is considered a binary, but the image references in the Page are resolved as I mention (and that will work for CSS too). Commented Dec 4, 2013 at 8:48
  • @PhilippeConil indeed, a benefit of managing them through Tridion is that you can do post processing (like minification) at publishing time. Although strictly speaking that is also an option you have available when you manage them outside of Tridion. I've seen it done in a post build step of Visual Studio on a DD4T site too. Commented Dec 4, 2013 at 8:51
  • Interesting - so you can get your image references done by the default templates, even if you are (correctly!) storing your css as text? Commented Dec 4, 2013 at 9:54

Here is the logic that I use with clients (and chiming in with what Alvin said):

C# is code, therefore belongs in a code repository (e.g. SVN). Java is code, therefore belongs is a code repository. SQL scripts is code, therefore belongs is a code repository. .... should I go on?

So what makes JavaScript or CSS any different? It is code that also needs to be tested and debugged.

The biggest reason that clients ask to keep JavaScript and CSS in Tridion is to bypass their IT's painfully slow Release Management processes. They want quick and timely front-end updates, for example to Marketing promotions, without having to wait 3 weeks. But relying on the Deployer to get this "code" released to Production without a full-on Release Management Process is a cheat (otherwise you wouldn't need the process), otherwise they would simply get FTP access to Production Presentation Servers. So I always caution clients that if they want to store CSS and JS in the CMS, then there are serious risks they need to consider and mitigate.

  • Definitely. You'll see this preference in places where front-end development is fast and "free," IT resources are expensive, and speed trumps code testing. Commented Dec 4, 2013 at 3:50
  • This. We put our JS and CSS in minified now. As if they're DLLs. I don't think you should be able to edit these in Tridion. It's not source control or an editor. Commented Dec 4, 2013 at 6:42

I'd personally keep them outside Tridion because both Javascript or CSS files do not really relate to the content managed in the CMS, specially when using a framework such as DD4T


I think Bart and John did a good job explaining the mechanisms of how to deal with CSS/JS. I want to chime in regarding whether to publish them as binaries or not.

I am a strong believer that you should not store CSS/JS as binaries (i.e. Multimedia Components). I don't think it's the right way. The whole contention point starts with the way these assets are created by Tridion when using the Dreamweaver a.k.a. WebDAV connector to upload a DWT TBB that refers to CSS/JS/Image assets. While it makes a lot of sense to store images as MMCs (doh!), I see it as a shortcut to create MMCs also for JS and CSS.

This is great demo material and it shows how easy it is to import your existing HTML markup & related files into Tridion. However, there is a lot of effort ahead to make it a content managed solution. That includes creating Schemas and CTs for JS/CSS or PT and DWT TBB (as presented by Bart).

On the other hand, if you consider it's too much work creating all these items, especially if you won't manage or modify the CSS/JS within Tridion, then probably it's best not to store it in the Content Manager in the first place (as John suggests).

A few points why it would be beneficial to have JS/CSS in Tridion and in textual representation:

  • editable - treat them as content and edit them in Tridion;
  • publishable - easily updatable by publishing to all targets and all destinations simultaneously;
  • manage related items - the JS/CSS and all the images it uses can be published together;
  • minification - grouping several JS Component Presentations in one Page makes it easier to minify it;

Considering the fact that you need script and styles all across DTAP (Dev, Test, Acceptance, and Production), JS and CSS files should probably follow the same development processes as application code.

The biggest benefit to placing these in the CMS is the "managed" part, which echoes Mihai's points:

  • History
  • Versions and comparisons
  • Publishing and unpublishing at will
  • Where Used

You only get text-based comparisons if these are actually text in the CMS. But I'm not quite sure multimedia or even code components are the best solution either.

Ideally we'd have:

  • CSS and JavaScript (front-end) developers using IDEs and tools they're most comfortable with on text-based files
  • Editors and/or developers responsible for releasing design/theme/style changes in control of those releases

So maybe if you can get a .css and .js as a text-based "item type" (doesn't exist, right?) in the CMS, you can make a new best practice.

Tweak your setup of people, process, and technology enough and you can legitimately break any of the rules in the name of business needs. Promos, for example, break all the rules and may include everything from custom code, custom stylesheets, and never-updated content (in forms with hundreds of fields). :-P

  • 1
    Normally JS and CSS are kept in a version repo like SVN or TFS, and most version repos have version history (obviously) and diff options, so they would be managed outside of Tridion as well. Commented Dec 4, 2013 at 3:01
  • 1
    Do most implementations feel "normal?" ;-) Commented Dec 4, 2013 at 3:47

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.