Dnn.platform: Add Existing Module From Another Tab Relocates All Current Tab Modules to Same Pane

[tpperlman]

Description of bug

When adding an existing module from another tab to the current tab, all of the current tab's modules move to the pane selected for the copied module.

Steps to reproduce

1. Create a new tab.
2. Add some new test modules to a couple of different panes.
3. Add an existing module from another page to the current page, making sure to uncheck the "Make a copy" box.
4. After the module is added, notice that ALL existing modules in different panes have been relocated to the pane of the copied module.

Current result

All existing modules move to the target pane of the copied module.

Expected result

Existing modules should remain in the same pane they were before adding the existing module

Affected version

• [x] 9.2.1
• [x] 9.2.2

Affected browser

• [ ] Chrome
• [x] Firefox
• [ ] Safari
• [ ] Internet Explorer
• [ ] Edge

[tpperlman]

Can anyone else confirm or acknowledge? This issue cripples building out sites with even only a couple of modules...

I had to create my own quick and dirty razor module to work around this...

BIGideas.CopyExistingModule.zip

[sleupold]

please verify that the issue still persists in DNN 9.2.2, thank you

[tpperlman]

Thank you for the follow-up, Sebastian. Yes, I can confirm that the issue persists in DNN v9.2.2

[sleupold]

Thanks for the heads up, I'll try to reproduce.
Unfortunately, there is no "severity" level any more to assign to it - like MS added to Win10 issues recently

[OllyHodgson]

I can reproduce on Evoq Engage 9.2.0.

I cannot reproduce in a completely clean Platform 9.2.2 install though.

[valadas]

I can reproduce on a site upgraded from 9.1.1 to 9.2.2

[valadas]

And I can confirm it does not happen on a clean 9.2.2 install too.

[dnndiva]

This also is happening on new install:
PRODUCT: DNN Platform
VERSION: 9.2.0
BROWSER:
Google Chrome
Version 70.0.3538.77 (Official Build) (64-bit)

[valadas]

@ohine @mitchelsellers I think it would be important to make sure this is taken care of for 9.3.0, can one of you guys add this to the milestone?

[valadas]

Maybe related to #2163 , just writing this link here to check on the other issue when this one is resolved.

It also happens on localized sites that use module references much more often that other users, it is a nightmare right now! I will try to take a look into the cause of this soon, if you have any clue of what changed, let me know...

[britchson]

I am also experiencing this error and may not be able to wait until it is fixed by the community though I lack the knowledge to fix it myself. Could someone please recommend a course of action to resolve this issue with a workaround. For example, would some type of downgrade be possible? If so, is there a guide somewhere on how to downgrade DNN?

[valadas]

@britchson there is no easy way to downgrade unfortunatelly, it is always a good idea to take a database backup and files backup before any upgrade for situations like this. That being said, this issue was tagged for a fix in Dnn 9.3.0 I am currently working on other parts of the next release but if nobody submits a pull request for this before I finish, it is definitely on my todo list. It is a big issue for me that have many localized sites.

[britchson]

@valadas Thank you for your response. Unfortunately, the site was created at 9.2.1, so the issue has always existed. I'll wait then.

[valadas]

Oddly enough, I am no longer able to reproduce, not sure why, tried enabling localization, different themes, etc. Not sure what makes it happen and not happen...

[valadas]

So far, I have one site that was upgraded from 9.1.1 to 9.2.2 with localization and another site that was built on directly with localization also, those two have the issue.

Trying to reproduce the same scenario 9.1.1>9.2.2 with localization and 9.2.2 new with localization and I can't make the issue happen again for some reason.
I tried with and without localization, with and without a module visible on all pages, on SQL 2012 up to 2017, with various cache and minification settings, with Chrome and Firefox, with and without ssl. If you guys get more ideas, let me know...

[ohine]

I think we will leave this at v9.3.0 and make sure we get a few people test and report back how it's functioning against the rc build next week.

[valadas]

IMO,

A. We untag the milestone and we fix this when we finally can find step to correctly reproduce ( I have one production site with this issue but cannot find why it only happens on that one).

B. We ask testers of 9.3.0 RC to focus on this and report back very detailed steps on how to reproduce.

[valadas]

Cannot reproduce again on a Dnn8.0.4 to 9.3.0 upgrade and on another 9.3.0 clean install.

