Fixed Upgrading/Installing Addon with Wincache Enabled Crashes XenForo

benFF

Well-known member
Affected version
2.2.8
When using Wincache as the config.php cache option, if you install/upgrade an add-on then XenForo will crash at the final step and stay crashed until you clear the Wincache usercache.

Checking the php_errors.log, the crash is caused by the cache not being flushed/updated and being invalid when xF tries to come back online.

The work around is to disable cache, do the upgrade, clear the Wincache usercache then re-enable it - but this is a right pain, so it would be nice if this could be done automatically as part of the install/upgrade routine (possibly only needs the wincache_ucache_clear function to be run).
 
CLI Search index rebuild crashes as well

Code:
An exception occurred: [ErrorException] [E_WARNING] array_key_exists() expects parameter 2 to be array, bool given in src\vendor\doctrine\cache\lib\Doctrine\Common\Cache\CacheProvider.php on line 98
#0 [internal function]: XF::handlePhpError(2, '[E_WARNING] arr...', 'W:\\HostingSpace...', 98, Array)
#1 src\vendor\doctrine\cache\lib\Doctrine\Common\Cache\CacheProvider.php(98): array_key_exists('xf[data_codeEve...', false)
#2 src\XF\DataRegistry.php(115): Doctrine\Common\Cache\CacheProvider->fetchMultiple(Array)
#3 src\XF\DataRegistry.php(83): XF\DataRegistry->readFromCache(Array, Array)
#4 src\XF\DataRegistry.php(228): XF\DataRegistry->get(Array)
#5 src\XF\App.php(1796): XF\DataRegistry->offsetGet('codeEventListen...')
#6 src\XF\Container.php(31): XF\App->XF\{closure}(Object(XF\Container))
#7 src\XF\App.php(1580): XF\Container->offsetGet('extension.liste...')
#8 src\XF\Container.php(31): XF\App->XF\{closure}(Object(XF\Container))
#9 src\XF\App.php(2839): XF\Container->offsetGet('extension')
#10 src\XF\App.php(2867): XF\App->extension()
#11 src\XF\App.php(1407): XF\App->extendClass('XF\\AddOn\\Manage...')
#12 src\XF\Container.php(31): XF\App->XF\{closure}(Object(XF\Container))
#13 src\XF\App.php(2323): XF\Container->offsetGet('addon.manager')
#14 src\XF\App.php(1895): XF\App->setupAddOnComposerAutoload()
#15 src\XF\Cli\App.php(25): XF\App->setup()
#16 src\XF.php(490): XF\Cli\App->setup(Array)
#17 src\XF\Cli\Runner.php(54): XF::setupApp('XF\\Cli\\App')
#18 cmd.php(15): XF\Cli\Runner->run()#19 {main}
 
Yes, but until the bug is resolved/this thread is responded to, to prevent the site from crashing, disable the cache.
 
Ah gotcha!

For day to day end user running it seems to be fine on production, I catch all the crashes when making admin changes on staging first :)
 
It looks like this might actually be a bug in WinCache. According to the documentation, passing an array to win_ucache_get should give back an empty array when there are no matching items, but it seems to be returning false instead. I don't have a Windows environment handy to test with, but can you see if replacing line 80 of src/vendor/doctrine/cache/lib/Doctrine/Common/Cache/WinCacheCache.php with the following line fixes this for you?

PHP:
        return wincache_ucache_get($keys) ?: [];

If so then we can include this as a work-around, but I would caution that WinCache seems like it may have been abandoned so it's probably worth looking into a different cache provider soon.
 
I don't have a Windows environment handy to test with, but can you see if replacing line 80 of src/vendor/doctrine/cache/lib/Doctrine/Common/Cache/WinCacheCache.php with the following line fixes this for you?
Perfect! Thank you - that will save me so much time :)
If so then we can include this as a work-around, but I would caution that WinCache seems like it may have been abandoned so it's probably worth looking into a different cache provider soon.
Yes, there is still work going on bringing it to PHP 8 - but for now, I'm ok running 7.4 :)

thank you again!
 
Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.2.9).

