When approaching a design in DotNetNuke, I often think about how to best translate the design into DotNetNuke skins not only to match the original comps but also allowing people to minimize the administrative time when building or updating their content.
One of the main reasons most people pick a content management system (CMS) for their web projects is to take advantage of the content editing without having a tech savvy resource in-house. But did you know if your design is being developed not using the optimal approach could lead to a more time consuming process of managing your website content?
I have seen many times when clients showed me a way they implemented or made changes to their content using the purchased commercial skins and it was time-consuming.
In this article, I’d like to show you a small development tip to enable site administrator to seamlessly implement their content with some minimal administrative effort. This approach only works with ASCX skinning but you’ll find the end results quite rewarding if you are comfortable working with ASP.NET scripts.
So let’s take a look at a common content building scenario. A few sites we built for our clients have a large campaign area on the homepage similar to what we have on ours here. But the banner graphic is different across from page to page. When they drop an HTML module on the campaign area and want to display HTML content without using the module title, they’ll have a few options to hide that module title as followed:
- Manually set the display of the container to none under ‘Module Settings’ by un-checking the ‘Display Container’ checkbox
- Or create a NoTitle container to use so the content only display the body of the container
The above approaches required site editors to navigate to the ‘Module Settings’ to accomplish what they want on all the instances of their modules. Luckily, there is a better way of doing it. By using the following method, you’ll be able to set the default container for the campaign area to have no title used without having to configure the module manually in any way.
Let’s take a look at a simple line of markup that makes up a DotNetNuke pane:
Now let’s set a default container for this ‘CampaignArea’ pane by using:
What it All Means
- ContainerType: indicates the location of the container package within your DNN instance. You have two options:
- L: is the location of the skin package on a ‘Portal’ level regardless of ‘PortalID’
- G: is to tell DotNetNuke to always look into ‘_default’ directory for this container package.
- ContainerName: this is the name of the container package. In this example, proLogic is the container package name associated with the skin package called proLogic
- ContainerSrc: is the actual container file you want to use. In this example, I use NoTitle.ascx as a default container for the CamapignArea pane.
So when site editors drop a module (any module) on the 'CampaignArea', DotNetNuke will automatically pull the right container that is default to this pane. For those pages that don’t require using the NoTitle container, site editors can override the default setting by navigating to ‘Module Settings’ and specify a different container. So this option isn’t a complete control over which container to use for the pane but rather saving you time by setting a default option.
Another appealing reason of taking this approach when developing DotNetNuke skin is that it can help protecting the design integrity. Since skin engineers apply certain CSS definitions to the default container of a specific pane, site editors more like aren't going to mess with "Module Settings" it if it looks right the first time they add modules on those panes.
Think of many use case scenarios in your implementation approach, this can help reducing the administrative time dramatically for site editors and increase productivity on managing and maintaining content of your websites.
NOTE: to take advantage of this approach, make sure you know the installation method you use (whether it's installed as Host or Admin)on your DNN instance. If your skin package is installed at Host level (inside the ‘_default’ folder) and your skin file indicates the location of the container package as ‘L’, it will not render that container but rather loading the default container of the site.