Top 10 v4.5.0: Page Builder Elements, Site-wide Tracking and Smaller Daily Tables

Dropping a popular posts list into a page built with Elementor, Bricks, or WPBakery has always meant pasting a [tptn_list] shortcode into a text block and hoping the builder left it alone. No element in the panel, no controls, no preview. I implemented this feature in Contextual Related Posts v4.4, and Top 10 Pro v4.5 now includes it.

This release also adds site-wide view tracking for Pro users and a tool to shrink the daily table on sites with years of history. It also includes a batch of tracking accuracy fixes that apply to every install, free and Pro.

Popular Posts elements for Elementor, Bricks, and WPBakery

Top 10 Pro now registers a Popular Posts (Top 10) element in all three builders, each under its own WebberZone category in the panel.

Every element renders through the same [tptn_list] shortcode used everywhere else in the plugin. That was the deciding constraint. I did not want three separate rendering paths drifting apart from the blocks and widgets, so the builders are a control surface over the shortcode and nothing more. The output and behavior match your existing lists exactly.

The controls are grouped the same way in all three: General, Query, Display, and Output. WPBakery calls that last group Advanced and adds its own Design Options group for the extra class name and CSS box. Bricks supports dynamic data tags on the text controls, so a heading can read Most viewed in {term_name}.

A control left blank, or a switch left off, falls back to your saved Top 10 settings, the same way an omitted shortcode attribute does. Only an explicit value overrides the setting for that one element.

Elements register only when the builder is active and Page Builder integrations are enabled on the Features tab. It is on by default, and there is nothing else to configure. Details are in the Page Builder Integrations documentation.

Site-wide tracking

Top 10 has counted views on posts, pages, and custom post types since the beginning. Everything else on the site was invisible. Your front page, your category archives, your search results pages: none of it was ever counted, even when the front page was the most visited URL on the site.

Pro can now track those too. Each context gets a reserved numeric ID taken from the top of the integer range, one each for the front page, posts page, search, category, tag, taxonomy, author, post type archive, date archive, generic archive, and anything else. The same IDs are used on every site, which is safe because count rows are scoped by blog_id, so a multisite network keeps each site’s numbers separate.

There are two switches, deliberately. Site-wide tracking on the Features tab loads the code and is on by default. Track site-wide views under Counter/Tracker does the actual counting and is off by default. Turning it on changes what lands in your count tables, so I didn’t want it to happen to anyone as a side effect of an update. See the Counter and Tracker options for the setting.

Reducing the size of the daily table

The wp_top_ten_daily table stores one row per post per hour. That hourly detail makes custom date ranges work, and it is worth keeping for recent data. For a post that was popular in 2019, it is 24 rows a day describing something nobody will ever query by hour again.

Reduce Daily Table Size on Top 10 → Tools is a Pro tool that combines hourly records older than a chosen number of days into one record per post per calendar date. The default is 14 days. View counts do not change. The only thing you lose is hourly granularity on dates older than your cutoff.

Each calendar date is processed in its own transaction, so an interrupted run picks up from the next date rather than starting over or leaving a half-finished date behind. The overall count table is never touched. Rows already collapsed to midnight are skipped on subsequent runs.

This is a one-way reduction. Back up your database first if you think you might want that hourly detail back.

On a network, the Network Admin version reads Reduce Daily Table Size Across Network and runs for all active sites. The Tools admin screen documentation covers the rest of that page.

There is a Pro CLI equivalent for anyone scripting maintenance:

wp top10 db rollup --dry-run
wp top10 db rollup --before=30 --dry-run
wp top10 db rollup --before=14 --force
wp top10 db rollup --network --dry-run

--dry-run reports exact row counts before and after without writing anything, which is the way to find out whether this is worth running at all. The full command reference is in the WP-CLI commands documentation.

If your site has a few months of data, you probably won’t notice a difference. If you have been running Top 10 since 2014, you will.

Faster admin screens on large multisite networks

Every Top 10 admin page ran four SHOW TABLES LIKE queries to confirm the tables existed. Four uncached queries per page load, on every page, forever. They now come from a versioned tptn_tables_installed network option. The Tools page still runs the live checks, because that is the one screen where you actually want the truth rather than a cached answer.

