Init View Count – AI-Powered, Trending, REST API

2.0.2 – September 26, 2026

• Security: the init_plugin_suite_view_count_shape_reset admin-post action (clears learned Traffic Shape data) had no capability check and no nonce, so any logged-in user (even a Subscriber), or a CSRF link, could wipe the learned data. It now requires manage_options and a valid nonce. A Reset traffic shape data button (with nonce) has been added to Settings → Init View Count. Custom links must now be built with wp_nonce_url( admin_url( 'admin-post.php?action=init_plugin_suite_view_count_shape_reset' ), 'init_plugin_suite_view_count_shape_reset' )
• Security: GET /top now only accepts post types that exist and are publicly viewable (is_post_type_viewable()), so the public endpoint can no longer expose titles/excerpts of internal post types such as wp_block. The init_plugin_suite_view_count_top_post_types filter still runs afterwards, so developers can explicitly add other types. number is capped at 100 (filterable via the new init_plugin_suite_view_count_api_top_max_number filter). An array passed as terms no longer causes a PHP fatal error
• Security: the [init_view_ranking] front-end script now builds items with DOM APIs (textContent) instead of injecting API strings into innerHTML, and only allows http(s) links/images
• Bug fix: on sites with a negative UTC offset (the Americas, etc.) the daily reset computed the day of week/month from a timestamp that had the timezone offset applied twice, so at 00:01 it thought it was still the previous day — weekly counters were reset on Tuesday instead of Monday and monthly counters on the 2nd instead of the 1st. All date math now uses real Unix timestamps with wp_date(). The $now value passed to the existing hooks/filters is unchanged
• Bug fix: the daily reset event now re-aligns itself to 00:01 site time after daylight-saving changes (WP-Cron’s daily recurrence is a fixed 24h and used to drift to 23:01 or 01:01). Sites without DST are never touched
• Bug fix (Trending): post age was computed as “local timestamp minus GMT timestamp”, adding the site’s UTC offset to every post’s age (e.g. +7 hours on GMT+7 sites), which skewed freshness boost and time decay. Age is now computed from real Unix timestamps. Old trending_last_calculation values stored in local time are handled safely on upgrade
• Bug fix (Trending): hot topics passed term_taxonomy_id values to get_term() as if they were term IDs. The two are not always equal (split/merged terms, migrated sites), so “hot” boosts could be attributed to the wrong category/tag. The query now returns term IDs and taxonomies directly
• Bug fix (Trending): the EWMA momentum component was stored in the non-persistent object cache, so on sites without Redis/Memcached it never carried over between runs and effectively did nothing. It now works on every site
• Bug fix: [init_view_count time="true"] showed “Posted 7 hours ago” for a just-published post on GMT+7 sites (GMT timestamp compared against a local timestamp)
• Bug fix: a single POST /count request containing the same post ID several times (e.g. [5,5,5]) incremented that post several times. Duplicate IDs in one request are now ignored
• Bug fix: [init_view_ranking] only initialised the first ranking block on a page; additional rankings stayed on the loading skeleton forever. Every ranking block is now initialised, and each keeps its own post_type
• Bug fix: the ranking script fell back to /wp-json/ when the tracking script was not on the page (archive pages, the Dashboard widget), which broke on sites installed in a subdirectory or without pretty permalinks. The correct REST URL is now always provided
• Bug fix: the view-count tracking script stopped completely when the browser blocked localStorage/sessionStorage (Safari private mode, strict privacy settings). Storage access is now guarded with an in-page fallback
• Bug fix: block className values with multiple classes (e.g. foo bar) were merged into foobar; [init_view_count class="..."] now accepts multiple classes too
• Bug fix: block attributes containing square brackets or quotes (e.g. a list title Top [2026]) broke the generated shortcode. Blocks now call the shortcode callback directly with an attribute array (core pre_do_shortcode_tag/do_shortcode_tag filters still apply)
• Bug fix: auto-insert now only adds the view counter to the content of the post actually being viewed, not to other posts’ content rendered on the same page, and not to excerpts generated from content (e.g. SEO meta descriptions)
• Bug fix: the front-end tracker now uses the queried post ID instead of get_the_ID(), so a theme/plugin that runs a secondary query before wp_head without resetting it can no longer make views count toward the wrong post
• Bug fix: the Shortcode Builder read the wrong localized object name, so “Copy”, “Close” and “Shortcode Preview” were never translated. Copy now also works on non-HTTPS admin screens
• Bug fix: init_plugin_suite_view_count_format_thousands() could output 1000.0 K (for 999,950) and 2.0 K; it now outputs 1 M and 2 K
• Bug fix: turning on Disable Trending now also hides previously calculated trending data from GET /top, as the setting describes
• Performance: POST /count now increments all counters of a post (total/day/week/month) with a single atomic UPDATE instead of one query per counter — 2 queries per view instead of 5 in the common case. First-view inserts and stale-cache situations are still handled atomically
• Performance: the daily rollover now only writes rows that actually change. Posts with no views in the period whose “previous period” value is already 0 (the vast majority on large sites) are no longer deleted and re-inserted every day; existing rows are updated in place. In testing on 42 posts, a typical day went from 126 inserts + 129 deletes to 3 updates + 3 deletes. The end result in the database is identical to the previous version (verified against the old logic with randomized data)
• Performance: the hourly Trending calculation primes post, term and meta caches up front, reads comment counts from the post object, stores EWMA/score-cap/streak state in a single non-autoloaded option instead of hundreds of per-post transients, and the MMR diversity re-rank is now O(limit × n) instead of O(limit² × n) with identical output. In testing, one run went from ~590 queries to ~30
• Performance: GET /top primes featured-image caches in one query; its cache key ignores parameter order and cache-buster parameters (_, no_cache); [init_view_list] also primes featured images
• Performance: front-end scripts are loaded with the defer strategy; fetch uses keepalive so a view is still sent if the visitor leaves right as it qualifies
• Improvement: batch mode keeps queued IDs beyond the batch size for the next send instead of dropping them; the view number updates in every place the post’s counter appears on the page
• Improvement: the View Count block uses the block context postId (Query Loop, FSE templates) when Post ID is 0
• Improvement: new filter init_plugin_suite_view_count_ip_headers to restrict which headers are trusted for Strict IP check (e.g. only REMOTE_ADDR on servers not behind a proxy/CDN)
• Improvement: cron events are removed on plugin deactivation; uninstall now also removes the yesterday/last week/last month meta, all plugin options and transients (including cached /top results, which the previous uninstall could not find), and runs on every site of a multisite network
• i18n: regenerated init-view-count.pot with WP-CLI; new strings translated in init-view-count-vi.po/.mo
• Code quality: all PHP files now pass WordPress Coding Standards (WordPress-Extra) with zero errors and warnings

