Dnn.platform: Telerik Removal

[ohine]

Description of Problem

We still utilize the out of date telerik components in a few places throughout the platform. We need to finish up the complete removal so we can finally remove these components from new installations.

Right now it appears that the digital assets module (dnn file manager) and the Html module are the major items that's holding us back. They both still reference and make heavy usage on the DotNetNuke.Web.Deprecated web controls.

Solution # 1

Remove usage and replace with asp.net components.

Solution # 2

Rewrite these as a SPA module and fix both the telerik and webforms issue at the same time.

Current Usage

A quick search on the solution found the following areas which should be address. This list isn't complete and will be updated as additional areas are identified.

• DotNetNuke.Web.Deprecated
• DotNetNuke.Website.Deprecated
• DotNetNuke.Modules.DigitalAssets
• DotNetNuke.Modules.Html

Host Settings

• EnableTelerikCDN
• TelerikCDNBasicUrl
• TelerikCDNSecureUrl

Build Scripts

Module.build (spell checker, assembly copy, package creation)
CreateCommunityPackages.build (file copies, package creation)

Other files

Tests\App.config
Config\SiteUrls.config
WebControlSkin (css styles)
admin.css (css styles)
dnn.jquery.js (RadComboBox type check)

[hismightiness]

I don't think there is a lot to comment on about this... Yes. Let's remove it! :D

Has anyone done the research on viable ASP.NET file management tools we can implement?

[hismightiness]

This appears to be the only popular one at the moment. :(
https://github.com/GleamTech/FileUltimate

[sleupold]

@hismightiness that doesn't seem to be open source :(

[kurtwilbies]

The server-side Web Api code is already written. What is needed is react with redux code. I personally think its not that hard.

[valadas]

I have done a lot of module updates for Dnn 9.2 compatibility and removing dependencies on Telerik without too much trouble. I am also for removing it. The only thing ( I think I asked in the past but got no reply ): Is there a reason why the DnnDatePicker is in an internal namespace? I used it a couple times taking that risk it disappears, but as a developer working often on old modules, this the the Telerik control I found the most time consuming to replace and the Dnn one (even though internal) has done a quick job as a direct replacement, can this be put public until webforms support goes away to make it easier on developers.

[OllyHodgson]

Obviously we'd want to replace those modules first. Do we need an RFC for each of those, or can that discussion happen here?

I'm not sure about making HTML into a full SPA module. The content editing side could all be client-side, but the actual rendering of HTML should probably still happen server side.

I take it any 3rd party modules which use Telerik controls (e.g. Mandeeps Live Forms) would need to start bundling them with their modules? Would this pose any issues? Do we need to document a migration path for them? (or does such documentation already exist?)

[ohine]

Obviously we'd want to replace those modules first. Do we need an RFC for each of those, or can that discussion happen here?

I think we can discuss those module details here, and then we can turn each area into a help wanted feature after we figure out the details.

I'm not sure about making HTML into a full SPA module. The content editing side could all be client-side, but the actual rendering of HTML should probably still happen server side.

Correct, We wouldn't want to use SPA for the view control, but I think for the edit control it would be a good example, and it would force us to fix the html text editor issue not being available for SPA types as well.

I take it any 3rd party modules which use Telerik controls (e.g. Mandeeps Live Forms) would need to start bundling them with their modules? Would this pose any issues? Do we need to document a migration path for them? (or does such documentation already exist?)

We need to label the deprecated assembly for telerik as obsolete and removed in v11. I'd like to reduce our core usage, and then remove the extension from the install and upgrade packages. This way if you had a site using it, the assembly would still be there, but we wouldn't extract it for new installs or update it again on upgrades. Things would be frozen as they are. We'd need a blog about how to remove it from your site since I think auto uninstalling it would be very very problematic.

[ohine]

Is there a reason why the DnnDatePicker is in an internal namespace?

I'm not too sure, probably just an honest mistake. If this is a telerik control I really don't want to change it, but if it's a standard webforms control then maybe we could make it public? I almost think we should mark them all as obsolete and move the ball forward. We really need to reduce our webforms usage instead of making it easier to continue webforms development.

[ohine]

The server-side Web Api code is already written. What is needed is react with redux code. I personally think its not that hard.

@kurtwilbies when will that pull request be ready for us to review? :-)

All joking aside, you're right. We already have most of the API's exposed. We just need a few of the react.common controls connected to those api's and we'd have a decent starting point for a replacement for digital assets.

[sleupold]

