There's alot on how to make components, but in this specific example, we have a configuration page node that calls in configuration components that the author needs to edit in the authoring mode. We received an ask to reduce the screen clutter by introducing a way to separate some of these configuration components; we have a tab nav ui element we use on the public facing page nodes, but the problem I have is that you can't interact with it because the authoring 'overlay' paints over it.
Is there a way to pass a click from the authoring overlay to the underlying content?
When you're in the authoring edit mode, it displays the content in an iframe, and the authoring ui in a div with id="OverlayWrapper" - but because that 'overlaywrapper' is 'above' in terms of z-index of the whole content area, an author can't interact with the content behind it to use the tabbed nav to switch between the various configuration components we have.
Simply put - we're looking for a way to either bubble up something from the content level to allow it to be interactive (and then refresh the painted area for editable components) OR pass something down from the overlaywrapper for it to interact with the content (and again, then refresh the area for editable components)
Can you show in a video what you mean by an author cannot access something. You state:
"an author can't interact with the content behind it"
An author should be able to interact with all components on a page (unless that is part of an editable template that is locked),
But for typical components on a parsy - an author should be able to click on the component and edit it via a component dialog. You should not have to modify the way AEM displays components.
So It seems like I'm not doing a very good job of explaining this.... Let me try again:
I've got an editable page with a tab nav on it. That tab nav is not an AEM component. Those tabs in the tab nav do have AEM components (they're used for configuration). On tab one, which is active, I can see those AEM components and they're editable. However, the author can't interact with the second tab to switch over to see the second batch of components on that tab.
We're looking for a way for the author to be able to interact with that non-aem tab nav.
that's unfortunate and I agree that's it is hard to edit configuration in that case. You should use the WCMMode and display a much more simple way when you are in WcmMode.edit to make the editing process easier. And display the "correct" tab navigation in every other wcmmode.
That isn't super convenient but you then have a clear separation between editing and preview. And it works.