WP-PostViews 2.0.0
-
WP-PostViews 2.0.0 is a total rewrite of the plugin with Claude Code to make it more modern and testable. There will be breaking changes. Please do test it https://github.com/lesterchan/wp-postviews/archive/refs/heads/master.zip
WP-PostViews 2.0.0 requires WordPress 6.8 and PHP 8.2. A site on an older stack is simply not offered the update, so if WP-PostViews has stopped appearing in your updates list, that is why.
View counts, templates and settings all carry over on their own.
If your view counts stop appearing, this is why: the_views is now wp_postviews_the_views. That name was far too generic for a filter belonging to one plugin, and it had been public since 1.78.1, so it is very probably sitting in a theme somewhere. Search for the_views: a line like add_filter( ‘the_views’, … ) needs the new name and nothing else, with identical arguments. A call to the_views() with brackets is the template tag and is unchanged. There is no shim, so the old name fails silently — the symptom is the count appearing but your custom wrapper, prefix or wording gone.
Three more were renamed the same way: postviews_should_count is now wp_postviews_should_count, and postviews_increment_views and postviews_increment_views_ajax are now wp_postviews_increment_views and wp_postviews_increment_views_ajax.
Update all seven WP-Stats plugins together. WP-PostViews, WP-Stats, WP-Polls, WP-PostRatings, WP-UserOnline, WP-EMail and WP-DownloadManager shared two unprefixed rows; each keeps its own copy now and deletes the shared ones, so whichever you update first takes them from the rest. A missing row means “show”, so a section you had hidden may reappear. The views section is toggled on Settings -> WP-PostViews now, which also sets how many entries the most viewed lists carry. WP-Stats receives one Views section rather than three separately switchable panels, so the most viewed pages list appears beside the posts list even if you had only ever asked for posts; untick the whole section if you would rather not see it.
The settings screen is options-general.php?page=wp-postviews, not options-general.php?page=wp-postviews/postviews-options.php. The Settings -> WP-PostViews menu item is where it always was.
Two rows are renamed on the first load after updating — views_options to wp_postviews_options and views_version to wp_postviews_version — and the old rows are deleted afterwards. Point any code, WP-CLI script or export reading views_options at the new name.
Three undocumented functions are gone. should_views_be_displayed(), postviews_round_number() and snippet_text() are now WP_PostViews_Display::should_be_displayed(), ::round_number() and ::snippet_text(). The widget class WP_Widget_PostViews is WP_PostViews_Widget, which matters only if you were instantiating it yourself; widgets already placed in a sidebar are untouched.
The Display Options settings are gone, and counts you had hidden will start appearing. The six rows — Home Page, Single Posts, Pages, Archive Pages, Search Pages, Other Pages, each of them “Display to everyone / Display to registered users only / Don’t display” — are removed, and the stored display_home, display_single, display_page, display_archive, display_search and display_other keys are dropped on upgrade. If you had set any of them to anything other than “Display to everyone”, that choice is not carried over: a site that hid the count on archives or on search results will show it there from the first page load after updating.
Restore the gate with the wp_postviews_should_display filter, which is the documented replacement and receives true. Return false to hide the count. All the conditional tags are available, so the old settings map across one for one:
add_filter( 'wp_postviews_should_display', function ( $show ) {if ( is_archive() || is_search() ) {return false;}if ( is_home() ) {return is_user_logged_in();}return $show;} );The first branch is the old “Don’t display on archive pages” and “Don’t display on search pages”; the second is “Display to registered users only”, for wherever you had chosen it.
WP_PostViews_Display::should_be_displayed() is unchanged as a public method and now returns what that filter answers, so anything calling it directly keeps working. The [views] shortcode and the admin Views column deliberately do not consult the filter: both are explicit requests for the number.
The settings screen is two tabs now, Settings and Templates, at the same URL. The two template fields moved to the Templates tab; everything else stayed. It is still one option row and one Save Changes button per tab, and saving one tab does not disturb the other.
The page I need help with: [log in to see the link]
You must be logged in to reply to this topic.