Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Cannot Add or Edit Components in Touch UI

Avatar

Level 4

Seeing this issue across both development and stage on our AEM 6.5.12.0 instances, while working in Touch UI over this last week: "The issue is that periodically ALL components will have their edit options removed, just leaving the Insert and Group options." (Same issues as this thread and this thread, which had no resolutions)

 

Suddenly seeing only Copy, Group, and Convert to EFV:

JaredAtUD_0-1673463677729.png

 

Additionally, the add component button on any parsys has disappeared:

JaredAtUD_1-1673463915508.png

 

The above screenshots are from our stage environment on an administrator account. The same issue is present across other user logins. There are no obvious errors in the granite logs or the web browser console.

 

Fixes attempted without any results:

  • Reinstallation of UI (apps) packages seemed to temporarily restore some functionality sometimes? But then it would occur again very quickly.
  • Suggested Band-Aid fix from this thread to specify "cq:actions" in the cq:editConfig node across components has been unsuccessful in this case.
  • Reverted any recent changes to a git history period prior to when the issue began.
  • Traced back permissions being served to the render function for the menu options, and found the same issue as this post: "For the line starting return ns.pageInfoHelper.canModify(), I think there is some data missing in the page info json object. On my broken machine, I cannot see a permissions array."

 

Any insight/suggestions are appreciated.

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Level 5

I had a similar issue just this week.  I noticed that when I edit any cq:editConfig, authoring across the entire system starts to fail.

 

The resolution I found: I had an overlay of basicpage, where I was hiding/updating the out of the box fields:

/apps/wcm/foundation/components/basicpage/v1/basicpage/tabs/...

 

 

I noticed that removing this overlay fixed the issue.  Ultimately the resolution I found was to copy everything from /libs/wcm/foundation/components/basicpage/v1/basicpage/* and then apply the changes I wanted accordingly.

 

Hope this helps.

 

 

 

View solution in original post

13 Replies

Avatar

Level 5

@JaredAtUD  - Are you able see components in policies/component groups in templates?

Avatar

Level 4

Components appear in all sidebar lists and pre-baked template areas as they're supposed to, yes.

Avatar

Level 5

@JaredAtUD  - Can you restart the server and start monitoring the error log and page console(check for any JS errors) to insight the issue first on page load.

Avatar

Level 4

From my original post: "There are no obvious errors in the granite logs or the web browser console."

 

Gave it another go on startup, regardless.

 

Granite logs:

JaredAtUD_0-1674151769842.png

 

Browser console:

JaredAtUD_1-1674151852938.png

In my development environment I'm still missing the ability to delete existing components or add new components to a parsys. In our stage environment, there's not even the option to edit.

 

Avatar

Level 5

@JaredAtUD  - Did this issue started post installing any of recent custom code? or 6.5.12.0 upgrade?

 

Avatar

Level 4

We're working through a lot of code changes right now, so yes, there have been many code changes. It started happening after a seemingly harmless adjustment to some component HTL. When I noticed, I reverted back to a code commit before the issue was occurring. This didn't fix the problem though.

 

I've just attempted rolling back to a much, much earlier code commit (before our current feature branch) with the same result: Whatever is happening is unnaffected by our custom code it seems.

 

As for the version, we've been on 6.5.12 for a long while. No changes there.

Avatar

Level 5

@JaredAtUD - I suggest locally start testing with vanilla (AEM 6.5.12) & install custom code and begin test so you can find which is the root cause(custom js loading in authoring mode might be issue)

Avatar

Level 4

Will give this a go and update here when I see some results. Thanks.

Avatar

Level 4

Following up here - Having no success tracking things down using your method here. The new instance will randomly fail for reasons unrelated to our current setup... Makes it difficult to actually get to test the current failure points.

 

I appreciate the suggestion, but I don't think I can dedicate too much time to getting this running at this moment. Let me know if you think of any other good places to start.

 

Thank you!

Avatar

Level 5

@JaredAtUD - You should have clean local setup as in stage to track the issue locally else its difficult.

Can you let me know the background when issue started appearing ?

 

Avatar

Correct answer by
Level 5

I had a similar issue just this week.  I noticed that when I edit any cq:editConfig, authoring across the entire system starts to fail.

 

The resolution I found: I had an overlay of basicpage, where I was hiding/updating the out of the box fields:

/apps/wcm/foundation/components/basicpage/v1/basicpage/tabs/...

 

 

I noticed that removing this overlay fixed the issue.  Ultimately the resolution I found was to copy everything from /libs/wcm/foundation/components/basicpage/v1/basicpage/* and then apply the changes I wanted accordingly.

 

Hope this helps.

 

 

 

Avatar

Level 4

Going to give this a try today. You may be right on the mark, as this was something we JUST implemented a change for (hiding unwanted OOTB navigational components).

 

Will check back in a bit. Thanks!

Avatar

Level 4

Success.

 

This seems contrary to the proposed nature of how overlays are supposed to function? But I agree, this seems to have fixed the issue.

 

Thank you for spending the time to reply!