Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

AEM 6.2 TouchUI Unlock page functionality not working

Avatar

Level 5

AEM 6.2, Using TOUCH UI

PROBLEM:  Author goes in and locks a page using the TOUCH-UI.  Page is Locked.  In 1 minute - without making changes, the same user tries to UNLOCK the page and cannot do so.  There are no browser errors or errors in the logs.  Additionally, if I try this as the admin user, the exact same thing happens !!!

I have a BASE page that has a resourceSuperType of wcm/foundation/components/page .... copied that page and made it the resourceSuperType of my page.

I've added a clientlib to the page and added a new property named “dependencies” of String[] type  with value of “cq.shared” (Recommendation from Adobe)

This DID NOT solve the problem.

INTERESTINGLY, if I go into the CLASSIC UI ... it will allow me to both lock and unlock the page as desired.

Does anyone have any suggestions on getting the TOUCH UI implementation to work?

-Dean

1 Accepted Solution

Avatar

Correct answer by
Level 5

I updated the properties and rebuilt the libraries and it worked.

“dependencies” of String[] type  with value of “cq.shared”

View solution in original post

5 Replies

Avatar

Correct answer by
Level 5

I updated the properties and rebuilt the libraries and it worked.

“dependencies” of String[] type  with value of “cq.shared”

Avatar

Level 10

Thanks for posting the solution.

Avatar

Employee

Yes, seems a known problem.  It occurs in AEM 6.2 as well

CQ-82282 - Editor assumes presence of the "CQ.shared" namespace inside content page. Therefore, your solution worked. workaround is to make sure that content pages include the cq.shared client library

Hotfix for 6.1 NPR-7937 - Page unlock does not work for pages using wcm/foundation/components/page as resourceSupertype [Fixed in 6.1 SP1]

 

Avatar

Level 1

After migration: from 6.2 to 6.4. There is no need to add cq:shared, just review in detail where the code started to fail.

Add the next code to load user data at the contentWindow level.

var contentFrame = parent.frames["ContentFrame"];

    Granite.author.ContentFrame = contentFrame;

    Granite.author.ContentFrame.contentWindow.CQ = {};

    Granite.author.ContentFrame.contentWindow.CQ.shared = {};

    Granite.author.ContentFrame.contentWindow.parent.CQ.shared.User.load()

    Granite.author.ContentFrame.contentWindow.CQ.shared.User = Granite.author.ContentFrame.contentWindow.parent.CQ.shared.User;

Avatar

Community Advisor

I was having a similar issue on my AEM 6.5 instance, and this trick temporary solved the problem. However, now we need to get down to it, and understand why is it doing this, and add the code where necessary. Thanks!