[Bug]: Replace Tokens in HTML module settings gets Unchecked after upgrade

[Mike35538]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

During a test upgrade from DNN 9.10.02 to 9.13.00 any module that had Replace Tokens enabled (check marked) in the HTML Module Settings was changed to disabled (or no longer check marked) after the upgrade. This occurred in every html module across every portal in the DNN installation that had the Replace Tokens enabled under HTML Module Settings. Which caused the token to display on the website since it was no longer parsed.

Steps to reproduce?

Have a html module using a token before upgrade with Replace Tokens enabled (check marked) in the HTML Module Settings. Upgrade to 9.13.00 and the Replace Tokens box is unchecked.

Current Behavior

No response

Expected Behavior

No response

Relevant log output

No response

Anything else?

No response

Affected Versions

9.13.0 (latest release)

What browsers are you seeing the problem on?

No response

Code of Conduct

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

[Mike35538]

Additional information...
Looks to have something to do with clearing the cache.

If you have a module with Replace Tokens enabled (check marked) in the HTML Module Settings and it is correctly parsing the tokens, then you go to Servers and hit the Clear Cache button, it actually removes the checkmark from Replace Tokens in the HTML Module Settings and then the tokens are no longer parsed in the html content.

[GerardSmit]

Maybe this is caused by #5742?

I'm not experienced with the caching of modules, so this is just a guess: the cache key is now set to the portal ID. Doesn't this mean 2 modules can get the same cache (since they are both in the same portal)?

[bdukes]

@valadas That makes sense to me, that the change introduced cache conflicts between modules in the same portal. I think the right approach is to include both the portal ID and tab module ID in the cache key, and then clear anything with the portal ID prefix whenever there's a change. Does that sound like it would work better? Are we missing something that is preventing conflicts?

[valadas]

@bdukes did you intend to ping me about this or someone else ?

[bdukes]

Sorry, wasn't clear about that. I did intend to ping you b/c #5742 was your PR.

[valadas]

Ok, good point, let me put my thinking hat here...

[valadas]

@bdukes I think your suggestion makes sense. We also have hostGuid and portalGuid we could leverage potentially... Unfortunately we don't have guids on the lower levels for modules and tabModules... But yeah, I feel like we probably need a compount cache-key here is some fashion.

[Mike35538]

@bdukes thanks for helping with this bug. Is there a patch that I can apply now, or do I just wait until 9.13.01 comes out? This bug is a pretty big hindrance to upgrading to 9.13.00. Thanks

[valadas]

Well if you just want to test it out you can download a "nightly build" from here: https://dev.azure.com/dotnet/DNN/_build/results?buildId=99491&view=artifacts&pathAsName=false&type=publishedArtifacts

However this is not an official release yet, so for production use I would wait on 9.13.1, which I believe could be done quickly...

[Mike35538]

@valadas ok thanks for the info, I'll wait for the official 9.13.1. Thanks for your contributions to the platform!