SWP_Post_Cache

Introduction

Certain data, like share counts, are cached in the post’s custom fields to eliminate the need to make API requests on every page load.

Since custom fields are auto-loaded with the posts, this will result in zero extra queries into the database when accessing the share counts.

SWP_Post_Cache class controls this cached data.

Purpose and Overview

This class controls the cached data for each individual post by using methods for measuring the freshness of the existing stored data. When fresh, we pull cache data from the custom fields and load it into a new SWP_Post_Cache object. When not fresh, it will make an API requests to update the data, then updated the existing data with the new data.

Direct access to the stored data is free. At instantiation, an SWP_Post_Cache fetches post meta and keeps it ready for access in memory.

Since all Post_Cache objects should be loaded with an SWP_Post_Cache_Loader object (we’ll cover this below), we will use the constructor to determine if the cache is fresh, and update it with new API calls if necessary.

This allows us to run that subset of functions only once per page load, and then all subsequent calls for the data will simply get what has already
been stored in the Post_Cache object.

All together, this means that during a page load, one of two things will happen:
We are delivered fresh, stored data packaged inside an SWP_Post_Cache, or
We make new API requests to update the data for this and future uses.

The Post Cache Loader

This class serves as a controller for SWP_Post_Cache objects. One instance of SWP_Post_cache_Loader exists to instantiate and store SWP_Post_Cache objects.

An example for fetching share counts for a post whose ID is 87:

// The instance of SWP_Post_Cache_Loader created by Social Warfare.
global $SWP_Post_Caches;  

$post_id = 87
$share_counts = $SWP_Post_Caches->get_post_cache( $post_id )->get_shares();

If the targeted SWP_Post_Cache does not exist, SWP_Post_Cache_Loader will attempt to create a new Post_Cache from the provided ID. If it succeeds, the requested SWP_Post_Cache is stored in the SWP_Post_Cache_Loader and is available for access through the duration of this request.

In fact, here’s what the get_post_cache() method looks like in the loader class:

public function get_post_cache( $post_id ) {
    if ( empty( $this->post_caches[$post_id] ) ) {
        $this->post_caches[$post_id] = new SWP_Post_Cache( $post_id );
    }		
    return $this->post_caches[$post_id];	
}

Since the get_post_cache() method of the Loader class returns the Post_Cache object, it allows for method chainin as you see in the example above.

As a result, if you have multiple panels of buttons on a post (example: top, bottom, and side), only the first request for the cache object will instantiate and potentially run the API requests. All future requests for the cache object, will receive the previously created cache object.

Return Values

The example above returns an associative array of the following model:

// The instance of SWP_Post_Cache_Loader created by Social Warfare.
global $SWP_Post_Caches;  

$post_id = 87
$shares = $SWP_Post_Caches->get_post_cache( $post_id )->get_shares();

print_r( $shares ); 

// expected output
array(16) { 
    ["google_plus"]=> int(0) 
    ["facebook"]=> int(0) 
    ["twitter"]=> string(2) "85"  
    ["linkedin"]=> int(0) 
    ["pinterest"]=> int(0) 
    ["mix"]=> int(0) 
    ["buffer"]=> string(2) "27" 
    ["reddit"]=> int(0) 
    ["flipboard"]=> int(0) 
    ["email"]=> int(0) 
    ["hacker_news"]=> int(0) 
    ["pocket"]=> int(0)  
    ["tumblr"]=> int(0) 
    ["whatsapp"]=> int(0) 
    ["yummly"]=> int(0) 
    ["total_shares"]=> string(2) "85" 
}

A few notes on the above return values:

• Share counts will only be fetched from the various API’s for social networks that are active in the options. All others default to 0.
• We preserve share counts for networks that were once active but are no longer are active. This is the case for Buffer in the example above.
• We only use the share counts from active networks while calculating total_shares. This is because it would look very silly, if not deceptive, if the total shares did not match the numbers on the displayed buttons.

Class Table of Contents

The methods of this class are organized into four logical categories.

1. Set up the cache object and necessary properties. The methods in this section are used to set up the cache object by initializing the object, setting up local properties, and pulling in the global $post object that will be used throughout the class. This also loads the cached data from the database so that it is available in section 4.
2. Check if the cache is fresh or not. The methods in this section are used to determine whether or not the cached data needs to be rebuilt or not.
3. Update the cached data when the cache is expired. This section will update the share count data from the API, check and retrieve fresh links from Bitly (if enabled), and rebuild the cached images that we use for Pinterest and Open Graph tags. Upon completion, the cached data from step 1 will be overwritten with the new data.
4. Allow a publicly accessible method for retrieving the cache data. The method get_shares() is accessed via the SWP_Post_Cache loader to retrieve the cached data and make it accessible to the buttons panels.

Debugging

The following URL parameters can be used to manipulate the behavior of this class or to var_dump certain information needed to debug.

Parameter	Description
?swp_cache=rebuild	The plugin only updates the share count numbers once in a while at certain intervals. Using this parameter, it will update the numbers immediately as the page is being loaded.
?swp_debug=post_cache	Outputs the entire contents of the SWP_Post_Cache object. Use in conjunction with ?swp_cache=rebuild to view the raw data as it is fetched from the API’s.