if we re-implement DAM as PB extension, do we still want to provide an option to use it as plain module on a page as well (which is a feature of DAM)? or do we even have a plan to provide a wrapper for PB extensions to use it as a module on a page for non admins (e.g. authors, who should be able to edit page settings and restore pages/modules from the bin - or user admins, who should be able to manage users and (specific) role membership?
An alternative for users in elevated roles to access PB features would be implementing a UI for PB permissions.

[kurtwilbies]

@ohine. We need a good plan. What, how and when. Then I would love to make my contributions. For DAM you could easily copy and past a large part of the code from the existing js code.

[mtrutledge]

Obviously, we need to remove it. I vote to do a SPA module to replace the components.

[OllyHodgson]

@ohine

I almost think we should mark them all as obsolete and move the ball forward.

Assuming you're talking about all of the web forms APIs, I'd be very tempted too! Is version 10 too early to do that?

[ohine]

@OllyHodgson

Is version 10 too early to do that?

Yes, we have to wait _at least_ two major versions to remove a function we mark obsolete. It should be in the policy document on github. That's why it's important to start figuring out what we want to remove and what is going to stick around for a bit.

[bdukes]

I'd be willing to argue that having had the Telerik components in an assembly named DotNetNuke.Web.Deprecated since 8.x is enough of a deprecation warning to remove them in 10.0, but if others want to wait, that's fine.

[OllyHodgson]

I meant is version 10 too early to entirely deprecate web forms module development in DNN. Not remove anything (apart from Telerik) but make it very clear that whole way of working is going away. That might be a discussion for another RFC though 🙂

[sleupold]

I like the idea of @bdukes, if possible, we should still provide the Telerik library as optional component - this will allow 3rd party modules in upgraded installations to work and on new installations to be used, if the library is installed (we might need to claim this to be unsupported and being deprecated in DNN 11+)

[kurtwilbies]

I too like @bdukes's idea. This in combination with making DAM optional, because not every user needs this feature. If NO DAM then NO telerik ice age library.

[valadas]

I'd be willing to argue that having had the Telerik components in an assembly named DotNetNuke.Web.Deprecated since 8.x is enough of a deprecation warning to remove them in 10.0, but if others want to wait, that's fine.

I would be willing to argue that many developers just referenced the deprecated dll and moved on to the next issue :) So my vote goes to keeping it around until we have to remove it.

For the DAM, I am of the opinion of making it into a React component, then this could be used both as a module on a page and in the Persona Bar. I would definitely open an RFC for that though to get people opinions on this.

[valadas]

An alternative for users in elevated roles to access PB features would be implementing a UI for PB permissions.

That would surely be nice to have, but I also see a situation of a site having many many DAM modules in place, so I think we should also wrap the new module into the same old one so that it remains usable in the pages it is already placed.

[OllyHodgson]

I would be willing to argue that many developers just referenced the deprecated dll and moved on to the next issue :)

Is there any mileage in making the Deprecated stuff an optional installable module for v10 onwards?

[valadas]

The thing with Telerik is that there was some kind of partnership where any Dnn developer could use their webforms controls as long as they where wrapped into a dnn control. Many of these wrappers had some additional changes (mainly some small styling things to match the UX/UI guidelines and some workarounds for Dnn specific quircks).

Now there are 2 things that are problematic:

1. Those wrappers will not get updates, so developers using them will be pretty much on their own to solve issues.
2. We need to clearly nudge everyone to move away from webforms but at the same time try as much as possible to keep them around for as long as possible to not pull the rug under so many older modules quick.

So it is a bit of a double edged sword, but as long as we make it easy to not rewrite modules, well people will not rewrite their modules.

However, even if we remove them, nothing would prevent any developer to grab the dotnetnuke.web.depracated.dll and the telerik dlls and keep using them, I believe they are pretty much self contained and don't really depend on Dnn other than for CSS rules. Also, developers can buy a telerik license and use their controls directly if they really need that.

[ohine]

However, even if we remove them, nothing would prevent any developer to grab the dotnetnuke.web.depracated.dll and the telerik dlls and keep using them, I believe they are pretty much self contained and don't really depend on Dnn other than for CSS rules. Also, developers can buy a telerik license and use their controls directly if they really need that.

Correct, the goal is to remove our usage from the core platform and stop including it going forward.

If we do, new installs will have to specifically opt-in to use the outdated components. If a vendor really wants to continue to use telerik from 2013 in their modules. I think they need to include the deprecated package with their modules. I do not think we should continue to even indirectly support these components any longer by continuing to package and include them with all install and upgrade packages.

As long as we don't automate the uninstall of the package, any upgraded site will continue to function with the old components. We will need a good guide to point people too to check their usage and the basic steps to start reducing and verifying they're ready to then uninstall the outdated controls.

If everyone is ok with removing them in v10, lets make it happen! I was playing it safe with setting the scope to v11.

[kurtwilbies]

Any updates on the roadmap of v10. Telerik makes dnn less usefull and impossible to upgrade/migrate to .net core. Remove all functionality/modules that use telerik and provide, after dev, clean developed or open source alternative solutions.

[zyhfish]

I just submit PR #2677 for this request. anyway it's not a complete PR as the major break project is DAM, this one depended on Telerik deeply, what I think available options are:

1. introduce another module to replace the DAM;
2. replace all Telerik references in DAM with some other components;
3. introduce a new persona bar module to replace the DAM.

