Skip to main content

Publishing CSS or JS as Multimedia Components?

Let me start by saying that I am a strong believer that handling, uploading or publishing CSS or JS files as Multimedia Components is bad practice. At the same time I was recently surprised that opinions are actually quite different on the topic. There are people who don't always agree with me, shocker!!!

So I guess the point of this post is just to present the advantages/disadvantages of the two methods and see which you like best. Make that one best practice :)

Multimedia Components

In this approach, CSS or JS files are uploaded into Tridion as MMComponents based on a MMSchema. This is the default way the Dreamweaver mediator handles references to CSS or JS from an HTML (.dwt) document.

  • speed - easy to upload into Tridion, without having to create additional items like Schemas, Components, CTs, PTs, Pages;
  • easy to understand - developers with little Tridion experience understand this approach easier;
  • out-of-the-box - this is the default way the Dreamweaver mediator handles references to CSS or JS;
  • published automatically - when the referencing PT is published, all these MMComponents are published too automatically;

  • not elegant - treating text documents as binaries is an improper solution (binaries are treated like a black box, read-only, cannot be modified, need to be added as Multimedia Types, then added as allowed types in a MMSchema);
  • difficult to modify - MMComponents cannot be edited in Tridion, so you have to download them, modify them in an external editor, then upload them back into Tridion (note that you are forced into using _some_ external editor);
  • no version comparison - Tridion cannot compare MMComponent binaries;
  • overhead in publishing - whenever the referencing PT is publshed, all these MMComponents are published too, which can have bad consequences to publishing performance;

I think this is bad practice because it does not use the Tridion methodology of publishing text documents. In this approach, Tridion is nothing more than an FTP tool backed by a binary repository.

Components, CTs, PTs and Pages

In this approach, CSS and JS files are stored inside a Component text field (multi-line, no RTF). An embedded Component Template on the same Schema is used to output the text field. A Page Template specifies the file extension and outputs all Component Presentations. For each CSS and JS Components, you need a Page using the respective PT and on it, you place the Component with the Component Template.

  • control - this approach gives full control over the CSS and JS, e.g. by allowing image references to be resolved and published from within the CSS;
  • verison compare - possible to use because we are now dealing with textual representation;
  • publishing performance - CSS and JS are not published automatically when the referencing PT is published, therefore there is no performance degradation due to this fact;
  • editing capability - CSS and JS Components can be edited inside Tridion GUI (no external tool is needed);
  • follows Tridion methodology - this is the proper way of publishing things from Tridion (i.e. from Schema to Component to templates to Page);
  • elegant - this approach is clean, architecturally elegant, and it implements Tridion properly without cutting shortcuts into development;

  • slower development - this approach is not the default way the Dreamweaver mediator is using and more Tridion items are needed (e.g. Schema, Components, CTs, PTs, Pages);
  • not published automatically - when a referencing PT is published, the CSS and JS it not automatically published, rather a manual publish is needed;

This approach is the best practice.


Neil said…
What about not adding CSS/JS files into Tridion at all! (if you can).

Improved release management - cant forget to publish latest CSS/JS if its not in Tridion in the first place!
Tooling - editing CSS/JS in Tridion is horrible. Via WebDAV slight improvement. Files kept as part of VS solution edited in VS even better!
Cleaner development - all the application files part of VS solution, in source control, no where else.
Control - cant cut corners and publish out a "quick fix" to CSS/JS that could actually break a site in your clients eyes (even if functionally its fine)

Your might have lots of red tape to go through to deploy updates to a PROD server.
Binarybasher said…
Well, not to agree or disagree with either approach, I would still like to add my comment:

1. Automation is dependent upon your implementation, it's not a given. MMC or Text Component it can still be automatically published if required.

2. Tridion has moved the template development from scripts to binaries, allowing VS to be used instead if the Tridion GUI, why do you say toss is not "best practice" for CSS/JS ? I don't believe that is true. (caveat: you can continue to use scripted templates, especially XSLT, but for how long?)

3. I agree with the version comparison issue, but that should be a source system requirement there same add with compiled template assemblies. (you still have Tridion versioning)

4. Scripted CSS/JS gives you the dabble ability, good or bad you decide.

5. "elegant", not sure I would agree, both solutions offer elegance depending on your view... Some prefer modules and blocks, others prefer scripts (beauty is in the eye of the beholder, and all that jazz)

Tridion gives you flexibility and the building blocks to architect your requirements, methods that were good yesterday aren't always good for tomorrow.

You can make any method either work for you or not, but in this particular case I don't believe there is a right or wrong approach, having used both.

