Content Tree: Any component which uses core/wcm/components/image/v3/image as super type always displays as a root item in the content Tree

[DennisAtDept]

We are trying to make better use of the core components, but we did notice they (Image V3) have some weird quirks


Normally when you have a container component and place sub components inside of that grid, this is reflected in the Content Tree

e.g.

SectionComponent
---> GridComponent
-------> GridItemComponent


However in this case we would have a GridImageItemComponent

But it shows up like this in the Content Tree

SectionComponent
---> GridComponent
-------> GridItemComponent
GridImageItemComponent

We would have expected this component to be visible like that:
SectionComponent
---> GridComponent
-------> GridItemComponent
-------> GridImageItemComponent



We downloaded the source of the v3 image component, but could not find anything weird in the files that might caused this.
Do you guys know why this is happening, what would we need to overlay to make the core image component behave similar as the other components when dealing with the Content Tree view within the AEM editor.

Thank you in advance!

Kind regards,

Dennis

[arunpatidar]

Hi @DennisAtDept 

Please check if helps https://medium.com/@arunpatidar26/cq-iscontainer-property-in-aem-94e5318e04fa 

[SantoshSai]

Hi @DennisAtDept,

The issue seems becuase of:

1. Missing cq:parentPath association

If a component renders outside the container’s DOM scope, or lacks certain metadata, AEM doesn't attach it correctly in the editor tree.

2. Image v3 uses data-cmp-is=image and is DOM-self-contained

Core Image V3 component uses its own isolated HTML output with no explicit support for slotting within parent containers' data-path blocks unless you explicitly manage layouting.

It doesn’t automatically inherit a cq:parentPath unless wrapped inside a container component with correct structure.

To resolve your issue try this:

1. Wrap v3/image in a container

Create a proxy component or wrapper (eg. GridImageItemComponent) like this:

<sly data-sly-resource="${'image' @ resourceType='core/wcm/components/image/v3/image'}"/>

But more importantly, in your wrapper component’s cq:editConfig.xml, include:

<jcr:root
    xmlns:cq="http://www.day.com/jcr/cq/1.0"
    jcr:primaryType="cq:EditConfig">
    <cq:dialogMode>floating</cq:dialogMode>
    <cq:layout>
        <cq:dropTargets jcr:primaryType="nt:unstructured"/>
    </cq:layout>
</jcr:root>

This hints to the editor that the image is part of the layout and belongs within the hierarchy.

OR

2. Use cq:isContainer="true"

In your wrapper component’s cq:editConfig.xml or cq:component, add:

<jcr:root
    jcr:primaryType="cq:Component"
    cq:isContainer="{Boolean}true"
    componentGroup="Your Group"/>

This helps AEM understand that your component acts as a container in the Content Tree.

[DennisAtDept]

Hi Santosai, 

I think i found the culprit in my situation.

The container component was already set to be a container so this was already fine.
But we are storing the images in a seperate "folder" node 

e.g.
image_gallery/images/item0

instead of 

image_gallery/image_gallery_item

The reason for this is that we wanted to use a Multifield to also let the users edit these images from the edit dialog of the container component.
But also want to keep the functionality to edit the component directly on the page itself using the edit dialog of the image component itself.
 
I think because of the extra "nt:unstructured" node  which act like a folder node, AEM is getting confused as it probably did not expect the item component to be placed 1 layer deeper.

[kautuk_sahni]

@DennisAtDept Just checking in — were you able to resolve your issue?
We’d love to hear how things worked out. If the suggestions above helped, marking a response as correct can guide others with similar questions. And if you found another solution, feel free to share it — your insights could really benefit the community. Thanks again for being part of the conversation!

[DennisAtDept]

Hi Kautuk,

We were not able to fix the issue in a timely fashion, we reached the end of the timebox and accept the fact that in our particular case it is not working as intended.
We do plan to revisit this in the future, but not sure when.