AEM 6.0, no content in editor.html window

Question

I have recently migrated a development site from AEM 5.6 to 6.0. When I click on the edit icon, in the Touch UI mode, a blank page loads with no UI. A sample Url in this mode looks like this: localhost:4502/editor.html/content/mypage.html

If I switch the url to the Classic content finder, my page and all of its content shows: localhost:4502/cf#/content/mypage.html

If I click on page properties, this URL loads and it is completely stripped of styling, is a long list of links for the AEM UI, including my user settings - but no page settings. localhost:4502/libs/wcm/core/content/sites/properties.html/content/mypage

Has anyone experienced this? Does the editor.html (Touch UI) require a different set of permissions or page properties that cf# (Classic UI) does not?

Answer 1

Make sure that your page component's sling:resourceSuperType is set to /foundation/components/page. It will inherit both dialog and cq:dialog. That will most likely solve both the editor.html and page properties issues.

Answer 2

There is slight change as per the AEM 6.1. Make sure that your page component's sling:resourceSuperType is set to wcm/foundation/components/page. You need to add this property to page component. It will inherit both dialog and cq:dialog. That will most likely solve both the editor.html and page properties issues. Hope it resolves!

Answer 3

Its just a copy-paste from one of the adobe's sites, explaining the diferences between Touch and Classic UI

A dialog that is built for the Touch UI is defined by using nodes of type un:structured. You define the type of control on the Touch UI dialog by setting the node's sling:resourceType property. For example, to define a text field on a Touch UI dialog, set the sling:resourceType property to granite/ui/components/foundation/form/textfield.

Note: When building a dialog for the Touch UI view, you define the type of control (for example, a text field) by setting the sling:resourceType property. In contrast, when building a dialog for the classic view, you define the type of control by setting its xtype property. You set both properties in the following sections. For a listing of all Granite objects, see Granite Reference.

The following illustration shows the JCR nodes of the component created in this development article.

As you can see in the previous illustration, there are two JCR branches that are related to the component's dialog:

/apps/mywebsite2/components/herotext2/cq:dialog /apps/mywebsite2/components/herotext2/dialog

Both of these dialogs are required when developing an AEM component. The first branch defines the component's dialog used in the Touch UI environment. The second branch defines the component's dialog used in the AEM classic view. Therefore to use the component in both AEM views, you need to create both JCR node branches.

So... summarizing, you need to have two dialogs defined if you want them to work on both UIs.