WP-PostViews for WordPress

To show the count on every post automatically, a classic theme calls the template tag from index.php, archive.php, single.php or page.php, anywhere inside the loop:

<?php if ( function_exists( 'the_views' ) ) { the_views(); } ?>

The settings live at WP-Admin -> Settings -> WP-PostViews, on two tabs. Settings is where you choose who gets counted and whether WP-Stats is offered a Views section; Templates is where you edit the markup a count is rendered with.

Where the count appears is decided by where your theme calls the_views() or where you put the shortcode. To hide it somewhere in particular, answer the wp_postviews_should_display filter:

add_filter( 'wp_postviews_should_display', function ( $show ) { return ! is_archive() && ! is_search(); } );

Showing The View Count In A Block One block is available in the editor, under Widgets:

Post Views — the view count, rendered with the template from the Templates tab. Leave Post ID at zero to show the count of the post the block is in, which is what an empty [views] does, or set it to another post’s ID to show that post’s count instead.

It renders on the server, so the block preview in the editor is the real number rather than an approximation, and the count keeps rising in every post showing it without anything being re-saved. Previewing the block in the editor does not count a view.

The shortcode still works and is not going anywhere. [views] and [views id="1"] behave exactly as they always have, and a post already containing one needs no change. The block calls the same code the shortcode calls, so the two render identically — use whichever suits the post.

WP-CLI wp postviews list wp postviews list --limit=50 --format=json wp postviews get 42

The command reads and never writes. No screen in this plugin edits a view count, so the command does not offer one either — wp post meta update <id> views <n> is still there for whoever genuinely needs it, and says plainly that it is reaching past the plugin.

REST API POST /wp-json/postviews/v1/post/<id>/view

Reading a count needs no route of its own. The count is already published as a read-only views field on the core post resource, so /wp-json/wp/v2/posts/<id> answers with the post and its count together, and a list of posts carries every count in one response.

What the core field cannot do is write, which is what this route is for: it counts a view, and it exists for sites serving cached pages, where the view has to be reported after the page is delivered. It takes the same wp_postviews_nonce the counting script is given, as a nonce parameter.

It is refused unless the site defers counting — that is, unless it has a page cache and has turned the AJAX counting path on. Otherwise the view has already been counted while the page rendered, and counting again here would record every view twice.

A refusal answers 403 — a bad nonce, or a site that counts views while the page renders. A post that does not exist is 404.

This route is an addition. The admin-ajax.php wp_postviews action is unchanged and still supported.