Hits per Page no longer works

[KillianLeroux]

Hi!

First of all, thanks for your powerful extension!! ;)

I use WP Statistics for several months and I have noticed since August 16th no data is captured for hits per page :(

I debug and I found a clue in function Pages::get_page_type() (file includes\class-wp-statistics-pages.php): get_queried_object_id() return 0, and global $post is null :/

But when I make var_dump(get_queried_object_id()); I have 0 in API call /api/wp-statistics/v2/hit 3 times and I have the good value (75) 2 times on frontend, is it normal?

Thanks for your reading :)

[mostafasoufi]

Hi,

Thank you for opening the issue and your feedback!

That's weird, can you please make sure the what's the value of current_page_id in the request?

[KillianLeroux]

Hi,

Thanks for your reply!

Yes I have a value in current_page_id, example: https://lamacompta.co/entreprise/adecia/

[mostafasoufi]

Can you please tell me where and which line did you put the var_dump?

[KillianLeroux]

I put the var_dump here:

File wp-statistics/includes/class-wp-statistics-pages.php:

    /**
     * Get WordPress Page Type
     */
    public static function get_page_type()
    {
        //Set Default Option
        $current_page = array("type" => "unknown", "id" => 0);

        //Check Query object
        $id = get_queried_object_id();
        var_dump($id);

        if (is_numeric($id) and $id > 0) {
            $current_page['id'] = $id;
        }

But I just noticed that there is a test on the api prefix in Helper::is_rest_request() called in is_rest_hit() itself called in includes\class-wp-statistics-hits.php constructor before hit page view, and $rest_prefix = trailingslashit(rest_get_url_prefix()); in Helper::is_rest_request() send wp-json/ but I redefined prefix with api in my functions.php:

const API_URL_PREFIX = 'api';

// Redefine API Prefix
function redefineApiUrlPrefix($prefix)
{
    return API_URL_PREFIX;
}
add_filter('rest_url_prefix', 'redefineApiUrlPrefix', 10, 2);

I think the problem is here, because when I remove my function redefineApiUrlPrefix() the hit page is back!

[mostafasoufi]

Weird, worked fine with that function to change the REST API prefix!

Let's try changing the priority of the hook or move it to a different place, function.php or something like that.

[KillianLeroux]

Weird indeed :/

I put var_dump in different places, and it appears that it is WP Statistics that loads first:

:

[KillianLeroux]

The head of my Child Theme functions.php:

<?php
var_dump('Child Theme');

// Redefine API Prefix
function redefineApiUrlPrefix($prefix)
{
    var_dump('Child Theme URL Prefix');
    return 'api';
}
add_filter('rest_url_prefix', 'redefineApiUrlPrefix', 0, 2);

In your test do you use a child theme?

[mostafasoufi]

I changed the REST API Prefix by that function through the child-theme, worked fine!

You need just to update the Permalink by pressing the Save Changes button.

[KillianLeroux]

Ok so similar to my case... I think I will test on clean installation and add parent theme, child theme and extensions one by one to test.

Yes I already saved Permalink in wp-admin many times ;)

[mostafasoufi]

If still doesn't work, just play around with the WP-Statistics's hooks priority.

diff --git a/includes/api/v2/class-wp-statistics-api-hit.php b/includes/api/v2/class-wp-statistics-api-hit.php
index 541abe31..c3e7ab46 100644
--- a/includes/api/v2/class-wp-statistics-api-hit.php
+++ b/includes/api/v2/class-wp-statistics-api-hit.php
@@ -24,7 +24,7 @@ class Hit extends \WP_STATISTICS\RestAPI
         parent::__construct();
 
         // Register routes
-        add_action('rest_api_init', array($this, 'register_routes'));
+        add_action('rest_api_init', array($this, 'register_routes'), 20);
     }
 
     /**
diff --git a/includes/class-wp-statistics-frontend.php b/includes/class-wp-statistics-frontend.php
index b4db5981..e123639d 100644
--- a/includes/class-wp-statistics-frontend.php
+++ b/includes/class-wp-statistics-frontend.php
@@ -18,7 +18,7 @@ class Frontend
         add_action('wp_enqueue_scripts', array($this, 'enqueue_scripts'));
 
         # Add inline Rest Request
-        add_action('wp_head', array($this, 'add_inline_rest_js'));
+        add_action('wp_head', array($this, 'add_inline_rest_js'), PHP_MAXPATHLEN);
 
         # Add Html Comment in head
         if (!Option::get('use_cache_plugin')) {
diff --git a/includes/class-wp-statistics-hits.php b/includes/class-wp-statistics-hits.php
index 2bc1fb87..af5de4c0 100644
--- a/includes/class-wp-statistics-hits.php
+++ b/includes/class-wp-statistics-hits.php
@@ -52,7 +52,7 @@ class Hits
         }
 
         # Record WordPress Front Page Hits
-        add_action('wp', array($this, 'record_wp_hits'));
+        add_action('wp', array($this, 'record_wp_hits'), 20);
     }
 
     /**
diff --git a/includes/class-wp-statistics.php b/includes/class-wp-statistics.php
index 567b1c33..028bcc61 100644
--- a/includes/class-wp-statistics.php
+++ b/includes/class-wp-statistics.php
@@ -53,7 +53,7 @@ final class WP_Statistics
         /**
          * Plugin Loaded Action
          */