[cameron-moore]

I think this has to do with the script in the function _processModuleForDrag within the file ModuleDialog.js which is within the code for the EditBar.

I believe that the function is attempting to create a collection of related modules so that those modules can be moved along with the module being dragged, by the code in the function dnn.ContentEditorManager.sortStop in the file ContentEditor.js.

At line 902 in ModuleDialog.js the code compares the module IDs of the current module and other modules. If a module has a higher module id than the module being operated on the module will be added to the related modules collection and will be moved into the same pane as the module being operated on when the dnn.ContentEditorManager.sortStop function executes.

I think the intention is that if there are multiple views (tabmodules with the same module id) for the same module on the page then all views should be transferred to the new page. However what happens instead is that all modules on the page with a higher moduleID are added to the related modules collection. Then all of those modules which were added to the related modules array are then moved to the new pane.

Because the code is currently using a greater than operator in the if statement, only modules with a higher module Id would be considered related modules. Therefore the issue will only occur if you add a module from another page that has a lower module ID than the modules currently on the page. That may explain why @valadas was unable to reproduce the issue in some cases. To reproduce the issue add a module on one page. Then add a new module to a second page and then add the first module, from the first page, as a referenced module to the second page. The key is that the module being referenced must have a lower module id than the modules already on the second page.

I'm not 100% sure what the original developer's intentions were with respect to related modules. Even if a there were multiple tabmodules for the same module on a page & the intention is to add them to the new page, I'm not sure that they should all be moved to the same pane if they weren't in the same pane already.

If you comment out the push statement on line 905 of the file ModuleDialog.js the issue no longer occurs & other modules all stay in the correct panes. However I'm not sure this is the right solution because it seems that the code is there for a reason. I just don't understand exactly what it's meant to be doing.

[valadas]

That is awesome info. I did not even know where to begin to look for that bug! Thanks.

[sleupold]

IMO we need to rethink, how we are storing data for modules "display on all pages". If they should appear on ALL pages (including admin), they are currently stored without additional tabmodule records for every page, Only after you moved or removed it on a single page, it will create all these links.
We should ALWAYS create all records, but have a proper link to master page and its settings.

[valadas]

@sleupold I agree this needs a rethink, almost every time I had clients use that feature on multiligual sites, we ran into problems. I try to avoid it as much as possible for that reason. For me, if it should show on all pages, it needs to be in the theme (skin) but I get that users need a way to show something on all pages easily. I will try to submit a PR to at least fix the issue at hand, but a rethink would be good in the future yes.

[valadas]

@sleupold also, this is not with "show modules on all pages" but just "insert an existing module" just one time.

[valadas]

@cameron-moore I can still not reproduce the issue, are those steps to reproduce correct?

1. Create page 1
2. On page 1, Create module 1
3. Create page 2
4. On page 2, Create module 2
5. On page 2 insert existing module 1 from page 1 unchecking "copy module"

If not, can you rephrase how you are able to reproduce in a list of steps.
Thanks.

[cameron-moore]

@valadas Yep, that's the steps I used to reproduce it.

Below is a link to a video of me doing the same thing. Only difference was this time I added both pages at once, using the Add Multiple Pages option. However, I get the same result whether I add two pages ast once or add the first page and then add the second page later.

Steps followed were:

• Add two separate pages called MyPage1 & MyPage2 using the Add Multiple Pages option. This will create two new pages with the default, empty, HTML module on each page.
• Navigate to MyPage2 & enter edit mode.
• Move the HTML module on the page to another pane.
• Click the Add existing module button on MyPage2.
• Ensure the "Make a copy" checkbox is unchecked.
• Select the MyPage1 page as page to reference from & then select the HTML module on that page.
• Wait for the module positioning element to appear.
• Drag the module positioning element to a different pane to where the other HTML module was moved to.
• Notice that both modules are now in the same pane.

AddRelatedModule_DNN911.zip

Hope that helps. Let me know how it goes.

[djfenske]

I've been experiencing this issue consistently on a clean 9.3.2 Platform install. I wasn't sure whether it was an issue with the skin or not, but it is exactly as described above.

[tpperlman]

@djfenske, the issue was fixed in a subsequent release, and no longer exists. I recommend you start with DNN v.9.4.1 at https://github.com/dnnsoftware/Dnn.Platform/releases

