fluidcontent cannot be installed with clean caches

[helhum]

When automating deployment with TYPO3 Console a usual way is to generate the PackageStates.php with a command, which marks extensions as active and after that running typo3cms extension:setupactive

This currently does not work with fluidcontent and here is why:

• It registers a cache, which by default has a database backend
• It registers a hook, which is triggered, when ext_tables.php are processed
• This hook tries to access the cache

During activation of the extension ext_localconf.php is read, which registers the cache, but the tables are still missing.

After that ext_tables.php is read and the hook is triggered. Since the cache is there, the mitigation implemented here: https://github.com/FluidTYPO3/fluidcontent/blob/d438d3558094900ca3845a0c9c26e88f71c2c55e/Classes/Service/ConfigurationService.php#L137-L142 does not work and $cache->has() fails with an exception.

Steps to reproduce:

Have a TYPO3 8.7.x composer installation composer require fluidtypo3/fluidcontent typo3cms install:generatepackagestates # or manually add the extension to PackageStates.php typo3cms cache:flush # or manually delete typo3temp/var/Cache

The easiest way to solve would be to set $cacheExists as well to false on cli request, as this is the most likely way how this bug can be triggered and caches should not be needed on cli, or at least it does not hurt much when the cli run is a bit slower.

Another option would be to bring your own database backend which inherits from the TYPO3 one, which gracefully returns false when an exception occurs on checking/fetching the cache

[dacostafilipe]

Just as a note, I had the same issue when completing the Typo3 installation with the Install Tool.

I've installed everything with composer install and continued on the Install Tool where after the first step (where the system is checked) I've got the same errors. (Table ‘typo3.cf_fluidcontent’ doesn’t exist)

[helhum]

Although I still consider the code I mention a bit hacky, the bug it causes can only be triggered in special cases (especially with automating with TYPO3 Console).

Since I now found a way to fix this (https://github.com/TYPO3-Console/TYPO3-Console/pull/534),

I think this can be closed.

[NamelessCoder]

Thanks Helmut - I'll keep this open so I don't forget to clean the dirty checks.