2.0.1 – August 29, 2026

• Bug fix: on a site where the admin had never opened and saved Settings → Init View Count at least once, the day/week/month view counters would keep incrementing normally (that code path defaults to “enabled” when the option doesn’t exist yet) but would never be reset by the daily cron (that code path had no default and treated the missing option as “disabled”). Reading _init_view_day_count directly would show it growing forever instead of rolling over into _init_view_day_yesterday. All reads of the day/week/month enable options now consistently default to enabled, matching the REST counting logic and the settings page’s default-checked checkboxes
• Bug fix: setting “Delay before counting” to 0 did not actually count views immediately — it silently fell back to the default (15000ms) or, depending on the browser, sometimes did not count at all. Same issue affected “Scroll percent required” set to 0. Root cause was a value || fallback pattern in the front-end script, which treats a valid 0 as falsy and always substitutes the default. Both options are now validated on save, enforced again at output time (so sites that already had 0 stored take effect without needing to re-save), and parsed correctly in the front-end script
• Bug fix: on pages shorter than the viewport (nothing to scroll), the scroll-percent check could never pass, because the scroll threshold was only ever evaluated inside the scroll event handler, and no scroll event fires when there is nothing to scroll. The script now also evaluates the scroll condition once immediately after the page settles, in addition to on scroll
• Change: “Delay before counting” is now clamped to a 100ms–600000ms (10 min) range, and “Scroll percent required” to a 1%–100% range. 0 is intentionally disallowed for both: a 0ms delay risks counting views before the page has actually rendered, and a 0% scroll requirement would silently disable the scroll check entirely
• Performance: the daily cron reset (init_plugin_suite_view_count_reset_counts — rolls today’s/this week’s/this month’s view counts into yesterday/last-week/last-month and clears the counters, across every publicly-registered post type, no configuration needed) used to loop get_post_meta() + update_post_meta() + delete_post_meta() per post per counter, which on sites with many posts could mean tens of thousands of individual DB queries in a single cron run. It now performs the same rollover in batched, direct SQL (500 posts per query by default, filterable via init_plugin_suite_view_count_reset_batch_size), cutting query count from O(number of posts) to O(number of batches), then flushes the object cache for affected posts in one pass — using the object cache’s batch-delete method when the active cache backend supports it (WordPress core does, since 6.0), and falling back to individual cache-delete calls otherwise for compatibility with third-party object cache drop-ins (Redis, Memcached, etc.) that may not implement it. Behavior is unchanged: every eligible post still ends up with a “previous period” value (0 if it had no views), preserving correct results in GET /top?range=yesterday|last_week|last_month; verified against the previous per-post logic across 1,000+ randomized scenarios before release
• Internal: extracted shared helper functions (init_plugin_suite_view_count_atomic_increment(), init_plugin_suite_view_count_flush_meta_cache(), IP-detection helpers, the K/M/B number formatter, and the new integer-clamping helper) out of rest-api.php and shortcodes.php into a new includes/utils.php, loaded first. No behavior change, purely a code-organization cleanup
• Internal: replaced extract() in the internal template-rendering helper with an explicit variable assignment for WPCS compliance (WordPress.PHP.DontExtract); the helper is only ever called with a single fixed key, so behavior is unchanged

