Joomla! 3.6 Cache Changes
By Michael Babker, Published on
With the release of Joomla! 3.6, additional error handling was introduced to the caching layer to help prevent issues. Unfortunately, this has exposed some misconfigured sites and has been met with calls for the change to be reverted and for Joomla to essentially discard cache layer errors silently. I'm going to explain here why the changes were made, how this is consistent with the rest of the method's error checks, and what can be done to make this error happen less frequently.
I submitted a pull request which made a change to the
JCacheStorage::getInstance() method to check that the requested cache storage adapter is supported on the local server which validates the adapter should be safe to use. It was a partial response to a bug report in which a Joomla installation was using a cache adapter that was not functioning after a PHP configuration update, resulting in a PHP Fatal Error. The support check causes
JCacheStorage::getInstance() to throw a
RuntimeException if the adapter is not supported instead of returning an adapter which cannot function and its use could lead to other errors.
This error handling is consistent with other checks already in
JCacheStorage::getInstance(), specifically how it will throw a
RuntimeException if an invalid adapter type is provided which prevents instantiating a class that doesn't exist in PHP, another fatal error and one that can only exist due to an application misconfiguration.
To trigger the new "Cache Storage is not supported on this platform" error, there must be a configuration issue present in the Joomla installation. The common issue comes from the file cache handler, which requires that the configured cache directory (either a custom path defined with the
cache_path parameter in the configuration or the
cache directory on the frontend or
administrator/cache directory for the backend) is writable. If this path is not writable, the cache store will report itself as not usable and cause the
RuntimeException to be thrown. Another potential example includes if APC(u) is configured as the cache storage adapter but the PHP extension is not installed or disabled.
If you get the above error, you will need to validate your cache configuration and that the configured adapter can be used. For the filesystem adapter, this means ensuring the
administrator/cache (or the path defined in the
cache_path configuration parameter) is writable. For other adapters, this generally means ensuring the PHP extension is installed, enabled, and functioning.
Some have suggested that Joomla's cache API should have a graceful fallback or swallow any errors to allow the site to continue functioning. At a high level, this is a bad behavior to accept because it causes errors to be masked. This however does not mean that errors can't be caught or consumers of the cache service implement their own fallbacks. The cache API throws
RuntimeException for "critical" failures (either the controller or storage adapters not being found, the storage adapter being unsupported, or failing to connect to a Memcache(d) instance), so consumers could wrap their cache interactions in a try/catch block to catch these exceptions and implement an error handling mechanism in the case of a major failure with the cache API.