A website that pulls decent traffic may want to display the number of views each of its pages has gotten. This information can make a website seem more active or credible (or, generally, worthwhile perusing) than it would otherwise to a visitor. This datum can also subtly and meaningfully guide a user’s interactions with a website (i.e., a page with more views is likely worth visiting in preference to a page with less views). YouTube, for example, leverages view counts to (and which) influence whether a video may be worth watching.
WordPress doesn’t track pageviews out of the box, but Jetpack is a popular plugin, which many WordPress websites use, that does track pageviews. It does not save pageviews, however, in a way which makes this data readily available to plugin or theme developers. But it is possible to import Jetpack’s pageviews so that the data is useable. And it makes sense to piggyback off Jetpack’s stats, rather than devise a unique solution to track pageviews; such inventions are typically unstable, imprecise, or prone to bogging down performance. Holding hands with Jetpack is a pretty sure-fire solution which adds minimal overhead (and elegance, too).
The data that Jetpack collects is available through the WordPress.com Stats API which can be accessed with the
stats_get_csv function provided by Jetpack. This API can be called while a page is loading, i.e., before the page is displayed to the visitor (in the
wp_footer action, for example), but a better method is to call the API after the page has finished loading, via Ajax. An Ajax implementation allows the user to visit the page unimpeded—without waiting for the API request to process first, which may take a split second or two—a relative eternity in the context of the internet (where instantaneous responses are generally expected). Instead, the call happens in the background, after the page has loaded, which affords the user a better experience.
Combined, this code will:
- save the pageviews for each
- in post meta key
- every ~4 hours.
This data can be displayed with
get_post_meta and posts can be sorted by
views, e.g., to query for popular posts:
The WordPress.com Stats API caches requests. This is problematic for us, because it means that a page’s current view count may not be returned for our request; we could instead be provided a view count from days ago. Typically,
-1 is supplied for the
days parameter, in this API call, to return “total views” (views accumulated in the past “infinite” [or all] days). However, the results from
'days' => -1 cache for an indeterminate amount of time, and thus will not always be current when requested.
To work around this, we attempt to bust the cache with each call, by requesting a page’s view count from the past
X days (instead of
-1 days), where
X is a random number from 36,500 to 2,147,483,647.
The former figure I chose somewhat arbitrarily; it is roughly 100 years in days. (I figure WordPress will be history by that point.) The latter figure comes from PHP’s
This range has proven sufficient—for me, anyway—to reliably bust the Stats cache with each API request.