Change log:
Work around an upstream issue in WinCache
There may be a delay before changes are rolled out to the XenForo Community.
 
Oh is there an updated hashes file I can use, so I don't get the "modified file" errors now?
I'm reluctant to advise this officially, but you can edit src/addons/XF/hashes.json to update the sha256 hash of the file if it's especially bothersome.
 
2.2.9 didn't fix this.

Error:

Code:
An exception occurred: [ErrorException] [E_WARNING] array_key_exists() expects parameter 2 to be array, bool given in src\vendor\doctrine\cache\lib\Doctrine\Common\Cache\CacheProvider.php on line 98
#0 [internal function]: XF::handlePhpError(2, '[E_WARNING] arr...', 'W:\\HostingSpace...', 98, Array)
#1 src\vendor\doctrine\cache\lib\Doctrine\Common\Cache\CacheProvider.php(98): array_key_exists('xf[data_codeEve...', false)
#2 src\XF\DataRegistry.php(115): Doctrine\Common\Cache\CacheProvider->fetchMultiple(Array)
#3 src\XF\DataRegistry.php(83): XF\DataRegistry->readFromCache(Array, Array)
#4 src\XF\DataRegistry.php(228): XF\DataRegistry->get(Array)
#5 src\XF\App.php(1797): XF\DataRegistry->offsetGet('codeEventListen...')
#6 src\XF\Container.php(31): XF\App->XF\{closure}(Object(XF\Container))
#7 src\XF\App.php(1581): XF\Container->offsetGet('extension.liste...')
#8 src\XF\Container.php(31): XF\App->XF\{closure}(Object(XF\Container))
#9 src\XF\App.php(2840): XF\Container->offsetGet('extension')
#10 src\XF\App.php(2868): XF\App->extension()
#11 src\XF\App.php(1408): XF\App->extendClass('XF\\AddOn\\Manage...')
#12 src\XF\Container.php(31): XF\App->XF\{closure}(Object(XF\Container))
#13 src\XF\App.php(2324): XF\Container->offsetGet('addon.manager')
#14 src\XF\App.php(1896): XF\App->setupAddOnComposerAutoload()
#15 src\XF\Pub\App.php(93): XF\App->setup(Array)
#16 src\XF.php(497): XF\Pub\App->setup(Array)
#17 countryUpdate.php(11): XF::setupApp('XF\\Pub\\App')
#18 {main}

(countryUpdate.php is a file I am running in root to update a few things - the lines before and including the crash are)

PHP:
<?php

error_reporting(E_ALL & ~E_NOTICE);

/** @var  $fileDir */
$fileDir = __DIR__;

require($fileDir . '/src/XF.php');

XF::start($fileDir);
$app = XF::setupApp('XF\Pub\App'); #crashes here

Runs fine with Wincache disabled.
 
Strange, testing locally shows that our patched class is loaded with exactly the same fix as above. I'll have to take a closer look, moving this back to open bugs for now.
 
Strange, testing locally shows that our patched class is loaded with exactly the same fix as above. I'll have to take a closer look, moving this back to open bugs for now.

I finally found out what was causing this - Wincache was disabled under CLI (wincache.enablecli) - when I enabled it, this error went.
 
So I think on the whole we can agree this is resolved and we don't have any further action to take.

Though I wanted to use this opportunity to point out that starting with XF 2.3 we will no longer be supporting Wincache as a caching provider.

There's numerous reasons this isn't really viable going forward. Not least being it doesn't appear as though Wincache has any version compatible with PHP 7.2 or above, and the minimum requirements for XF 2.3 will be PHP 7.2.5 and above.

For the most part, the native opcache within PHP will do the same or better job than Wincache anyway.

Finally, we're moving to Symfony Cache from Doctrine Cache in XF 2.3 and they just do not have a Wincache adapter available most likely for all of the reasons stated.
 
Finally, we're moving to Symfony Cache from Doctrine Cache in XF 2.3 and they just do not have a Wincache adapter available most likely for all of the reasons stated.
Does this mean every location touching \XF::app()->cache()->fetch() and \XF::app()->cache()->save() is going to be requiring changing? That will be painfully disruptive :(
 
Back
Top Bottom