FacetWP | Caching

FacetWP-specific AJAX requests can be cached in the database to speed up the loading of pages powered by FacetWP.

How it works

Each distinct facet filter combination that a visitor selects will be stored in the database’s cache and retrieved from there the following time that combination is selected. Caching the AJAX queries won’t assist much if you have many people making several unique picks (such as providing their own location or choosing random groups of facets), as such combinations won’t have been cached yet. Therefore, the Caching add-on will only be useful on regularly viewed sites (like landing pages) with a limited number of facets and frequently used facets and facets options/combinations.

Other caching plugins are enhanced by the FacetWP Caching add-on. It won’t adversely effect any other caching solutions you use because it just caches its own AJAX queries. Due to the fact that most caching plugins, including WP Rocket, purposefully ignore AJAX requests, it may be used in conjunction with other caching plugins.

Installation

The plugin just has to be installed and turned on.

See the instructions on how to verify that the wp facetwp cache database table exists and contains entries, as well as potential problems and solutions, below if you want to make sure the plugin truly functions.

Setting the expiration

You might want to play around with the cache expiration time depending on how frequently your material updates. The cache expires by default after one hour (3600 seconds).

Increase the cache lifespan as well if your material only updates on a weekly or monthly basis. You might set the cache to have a very long expiration date and then manually remove it as needed if your material doesn’t change frequently. Actually, we do it on facetwp.com because the demo material there seldom ever changes.

By including the following code in your (child) theme’s functions.php, you may change the expiration:

Page-specific expiration

By including the following code to your (child) theme’s functions.php, you may additionally provide unique expirations for particular pages:

Clearing the cache

When signed in, an FWP menu with an option to erase the whole cache may be found in the black admin bar. The menu will also provide a choice to erase the cache for only that page if you are currently on a front-facing page.

Clearing the cache via code

Use the following code to clear the cache:

Fixing possible issues

Check if caching is working

Whether you want to ensure that the Caching add-on is working properly, click a few facets first, then sign into phpMyAdmin and see if the wp facetwp cache database table is there, has the required 5 columns (id, name, uri, value, and expire), and includes any entries.

The table should look like this:

The most frequent cause of a table not existing or being empty is a clash with another plugin having a db.php file or symlink in the same location. Fixes for potential incompatible plugins are shown below.

Another possible reason is that the Caching add-on cannot create a db.php symlink to its plugins/facetwp-cache/db.php file in the wp-content directory because your host is actively restricting third-party caching. If so, the fix is to manually create an empty wp-content/db.php file and then paste the contents of the plugins/facetwp-cache/db.php file for the Caching add-on into it. After that, if the wp facetwp cache table is still empty, see whether your host is actively restricting the use of db.php.

Another reason might be that the wp-content directory cannot be written to, which prevents the db.php symlink from being placed.

Fixing conflicts with db.php

The Caching plugin will attempt to automatically insert a db.php symlink to its own plugins/facetwp-cache/db.php file into the wp-content folder as soon as it is activated. Other plugins may also add a symlink or an actual file to their own db.php in the wp-content directory. Depending on whether plugin inserted its db.php symlink or file first, this conflict may prevent the Caching plugin from functioning or the other plugin from functioning at all. Some plugins, like Query Monitor and W3 Total Cache, will alert you to this problem, while others, like FacetWP’s Caching add-on, won’t.

This problem is brought on by a basic restriction of WordPress, which states that only one file with the name db.php may exist in the wp-content directory and that it must be a drop-in plugin file.

There are more caching plugins that use this file in addition to the two listed below that potentially clash.

Query Monitor

Upon activation, the Query Monitor plugin creates a db.php symlink to a file located at plugins/query-monitor/wp-content/db.php. However, Query Monitor cannot create its symlink if the Caching add-on is already active. Without it, Query Monitor will issue a warning and key functionality of that plugin (such viewing queries by component) won’t function. You must deactivate the Caching add-on, remove its symlink from wp-content, deactivate Query Monitor, and then activate it once again for it to create its symlink upon activation if you want these capabilities to function. For additional details, visit our article on using Query Monitor.

You should be aware that the Caching add-on cannot create its symlink upon activation and will not function if Query Monitor’s db.php was previously present.

The only way to make them both function simultaneously is to insert the contents of plugins/facetwp-cache/db.php at the bottom of plugins/query-monitor/wp-content/db.php. However, as soon as you upgrade Query Monitor to a new version, you will no longer have this workaround.

Simply deactivate Query Monitor if you no longer require it. When the Caching add-on is turned on, a db.php symlink will be automatically created and deleted. Alternately, if it was already active, deactivate it and then reactivate it.

The Caching plugin does not automatically delete its symlink upon deactivation, thus if you want Query Monitor to create its symlink upon activation, you must first manually remove that symlink. Generally speaking, a db.php symlink or file that already exists won’t be overwritten by a plugin.

After resolving these problems, you can check to see whether the Caching add-on is working properly by clicking a few facets and then logging into phpMyAdmin to see if the wp facetwp cache database table contains any entries.

W3 Total Cache

The W3 Total Cache plugin experiences the same issue as the aforementioned plugin, with one exception: W3 Total Cache utilises a file for db.php rather than a symlink.

The only way to get W3 Total Cache and the Caching add-on to function together is to copy the contents of plugins/facetwp-cache/db.php and put them at the bottom of wp-content/db.php in W3 Total Cache.

When deactivated, W3 Total Cache automatically deletes its symlink, much like Query Monitor does. However, the Caching plugin does not, thus if you want W3 Total Cache to generate its symlink, you must manually delete the Caching plugin’s symlink first. It doesn’t replace a connection that already exists.