First feedback

  • Hello Derrick,

    I’m an early adopter of things like this, so I ran some tests on several ‘lower end’ shared hosting accounts. That said, I have to admit that you did a great job!
    So far your plugin performs amazingly well.

    Just a few things to clarify.

    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?

    How is cache pruning performed when WP_FOCUS_MAXTTL is reached? Is there a WP cron job that prunes files? 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?

    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. Ideally, there can be a button on plugin settings page to do this ??

    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. Or even (not sure if it’s possible though) move /focus-object-cache/ one level up the public_html.

    Thanks again for your great work!

Viewing 1 replies (of 1 total)
  • Plugin Author Derrick Tennant

    (@emrikol)

    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.

Viewing 1 replies (of 1 total)
  • The topic ‘First feedback’ is closed to new replies.