Clone custom field array/object values on retrieval

[brandonkelly]

When accessing a custom field value on an element (element.myCustomField), if the value is an array or object, it should be cloned automatically before being returned by __get().

This will solve a lot of the confusion that has stemmed from the new element query behavior in Craft 3 (e.g. #2929, #3477, #5637), as each time you call element.myRelationalField you’d be working with a fresh copy of the field value.

This change in behavior has the potential to break some plugins/templates, if they happen to be relying on the current behavior, but I suspect there are far more cases where this would fix unknown/unresolved bugs due to templates unwittingly assuming Craft 2 behavior.

[narration-sd]

Great call...!

[Anubarak]

Please no. It causes more issues because of avoidable overhead. I was glad it was removed during the release of Craft 3 and I would have to adjust nearly all of my projects with this change.

You clearly stated this great improvement in the release notes of Craft 3 and it's explained in the docs (plus it was obvious for me in the beginning).
I don't think it's a good move to include this breaking change just because people don't know/understand how it works. Calling objects by reference is a well known, approved concept in programming

[brandonkelly]

@Anubarak To be clear we would only clone the objects on retrieval from element.myCustomField. I’m not proposing that we fully revert to Craft 2 behavior. So this would still work the same as it does now:

{% set query = entry.myEntriesField %}
{% do query.type('blogPost') %}
{% set blogPosts = query.all() %} → would still return blogPost entries only

[Anubarak]

But it will increase the DB queries as well. When you clone the query, the result won't be cached.

Please use a config setting whether to clone or not to clone object on retrieval.
You made so many breaking changes in Craft CMS 3.x it's no joy at all to update it.
Most of my projects are not even considered to be updated anymore because it's a mess. The new features and bugfixes are not worth the time it takes to fix the newly created incompatibilities a new version caueses, especially when so many places are affected.
I really don't remember all lines of code for every project where I rely on calling values by reference rather than value. It's even worse when I have to update a project that was created by someone else in the company.

When you do it via config setting and one is able to turn it off, I'm fine with it.

[brandonkelly]

Query results aren’t cached to begin with, unless setCachedResult() was called, which is only used by Matrix (and similar field types) when we need to store the blocks that are being saved.

I agree we’ve made way too many breaking changes in 3.x, and I’m sorry for the trouble that has caused. We are fixing that with a new annual release cycle that will start with Craft 4, where breaking changes will always be pushed back to the next major release. I suppose it would be better to follow suit with this one too, so will change the milestone to 4.0.

[Anubarak]

Thank you very much.
Don't get me wrong, I really really adore Craft and it's features and really love the CMS over all. You all do a great job. I was a too harsh in my comment, sorry - I was just a little bit down when I imagine I have to search the 80.000 lines of code in my current project and remove/change all pieces because of the change.
I made a system that relies heavily on DateTime objects and often used the short syntax

$element->getFieldValue('dateTime')->modify('+x minutes');

instead of

$element->setFieldValue('dateTime', (clone $element->getFieldValue('dateTime'))->modify('+x minutes'));

[brandonkelly]

@Anubarak Cool, this is exactly why there have been too many breaking changes in Craft 3 – we make assumptions about how people are/aren’t using existing features, and those often end up being wrong.

[narration-sd]

What a great conversation, both.

And yes, Brandon, also if you include how people are likely to have instinct to use freshly created features; and then we have the framework for improving over their full span of evident presence, the drafts.

There's been a very large amount of ingenuity, each in a fork, along the way of the last year -- and then what could help meld these together into a fully renewed whole, would have been drawing back more regularly, I suspect, into a quiet status of reflection.

When this can happen, you get something better than with just continuing the energy into a momentum of completion.

Maybe there's even a way you can think of drawing a visible set of periods for it, into your new framework of plans for each year, first where you reflect internally, make substantive adjustments; and then after, have a true beta period, where this fine eager bunch of others can pitch in, with full spirit and presence of it.

[narration-sd]

...just thoughts, of course; sometimes as you probably know, I get more literary mornings... :)

[brandonkelly]

Added for Craft 4 (#10101).