Cache Buster

The team at Theme Fusion has done a wonderful job trying to increase the performance of Avada to accommodate the variety of web hosts, unfortunately, the options can have unexpected results. When Avada 7.7 was released I started to have a problem on this website where new posts in the post cards element would not appear. Through trial and error, I found that if I modified a post cards element and changed the query parameters this was resolved. This led me to believe it was a caching problem, but no matter what I did, nothing seemed to work aside from editing the element. I reached out to the Avada support team but they could not offer a solution. This was only happening on sites hosted in Pressable. Jump to this past week and I started experiencing the same problem on another site hosted in another location but owned by Automattic (parent company of WordPress and owners of Pressable). This is a much higher tier solution and the hosting support team helped identify the problem — Avada’s query cache. It is not entirely a problem with Avada, but the Automattic locations use an advanced query caching plugin to improve performance. Because of the way Avada handles the caching (it caches the parameters), there was nothing to trigger this lower-level cache to recognize a change. From the support team:

It looks like what’s happening is that the fusion_cached_query() function is caching the WP_Query from FusionSC_PostCards by the query arguments. Unfortunately, since the query is only querying a specific category, the arguments are always the same, even if a post is removed from the category it requests the same cache key and it gets returned.

As you can see this directly impacts the post cards query loop. What to do? Fortunately, the Theme Fusion team did a good job coding and made it easy to find a solution. The support team provided a client_mu_plugin (Must Use Plugin) that uses the same code as Avada without the caching and then when the Avada function runs since the function already exists, it skips the caching function.

As you will see in the code below, removing the caching is fairly easy and Avada, seeing that the function is already enabled, will bypass the caching. Obviously, this is not something you should do unless you know your host offers a lower-level query caching function and this is proved with no support or guarantees.

<?php
/**
 * Disable Avada's Query Caching
 *
 * The built-in query caching can be overly aggressive, resulting in the frontend
 * not updating when post changes are made on the backend. Since we're using
 * Advanced Post Cache at the platform level, we don't necessarily need this extra
 * layer of caching.
 *
 * Due to the original caching using an md5 of the query args, we can't easily use
 * a post save filter to bust the cache, since we don't know which cache keys have
 * the posts we need to clear.
*/

if ( ! function_exists( 'fusion_cached_query' ) ) {

	function fusion_cached_query( $args ) {

		// Make sure cached queries are not language agnostic.
		if ( is_array( $args ) ) {
			$args['fusion_lang'] = Fusion_Multilingual::get_active_language();
		} else {
			$args .= '&fusion_lang=' . Fusion_Multilingual::get_active_language();
		}

		$query = new WP_Query( $args );
		return $query;
	}
}

function fusion_cached_query( $args ) {

		// Make sure cached queries are not language agnostic.
		if ( is_array( $args ) ) {
			$args['fusion_lang'] = Fusion_Multilingual::get_active_language();
		} else {
			$args .= '&fusion_lang=' . Fusion_Multilingual::get_active_language();
		}

		$query_id = md5( maybe_serialize( $args ) );
		$query    = wp_cache_get( $query_id, 'fusion_library' );
		if ( false === $query ) {
			$query = new WP_Query( $args );
			wp_cache_set( $query_id, $query, 'fusion_library' );
		}
		return $query;
	}

Along with this caching issue, I have that either performance settings in Avada are either redundant or create more problems in this environment.