c31d35a made changes to avoid loading cache storage adapters when caching was disabled. Included in 3.6.3. This factory method does not take into consideration the caching state, especially as it can be set in an individual JCache instance.

The other option is to petition to PLT to reconsider #12562 as several users since the offending lines were introduced with 3.6.0 have groaned that the extra validation has brought down their sites.

Just to add also, the checks added in 3.6.3 only apply to fetch and save operations. We purposefully didn't add the checks to delete operations; even if caching is disabled (either globally or in the active JCache instance) one should still be able to clear their cached data and adding "cache enabled" checks to these methods would block that.

Disabling caching, does not force individual extensions not to cache anything,

it is up-to every extension to still cache something, that they know not to change or they consider important to cache it, right ?

(I do not say do view-caching etc, i just say some data are may still be cached by various extensions and template frameworks, etc or it maybe enabled individually in extensions)

Make sure the system's "cache" folders (site and administrator) have their permissions set to be unwriteable

so, ok this is a newly thrown error

but correct me, it is a requirement for proper site operation that they are writeable,
just with previous joomla version, the attempts of the extensions to cache something failed silently (and execution continued to get the data by executing code)

which makes me think that "hiding" the parameter "Cache handler" with "showon" in global configuration is not proper

For reference the lines Cory linked specifically were added in part to deal with conditions where a site was migrated and the previous cache configuration didn't work on a new server (Walt had a condition where he migrated a site using Memcached to a new server where it wasn't available and the site was hitting fatal errors dealing with that). So the check's perfectly valid in that context, it just also has side effects of raising errors in other cases like misconfigured permissions on shared hosting or an environment where the directories can't be written to at all for one reason or another. That's why the checks in 3.6.3 should keep this from getting executed in the context of JCache, but if someone's direct instantiating a handler through the factory there isn't much we can do there.

which makes me think that "hiding" the parameter "Cache handler" with "showon" in global configuration is not proper

Well, yes and no. For the global configuration it's fine, but if extensions are trying to use cache based on the global config and ignoring the cache state then it does cause issues.

If individual extensions need caching, shouldn't they throw their own errors if the cache folders are not writeable? To me, if I disable caching in the global configuration, then it should be irrelevant whether or not my cache folders are writeable.

Also, if it's going to throw an error, shouldn't the message be more descriptive? It just says something to the effect of "File cache handler is not supported on this system," which says nothing of why it's not supported. If the message had said "File cache handler is not supported on this system because the cache folder permissions are not writeable" I could have easily resolved the issue for myself. Instead, I had to dig into the code to figure out why it was giving me an error. Not a big deal for me, but for the average user this would be virtually unsolvable.

IMHO we should remove mentioned code:

https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/cache/storage.php#L171-L174

and place it at the beginning of __construct probably before parent::__construct($options); for every storage.

That won't hide the error but an exception message will be more appropriate per storage.

After that we won't need to call isSupported method on getConnection like at:

https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/cache/storage/memcached.php#L65

What do you think?

Personally I'm not the biggest fan of checks like that in a constructor unless they are really the only place you can rely on them. It also doesn't really improve the messages much and I don't think we should be putting that level of server related detail into a message that is most likely going to be displayed to an end user because nothing is catching exceptions from the cache API.

We can create a storage instance manually when it is not supported (like new JCacheStorageFile):

• without calling isSuported() at:
  • apc, apcu, file, xcache, wincache
• with calling isSupported() in geConnection():
  • memcache, memcached and redis
• or
  • cachelite will trigger fatal error after require_once 'Cache/Lite.php';

As mentioned above memcache(-d) and redis check support once again before create connection.

The best way would be to have all storages behave in the same way.
Current joomla checks that before creating instance as a workaround.

isSupported() isn't a thorough check in all cases, and really can't be for all adapters. For the three connecting to an external server, as you pointed out before if we check if the configuration is valid to connect to the server in isSupported() it blocks being able to configure the connection via the UI, so they have to do the added connection checks at runtime.

isSupported() really should be high level checks that are safe to perform. In most cases this is basically if the underlying PHP requirements are met. For that part I don't think we need the isSupported() checks in the constructors. So to me it's fair that isSupported() is used independently of instantiating the class.

These types of checks really shouldn't be happening in the class' instantiation. If we had a proper service layer, that would be throwing the exceptions if the environment is unsupported or the runtime connections couldn't be established and the handlers would be left to just function with blissful ignorance to anything else in the environment, but sadly we aren't there yet.

Ok, then isSupported() should be call before create a new instance of storage.
Then check that again in contructor or geConnection() is not needed.

The other thing is that nothing is catching exceptions from cache.
IMHO this should be changed.
Cache only helps joomla and it should not block all page.

