Can I customize the layout of the list?
Yes. Use the template attribute in [init_view_list] (e.g. template="grid" ), and override the corresponding file in your theme like WooCommerce templates.
Does it work with custom post types?
Yes. Just set post_type="your_custom_type" in the shortcode or REST query.
How does it avoid duplicate views?
Init View Count uses both time delay and scroll detection via JavaScript, and stores viewed post IDs in either sessionStorage or localStorage (your choice).
Is the view count updated immediately?
Yes, by default. When the scroll+delay conditions are met, the count is sent via REST API and saved with a single atomic database update. If you enable Reduce view count cache refreshes , views are still written to the database immediately, but the numbers displayed on your site may lag behind by up to the configured interval (see below). If you enable Buffer view writes in the object cache , views are written to the database in batches once per interval; the number returned right after a view is counted is always up to date.
What meta key is used to store views?
By default: – _init_view_count (total) – _init_view_day_count – _init_view_week_count – _init_view_month_count These keys can be changed via the init_plugin_suite_view_count_meta_key filter. Trending scores are calculated separately and stored in a transient.
Can I display view counts in my template manually?
Yes. Use get_post_meta($post_id, '_init_view_count', true) or similar keys. Or use [init_view_count] shortcode in post content.
Can I disable the built-in CSS?
Yes. There is an option in the plugin’s settings to disable the default stylesheet. You can style the output manually as needed.
Is it compatible with caching plugins?
Yes. Since it uses JavaScript + REST for counting, page caching doesn’t interfere. However, REST responses ( /top ) are cached using transients.
Can I use it in block editor / Gutenberg?
Yes — since version 2.0.0 there are 3 native blocks (search “View Count”, “Popular Posts List”, “View Ranking” in the block inserter, under the “Init View Count” category), each with its own settings panel and live preview. You can still use the classic Shortcode block with [init_view_count] / [init_view_list] / [init_view_ranking] if you prefer.
What is Abilities API support and do I need it?
Since version 2.0.0, on WordPress 6.9+ the plugin registers two read-only Abilities ( init-view-count/get-post-views and init-view-count/get-top-posts ) via the core Abilities API, so AI agents and automation tools can discover and query view-count data in a standardized way. This is entirely optional and has no effect on sites without the Abilities API (WordPress below 6.9) or on how the plugin otherwise works — no view/increment/reset ability is exposed.
Does it track bots?
No. Since counting only happens after scroll and delay via JavaScript, bots like Googlebot are naturally excluded.
Can I sort posts by views in WP_Query?
Yes. Use 'meta_key' => '_init_view_count' and 'orderby' => 'meta_value_num' in your WP_Query args.
Can I reduce the number of view requests sent to the server?
Yes. You can enable batch view tracking in the plugin settings. Instead of sending one request per view, views will be stored in the browser and sent in a group once the threshold is reached.
Should I enable “Reduce view count cache refreshes”?
Only if your site uses a persistent object cache (Redis, Memcached, etc.) and gets a lot of traffic. By default, each counted view clears the cached metadata of that post, so a popular post has to reload all of its metadata from the database again and again. With this option on, each post’s cache is refreshed at most once per interval (60 seconds by default, 10–600 allowed). Every view is still written to the database right away and nothing is lost — only displayed numbers (shortcodes, blocks, rankings, Trending, the number shown after counting) may be slightly behind. A post that stops receiving views may keep showing a slightly lower number until it gets another view, is updated, or the daily reset runs (when daily views are enabled). Without a persistent object cache the option has no effect, and the settings page tells you so.
Should I enable “Buffer view writes in the object cache”?
Only if your site gets a lot of traffic and runs a working persistent object cache (Redis, Memcached, etc.). It is off by default. By default every counted view runs an UPDATE on wp_postmeta ; on a very busy site, many visitors reading the same popular post update the same rows at the same time and queue up behind each other’s row locks. With this option on, each view only increments a counter in the object cache (an atomic in-memory operation), and a background WP-Cron job writes everything to the database once per interval (60 seconds by default, 30–600 allowed) using a single UPDATE per counter type for up to 500 posts, then refreshes each post’s meta cache once. Traffic Shape data is buffered too, exactly, without sampling.
Nothing changes for code that hooks into view counting: init_plugin_suite_view_count_after_counted still fires once per view with the same parameters, and its total / day / week / month values still increase by one per view. Numbers read from the database (shortcodes, blocks, rankings, Trending) may lag behind by up to the interval. Buffered views are always written before the daily reset, when the option is turned off, and when the plugin is deactivated, and you can write them at any time with Write buffered views now .
Memory use is small: about 200 bytes per post/counter pair that received views in the current hour. Counters of past hours are deleted from the object cache a few minutes after the hour ends, so the object cache only ever holds roughly one hour’s worth of counters.
Requirements and trade-offs: the object cache must increment counters atomically (Redis Object Cache, Object Cache Pro and the common Memcached drop-ins do; the plugin runs a self-test before the option can be turned on, and automatically falls back to direct database writes while Redis is unreachable, when Redis Object Cache uses igbinary, or when the plugin’s cache group is configured as non-persistent). If the object cache is restarted or flushed, views not yet written (at most about one interval) are lost. Configure Redis with maxmemory-policy noeviction or volatile-lru so buffered counters are never evicted, and make sure WP-Cron runs reliably. A real server cron is recommended; if WP-Cron stops running, the plugin writes overdue views itself during a view request.
Should I enable “Sample Traffic Shape writes”?
Only on busy sites with Trending enabled. The Traffic Shape Learner (which teaches Trending your site’s hourly and weekday rhythm) updates a database option on every view request. With sampling on, it records only 1 in every N requests (10 by default, 2–100 allowed) and counts each sample N times, so it writes about N times less often while the expected numbers stay the same. On low-traffic sites the learned pattern becomes noisier, so leave it off there. Post view counts are never sampled.
Does “Strict IP check” affect performance?
A little. It reads a transient on every view request and writes it back every time a view is counted. With a persistent object cache (Redis, Memcached) that happens in memory. Without one, transients live in the wp_options table, so each counted view adds up to two extra database writes. On busy sites without a persistent object cache, only enable it if you really need it.
Should I enable “Require REST nonce verification”?
It’s optional and off by default. Enabling it makes the /count endpoint reject requests that don’t carry a valid WordPress REST nonce, which helps block fake POST requests sent directly to the endpoint. However, WordPress nonces expire after roughly 12-24 hours. If your site uses full-page caching with a long TTL, cached pages will keep serving an old nonce and view counting will quietly stop working on those pages until the cache refreshes. Leave it off on sites with long-lived page caching, or make sure the cache is purged/refreshed regularly. The /top endpoint is unaffected either way, since it’s read-only and public by design.