I would say, if using the MMC approach then consider publishing as dynamic component presentations, no need for pages as well.

Binarybasher said…
Update (fixed typo's):

2. Tridion has moved the template development from scripts to binaries, allowing VS to be used instead if the Tridion GUI, why do you say it is not "best practice" for CSS/JS ? I don't believe that is true. (caveat: you can continue to use scripted templates, especially XSLT, but for how long?)

3. I agree with the version comparison issue, but that should be a source system requirement the same as with compiled template assemblies. (you still have Tridion versioning)
Mihai Cădariu said…
This is a valid approach too. However for CSS, I would actually prefer to use Dreamweaver or another HTML editor, rather than VS.

Not sure I agree with 'control': you can always cut corners, don't test enough, make mistakes, etc. In this case, a mistake will be harder (take longer) to solve due to the red tape you mention.
Mihai Cădariu said…
Good comments! This proves to me once again that this is a hot topic.

My main issue with JS/CSS as MMC is the misuse of types. Why put a text file inside a binary format? With this rationale we could consider everything being a binary file. This is what I don't find elegant.

Not sure I understand #2 -- do you mean scripts as in old school VB/JS scripts? We still have DWT including its Expressions Language that generates the output, which is ultimately still a script.

Finally, I don't think publishing MMC JS/CSS as DCPs is viable due to the fixed file extensions they have when published. For this to work, we would need some deployer/storage extensions or dynamic CD code to include them into the HTML.
Nivlong said…
Regardless of approach, I think buy-in also depends on an organization's existing processes and especially on who "owns" these files.

In situations where Web and CMS development are consolidated (e.g. my Tridion VM), I'd want styles and script centrally located. But if we have distinctly separate developer and designer teams, I can see why JS/CSS as MMC is appealing.

If treating JS/CSS as text in Tridion, I'd recommend at least training or some automation that lets designers work in ways that are familiar to them. Maybe a simple script that "pushes" local dev changes to the DEV CMS (check time stamps, read files, create corresponding components, etc), for example.

Then Tridion could remain a "black box" to designers, chief editors can control releasing page and maybe design changes, and developers/IT get managed web-related files in Tridion.

Popular posts from this blog

Running sp_updatestats on AWS RDS database

Part of the maintenance tasks that I perform on a MSSQL Content Manager database is to run stored procedure sp_updatestats . exec sp_updatestats However, that is not supported on an AWS RDS instance. The error message below indicates that only the sa  account can perform this: Msg 15247 , Level 16 , State 1 , Procedure sp_updatestats, Line 15 [Batch Start Line 0 ] User does not have permission to perform this action. Instead there are several posts that suggest using UPDATE STATISTICS instead: I stumbled upon the following post from 2008 (!!!), , which describes a way to wrap the call to sp_updatestats and execute it under a different user: create procedure dbo.sp_updstats with execute as 'dbo' as

Content Delivery Monitoring in AWS with CloudWatch

This post describes a way of monitoring a Tridion 9 combined Deployer by sending the health checks into a custom metric in CloudWatch in AWS. The same approach can also be used for other Content Delivery services. Once the metric is available in CloudWatch, we can create alarms in case the service errors out or becomes unresponsive. The overall architecture is as follows: Content Delivery service sends heartbeat (or exposes HTTP endpoint) for monitoring Monitoring Agent checks heartbeat (or HTTP health check) regularly and stores health state AWS lambda function: runs regularly reads the health state from Monitoring Agent pushes custom metrics into CloudWatch I am running the Deployer ( installation docs ) and Monitoring Agent ( installation docs ) on a t2.medium EC2 instance running CentOS on which I also installed the Systems Manager Agent (SSM Agent) ( installation docs ). In my case I have a combined Deployer that I want to monitor. This consists of an Endpoint and a

Debugging a Tridion 2011 Event System

OK, so you wrote your Tridion Event System. Now it's time to debug it. I know this is a hypothetical situtation -- your code never needs any kind of debugging ;) but indulge me... Recently, Alvin Reyes ( @nivlong ) blogged about being difficult to know how exactly to debug a Tridion Event System. More exactly, the question was " What process do I attach to for debugging even system code? ". Unfortunately, there is no simple or generic answer for it. Different events are fired by different Tridion CM modules. These modules run as different programs (or services) or run inside other programs (e.g. IIS). This means that you will need to monitor (or debug) different processes, based on which events your code handles. So the usual suspects are: dllhost.exe (or dllhost3g.exe ) - running as the MTSUser is the SDL Tridion Content Manager COM+ application and it fires events on generic TOM objects (e.g. events based on Tridion.ContentManager.Extensibility.Events.CrudEven