[Bug]: No more possible to install new theme at portal level

[Scippy]

Is there an existing issue for this?

• [X] I have searched the existing issues

What happened?

I've tried to install new theme throught Settings=>Extensions and Manage=>Themes but in both way the result is the same:

• Install from PB menu Settings => Extensions: Theme has been installed to \Portals\_default\Skins\
• Install from PB menu Manage => Themes: Theme has been installed to \Portals\_default\Skins\

It is a issue because throught Settings => Extensions it should install the theme in the path \Portals\PortalName-System\Skins\ Now, to install a new theme at Portal level I have to move it manually to the right folders.

Steps to reproduce?

1. New DNN 9.12.0 installation
2. Install new theme from PB menu Manage => Themes

Current Behavior

The new theme is installed under \Portals\_default\Skins\

Expected Behavior

The new theme sould be installed under \Portals\PortalName-System\Skins\

Relevant log output

No response

Anything else?

No response

Affected Versions

9.12.0 (latest release)

What browsers are you seeing the problem on?

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[mitchelsellers]

@dnnsoftware/approvers correct me if I'm wrong, but I'm 99.9% sure that this was an intentional change years back to no-longer support portal based themes.

[david-poindexter]

@mitchelsellers that was a conscious decision (for security reasons) to remove the portal skins feature as we knew it. However, I am pretty sure it is possible again as of DNN 9.1.1 for a super user to install a site-level theme. I have never used or tried this, but I am pretty sure it is possible again. If my memory serves me correctly, those site themes live in a different folder structure than before.

[david-poindexter]

My apologies for not fully reading the original issue post @Scippy - I think you are correct in what is expected. That rings a bell to me.

[Scippy]

I don't think it's possible that it's intentional. If it were no longer supported, installing the theme at the global level would be a huge limitation. It would mean that if that skin is used for multiple portals, its customization would affect all the portals for which that skin is in use. Furthermore, the skins are also sold with specific licenses for uses in multiple portals on the same DNN installation, what would be the point if the same skin is shared among all the portals?

[mitchelsellers]

Without divulging too much here in the open forum, the conversation/concern about the existing "Site Themes" functionality was that a non-privileged user could upload/update a theme package. These packages contain executable code and are not validated.

I see the concern desire here with multiple themes, but there isn't al imitation that you cannot have many in the global level.

I'm not sure that the theme/configuration process even supports site-level themes anymore. This warrants a deeper dive for those with "Super User" permissions to possibly drop into the /Portals/{PORTALHOME}/skins directory

[Scippy]

The limitation at global level is that I'm no able to install the same skin multiple times. Then using the same skin on multiple portal don't allow me to customize the skin for each portal because any customization it would reverberate in all portal. For design work it is unthinkable that you cannot customize the theme because it is shared among several portals. Otherwise we have to inform all skin vendors that the professional license is useless!

[valadas]

IMO customizing a skin directly is a bad practice, one should make a copy and customize the copy... The copy would have a different name.

[jeremy-farrance]

Now, to install a new theme at Portal level I have to move it manually to the right folders. - Scippy (above)

I believe this is what you should do. DNN still recognizes the appearance of a theme in /Portals/{...}/skins (and /containers), so in your situation, my suggestion is that you have your solution (workaround).

If there is nothing special that the installer used to do that is somehow hard or not obvious when doing it manually (unzip the installer, copy files to the right place(s), read the .dnn manifest for clues), then this seems like a good solution.

@mitchelsellers, @david-poindexter, @valadas, @bdukes - are there plans that DNN v10 or v11 will prohibit (prevent or ignore) the use of themes at the Site (Portal) level?

[david-poindexter]

@Scippy typically, for multi-site themes, we simply update our theme build automation to package up each theme installation package separately (but still install them globally - the packages just have unique names to distinguish usage). We share some code between themes, but for those items that are unique to a specific portal, we use strict naming conventions that are used by our build automation to package them accordingly. That's for more complex scenarios, but most of the time the differences between sites are minimal and do not require this level of effort. For example, it may just be some CSS differences, so we just use specificity within the CSS to handle the differences.

[Scippy]

Thanks everyone for the extensive explanations. Yes ok, I have my workaround but it seems to me that the problem is much more danger than a bug around the skin installation. As I understand it then globally installed skins are safe while locally installed skins are not. Right? If so, it means that now I find myself with dozens of unsafe portals!😱 To solve it, I have to move all the skins and containers from local portal folder to _default global folder by renaming each folders with different names? Is this security issue there even if i am the only host and admin user above all portals?

[mitchelsellers]

As I understand it then globally installed skins are safe while locally installed skins are not. Right? If so, it means that now I find myself with dozens of unsafe portals!

This isn't the actual issue. The issue was that the older functionality allowed NON Super Users to upload Themes (Skins) to the portal specific elements. THIS introduced a risk.

If you are doing it as a host user, it isn't introducing any more risk than normal