dnn.js not included on the page when cookie consent is enabled

Description of bug

The new cookie consent functionality released with DNN 9.3.1 depends on the window.dnn object being available which is created by dnn.js. However, when not using a skinobject that includes dnn.js on the page (or manually registering it), dnn.js is not included on the page and the cookie consent functionality breaks.

Relevant code:

$(window).on('load', function () {
    window.cookieconsentoptions = window.cookieconsentoptions || {};
    window.cookieconsentoptions.content = {
        message: window.dnn.getVar('cc_message'),
        dismiss: window.dnn.getVar('cc_dismiss'),
        link: window.dnn.getVar('cc_link')
    }
    if (window.dnn.getVar('cc_morelink') != '') {
        window.cookieconsentoptions.content.href = window.dnn.getVar('cc_morelink')
    }
	if (!window.cookieconsentoptions.palette) {
		window.cookieconsentoptions.palette = {
			"popup": {
      "background": "#000"
    },
    "button": {
      "background": "#f1d600"
    }
		}
	}
    window.cookieconsent.initialise(window.cookieconsentoptions);
});    

Our current short-term (as in, critical fix) workaround involves including the search skinobject on the page in a hidden div. Less than ideal of course.

Steps to reproduce

List the steps to reproduce the behavior:

1. Create a simple empty page skin (no skinobjects that register dnn.js)
2. Enable the cookie consent functionality
3. Log out (dnn.js is loaded when logged in, into a SuperUser account anyway)
4. Cookie consent message does not show

Current result

The cookie consent popup does not show.

Expected result

The cookie consent popup should show.

Screenshots

If applicable, provide screenshots to help explain your problem.

Error log

See above

Additional context

Add any other context about the bug that may be helpful for resolution.

Affected version

• 9.3.1
• 9.2.2
• 9.2.1
• 9.2
• 9.1.1
• 9.1
• 9.0

Affected browser

• Chrome
• Firefox
• Safari
• Internet Explorer
• Edge

[yog-it]

I had the same issue and your workaround fixes the issue by placing that line in the skin’s .ascx file and removing PathNameAlias=“SkinPath”.

[bdukes]

Yes, in 9.10.1