[djfenske]

Thanks, Phil - that's good news. I may try an upgrade of this particular site to see if that corrects the issue for me; what prompted me to look this up was that I didn't see any mention of it in the release notes for 9.4.1, and then discovered this still listed as an Open issue.

[valadas]

Awesome, I remember there was something near this issue merged in 9.4.x somewhere, I only had this very intermitently on a site or two (don't even remember which now). In the spirit of cleaning the backlog I am closing this issue because we have one positive confirmation of it being fixed.

If there are still issues with this using 9.4.1, please comment and I will be glad to re-open

[jacoch]

Hi. I confirm the bug still exists in 9.4.1. Isn't it possible to just disable search of relative modules when the added module is linked to another existing module? Because most of the time, when adding an existing module as a ref, it will have a lower ID than new modules on the current page.

[jacoch]

Here is the solution I've applied to work around this problem.

In ModuleDialog.js, I changed the setModuleId function as follow (I save in cooke and clear from cookie the value of _callFromExistingModule):

setModuleId: function (moduleId) {
    if (moduleId <= 0) {
        this._removeCookie('CEM_NewModuleId');
        this._removeCookie('CEM_ExistingModule');
    } else {
        this._setCookie('CEM_NewModuleId', moduleId);
        this._setCookie('CEM_ExistingModule', this._callFromExistingModule);
    }
},

In ContentEditor.js, I modified the window load event like this (I load the new cookie and add its value to apply method of moduleDialog):

var cookieModuleId = moduleDialog._getCookie('CEM_CallbackData');
if (cookieModuleId && cookieModuleId.indexOf('module-') > -1) {
    var moduleId = cookieModuleId.substr(7);
    var existingModule = moduleDialog._getCookie('CEM_ExistingModule');
    if (!existingModule) existingModule = false;

    var module = $('div.DnnModule-' + moduleId);
    var moduleManager = module.parent().data('dnnModuleManager');

    moduleDialog.apply(moduleManager, existingModule);
    moduleDialog._processModuleForDrag(module);
    $('#moduleActions-' + moduleId).addClass('floating');
    moduleDialog._removeCookie('CEM_CallbackData');
} ...

As the value of callFromExistingModule is restored in ModuleDialog, function _processModuleForDrag ignores relative modules when the added module is an existing one.

[leedavi]

I still get this issue in DNN9.4.1 ??

[donker]

I will look into this.

[leedavi]

thx Peter. Let me know if you need any help.

[jacoch]

In the meantime, you can apply the fix above. It's just 2 js files to modify.

[leedavi]

OK, thx, it's not a problem for me at the moment. I was just confirming your findings on 9.4.1.

[Timo-Breumelhof]

I have a client that has this issue, but on one of my test installs (9.3.2) I cannot reproduce it using these steps:
https://github.com/dnnsoftware/Dnn.Platform/issues/2289#issuecomment-456783898

[leedavi]

https://github.com/dnnsoftware/Dnn.Platform/issues/3309

Here are the step I can reproduce in 9.4.1

[valadas]

Can you guys check 2 things please for triage:

1. Is this still reproducible on 9.4.2 (or 9.4.3 RC)
2. Is this issue and #3309 the same ? If so we could close one of them as a duplicate...

[jacoch]

1. Just upgraded a test site. I can confirm that the problem still exists on 9.4.2.
2. Yes. Issue 3309 can be closed. It's the same bug.

[valadas]

Thank you.

[marcoburlando]

By following these instructions I solved the problem: comment-552179624 thanks to jacoch
I cleared the firefox cookies also.
Tested on DNN 9.4.4 and Firefox (Windows 10)

[Timo-Breumelhof]

@david-poindexter you marked the Effort as high, but I think the fix is in comment-552179624 ?

[tpperlman]

I see this issue exists in 09.05.00 as well. I had thought it was fixed a couple releases ago?

[valadas]

We did not receive a PR with the proposed changes, @jacoch can you submit a pull request for your changes please ?

[jacoch]

Well it was just a work around I used on my side. I thought it would be fixed by devs in another way. But sure, I can open a pull request.

[Timo-Breumelhof]

Well it was just a work around I used on my side. I thought it would be fixed by devs in another way. But sure, I can open a pull request.

that would be really nice :-)