Running classic UI on AEM 6.5.15

[RobertHarperFS]

We are doing a long overdue upgrade from 6.2 to 6.5 and we don't have time to convert everything over to touch UI so we need to enable the classic editor. I've added the configuration node at /apps/wcm/core/content/editor/jcr:content/content/items/content/header/items/headerbar/items/pageinfopopover/items/list/items/classicui.

I don't get to the edit page because the the edit causes a 500 error. I'm not seeing where the 500 error is but it looks like it is trying to open a page at /cf#/content/mysite/home.html and this causes the 500 error. Then if I change the URL to /editor.html/content/mysite/home.html the page loads but, of course, I am not able to edit anything. Then if I use the "Open in Classic UI" button, again I encounter the 500 error.

Any ideas on what I need to do in order to resolve this?

[DPrakashRaj]

Classic component won’t work in touch ui editor as node definition is different there and since adobe has officially depreciated the support of classic ui so you left of no other option to convert the component to touch ui

[RobertHarperFS]

I know that the touch UI will not work with classic components. The problem is that when the URL changes to /cf#/content/mysite/home.html, it should open in the classic editor but it is causing a 500 error.

I also know that the classic UI has been deprecated for years. I was never fond of it. We just have to deploy with it because converting over to touch UI before we go live will add months to the project and we simply can't afford that. There is still classic support in 6.5, it just isn't the default. At some point after deployment, there will be projects to update the components and templates but we just don't have time right now.

The big issue is that adding the /cf# to the front of the page URL is causing a 500 error and I'm not seeing the exception in the log files.

[EstebanBustamante]

I agree, you should not force to use something which is deprecated, it will be a major problem in the long term.

Instead, you can take advantage of the Adobe Modernization Tools to convert to touchUI https://experienceleague.adobe.com/docs/experience-manager-65/developing/devtools/modernization-tool... This can save you a lot of time.

[RobertHarperFS]

I agree with you all on this point but it simply is out of scope and not an option at this very moment. We should be able to release without touch UI.

[EstebanBustamante · Accepted solution]

Got it, so I followed this link (which I assume you already did) and I was able to get the classicUI view:

I don't have a site compatible with classicUI that's why I can't edit my sample, but if you have one old site, I guess this should work, and what I mean by "old classicUI" compatible means it will have all the JS required to load the overlays and sidekick.
Do you see any interesting messages in the error log?

[RobertHarperFS]

Well, It looks like something the legacy code is doing. I have an instance I can run on my personal system and I can easily switch to the classic UI by just switching the touch IU's edit.html with cf# in the url and the UI switches seamlessly. Of course there isn't much I can do because I don't have classic UI dialogs but it doesn't break things.

[rawvarun]

The recommendation is to use Touch UI instead of the classic UI.

But. if you still want to use it, then Adobe does not support it.

One way is to start converting using https://experienceleague.adobe.com/docs/experience-manager-65/developing/devtools/modernization-tool....

Also, please share error code or screenshot of the error along with scenario where issue comes.

[Manu_Mathew_]

@RobertHarperFS it seems by default, the ability to switch to the classic UI via the admin consoles has been disabled, 

ref.

https://experienceleague.adobe.com/docs/experience-manager-65/administering/operations/enable-classi...

[RobertHarperFS]

Though it is true that the classic UI is "disabled"(just not shown), you can add a simple overlay and the link to switch can be added to the drop down menu on the editor page. You can also replace "editor.hml" with cf# in the address bar to switch. It looks like my issue might be that the sling servlets are not registering properly so the script calling them cause a server error. I'm now looking at issues in our code. I've tried this with other instances I have on my personal computer and the feature works as designed. I'll close this question.