New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

DNN 6.1 JS/CSS File Combination: Potential Gotchas

Recently I wrote about how DotNetNuke 6.1 introduces exciting new ways for developers to manage CSS and JavaScript. The release represents a significant first step in optimizing the client side impact of the framework by focusing on reducing the number of requests using dynamic page-based resource combination.

This release represents a large shift in the strategy for delivering JS and CSS resources to the client. While this is undoubtedly a net-positive to both DNN developers and users, there is also a bit of a learning curve, an adjustment period, and a few strategic changes to make along the way to insanely great performance.

File Combination

File combination is not a technique that is unique to DotNetNuke by any means. It is a common technique that is used to provide flexibility during development, and performance in production. The key to any file combination strategy is that all of a given resource type (e.g. JS or CSS) are combined with each other and output as a single file to the client’s browser.

This is the strategy that DNN 6.1 has largely adopted throughout the core framework. Let’s examine some characteristics and gotchas to be aware of when combining files.


When combining JS files, we’re primarily concerned with syntactical errors. What if one of the JS files we combine isn’t formatted correctly – and it ends up breaking another file that was loaded below? Now that these previously separate chunks of JavaScript logic are living in the same file – they can certainly have the opportunity to impact one another.

First, I’d like to address the root cause of this, before we talk about how to alleviate any potential problems after the fact. Always make sure you check your JavaScript for potential errors. There are plenty of tools out there to help you make sure your code is formatted properly. Of them all, I’d probably recommend JSHint. Just paste your code in there and run it through. Fix any glaring syntactical errors, and perhaps investigate any deeper recommendations the tool makes. It’s often an excellent opportunity to learn more about JavaScript.

But in a DNN world, we don’t explicitly control every JavaScript file loaded on our website (some are core, some third party and some may be custom) – so what about the case where someone makes a rogue syntactical mistake that impacts other JavaScript files when combined? Well, the underlying framework that’s being used in DNN 6.1, the Client Dependency Framework, takes care of that for us by delimiting each combined JS file with a semicolon, so as to effectively block any rogue JavaScript from impacting logic further on down the line.


So, we’re feeling pretty good about JavaScript, but what about the impacts of combining CSS? This topic is actually of more immediate importance in DNN, as most CSS files for a module or skin (module.css, skin.css) will automatically be included in this new system in DNN 6.1. The old RegisterStyleSheet method is now forwarded to the new API, so the file combination benefits for CSS happen upon upgrade. But there are two primary things I’d like to call attention to – as they may potentially have an impact on existing sites that are upgraded to DNN 6.1

The first is rogue multi-line comments. If a CSS file opens a multi-line comment and doesn’t close it out –it will start commenting out the next files CSS when combined. While adding a comment delimiter between file contents for CSS (similar to what is done with JavaScript) may be the best idea in the long run, DNN 6.1 does not include any features of this nature. So we should probably validate our CSS as much as possible to avoid any issues like this! Good thing the W3C has a handy CSS Validation Service to help us.

While the other gotchas I’ve listed have focused on syntactical issues – there is a potential strategic difference that I’d like to call attention to as well. CSS @import statements are used to help structure code when developing but to ease simplicity of file registration. For example you could create multiple CSS files, each with very focused and reusable logic, and @import them in other CSS files as appropriate. However, this example is sub-optimal from a performance perspective because the browser is still making multiple requests for these files.

In addition, @import statements are only considered valid by a browser if they are at the top of the CSS file. So if they are in the middle – they are ignored. This has significant implications when we combine the @import strategy and the file combination strategy – it could mean that @import statements are rendered ineffective depending on where they end up in the combined file.

Subsequent releases of DNN should include the ability to replace the @import statements with their actual file contents when combining files; however we were not able to get that enhancement in place for DNN 6.1.

Disabling file combination

If you run into any issues with file combination, you do have the ability to disable that specific feature altogether. This will preserve all of the other features gained by use of the new API, but will disable the file combining only.

To do so, you will need to edit values in the web.config. Specifically, find the clientDependency "fileRegistration section. Each one of the providers listed (DnnBodyProvider, etc) allows for enabling or disabling file combining. Each are enabled by default. To disable, simply change “enableCompositeFiles” to false for each provider.




While the new Client Resource Management API offers some very compelling benefits, it does also represent a very notable shift in the strategy for delivering CSS and JS content. There may be a few bumps along the road, and an adjustment period, as with any significant changes, but being aware of potential challenges and knowing your options are very important! Please let me know in the comments if you have any questions or concerns.


Bruce Wayne
It would be nice if I could just disable this feature for individual JS and CSS files that I do not want to include in the concatenated output file instead an "all or nothing" approach.
Bruce Wayne Thursday, May 7, 2015 12:40 PM (link)

Comment Form

Only registered users may post comments.


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Daniels (3)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (37)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (213)
Chris Paterra (55)
Clint Patterson (108)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (181)
Daniel Valadas (48)
Dave Buckner (2)
David Poindexter (12)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (80)
Francisco Perez Andres (17)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (4)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (2)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (40)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Patricio F. Salinas (1)
Patrick Ryan (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott Schlesier (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Tony Henrich (3)
Torsten Weggen (3)
Tycho de Waard (4)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (180)
William Severance (5)
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out