When wp-content is unwritable, neither the "cache" nor "settings" directories can be created. There's no visible indication that there's a problem, but without those directories, the plugin simply won't do anything.
This commit tweaks the existing file permissions requirements check to warn if wp-content/cache or wp-content/settings do not exist and probably cannot be created because wp-content is unwritable. This isn't perfect, because we don't necessarily know that the cache directories live exactly two levels under wp-content. But the cache hierarchy is created on-demand when a page is cached, so we can't simply ask if it exists during the requirements check (which may happen before any pages have been caches). Taking that into consideration, the heuristic seems acceptable.
When wp-content is unwritable, neither the "cache" nor "settings" directories can be created. There's no visible indication that there's a problem, but without those directories, the plugin simply won't do anything.
This commit tweaks the existing file permissions requirements check to warn if wp-content/cache or wp-content/settings do not exist and probably cannot be created because wp-content is unwritable. This isn't perfect, because we don't necessarily know that the cache directories live exactly two levels under wp-content. But the cache hierarchy is created on-demand when a page is cached, so we can't simply ask if it exists during the requirements check (which may happen before any pages have been caches). Taking that into consideration, the heuristic seems acceptable.