I started on an update to one of our modules for DotNetNuke this week, and was surprised to see many of the administrative pages looked like they had no styles applied to them. Tables were jumbled, with no differentiation between header and or row content; things just didn’t look right.
As I tried to adjust some of those styles, I came to realize that the issue was, in fact, a change in the behavior of DNN. While before, when I accessed a control in the admin directory of my module, the module.css file in that directory was referenced; now the module.css in the main folder of my module was referenced (that is, previously DesktopModules/MyModule/admin/module.css was referenced, but now /DesktopModules/MyModule/module.css is referenced).
After some digging, I figured out that the change happened in DNN 4.9.0 (the latest version) and found mention of it in DotNetNuke's Issue Tracker. So, now, the moral of this story. Starting in DotNetNuke version 4.9.0, only the module.css in the main folder of a module is referenced, regardless of where the control being loaded lives (unless there isn't a module.css there). Therefore, you only need one module.css to control the styles of all of your controls. This is great news from a maintainability standpoint.
However, if your modules still need to support versions before 4.9.0, we need to figure out how to manage this relationship. It seems obvious that, to support 4.9.0, we need to combine all of our stylesheets from whatever folders they may be in currently, creating one stylesheet for all our controls in our module’s root folder (I used CleanCss to combine them and remove duplicate styles).
Now, after the obvious choice, we have to face the less-obvious choice of how to provide those same styles on pre-4.9.0 sites. My first instinct was to remove all content from the module.css in my admin folder, and replace it with an import to the main module.css, that is @import url('../module.css')
. This may work, but I wasn’t sure if the browser would cache that reference, and it seemed wrong to have to load two files just to get to the real one. What I ended up deciding was to create a Post-Build Event in my project to copy module.css from my module’s root folder into the admin folder (which looks like copy $(ProjectDir)module.css $(ProjectDir)admin/module.css
).
Hopefully this provides you module developers with a good guideline for what’s going on and how to deal with it when you come across your modules acting like they’ve never heard of this “stylesheet” you keep telling them about.