WIP: Query Loop Conflict in Nested Component Instances within Slots

There is a significant issue regarding the isolation of Query Loops when using the new Component System. When multiple instances of the same component (e.g., a “List-Item” component) are placed inside a Slot of a parent component (e.g., a “Specs” wrapper), the Query Loop settings of the first instance override all subsequent instances. It appears that the query context is not properly scoped to the individual component instance when rendered via a slot.

Steps to Reproduce

  1. Create a component “Specs Wrapper” containing a Slot.
  2. Create a child component “Specs Item” that contains a Query Loop (e.g., fetching terms from a taxonomy).
  3. Insert the “Specs Wrapper” into a page.
  4. Drop three instances of the “Specs Item” component into the wrapper’s slot.
  5. Configure a unique Query Loop for each instance:
    • Instance 1: Query Taxonomy “Cars”
    • Instance 2: Query Taxonomy “Buildings”
    • Instance 3: Query Taxonomy “Plants”
  6. Check the frontend output.

Expected Result

Each instance should maintain its own query context and display unique data:

  • Row 1: Cars
  • Row 2: Buildings
  • Row 3: Plants

Actual Result

All three instances display the results from Instance 1 (Cars).

  • If Instance 1 is deleted, Instance 2 and 3 suddenly show “Buildings”.
  • If Instance 2 is then deleted, Instance 3 finally shows “Plants”. The query configuration seems to be “leaking” or being cached based on the component definition rather than the specific instance settings when placed inside a slot.

// Addendum:
This works and is currently my workaround. However, it would be beneficial if it also worked with slots.

Hi,
Thanks so much for your report!

Unfortunately, I cannot reproduce the problem (probably doing something wrong). Can you please either export your layout (and, if possible, the components individually) so we can test with your exact setup? Thanks!

Best regards,
timmse

I sent you a message.

Thanks so much!
I can replicate the issue and added it to our bug tracker. We’ll update this thread once it’s fixed.