You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 4, 2018. It is now read-only.
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:
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
The text was updated successfully, but these errors were encountered:
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)
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).
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:
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:
fluidcontent/Classes/Service/ConfigurationService.php
Lines 137 to 142 in d438d35
$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
The text was updated successfully, but these errors were encountered: