[Bug]: Incorrect SkinPath resolution when fallback to default Host popUpSkin.ascx occurs

[thienvc]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

I have identified an issue with how the SkinPath is resolved when the system falls back to the default Host popup skin.

The code logic relies in default.ascx.cs:
public string CurrentSkinPath => ((PortalSettings)HttpContext.Current.Items["PortalSettings"]).ActiveTab.SkinPath;

Dnn.Platform/DNN Platform/Website/Default.aspx.cs

Lines 109 to 111 in 57252ad

	public string CurrentSkinPath => ((PortalSettings)HttpContext.Current.Items["PortalSettings"]).ActiveTab.SkinPath;

This works correctly when the popUpSkin.ascx exists within the Active Tab's assigned skin package. However, if the active skin package does not include a popUpSkin.ascx, DNN falls back to the default Host skin located at /portals/_default/skins/_default/popUpSkin.ascx.

The Problem: In this fallback scenario, CurrentSkinPath continues to return the path of the Active Tab's skin, rather than the path of the Default skin where the popUpSkin.ascx is actually running.

Consequently, any resources (JS/CSS) registered using PathNameAlias="SkinPath" inside the default popUpSkin.ascx will attempt to load from the Active Tab's skin directory instead of the _default directory, resulting in 404 errors.

Steps to reproduce?

1. Prepare the environment: Go to a specific skin folder currently in use (e.g., Aperture) and rename popUpSkin.ascx to something else (e.g., popUpSkin1.ascx) to force the system to trigger the fallback mechanism.
2. Modify the default skin: Open the default Host skin file located at /Portals/_default/Skins/_default/popUpSkin.ascx.
3. Add a resource: Register a test JavaScript file using the SkinPath alias:
   <dnn:DnnJsInclude runat="server" FilePath="popUpSkin.min.js" Priority="130" PathNameAlias="SkinPath" HtmlAttributesAsString="defer" />
4. Trigger the popup: Navigate to the website, enter Edit Mode, and open any popup (e.g., Edit HTML Content).
5. Observe: Inspect the network requests in the browser console.

Current Behavior

DNN attempts to load popUpSkin.min.js from the Active Tab's skin directory (e.g., /Portals/0/Skins/Aperture/popUpSkin.min.js), which results in a 404 Not Found error because the file (and the actual ASCX being used) resides in the _default folder.

Expected Behavior

When DNN falls back to the default popUpSkin.ascx, the SkinPath alias should resolve to the _default skin directory (e.g., /Portals/_default/Skins/_default/), ensuring that resources registered within that ASCX are loaded from the correct location.

Relevant log output

Anything else?

The issue is caused by the execution order in DefaultPage (Default.aspx.cs). Currently, SkinPath is registered inside InitializePage(), which runs before the skin control is loaded and validated.

Since the GetSkin() method handles the fallback logic and updates the PortalSettings.ActiveTab configuration when a fallback occurs, we simply need to defer the registration of the SkinPath alias until after GetSkin() has completed.

By moving the registration line after the GetSkin() call in DefaultPage, the CurrentSkinPath property will correctly retrieve the updated path from ActiveTab (which reflects the fallback skin if one was used).

Suggested Code Change:

To fix this, we need to move the code line this.clientResourceController.RegisterPathNameAlias("SkinPath", this.CurrentSkinPath); out of InitializePage() and place it after var ctlSkin = this.GetSkin();.

In Default.aspx.cs (class DefaultPage):
// Current Logic

Dnn.Platform/DNN Platform/Website/Default.aspx.cs

Lines 225 to 229 in 57252ad

	// set global page settings
	this.InitializePage();
	var ctlSkin = this.GetSkin();

**// Proposed Logic**

// 1. Remove clientResourceController.RegisterPathNameAlias("SkinPath", ...) inside InitializePage()
this.InitializePage(); 

// 2. Load the skin (this method updates ActiveTab settings if fallback occurs)
var ctlSkin = this.GetSkin();

// 3. Register the alias now. CurrentSkinPath will now return the correct value from the updated ActiveTab
this.clientResourceController.RegisterPathNameAlias("SkinPath", this.CurrentSkinPath);

Affected Versions

10.2.0 (latest v10 release)

What browsers are you seeing the problem on?

Chrome

Code of Conduct

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