[5.11.0]: .owner on nested entries returns ElementCollection in Twig after owners are batch-eager-loaded

[redburn]

What happened?

Description

Since 5.11.0, accessing .owner on a nested (Matrix-owned) entry in Twig can return an ElementCollection instead of the owner element, so any chained field access throws. Example:

BadMethodCallException: Method craft\elements\ElementCollection::afbeelding does not exist.

This worked fine in 5.10.14. Claude reports: "It looks like getOwner() now eager-loads owners for the whole query result, and Element::__get prefers the eager-loaded set over the getter — hence the collection."

Maybe getOwner() is the better way, and the workaround is to use that instead, but given that the trait's docblock declares @property ElementInterface|null $owner this looks like an unintended consequence of recent changes? Might affect others as well.

Steps to reproduce

1. Query nested Matrix entries directly, e.g. craft.entries.type('myMatrixEntryType').all()
2. Loop the results and access {{ entry.owner.title }} (or any field on the owner)
3. Once one row's owner resolution triggers the eager-load, subsequent rows' .owner returns an ElementCollection and you get chained access throws

Expected behavior

entry.owner returns the owner element (or null), as documented in the docblock

Actual behavior

entry.owner returns a craft\elements\ElementCollection

Craft CMS version

5.11.0

PHP version

8.4.25

[linear-code]

CMS-2382

[brandonkelly]

Thanks for reporting that! Craft 5.11.1 is out with a fix.