Derrick Tennant

Hi!

A caching layer isn’t necessarily a good place to store large or long term data since normally caches don’t promise the data will always be available. In cases like that, storing data in a database may be better.

As an example, the plugin WP Large Options stores large amounts of data as a custom post type in the database where it can be accessed in a way similar to the WordPress Options API.

Hi! Thanks for the great feedback. I appreciate you taking the time to look into the plugin 🙂

I see that you’re using WP_CACHE_KEY_SALT and you set it to empty string if it’s not defined otherwise in wp-config.php
What’s the reason of using salt for disk-based object caching? If this for WP Network? Or for those setups where several WP installs use the same database with different table prefixes?

It’s left over from much earlier development. I don’t think it’s needed anymore and I’ll remove it. (GitHub Issue)

How is cache pruning performed when WP_FOCUS_MAXTTL is reached? Is there a WP cron job that prunes files?

There’s a GitHub issue to add a cron job to purge expired data for v1.1.

If that’s the case – will it still work w/o issues when the ‘native’ WP cron is disabled and an external one is being used?

If you mean using define('DISABLE_WP_CRON', true); and triggering the WordPress core cron externally, then it should still work since the cron jobs should still run.

Since any object caching takes care of transients, I believe you can add a note to plugin docs about deleting all transients from wp_options.

I added a GitHub issue to add documentation about that.

Ideally, there can be a button on plugin settings page to do this 😉

Another GitHub issue for a potential future enhancement to purge database transients.

Finally, I’d rather put a single .htaccess file in /wp-content/focus-object-cache/ folder to protect files from public access rather than zero-length index.php.

Good idea. I personally use nginx, but adding the .htaccess file shouldn’t cause any issues. I’ll also try to add other instructions for nginx on how to disable access to the directory. (GitHub Issue)

Or even (not sure if it’s possible though) move /focus-object-cache/ one level up the public_html.

Added a GitHub issue to work on the ability to change the cache directory.

Hopefully that provides an answer to all of the feedback, but if not, just let me know.

It should be compatible with full-page caching plugins, such as WP Super Cache, WP Fastest Cache, Comet Cache. It’s not compatible with plugins that offer their own persistent object caching, such as W3 Total Cache or Redis Object Cache.

If you notice any issues with a full-page caching plugin, please let me know.

Thanks!

Hi moxymore,

I’d like to know more about the problem. Is the plugin not compatible with BuddyPress, or is there something else you’re looking for?

Thanks!

Since, as far as I can tell, the actual image information isn’t saved into the database when you use the “From URL” option, we would have to enter it into the HTML on the page. So do you feel it would be best to add attribution to the image caption directly? If so, I think it can be done. Something like this:

[caption id="" align="alignnone" width="381" caption="Caption Text Here. Image CC-BY Google.com"]<a href="Http://link.to.author.flickr.page.com/"><img alt="" src="https://ssl.gstatic.com/gb/images/j_e6a6aca6.png" title="Google CSS Srite" width="381" height="45" /></a>[/caption]