If cache failed (means throw exception) then only error message should be generated for admin or end user.

May be JCacheController subclasses can add try {} catch() {} statement in get and store methods.
JCacheController has also __call method.

IMHO this should be changed.
Cache only helps joomla and it should not block all page.
If cache failed (means throw exception) then only error message should be generated for admin or end user.

This is exactly what i wanted to suggest,
some errors do not need to be fatal !!

A more graceful recovery is good (when possible), and a message at the admin side is enough to give time to the administrator users to fix the issue, without the site getting down for a "long" period

This is only "fatal" because nothing catches and handles the exceptions thrown by the API. Implement correct try/catch blocks and the "fatal" part of this goes away and you can have all the graceful degradation you want.

JCache itself should NOT be aware of the active application (and it still pisses me off to no end there is code handling just that in the Redis adapter). That's the point of having decoupled high level APIs like this one, our high level libraries shouldn't have intricate and difficult to trace inner dependencies such as active objects in JFactory (all of those dependencies just make testing this code harder because you have to mock much more of the environment with "working" objects).

EVERY error that I've personally added this year is catchable everywhere. It's not my fault the core CMS and the extension developers suck at catching exceptions.

Thanks Michael for description.

And going back to the issue:
@corywebb Can you confirm that you used plugin System - Page Cache?

@csthomas no, System - Page Cache is not being used. I have cache completely disabled on the site, which is why I was surprised to be getting a fatal error about the cache system.

@corywebb You can have 3rd party extension that uses cache in custom way without catching exception.

The default templates with debug mode enabled will give a stack trace. Turn that on and try to trigger the error. If caching's disabled as you say and you're still getting this error then odds are that there is an extension trying to use the cache system anyway (totally possible and valid) and the trace will show what that is.

I have the same error. Ok, I have to say that my hosting provider has disabled memcache and memcached for shared server. Please, check the screenshots:

Step 1:

Step 2:

Stept 3:

I hope the screenshots can help for solution or fix.

If you're going to com_cache it makes sense there that it's trying to connect to the cache handler because it's trying to display what's in the cache.

Even if caching is disabled at a global level, data can still be cached by extensions, so it still needs to be possible to clear that cache data. If we had com_cache just display a "caching's disabled" message if it is disabled at the global level then that makes it pretty hard to use.

Also get the error if I try to change to "APC" or "File" cache system. It is normal?

I have repeated this error on my custom staging joomla from git.

Instruction:
1. disable cache.
2. remove access to write for administrator/cache, clear folder from cache items if any.
3. try to change cache handler to other handler (ex APC, memcached) and save.
4. Error: An error has occurred. The file Cache Storage is not supported on this platform.

https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_config/model/application.php#L291

That should wrap in a try/catch, there's no reason that should cause a fatal error saving the configuration.

@mbabker I don't understand... When is that solution in a Joomla stable version?

This happened on my site this morning and it's not the only time. I think the last time is months before. It's so scary cause I have to reboot the whole sever to make my site working!
So, the memcached server was really broken?

@zhous

So, the memcached server was really broken?

No, you are off-topic, memcached is not broken,
if you think it is broken you should open a new issue

• what is discussed in this thread is that Joomla will refuse to work if the configured caching is not available (=disabled / crashed / other)

In your case,

1. after some time, your memcached server process has crashed, Joomla cannot restart your server ... or anything similar ...
2. it is not Joomla that needs to be fixed, but your server, e.g. would expect Joomla to continue to work if "Apache" or "MySql" server processes crash ? ! well it does not work if the cache server process crashes too, if this should be ignored or not, this is discussed here ...

So for the problem with memcached server periodically crashing, contact your web-host ...

Now about the topic discussed in this thread, the alternative is to silently ignore the error and continue working even if the configured caching system is not available ...

• which will make Joomla continue to work, but much more slowly since caching does not works

The fact that the caching configuration was hidden when people disable the "view" caching parameter in global configuration was wrong,

In next Joomla version it will alway be shown, see the picture:

I get the same/similar problem on one server

Even cache is disabled in Global Configuration, I get:

The apc Cache Storage is not supported on this platform.
The file Cache Storage is not supported on this platform.

by every action in administration.

So the problem is - Cache is disabled, why the server throws this error - this is new installation, no cache plugin enabled, no 3pd plugin installed - fresh install.

FTP layer is enabled and the cache folders (site, admin) are the same owner as FTP and are writable by this owner. BUT caching is disabled.

Joomla! 3.6.5, PHP 5.6.30, SQL 5.5.54-MariaDB, OS Linux

FWIW with 3.7 a lot of resources that are cache aware now have exception handling in place.

@corywebb can you please test Issue on 3.7?

@franz-wohlkoenig I tested it on 3.7 and can confirm that I am not getting any errors with this.