2.0.0 – August 4, 2026

• Breaking change: Requires at least is now WordPress 6.9. This major version bump reflects two significant new features added in this release — Abilities API support and native Block Editor support (see below)
• New: Abilities API support (WordPress 6.9+). Registers two read-only abilities under the init-view-count category so AI agents and automation tools can discover and query view-count data through the standardized wp_register_ability() registry, without needing to know the plugin’s REST routes:
  • init-view-count/get-post-views — returns the tracked view count for a single post (total/day/week/month)
  • init-view-count/get-top-posts — returns a ranked list of the most viewed posts (wraps the exact same logic as GET /top and the [init_view_ranking] shortcode, so results always match)
  • No write/destructive abilities are registered, by design — nothing can increment or reset view counts through this API
• New: Block Editor (Gutenberg) support with 3 dynamic blocks matching the existing shortcodes 1:1 — View Count, Popular Posts List, and View Ranking (Tabbed). Each block is a thin PHP wrapper (render.php, via the render field in block.json) that builds the same shortcode tag and calls do_shortcode(), so there is no duplicated display logic and output always matches the shortcode. The editor script is plain vanilla JavaScript (no build step, no JSX) using ServerSideRender for a live preview directly in the editor
• Tested up to: 7.1

1.22 – August 4, 2026

• Bug fix: sticky posts were no longer being excluded from view-based rankings. GET /top (and by extension the [init_view_ranking] shortcode, which consumes it) and the hourly Trending Engine calculation could show a sticky post at the top of the list regardless of its actual view count, since the underlying WP_Query calls were missing ignore_sticky_posts. All ranking queries now explicitly ignore sticky posts, consistent with [init_view_list], which already did this correctly
• Performance: the scroll-progress listener in the front-end tracking script (script.js) is now throttled with requestAnimationFrame instead of running its calculation on every single scroll event, and is automatically removed once the scroll threshold is reached — reduces main-thread work on long pages and low-end mobile devices. The listener is also registered as passive to avoid blocking scroll rendering. Also fixed a theoretical division-by-zero edge case when a page’s content is shorter than the viewport

1.21 – July 17, 2026

• New optional setting: Require REST nonce verification? (Settings → Init View Count). Off by default. When enabled, POST /count requires a valid X-WP-Nonce header and rejects the request with 403 otherwise, helping block direct spam POSTs to the endpoint that skip loading the page first
  • The nonce is only added to the localized config, and the client only sends the header, when this setting is turned on — zero overhead otherwise
  • GET /top is intentionally excluded, since it’s a read-only, public-by-design endpoint
  • Documented trade-off: WordPress nonces expire after ~12-24h, so sites using long-lived full-page caching may see view counting silently stop working on stale cached pages until the cache refreshes. See the Settings page description and the FAQ for details
• i18n: added missing English source strings (Invalid post ID., Not enabled for view counting.) plus all new strings from this release to languages/init-view-count.pot, with ready-made Vietnamese translations in languages/init-view-count-vi.po / .mo

1.20 – July 16, 2026

• Performance & accuracy overhaul for the /count REST endpoint:
  • View counters (total, day, week, month) are now incremented with a direct, atomic SQL UPDATE ... SET meta_value = meta_value + 1 instead of a read-then-write get_post_meta() + update_post_meta() pair, removing a race condition that could drop views under concurrent traffic
  • The value returned to the client is derived locally (cached value + 1) instead of re-querying the database after the write, saving a query per counted key
  • The object cache for a post’s meta is now invalidated exactly once per post per request (after all of its keys are updated), instead of once per key
• Traffic Shape Learner: hourly bin tracking is now buffered per-request and flushed with a single get_option()/update_option() call on shutdown, instead of once per counted post — meaningful reduction in option writes on sites using batch view tracking
• General hardening pass across the REST API code path (WPCS-compliant direct queries with documented phpcs:ignore justifications, no behavior change to existing filters/actions)