need community help and continue working on this to resolve above problem, then the PR can be processed, thx so much!

[mitchelsellers]

@zyhfish Is there any possibility of a partial contribution of the PB variation of Site Assets (DAM) from Evoq into the platform?

[roman-yagodin]

:pray: Please don't remove anything without providing equal replacements or at least clear paths and solid options for developers to migrate!

While replacing DnnComboBox with ASP.NET one is not a problem, replacing others like DnnUrlControl, FilePickerUploader or DnnDateTimePicker is not that simple. Migrating simple edit form from WebForms to e.g. React could require total rewrite - I'm fine with that - but also relying on external JS libraries of questionable quality which just not aware of .NET and DNN specifics (modules, UI and content localization), nor packaged for DNN.

Example: A really cool :sunglasses: 2Sic Mobius Forms rely on smoke library to do form validation, as they state that it's the only JS library which not require entire page to be validated on submit (which is good for DNN modules). But it:

1. Last updated 3 years ago.
2. Have lots of hardcoded things like min. password length.
3. Doesn't support custom validation! :warning: :stop_sign:

I'd very like DNN to be not a sandbox for custom thing-in-itself :black_large_square: extensions, but cool reusable components library for basic developer needs. Thanks all peoples behind https://github.com/dnnsoftware/Dnn.React.Common by the way :+1:

About DAM - despite its bugs, very damn useful thing :smile: Please keep it there, with Telerik or without.

[valadas]

I am currently working on a proof of concept for DAM, I would like to have it be a full class citizen of both the Persona Bar and as a regular module but SPA based. I would also like to have feature parity.

It is a bit early to make any promise but I should have something hopefully in a week or two to show...

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[valadas]

Hey Stalebot, yes we are still working on this

[kurtwilbies]

@valadas Will the team remove telerik in version 10? News? Progress?

[valadas]

It is the goal yes. The major thing is the file manager to completely rebuild and before that happens I have some progress on things that relate to this rebuild and hoping we can rebuild it for 10 in the next months before Dnn Summit. The other things that rely on Telerik should be pretty quick to rewrite.

[kurtwilbies]

I would like to contribute. Could you give me a list of tasks or something. My coding skills, sql, c# and js (react), are good.

[thabaum]

@kurtwilbies As a contributor you get to make your own list of tasks. You can select "Bug" in the list of issues and go to town there or do whatever you feel would make DNN better. Helping out with supporting bugs is a major help if you can. We are trying to get 9 bug free before 10. It is a free for all here :)

• Be sure to select the development if you are working on 10 or branch 9.4.x for current version as of now.
• Search for a file that has to do with the issue
• Edit that file and it will get saved into your fork as a patch.
• when done and things look good submit as a PR referencing the issue you are trying to resolve.

This has been my workflow... works pretty well except when you forget to select the right branch to start. GitHub app is pretty nice I just started using it along with using GitHub and Visual Studio together. I am not 100% there yet @valadas can explain things better or just look through all my recent PR's as they show all my pitfalls and lots of great help explaining from everyone.

Seriously welcome any help and even PR's that get rejected are great tries dont give up! If it works and does not provide breaking changes for the current release it will probably get accepted. If it breaks something by removing or changing thing others may use for modules it needs to be put into a future release to be accepted with a path to move away from the old changes that give mod developers a heads up and time to react to the changes.

Currently only handful of community developers are actually working on many many issues... Thank you all!

[kurtwilbies]

Actually, working with (todo) lists is what I prefer.

[thabaum]

Well anything labeled bug like here is on the todo list for the community. No one may take these on for years. I just fixed one from 2006... took me 1 hour but i had thought about it for years. Finally dove into submitting PR's recently. It took longer to setup github and stuff... but most all others I cannot do this quickly and so I rather work for $$$ to support my life :)

The bugs, chores or enhancements are some community things to do if this is what you are looking for I dont know if there is a todo list. I asked the same Q's as you... not long ago. This was a great answer I liked :) tackle the ones you feel good about.

Or if you want to get into version 10 or 11 there are all the milestones anything not closed is something that is "Todo" https://github.com/dnnsoftware/Dnn.Platform/milestones

I think if you go for anything just let everyone in community know you are working on it... and if you give up on it as well. If something is stale it may need some extra love :) For something like removal of telerik if you follow what the discussion here is talking about, create an issue on any point you can fix once you created a fix for it and submit the PR with a link back to the issue you created and this one. Do what you can when you can if you want to it is up to you 100% no one is telling anyone what to really do. We just talk and discuss and do things. If you do something that is reviewed and accepted it will be merged into the branch you started working on.

The GitHub app I found is very good at showing a lot of examples of past PR's and code changes. Go to town on whatever you wish, community will back you up as much as we can.

[valadas]

I removed the RFC title and created #3439 which I am starting to work on.

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[stale[bot]]

This issue has been closed automatically due to inactivity (as mentioned 14 days ago). Feel free to re-open the issue if you believe it is still relevant.