TYPO3 Core

Two hours later:

The fix should rather go to /extbase/Classes/Validation/Validator/GenericObjectValidator.php:

    protected function getPropertyValue($object, $propertyName)
    {
        // @todo add support for lazy loading proxies, if needed
        if (ObjectAccess::isPropertyGettable($object, $propertyName)) {
            return ObjectAccess::getProperty($object, $propertyName);
        }
        throw new \RuntimeException(
            sprintf(
                'Could not get value of property "%s::%s", make sure the property is either public or has a getter get%3$s(), a hasser has%3$s() or an isser is%3$s().',
                get_class($object),
                $propertyName,
                ucfirst($propertyName)
            ),
            1546632293
        );
    }

I'm having the exact same bug and I'm totally stuck as I have a lazy dependency to static_countries and extbase tries to validate $countryZones in the Country model which will crash because of this.

How to reproduce:

Create a model A with a lazy dependency $country to static_countries and validate model A.

Workaround: make all affected properties public.

Same problem. Workaround to make the property in question public worked. But going by the call trace this will hurt performance as Symfony triggers _loadRealIstance for single reference lazy loaded properties. A fix would be greatly appreciated.

I experienced a case which might be related here. Had a list of objects "a" and using fluid I wanted to access a property nested some hierarchies deeper (here: d). So I simply tried to output the variable {a.b.c.d}. That resulted in "null" since c wasn't yet loaded (marked as Lazy in the relation b to c). First doing a debug-output for {a.b.c} triggered the loading and then d was accessible as expected.

Discussed this with Mathias Brodala who agreed that "LazyLoadingProxy" might be part of the issue here. He mentioned probably dropping LazyLoadingProxy and "[...] ATM this could only be implemented using generated proxy classes like News or Doctrine ORM does".

Stumbled upon the same error but in my case setting a default value (null) for the property fixed the issue for me (v10, php 7.4).

I stumbled upon this as well and I wonder how that ever worked in the past but I have the feeling that Extbase simply opened the property via reflection which symfony/property-access does not do.

I would propose the following quick fix:

// LazyLoadingProxy.php

public function __get($propertyName)
{
    $realInstance = $this->_loadRealInstance();

    if ($realInstance instanceof AbstractDomainObject) {
        return $realInstance->_getProperty($propertyName);
    }
    return $realInstance->{$propertyName};
}

It's not a real solution but it prevents errors that didn't occur in the past.

Verified that the patch Alex suggested works and I think this is a better solution than making properties public.

I "solved" the issue locally by XClassing \TYPO3\CMS\Extbase\Persistence\Generic\LazyLoadingProxy and overwriting __get() as Alex suggested.

Torben Hansen wrote in #note-9:

Verified that the patch Alex suggested works and I think this is a better solution than making properties public.

I "solved" the issue locally by XClassing \TYPO3\CMS\Extbase\Persistence\Generic\LazyLoadingProxy and overwriting __get() as Alex suggested.

Not sure why my initial approach to fix it was never accepted....

@Till: Maybe because you never created an actual code change in gerrit? Just by commenting here, the code does not find its way into the core :D

Patch set 2 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74072

Quick poll: should this fix be backported for v10 or only for v11? There are fears of breaking something in v10 installations where people come up with other solutions which are incompatible with Alex's solution

Patch set 1 for branch 11.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/74117

@Simon: I'd be in favor of having it backported. For us the patch in some cases was to trigger loading the real instance first thus working around lazyloaded objects.

We decided to not backport to v10 anymore - v10 instances that really need this probably established a workaround already or could pick that patch on their own.

PLEASE backport it! I finally want to pull upgrades... I reported this issue 1.5 years ago...

I tried my best to convince Christian, but he was too scared to back port it to v10 as some people might have come up with other solutions, and they might then get results with the fix which are breaking. So the best solution for v10 is to Xclass the class or make the property public or apply the patch via composer.

I can't understand this strategy. If they have their own fix, then they have to patch the code each time they get an update. How is this more convenient than dropping their own solution?

And if there are many people who had an issue with this, then why only a few reported it? I reported the issue and hold back all our clients updates for 18 months, for nothing... Strange to care more for the few people who might have an issue than to care for people who obviously have an issue and reported it.

By the way: I wonder how this fix could negatively interfere with other solutions...

Hey Till.

I understand your frustration this has not been fixed anymore in v10.

The current state of v10 is 'old-stable': Only security fixes and critical issues like browser crashes are still fixed in v10.

As a maintainer, my main goal is to absolutely not break anything in v10 anymore - a regression at this point in v10 lifetime would be really ugly.

This bug is for most people not considered critical. Instances with this issue probably worked around it already, and it's not a bug that we introduced recently - it is not a patch level regression. The patch itself is just a couple of lines, so instances that really need it, could apply the patch on their own and test if everything is still fine. I assume that the majority of instances is not affected by the bug in the first place. But the patch is in a low-level area of the extbase framework and it's really hard to be 100% sure it can not break something. This patch is far away from a no-brainer, and as such risky.
I picked up the patch and took responsibility by merging it. Considering the above points I don't feel good enough to take the additional responsibility for a v10 merge. Maybe some other core maintainer is more relaxed and can be convinced to additionally backport this to v10, I'm not.

I'm aware users, devs and maintainers have different views on this topic. It's not always easy to balance these things and I hope you understand my decision, although you may disagree in this case.