Fixed Upgrading/Installing Addon with Wincache Enabled Crashes XenForo

[Chris D]

It may/will be painful, yes.

I have some ideas to mitigate but haven't tested them yet.

The current pain points are:

• CssRenderer::__construct signature has changed and this method is extendable with the XFCP
• Cache adapter objects are obviously different types now so third party code which expects particular types for arguments or returns will break and will need updating
• The API is slightly different, as you note, with \XF::cache()->fetch($key) (more or less) becoming \XF::cache()->getItem($key) and \XF::cache()->save($key) now requiring a cache item to be passed in rather than a string cache key.

As it stands, this will break pretty much everything for customers who have add-ons that touch any of the above.

One mitigation I'm thinking of is having some sort of generic wrapper class which takes the real Symfony cache object as an argument, and we can have slightly more familiar fetch and save helper methods attached which proxy through to the adapter class.

This doesn't solve all of the above but the API changing is probably the most significant (in that it's not quite a simple find and replace).

 

[Jeremy P]

Just wanted to follow up to say we're implementing a compatibility shim for Doctrine Cache (enabled by default) which should mitigate any BC breaks (aside from unsupported adapters). An optional third argument can be passed to \XF\App::cache to get an instance of \Symfony\Component\Cache\Adapter\AbstractAdapter instead.