Hi.
I wanted to post some recent issues that have come up with the Opt In Email module. I am attaching some of the thread from a recent post on the Benefactor forums on DotNetnuke.
This is related to any module that uses a Rich Text Editor within the Settings area of a module on DotNetNuke 4.7 (problem did not exist before 4.7)
---------------------
Hi guys...
A number of our modules use a DNN Text Editor within the 'Settings' area of modules. We have found and duplicated a bug where using the Richt Text Editor in the settings area and saving the settings with changes to the Rich Text Editor the value is never stored/lost. After reviewing this further we determine that this was not happening in 4.5.x or 4.6.x and just started happening in 4.7. We search and searched the code and never saw that it was ever getting reset on a postback or anything like that (which isn't a big surprise since it was working fine until 4.7). I also started reseraching some of our other modules that use the Rich Text Editor in the settings area and am finding the same problem... So, has anyone else run into this? Are there any core modules that use the editor during in settings?
Also, as a work around we have found that if the user chooses 'Basic Text Box' on the editor then it correctly saves what the user was wanting to save, only when the user chooses Rich Text Box that the values are lost.
Any help or thoughts?
Thanks,
Chad
---------------------------------
Hi guys... I have been able to duplicate this with at least one Core module as well. I was looking around for any core module that utilizes the Rich Text Editor directly within settings and the first module I could find was the Repository module.
So, to duplicate with the Repository module just go into the settings area on DNN 4.7 and update the description for the repository (the very first item within the settings). You will notice that whatever you attempt to save within the editor does not get saved unless you click 'Basic' radio button and then you do not use the Rich Text Editor. I have been able to duplicate this bug here as well.
Before posting this to to Gemini I did a search but couldn't find one... I then also couldn't find where within Gemini I was supposed to report it (I could only search and didn't see an option to post?).
Thanks,
-Chad
---------------------------------------------
Shaun Walker
President / Chief Architect
DotNetNuke Corporation
------------------------------------------------
Shaun,
Hi. Thanks so much for the fast turn around.
Yes I think either of those two ssuggestion would work and be better than having the coder add code to check for this (or even allowing the developer to have a setting on the module definition itself to disable this feature would be idea so that something could be included in the manifest). This way the setting only has to be disabled on modules where it might cause a problem... Hmmm, after re-reading your post this might have been what you already suggested with the partial rendering flag.
Ok, well at any rate in some modules this would need to be required. The post from Michael Washington was referring to a link called 'Export' and in our case the module in particular we were working with was for a similar link called 'Update Message'. In the case of so many other modules though they would just be updating with the normal 'Update' button at the bottom of the settings page. In this case I couldn't find a solution with the code work around and this linkbutton is not rendered in the module user control.
Thanks again!
-Chad
---------------------------------------
In 4.7 many areas of the Core were Ajaxified using the SupportsPartialRendering module attribute. This included the Module Settings control - effectively wrapping it in an UpdatePanel at run-time if AJAX is installed in the site. However, the Module Settings control also has the capability to dynamically load another user control which inherits from ModuleSettingsBase to provide a user interface for custom module settings. If the dynamically loaded user control contains functionality which accesses the Request or Response objects directly or other advanced controls like the RichTextEditor, the UpdatePanel can cause problems with the behavior of the module. This bug was identified earlier by Michael Washington with the Survey module in this blog:
http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryID/1647/Default.aspx
Michael came up with a solution but it involved a change to his module code. I believe there is a way we can deal with this in the core by wrapping the dynamically injected Settings control so that it is excluded from the UpdatePanel processing. This could be done in the case that the Settings control does not have its SupportsPartialRendering attribute set.
|