-        add_action('plugins_loaded', array($this, 'plugin_setup'), 10);
+        add_action('plugins_loaded', array($this, 'plugin_setup'), 30);
 
         /**
          * Disable AddOns For Compatible in Wp-Statistics 13.0

[KillianLeroux]

Unfortunately it's the same result :/

[KillianLeroux]

And if we put filters in function called after rest_url_prefix hook, like that:

    /**
     * WP_Statistics Hits Class.
     *
     * @throws \Exception
     */
    public function __construct()
    {
        # Sanitize Hit Data if Has Rest-Api Process
        add_action('rest_url_prefix', array($this, 'hits_init'), 30);

        # Record Login Page Hits
        if (!Option::get('exclude_loginpage')) {
            add_action('init', array($this, 'record_login_page_hits'));
        }

        # Record WordPress Front Page Hits
        add_action('wp', array($this, 'record_wp_hits'), 20);
    }

    public function hits_init()
    {
        if (self::is_rest_hit()) {
            # Get Hit Data
            $this->rest_hits = (object)self::rest_params();

            # Filter Data
            add_filter('wp_statistics_user_agent', array($this, 'set_user_agent'));
            add_filter('wp_statistics_user_referer', array($this, 'set_user_referer'));
            add_filter('wp_statistics_user_ip', array($this, 'set_user_ip'));
            add_filter('wp_statistics_hash_ip', array($this, 'set_hash_ip'));
            add_filter('wp_statistics_exclusion', array($this, 'set_exclusion'));
            add_filter('wp_statistics_user_http_agent', array($this, 'set_user_http_agent'));
            add_filter('wp_statistics_current_timestamp', array($this, 'set_current_timestamp'));
            add_filter('wp_statistics_current_page', array($this, 'set_current_page'));
            add_filter('wp_statistics_page_uri', array($this, 'set_page_uri'));
            add_filter('wp_statistics_user_id', array($this, 'set_user_id'));
            add_filter('wp_statistics_track_all_pages', array($this, 'set_track_all'));
        }
    }

?

But I don't understand why it doesn't work for me but it works for you :/

[craigconstantine]

…I'm not sure I can be of any help troubleshooting, but: Me too!

I'm not sure what exact date it stopped working. And I'm wondering if it's related to some security-setting/tweak I've changed in the iThemes Security plugin https://wordpress.org/plugins/better-wp-security/

[mostafasoufi]

Good point! let's test in a fresh WordPress installation.

[craigconstantine]

I'm really feeling like there's something wrong here… :)

[KillianLeroux]

You're really good in SEO 😎

[mostafasoufi]

Weird indeed, have you changed the robot's configuration recently? @craigconstantine

[craigconstantine]

I fiddled with something— some setting related to cache as I though maybe I had that wrong, and had caused my original, actual callout...

which is: Why are there no page accesses being counted?

[dannymasao]

Maybe this is the same issue. After upgrading a site from WordPress 4.9.4 to 5.7 and updating WP statistics along with other plugins, it seems the page hit counting stopped. The hits column in post/pages list for the articles published after the upgrade keeps showing 0. But on the settings page I can see that it tracks overall site visitors/visits. It just stopped tracking individual page hits. Unfortunately, I don't know what version number WP statistics was before I updated it but it probably hadn't been updated in about 2 years. Tried disabling other plugins but doesn't seem like anything changed.

[craigconstantine]

I've been keeping up with WP and wp-statistics updates within days of every release of both, for years. This just started recently for me. Very oddly, I have 4 other WP sites that use wp-statistics and things are fine on those sites.

On the site with the problem, I recently used a plugin to remove a bunch of [what i believe were] unused tables from the database. So I've been thinking that maybe I removed a table that wp-statistics needs?? I'd expect much more brokenness though...

Can a dev tell me the tables is expects so I can verify I didn't remove one that's needed? …or does it have any sort of "check my tables" functionality built in??

[KillianLeroux]

I think it's not a db table problem @craigconstantine.

@craigconstantine and @dannymasao do you override the WP API prefix?

