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:
Additionally, the add component button on any parsys has disappeared:
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:
Any insight/suggestions are appreciated.
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
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.
@JaredAtUD - Are you able see components in policies/component groups in templates?
Components appear in all sidebar lists and pre-baked template areas as they're supposed to, yes.
@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.
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:
Browser console:
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.
@JaredAtUD - Did this issue started post installing any of recent custom code? or 6.5.12.0 upgrade?
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.
@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)
Will give this a go and update here when I see some results. Thanks.
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!
@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 ?
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.
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!
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!