Setting in Sql possible ?

On the top of my head that would not be possible without some big changes to Cache Enabler. The reason the settings file is used is due to what’s available by default when the advanced-cache.php file is included by WordPress (which is included if the WP_CACHE constant is defined as a truthy value). This is an early part of the load cycle that allows caching plugins like Cache Enabler to do things before other parts of WordPress have been loaded. In our case it’s maybe delivering a cached page or starting our output buffer to maybe cache a page.

For example, the get_option() function is not available in this part of the load cycle when trying to deliver cached pages, which is why they are pulled from that settings file instead. While the settings from the database could be used to generate a cached page as that comes later in the load cycle, the settings file value is used to create and deliver cached pages with the same source.

• This reply was modified 4 years, 8 months ago by Anonymous User 16850768. Reason: clarification

You’re most welcome, @treecutter. 🙂 I really appreciate knowing you’re happy with the plugin. As of version 1.8.7, that warning will be displayed if the /path/to/wp-content/cache or /path/to/wp-content/settings directory exists and is not writable. Are you experiencing different behavior?

Checking if the directories above are writable is not related to the wp-content/advanced-cache.php drop-in file that Cache Enabler automatically creates. Cache Enabler will only be able to create that advanced-cache.php drop-in file if the wp-content directory is writable.

The overall requirements handling process will eventually be improved, so I do expect this to change in the future. I’m unsure how much will change, but I do believe more time and focus does need to be put into that part of the plugin. I haven’t fully gotten to that part since I started working on the plugin.