Check the manifest and module definition table. We had same problem with forums module where we had a two module definitions records for same module definition but with different name. Perhaps you copied your module and manifest from an existing custom module but didn’t change everything in the manifest?

John's suggestion is a great one. I've also seen this happen in the past with a module that has a JS that caused the JS to run more than once. It was a PITA to track down, too!

Thanks, John, that seems to be the reason. I have 2 entries in the ModuleDefinitions table with the same DesktopModuleID.

This seems to be the result of changing the FriendyName from "My_Custom_Module" to "My Custom Module" somewhen.

Is it enough to delete the older record, or is there anything else to keep an eye on (there are dependent records in the ModuleControls table for example)?

Happy DNNing!
Michael

 

 

Uninstall the module, then look for and delete any orphan records in moduledefinitions and modulecontrols, then reinstall?

Here’s what we did for the forums module
https://github.com/DNNCom...unityForums/pull/731

You should be able to do this for the module name you don’t want to keep.

Posted By johnhenley on 8/21/2024 2:08 PM
Uninstall the module, then look for and delete any orphan records in moduledefinitions and modulecontrols, then reinstall?

And loose all content of a module that was used about 150 times on the site? ;-)

Thanks to a testing environment, I could do it. I had two records in the ModuleDefinitions table with the same DesktopModuleID. Using the ModuleControls table I found out which one to keep and which one to throw - the "older" version had a control that was thrown (or the functionality was merged with another control).

Then I changed the ModuleDefID in the Modules table from the "old" value to the new one (I forgot to do that in the first case, so I lost all the modules with the old value after deleting the record from the ModuleDefinitions table - it is a good idea to have everything in a testing environment :-)). Finally I deleted the record in the ModuleDefinitions table, and - hooray! - the depending records in the ModuleControls were gone as well. There were no depending records in the Permission and ProfilePropertyDefinition tables.

After restarting the app pool everything was fine...

Happy DNNIng!
Michael