Bug #55252
closedPHP 5.5 and require LocalConfiguration
100%
Description
I tracked down an issue on the 123 installer with dbal #53997 to the point that LocalConfiguration isn't included correctly with "require" on PHP 5.5 wit OPcache. As the OPcache is default on, we should fix this.
TYPO3\CMS\Core\Utility\ConfigurationManager is responsible for handling the LocalConfiguration.php, the DBAL autoloader requests to add adodb and dbal to the required extensions, which fails (or do not work correctly) and this courses an endless redirect loop.
What happens in ConfigurationManager on a write (by adding adodb):
- require LocalConfiguration.php
- Merge array with new configuration for 'EXT/extListArray'
- write LocalConfiguration.php
After this, the old configuration still exists in the OPcache. If we now add dbal:
- require LocalConfiguration.php (The old one from start of process so without adodb)
- Merge array with new configuration for 'EXT/extListArray'
- write LocalConfiguration.php (with dbal but without adodb)
=> Issue 1: We are missing adodb!
The OPcache only checks every 10 seconds (or so) the timestamps (to be fast) so the dbal redirect comes to the point that dbal isn't installed, installs it and does the redirect, till the browser ends this loop after 20 steps.
=> Issue 2: Our written config isn't there after reload.
3 ways to fix, if OPcache is available:
- opcache_compile_file => Available from PHP 5.5.5 onwards, so no option
- opcache_reset => This do not help against issue 1 as the second require will get the same data as the first require, even though opcache_get_status tells us, that no file is in cache. Beside of it clears to much.
- opcache_invalidate is the way to go, after writing the PHP file, which we require self.
IMHO this issue also needs to be fixed for the CachingFramework for the PHP cache and maybe in more places.
To resolve this issue, I would propose to create a new Utility Class, which will provide clearing cache for a file for OPcache, APC and maybe more.
Files