Caching

Make FacetWP-powered pages load quicker by caching FacetWP-specific AJAX requests in the database. The

The Caching add-on can help speed up high-traffic pages with commonly used facet combinations because it prevents FacetWP from having to calculate the choices for each facet on each page load.

How it works

Each unique facet filter combination that is used by a visitor will be cached in the database and retrieved from the cache the next time someone chooses that combination. If you have many users selecting a lot of different unique combinations (e.g. entering their own location or making random assortments of facet selections), then caching the AJAX requests isn’t going to help much because those combinations will not have been cached yet. So the Caching add-on will only be effective on frequently visited pages (like landing pages) with only a few facets and facet options/combinations that are used often.

The FacetWP Caching add-on compliments other caching plugins. It doesn’t cache anything else than its own AJAX requests, so it will not negatively affect other caching systems you are using. It can be used side-by-side with other caching plugins like WP Rocket because most of them intentionally ignore AJAX requests.

Installation

Simply install the plugin and activate it.

If you want to make sure the plugin actually works, see below for instructions on how to check if the wp_facetwp_cache database table exists and has entries, and possible causes and fixes if this is not the case.

Setting the expiration

Depending on how often your content changes, you may want to experiment with the cache expiration time. By default, the cache expires after 1 hour (3600 seconds).

If your content only changes weekly or monthly, it would make sense to increase the cache lifetime as well. If your content rarely changes you could set the cache to a really long expiration time, then manually clear it when necessary. That’s actually what we do on facetwp.com because our demo content almost never changes.

You can adjust the expiration by adding the following code to your (child) theme’s functions.php:

function my_cache_lifetime( $seconds ) {
    return 86400; // One day. Default: 3600 (one hour)
}
add_filter( 'facetwp_cache_lifetime', 'my_cache_lifetime' );

Page-specific expiration

You can also set custom expirations for specific pages by adding the following code to your (child) theme’s functions.php:

function my_cache_lifetime( $seconds, $params ) {
    if ( 'products' == $params['uri'] ) { // http://website.com/products/
        $seconds = 1800;
    }
    return $seconds;
}
add_filter( 'facetwp_cache_lifetime', 'my_cache_lifetime', 10, 2 );

Clearing the cache

When logged in, you’ll see a FWP menu in the black admin bar with an option to clear the whole cache. If you are on a front-facing page, the menu will also show an option to clear the cache for that page only.

Clearing the cache via code

To clear the cache via code, use the following:

FWP_Cache()->cleanup(); // clear expired cache

FWP_Cache()->cleanup( 'all' ); // clear everything

FWP_Cache()->cleanup( 'demo/cars' ); // clear the "/demo/cars/" page

Fixing possible issues

Check if caching is working

If you want to make sure the Caching add-on is functioning properly, first click some facets, then log into phpMyAdmin and check if the wp_facetwp_cache database table exists, contains 5 columns (id, name, uri, value, expire), and has any entries.

The table should look like this:

If the table does not exist or is empty, most often the issue is a conflict with another plugin that is using a db.php symlink or file in the same place. See below for possible conflicting plugins and fixes.

Another cause can be that your host is actively blocking 3rd party caching and the Caching add-on cannot place a db.php symlink to its plugins/facetwp-cache/db.php file in the wp-content directory. If this is the case, the solution is to manually create an empty wp-content/db.php file, then paste the contents of the Caching add-on’s plugins/facetwp-cache/db.php file into it. If the wp_facetwp_cache table is still not being populated after that, check with your host if they are actively blocking the use of db.php.

Another possible cause is that the wp-content directory is not writable, making it impossible to place the db.php symlink.

Fixing conflicts with db.php

On activation, the Caching plugin will automatically try to place a db.php symlink to its own plugins/facetwp-cache/db.php file into the wp-content folder. There are other plugins that also place a symlink to their own db.php in wp-content, or they place it as an actual file. This conflict can lead to either the Caching plugin or the other plugin not working, depending on which one placed its db.php symlink/file first. Some plugins will warn you about this conflict (like Query Monitor and W3 Total Cache) but others don’t (like FacetWP’s Caching add-on).

This issue is caused by WordPress’ core limitation that the drop-in plugin file must be called db.php and placed in the wp-content directory, and only one file with this name can exist there.

The two plugins described below can cause this conflict, but there are more caching plugins that use this file.

Query Monitor

The Query Monitor plugin places a db.php symlink to its own plugins/query-monitor/wp-content/db.php file into wp-content on activation. However, if the Caching add-on was activated already, Query Monitor cannot place its symlink. Without it, certain features of that plugin (like showing queries by component) will not work and Query Monitor will show a warning. If you want these features to work, you need to de-activate the Caching add-on, delete its symlink from wp-content, de-activate Query Monitor, and re-activate it again so it can create its symlink on activation. See our page on using Query Monitor for more information.

Be aware that if Query Monitor’s db.php was already there first, the Caching add-on cannot place its symlink on activation and will not work, without warning you.

If you want them both to work at the same time, the only way is to paste the content of plugins/facetwp-cache/db.php into plugins/query-monitor/wp-content/db.php, at the bottom of that file. But you will lose this fix as soon as you update Query Monitor to a new version.

If you don’t need Query Monitor, just de-activate it. It will automatically delete its db.php symlink, and activating the Caching add-on will create its symlink. Or if it was active before: de-activate and then re-activate it again.

Note that Query Monitor automatically removes its symlink on de-activation, but the Caching plugin does not, so you have to manually remove that symlink first if you need Query Monitor to create its symlink on activation. Plugins in general do not overwrite an already existing db.php symlink or file.

If you want to make sure the Caching add-on is functioning properly after fixing these issues, click some facets, then log into phpMyAdmin and check if the wp_facetwp_cache database table has any entries.

W3 Total Cache

The same thing as described above happens with the W3 Total Cache plugin, with one difference: W3 Total Cache uses a file for db.php, not a symlink.

If you want the Caching add-on to work with W3 Total Cache at the same time, the only way is to paste the content of plugins/facetwp-cache/db.php into W3 Total Cache’s wp-content/db.php, at the bottom of that file.

Just like Query Monitor, W3 Total Cache automatically removes its symlink on de-activation, but the Caching plugin does not, so you have to manually remove that symlink first if you need W3 Total Cache to create its symlink. It does not overwrite an already existing link.

See also

• FacetWP performance, speed, limits and scalability
• How to use Query Monitor to optimize performance
• How to make your website load faster
• Using FacetWP with WP Rocket