The network dashboard popular-posts query was a LEFT JOIN against a subquery covering the whole daily table. It now runs in two phases: order first from either idx_cntaccess or an idx_dp_date range scan, then fetch the other count for just the post and blog pairs that survived. The dp_date comparisons are index-friendly ranges instead of DATE() calls that no index could help with. Historical dashboard tabs load on demand rather than all at once, and the Tools page uses estimated row counts and direct WPP table probes instead of exact counts across every site.

On my test network, the network dashboard was 16.85% faster on server time and 47.86% faster on database time.

Single-site installs will see very little of this. Networks with many sites are where it shows.

Tracking accuracy

Seven separate problems, all of which meant your numbers were slightly wrong in one direction or the other. These apply to free and Pro alike.

Views were being lost when visitors clicked through quickly. The tracker sent a plain request that the browser could cancel the moment you navigated away. It now uses navigator.sendBeacon, which the browser commits to delivering, and falls back to fetch() with keepalive where that is not available.

Back-button visits counted nothing. A page restored from the browser’s back/forward cache does not re-run scripts, so returning to a post recorded no view. A pageshow listener now re-tracks when the page comes back from that cache.

Prerendered and hidden pages counted as real views. If the browser prerendered a page the visitor never actually opened, Top 10 counted it. Tracking now waits for prerenderingchange on a prerendering document, and for visibilitychange on a page that starts hidden.

Bots were counted from cached pages. Bot detection ran when the page was generated. A page generated for a human, cached, and then served to a crawler still carried the tracker, and Top 10 recorded the crawler’s view. Detection now also runs at the tracking endpoint itself, honoring your Do not track bots setting.

Browser prefetches and direct hits on the tracker URL created views. The endpoint now rejects any request carrying a Sec-Purpose or Purpose header of prefetch or prerender, and rejects top-level navigations identified by Sec-Fetch-Mode: navigate. The Fast and High-traffic trackers received the same guards.

Some views were lost between the funnel and the count tables. Tracked views land in a funnel table first, and a cron job drains them into the count tables every couple of minutes. That drain could silently discard rows, so views a visitor really made never reached your totals. The Fast Tracker also raised an undefined array key warning on the same path.

The tracker did nothing at all when loaded asynchronously. It registered a DOMContentLoaded listener without checking whether that event had already fired. On sites that concatenate or defer scripts, it often had, and the listener never ran. It now checks document.readyState first. If your counts have looked low since you turned on a minification plugin, this is likely why.

Other fixes in this release

• Uninstalling one version of Top 10 while its paired free or Pro counterpart was still active deleted the plugin’s data. Switching between free and Pro no longer risks your counts.
• On a multisite network, settings read after a switch_to_blog() call in the same request could come back from the wrong site, through either tptn_get_option() or the global $tptn_settings.
• Generated output cache keys were not discoverable by the Clear Cache tools or the WP-CLI cache flush command, so clearing the cache quietly left them behind.
• [Pro] Daily counts in the wp top10 popular command ignored the selected custom date range.
• tptn_get_settings() returned false rather than an empty array when no settings had been saved yet.
• Settings sanitization is hardened for users without the unfiltered_html capability, and the settings framework picked up renamed JS globals plus tighter referer and array handling from a WordPress.org plugin review.
• Setting defaults now resolve from a single lightweight list instead of building every settings field, so reading an option early in the page load no longer risks loading translations too early.

Upgrade notes

1. Update from your Plugins screen as usual. Top 10 v4.5.0 needs WordPress 6.8 or later and PHP 7.4 or later, and is tested up to WordPress 7.1.
2. Clear your page cache after updating so visitors get the new top-10.min.js. The tracking fixes take effect as soon as the new script loads, and a cached page will keep serving the old one.
3. Pro users: Page builder integrations, Site-wide tracking, and Daily table size reduction are all enabled on the Features tab by default. Nothing starts counting until you turn on Track site-wide views under Counter/Tracker.
4. Pro users: back up your database before running Reduce Daily Table Size, and run wp top10 db rollup --dry-run first if you want to see what it would do.
5. Running the Fast or High-traffic tracker: the plugin update updates the endpoint files, so there is no config file to regenerate for these changes.

If your view counts have been drifting for reasons you could never quite pin down, the tracking section above is the part of this release to read twice.