The default API prefix is "wp-json" (https://mywebsite.com/wp-json).

For me, it's because I override this API prefix by "api" (https://mywebsite/api) that hit per page doesn't longer work, when I restore "wp-json", it works!

FYI the potential override may be in plugin, or when using hook "rest_url_prefix" in file "functions.php":
http://hookr.io/4.6/filters/rest_url_prefix/

[craigconstantine]

http://constantine.name/wp-json/ exists on my server, yes. (So I've not intentionally changed that, and no plugin seems to have changed it.) I notice that "wp-statistics" also appears in the output . . .

I cleared my browser cache and loaded a page on my site. Here's all the resources fetched across the network... I don't see anything in here that indicates j/s making an API call to track a page load . . . am I reading this correctly:

[craigconstantine]

I'm using the Autoptimize plugin. I have this wp-statistics setting off. Last week I turned this on (and saved the permalinks settings) and I believe that's when I saw the big-fat-zero in my stats for a few days (ref screenshot above) ... ?

[mostafasoufi]

When the Cache Compatibility option is enabled, then you can see the REST API request in the Network XHR panel.

If the counter does not work, probably related to a cache issue or REST API endpoint which is blocked or restricted by some security plugin, In terms of experience, It might help to find the issue by checking the following:

• Add the WP-Statistics's REST API endpoint to the whitelist if the REST API is restricted by security plugins or CDNA services such as Cloudflare
• Check the WordPress error log (WP_DEBUG_LOG) and WP-Statistics's log which is stored in wp-content/uplaods/wp-statistics/debug.log

[craigconstantine]

¯\_(ツ)_/¯

I don't have Cache Compat enabled on 4 other WP sites, where "top pages" is showing data. On one of my sites, I've now enabled Cache Compat and I'm seeing "hit" in XHR which looks like it's tracking…

…but still nothing is showing in Top Pages

[KillianLeroux]

¯\_(ツ)_/¯

I don't have Cache Compat enabled on 4 other WP sites, where "top pages" is showing data. On one of my sites, I've now enabled Cache Compat and I'm seeing "hit" in XHR which looks like it's tracking…

…but still nothing is showing in Top Pages

I have exactly the same :/
So I developed my own solution :x

[mostafasoufi]

Weird indeed, can someone give me WordPress access? I think I need to check something there, please send the access to mostafa@veronalabs.com

[craigconstantine]

I'm not inclined to give you access, no. You're welcome to explain to me how to troubleshoot this. I have full access to the db, wp, etc.

Meanwhile, I'm going to DISable that cache compat feature on this site, since the stats overview now looks like this…

[craigconstantine]

In an effort to keep poking at this, I decided I'd not mind losing all my historical stats... so I delete and installed the plugin.

IT'S FIXED. o_O ...all my page stats are now showing. So this tells me they were being recorded all along, and there was just something wrong with display —— is it possible there's some setting I flipped off that killed display of the stats, and delete/install reset some config I'd jiggled??

[KillianLeroux]

@craigconstantine did you just uninstall and then reinstall the extension? This is what I just did and it didn't work :(

[craigconstantine]

…yes, that's all I did.

[jimsihk]

Not sure if there is a fix on this as I have also come across this issue using PHP 7.4.27 and WordPress 5.9 with plugin version 13.1.15. With WordPress debug mode enabled, below error are shown at the "Page" view page:

WARNING: wp-content/plugins/wp-statistics/includes/class-wp-statistics-pages.php:407 - Invalid argument supplied for foreach()

do_action('statistics_page_wps_pages_page'), WP_Hook->do_action, WP_Hook->apply_filters, WP_STATISTICS\pages_page::view, WP_STATISTICS\Pages::getTop

Using the Debug Bar plugin, I am able to see below in the Query tab that the plugin is trying to retrieve data from the table wp_statistics_pages.

SELECT pages.date,pages.uri,pages.id,pages.type, SUM(pages.count) + IFNULL(historical.value, 0) AS count_sum FROM wp_statistics_pages pages LEFT JOIN wp_statistics_historical historical ON pages.uri=historical.uri AND historical.category='uri' WHERE (pages.date BETWEEN '2022-01-06' AND '2022-02-05') GROUP BY uri ORDER BY count_sum DESC LIMIT 0,10

do_action('statistics_page_wps_pages_page'), WP_Hook->do_action, WP_Hook->apply_filters, WP_STATISTICS\pages_page::view, WP_STATISTICS\Pages::getTop, PDODB->query

SELECT COUNT(*) FROM wp_statistics_pages pages WHERE date BETWEEN '2022-01-06' AND '2022-02-05' GROUP BY uri

do_action('statistics_page_wps_pages_page'), WP_Hook->do_action, WP_Hook->apply_filters, WP_STATISTICS\pages_page::view, WP_STATISTICS\Pages::TotalCount, PDODB->query

However, if tried to check the table, the table does not exist, is that expected?