How does one completely disable the touch UI? | Community
Skip to main content
J
jforney
Level 2
October 16, 2015
Solved

How does one completely disable the touch UI?

  • October 16, 2015
  • 5 replies
  • 2884 views

I know how to configure AEM to choose the classic UI by default on sign-on but that doesn't prevent access to the Touch UI if an individual knows the URL for the Touch UI.  Is there a way one can completely disable or remove the Touch UI so that it's not available even if you know it's URL?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by smacdonald2008

According to the AEM documentation - you can only configure which UI to use -- you cannot disable Touch UI. See this AEM topic for more information:

Configuring which UI to use

Hope this helps. 

5 replies

smacdonald2008
smacdonald2008Accepted solution
Level 10
October 16, 2015

According to the AEM documentation - you can only configure which UI to use -- you cannot disable Touch UI. See this AEM topic for more information:

Configuring which UI to use

Hope this helps. 

J
jforneyAuthor
Level 2
October 16, 2015

Yeah, OK.  That's what I thought but I've got to say I'm a little bit surprised by that given that aspects of the UI such as page authoring or still considered a preview technology as the following page indicates:  http://dev.day.com/docs/en/cq/current/touch-ui/touch-ui-page-authoring.html.

In fact, I feel like the whole thing could have been handled better.  Why make the touch UI the default UI out of the box?   This created a lot of initial concern up front with our authoring community who were immediatel concerned that they had to learn a whole new interface with this release.  Even now that we've configured the site to present the classic UI by default we're still getting concerns from the corporate oversight group that it's still possible for business unit level authors to get into the touch UI if they know the URL which is one thing but in fact there's been instances of users getting in advertantly dumped into the touch UI from the classic UI w/o any manual manipulation of the URL in the brower's address area.  Although I must admit that no one's yet been able to recreate such a scenario for me the reports are coming from veteran CQ/AEM authors that have no reason to make up such a thing.

Thus there's been pressure from the authoring community for me to find a way to complete remove/disable the touch UI.

H
Adobe Employee
hereathomeAdobe Employee
Adobe Employee
October 16, 2015

Hi,

Not sure if this is a good idea, but if you're using a dispatcher you might have luck to shut the door by denying access to /editor.html.  Seems a little harsh IMHO.  

      /0091 { /type "deny"  /glob "GET /editor.html/*" }

Probably a more elegant solution would be to have a apache rewrite rule to control access to the editor url.

You could also overlay the component responsible for the editor,  /libs/cq/gui/components/authoring/editor.  By overlaying the editor component's head.jsp script you could create a redirect here to whatever page you like.

<%@page session="false" import="com.day.cq.wcm.api.AuthoringUIMode, com.day.cq.wcm.api.AuthoringUIModeService"%><% %><%@taglib prefix="cq" uri="http://www.day.com/taglibs/cq/1.0"%><% %><cq:defineObjects /><% %><head> <% String suffix = slingRequest.getRequestPathInfo().getSuffix(); AuthoringUIModeService authoringUIModeService = sling.getService(AuthoringUIModeService.class); String editorUrl = authoringUIModeService.getEditorURL(AuthoringUIMode.CLASSIC); String url = editorUrl + suffix; String xssUrl = xssAPI.getValidHref(url); response.sendRedirect(url); %> </head>

Essentially you can do whatever you like at this point, redirecting to the classic mode is just one example.  I hope there is something here that you can utilize for your environment.

Cheers!

Sham_HC
Sham_HC
Level 10
October 16, 2015

We recommend moving forward mobile first approach with AEM. Some of you might not agree.  A mobile first design philosophy reverse the typical design process. Note mobile is not necessarily portable it is compose of everything that is not desktop.  Hence touch ui made default. 

For author group deny the permissions for [1] & you might not able to access touch ui. 

[1]
/libs/cq/core/content/projects
/libs/cq/core/content/tools
/libs/dam/gui/content/assets
/libs/social/core/content/communities
/libs/media/publishing/admin/content/publications

R
raphael_wegmuel
October 16, 2015

Hi,

Thanks to Ben and Sham for already providing some viable options. As an alternative to denying read access to or redirecting the nodes mentioned above (including /libs/wcm/core/content/editor and /libs/cq/gui), you might just want to remove them altogether.

For bulk removal, you could create an empty package with the above paths in the filters. If you include the OSGi config for the root redirect to point to /welcome,  this will result in a handy "Touch UI Removal Package" which you could then activate/install on a number of instances.

Hope this helps!

Regards,
Raphael

Terms & ConditionsAccessibility statement

Loading footer...