PHP Warning: Undefined array key "native" in flux/Classes/ViewHelpers/Field/AbstractFieldViewHelper.php line 165

[ako-3004]

Migrated a stable running installation of TYPO3 from classic extension management to composer (with flux 9.7.4) - no further changes done. Afterwards got some "undefined array key php warnings" from (https://github.com/FluidTYPO3/flux/issues/2114), so upgraded flux to 10.0.10 / stable. PHP is still at 8.0.27 (upgrading soon). TYPO3 is 11.5.38.

Opening any Page in the Backend now causes the PHP Warning: Undefined array key "native" in flux/Classes/ViewHelpers/Field/AbstractFieldViewHelper.php line 165 Maybe this is not a standard behaviour but caused after the update from flux 9.x to 10.0.10?

Tried to fix the line 165 in 10.0.10, afterwards also the line 166 $component->setNative($arguments['native'] ?? false); $component->setPosition($arguments['position'] ?? ''); causing more php errors...

Now I'm using flux 9.4.7 with the fix from https://github.com/FluidTYPO3/flux/issues/2114 until a 10.0.10 reason is found.

[mogensf]

I got nearly same issue. TYPO3 12.4.16 Flux 10.0.10 PHP 8.2

After update from TYPO3 11 latest to 12 and to Flux 10.0.10 i got the Type-Error that the Argument 1 of the setNative method has to be of type bool. Null given. I first startet to set the native attribute on several viewHelper calls in my ce's. But then i changed: flux/Classes/ViewHelpers/Field/AbstractFieldViewHelper.php line 165 to: $component->setNative($arguments['native'] ?? false);

That fixed the problem for me. Will this be fixed in next version, or do i have to adjust all my ce's.

@ako-3004 If you only get php warnings about missing Array-Keys you can set the following in your AdditionalConf to suppress the warnings: $GLOBALS['TYPO3_CONF_VARS']['SYS']['errorHandlerErrors'] = 22517; $GLOBALS['TYPO3_CONF_VARS']['SYS']['syslogErrorReporting'] = 22517; $GLOBALS['TYPO3_CONF_VARS']['SYS']['belogErrorReporting'] = 22517;

[NamelessCoder]

Will this be fixed in next version, or do i have to adjust all my ce's.

It will be fixed - though I'm not sure if it will be the very next verion, or when that might be. TBH it is unexpected because $arguments['native'] should be filled with the default value of the argument (which is false as you'd expect). That happens correctly for every other argument used within that class.

Is it possible that this only happens until you flush the system caches which gets rid of the compiled Fluid templates and ensures they are recompiled with a now complete set of arguments for the ViewHelper call?

I'm aware you might not even be able to flush the system caches unless going directly through the install tool, because TYPO3 treats this error as an exception. You can also manually rm -rf var/cache/code/fluid_template to achieve the same.

EDIT: actually, if system caches are the cause then this will not be "fixed" as such (with a code change) as no fix is required. The fix will in that case be to flush the system caches, as that would solve not just this problem but any future problem of the same kind.

[mogensf]

Your right. Clearing the Cache fixes the issue. I didn't recognized this, because i patched my version via composer. So no fix is needed here.

[NamelessCoder]

Thanks for the quick follow-up; I had a hunch that it was just a compiled state of an incomplete arguments array. The fluid cache auto-updates when changes happen in templates but it doesn't catch changes that happen in ViewHelpers (class availability and arguments). Since you're using composer: I would recommend that you declare a "post autoload" execution step which runs the cache:flush TYPO3 CLI command, that should make sure that every time you run composer install or composer update you get a clean slate for not just the fluid cache but also other important caches like the ext_localconf cache. And of course it makes sense to add the same to any deployment you might use, if that deployment doesn't run composer install on the remote host.

I'll close the issue as solved since I'm quite sure it's the exact same problem @ako-3004 has.