simon.holliday

Hi,

I don’t know.

I’ve afraid I haven’t tested FlexiCache with every other possible plugin, because there are over 30,000 of them, that would take up too much of my life ??

Why not give it a go and then tell me if it works?

Thanks.

Si.

Hi again Jan ??

FlexiCache does not issue any 302 responses itself, so this output is not coming from the plugin. It is likely that an invalid infinite-loop redirect is being issued by WordPress or by another plugin, which is then being cached by FlexiCache.

I would suggest that you start by finding what is issuing the 302 header, and then see if you can use FlexiCache’s rules to avoid caching or serving that response.

Let me know if you track it down.

Thanks again for your feedback.

Si.

Hi Jan,

Thanks for your feedback.

The plugin page (https://[your.website.com]/wp-admin/options-general.php?page=flexicache&section=standalone
) recommends that you make the .htaccess change manually rather than use the automatic updater, due to the number of variations of what that file may contain and where it may be, there is no guarantee that it will work as expected, and could easily break your site.

Unfortunately I cannot make a version of the automatic updater which will work on every different installation as there really are infinite possibilities ??

Try making a manual change and see if that works.

Thanks,

Si.

Hi, thanks very much for your comment. I know it was six months ago, but I only just saw it… Really pleased it’s working well for you ??

Si.

Hi,

You can add a “no-store” condition to prevent FlexiCache from caching a page based on a number of rules. How this works is explained in the documentation which comes with the plugin: https://your.website.com/wp-admin/options-general.php?page=flexicache&section=documentation#flexicache-doc-configuration (change your.website.com to your WordPress hostname)

To prevent FlexiCache from caching the homepage, create a new no-store rule as follows:

Source: $_SERVER
Key: REQUEST_URI
Match Type: Equals
Value: /

This will prevent FlexiCache from caching anything where REQUEST_URI=”/”, which is the URI of the home page.

Once you have done this, FlexiCache will no longer cache that page. Bear in mind that if the page has already been cached, it will continue to be served up until the cached item expires, so you may also want to clear the cache to see this configuration working immediately.

Hope that helps!

Si.

Hi,

Thanks for your feedback, I’m glad the plugin is working for you, and it’s great that you are recommending it to others.

I have tried to explain all the options in the documentation which comes with the plugin, and to make them as clear as possible.

In most cases, the default settings will work fine, and very little configuration is required to gain a huge increase in the performance of any site.

I maintain this plugin in my spare time, and I don’t have a lot of that at the moment, so I’m afraid I cannot make plans for a new interface at the moment.

Si.

Hi again,

Standalone mode bypasses loading WordPress to serve the request, which means that other plugins will not run when you are serving requests in this way, which is why it’s so fast.

Normally other plugins don’t need to run when serving a cached page, because their output is already cached, but if you are relying on a plugin for your stats, it is likely that this will not run either.

If you want to keep the performance of standalone mode, you will need to use a client-side stats tool like Google Analytics.

Si.

Hi,

I would not suggest using SQLite for a production site – it’s really just there for test purposes. Memcache will get you the best performance, filesystem should be used if you don’t have Memcache available.

Hope that helps!

Si.

Hello,

I’m afraid I haven’t used either of those plugins so I can’t tell you whether they are compatible. It’s impossible for me to test compatibility between FlexiCache and every other WordPress plugin ??

The best thing I can suggest is that you try it and see what happens!

Si.

Hi there,

Thanks for your feedback. These warnings are sometimes generated when pre-caching is enabled, and although they appear in the log, they should never actually be visible to a user viewing your site. There is a note in the documentation which explains why this occurs.

If you want to stop the warnings happening, you can disable pre-caching by setting “Pre-cache time” to “0” in FlexiCache’s “Main Options” page. Follow the documentation link next to that option if you want more info.

You should not see any significant loss in performance by disabling pre-caching.

Hope that helps. Please let me know if this does not resolve your problem.

Thanks!

Si.

Hi Dan,

Thanks for your feedback and sorry to hear you’ve had problems.

From the information you’ve provided it looks like PHP’s chdir() function is failing in the standalone.php file, and it is trying to include a file in the wrong directory.

I’ve never seen this before and I don’t know why it should fail, unless $_SERVER[‘DOCUMENT_ROOT’] is not set or is empty in your web server installation. This would be unusual.

It would be helpful if you could test this for me – if you are happy to do this, create a temporary file (e.g. “phpinfo.php”) somewhere on your site containing the following:

<?php phpinfo(); ?>

Please visit this in a browser and look for _SERVER[‘DOCUMENT_ROOT’] in the “PHP Variables” section. It should show the webroot for your site. Let me know if it exists and is correct. Once you’ve checked you should delete the phpinfo.php file from your site.

In order to delete the plugin, just remove the entire “flexicache” directory from inside “wp-content/plugins”. The plugin does not write data anywhere outside of this directory and does not make database changes.

You are correct that deactivating does not remove the .htaccess change, but this is explained very clearly in the plugin’s documentation page (viewable from the plugin settings in your WordPress admin panel) as follows:

Important: If you deactivate FlexiCache, you should remove (or comment out) these lines from your .htaccess file first. If you deactivate FlexiCache on an individual blog in WordPress MU or WordPress 3, you should remove the site’s hostname from the HTTP_HOST condition before deactivation.”

Hope that helps a bit. Sorry I can’t explain your original error yet!

Si.

Hi Jose,

Thanks for your questions.

Please ensure that you have read through all the documentation which is provided with the plugin, as it may help explain some of these points. In your WordPress admin area, go go the plugins page, click on “Configuration & Status” next to FlexiCache, and then select “Documentation” from the drop-down list at the stop.

1) Remember that FlexiCache does not cache items when you are logged in as an administrator, so if it doesn’t *feel* like it’s going faster, try visiting the site in a browser which is not logged in. Google Chrome, for example, has an incognito mode which is useful for this.

2) The ENABLE_CACHE constant is nothing to do with FlexiCache and will not have any effect on the plugin’s behaviour.

3) I am not clear what you mean by “It is neccesary standard mode or I can use default httaccess?”, but the documentation which comes with the plugin explains information about the .htaccess file. See also point 4 below which can be implemented using .htaccess

4) The site speed report you have posted shows good results for HTML pages, but poor results for CSS, JavaScript, images etc. Your web server serves these directly – they do not go via FlexiCache – so you need to configure your web server to set expiry times for these. These page have information which might help with those issues:

– https://stackoverflow.com/questions/6878427/leverage-browser-caching-how-on-apache-or-htaccess
– https://httpd.apache.org/docs/2.2/mod/mod_expires.html

5) To see whether FlexiCache is working, look at the response HTTP headers. FlexiCache adds one called “X-FlexiCache” which indicates the cached status of the page. You can also enable HTML comments in the config options, but these will only be added when service uncompressed responses.

6) Yes, FlexiCache supports gzip, deflate, and uncompressed responses. This is explained thoroughly in the documentation and configurable in the plugin options – there is section called “Compression”.

Hope that helps,

Si.

Hi there,

1) It’s possible, but not a good idea. Logged-in users can be served different content, specific to each user, and you would never want to serve user A with content that had been created for user B and cached. This is the reason why it’s not implemented. It would be possible to cache pages per-page and per-user, but this could end up using a much greater amount of storage for little gain in performance.

2) There is a setting in the plugin’s Main Options page: “Show HTML comments to indicate cached status”. Turn this on and comments will be added to HTML pages. The plugin also adds an HTTP header named “X-FlexiCache” which gives information about the status of the response for cached pages.

Hope that helps!

Si.

Hello,

This looks like one of two things:

1) An incompatibility with another plugin,

2) Your browser is indicating that it supports compressed output, and FlexiCache is serving the output compressed, but your browser is not decoding it properly.

To test which of these it is:

1) Disable all other plugins and see if the problem still occurs.

2a) Try a different browser and see what happens.

2b) In the FlexiCache settings, under “Compression Options”, enable “Store plain-text responses” and disable “Send gzip-encoded responses to supported browsers” and “Send deflate-encoded responses to supported browsers”, then empty the cache (from the FlexiCache “status” page) and see if that stops the problem.

Let me know!

Thanks,

Si.

Hi there,

FlexiCache doesn’t affect expiry time for images which exist on the filesystem, since these are served directly by the web server, not by WordPress.

If you’re using Apache web server, you can use the ExpiresByType directive in your .htaccess file (or main Apache config file) to set the expiry time for images:

https://httpd.apache.org/docs/current/mod/mod_expires.html#expiresbytype

For example, the following directives in your .htaccess will set the expire time for GIF, JPEG and PNG files to one week:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/gif A604800
ExpiresByType image/jpeg A604800
ExpiresByType image/png A604800
</IfModule>

Hope that helps,

Si.