RFC: Theme & Container Selection Using Multiple Themes

[mitchelsellers]

Description of Problem

In the current Theme/Container selector you are only able to select themes & containers from the same theme pack. Prior to DNN 9.x it was possible to use a Themes and Containers from different theme packs. This was important in enterprise applications that setup "shared" packages. Consider this example.

The site has the following structure inside of the /Portals/_default folder

/Containers
/Containers/CompanyAContainers <- This contains multiple containers such as H1, H2, H3, etc.
/Skins/SiteATheme <- This contains the theme for this site
/Skins/SiteBTheme <- This contains the theme for a different site
..etc

In prior versions of DNN. you could set site/page defaults to use /CompanyAContainers - H1 as the container and you could pick any of the themes as well

Current behavior

This has a dual impact in regards to behavior on sites using DNN 9.x depending on the nature of the site.

• If the site was upgraded, everything works, until you save Page Settings or Site Settings. Then the first container from the selected theme will automatically override the old value
• If the site is new, you just can not select/use the other containers

Proposed Solution Option 1

I would propose that users be allowed to select the "Theme Package" or otherwise, within the Containers section to support the use of hybrid themes.

This would be needed on "Page Settings" as well as "Site Settings"

Current Workaround

The current workaround requires the usage of database queries to find/edit the values directly.

Alternatives Researched

The only real alternative is to identify that this feature is not desired, and create a recommendation for people to change their processes.

Affected version

9.0.0 and later

[david-poindexter]

I agree 100% and would support your proposed solution.

[valadas]

I also agree with this solution

[MaiklT]

Well I never use a container that is not in the skin package, but I see there is a need for this. This may raise problems (eg skin loads some JS library that is needed by the container, but as there is a different skin and the JS package is not provided it may fail). Anyway, I don't see a reason for not providing this functionality, as it has always been there - therefore I agree with Mitchel's solution.

[worldheadquarters]

i have sets of containers that are generic - will work and look good with multiple skins. With the current setup, I have to alter the skin/theme package for each theme that I want to use containers with to include the same, redundant set of containers. having only one copy would be much more efficient.

[sleupold]

in theory, DNN separated module containers from page skins. However, there are many situations, where style definitions for module containers are part of the skin.css, defined in Skin.css of the package. Mixing containers from different theme packages would not result in appropriate solutions. And whatever you do, the containers for the default skin are always listed. Especially for novice site admins, it would be useful, limiting the choice of module container just to a selection provided by the designer.
As a short term solution, I would add a button to the container choice "Include containers from other packages".
in the long term, we should move skins and containers to a new folder /themes and associate by metadata in the database (e.g. register all designs and reference it in skins and containers table - and allow containers to be "neutral", if they don't interfere with any skin an its CSS.

[valadas]

The behaviour is still possible in the API (seen multiple times with upgrades) so I guess this boils down to a UI issue and moving it the AdminExperience