Same problem here, my site before update has cache enabled, redis cache, conservative cache.
For let my Joomla 3.6 work, i have disabled cache by editing configuration.php and removed "redis" label from cache handler.

It seems that is not recognizing installed cache handlers.

This is what i see after upgrade from 3.5.1 to 3.6.0

My system:

Each storage adapter has a check for support. Redis and XCache are in essence checks for the requisite PHP extensions.

If your systems can't pass those checks, then Joomla now detects this and throws an Exception versus allowing the system to continue and attempt to use unusable storage adapters.

After you manually adjust your configuration.php file to either use the 'file' adapter (or none at all), log into your Joomla admin and go to the global configuration. The part where you can configure the cache settings lists all adapters that Joomla detects it can work with. If your preferred adapter isn't in that list then something isn't configured correctly on the server.

@mbabker public $cache_handler = 'file';or anything else?

Because that does not fix it

If using "file" doesn't fix your issue then you've got an issue with Joomla being unable to write to /cache and /administrator/cache (or whatever custom path you specified if you did so). Otherwise apparently you can use public $cache_handler = ''; but I wouldn't suggest it for much longer than debugging your issue.

@mbabker the error msg doesn't change. tried '' now, no dice.

0 The xcache Cache Storage is not supported on this platform.

File permissions are 755 on both folders.

I'm going to ask what's going to come across as a stupid question now, but it has to be asked. Are you editing the right site's configuration? If you've got public $cache_handler = ''; and still getting an XCache related message then either you're editing the wrong file, your filesystem has some kind of caching of file contents outside Joomla's processes, some extension is trying to explicitly use XCache for some reason, or some other unknown issue happening outside the normal Joomla process.

Looks like it was an issue with FileZilla, it did not upload the edited file. Now changed it directly on the server and it works again. Still weird that it used to work with 3.5 but I guess Joomla is now more strict with which caching it allows? Why doesn't it disable caching or fall back to file when it detects and incompatible solution? Seems weird to just let it break the site.

Problem solved for me: it is not a Joomla problem but a Redis problem in my server. So sorry for the comment. Anyway it is a problem that after the update we can't access to admin if an old and not enabled cache handler is selected. Maybe could be a good thing let the administrators to navigate to global configuration and change settings without touching the configuration.php.

Closed as not a joomla issue

It's more strict about checking that the cache configurations are supported instead of trying to use an unsupported handler causing other errors (#9426 is one example of what's trying to be blocked). It would really only break the site if you're doing a server-to-server migration or you've manually edited the configuration file to use an option that Joomla doesn't give you from the backend UI. The fact that it started throwing errors now probably means that at one point your site was set to use that storage adapter but you probably have caching disabled so it wasn't a big deal.

From a developer perspective, the current behavior is right. It raises notice to a server misconfiguration issue and one that requires critical attention. Arbitrarily falling back to another adapter (which also may not be supported) or disabling caching completely aren't favorable options because it masks a broken behavior.

As for letting admins navigate to global config, unfortunately that's not an easy or favorable thing either. The cache API is booted up extremely early in Joomla's request cycle so the errors with the unsupported storage happen too early to have a "graceful" fallback without wrapping every use of the cache API in Exception catching code and basically going to that fallback or disable completely behavior (the first use of the cache happens at a point before Joomla has even routed the request; so it can't know at that point you're trying to get to the config component).

Should still fall back to something that works when it detects a setting that does not work, imo.

And again, that's not practical. It masks a critical configuration error and there's no guarantee that any fallback could work. The system default is the file adapter and if your system can't use that then what happens? The cache API can't be accessed without a functioning storage adapter so at that point that component of the system is critically unusable and should abort. It's similar logic to the database or session layers; with the database, if MySQLi isn't available Joomla doesn't try to fall back to either PDO or the deprecated MySQL extension, it critically fails because it can't connect to the configured resource.

There are some errors that can be safely recovered from and the system operate in a degraded state. This isn't one of them.