AdlerBCE

@kimvt1991 – Perfection!

You can take me off the list. The message is generated by google reCAPTCHA. It could theoretically appear on any form submission using google reCAPTCHA. In my case it appears that a plugin I had installed to add reCAPTCHA to the backend was causing a conflict with Ultimate Member.

You can now add me to the list. I have been working with UM for years. Just now building a new site. Just cleaning up email notification. All was working great until 30 mins ago. No caching.
All yesterday I was setting up the same dummy account over and over to check the email responses – no problems at all. I did have other member plugins active at the time – no problems at all. This morning it was time to remove the competing plugins and update UM to latest version – Bingo! – “The response is no longer valid: either is too old or has been used previously.”
I have been force to return to one of your competitors to make this go away. Re-installing UM and UM-reCaptcha just triggers the problem again.
The error message comes up regardless even when I try to use my admin login which has never been fiddled with, I now get the message. UM completely disables the User Front end login.

To provide some clarity with the debugging of my site, is this message coded into your plugin?

OK… Now that I can see the Dashboard for 3-5 second, I can scroll down to the bottom of the page where I see that “PageSpeed Insights is preparing data…”. Clearly, once the data is prepared and the plugin attempts to display the results, that is when the error is triggered. That is when the error is loaded in to the OpCache. Clearing the OpCache forces the plugin to regenerate the PageSpeed data enabling me to briefly see the dashboard again.

It seem pretty clear that PageSpeed is generating the code to display the data and it is failing to generate a line or code or subroutine properly. The result is that following line(s) of code are being interpreted as data for the un-terminated code sequence when it is actually the next command sequence which is supposed to be displaying something (given all the references to div in the error sequence).

Well, at least that is my two pennies worth. Keep us posted.

P.S. I have also notice that this error is listed as a “unexpected PageSpeed Insights API response”. I am not using PageSpeed although I can see it is connected when I look at the Settings page of the Site Kit.

If I may chime in with some more info.

I installed and activated your mini plugin. It did have a beneficial impact or sorts. With the plugin active I can view the Dashboard for 3-5 second every time I visit it. You should note from my first post that previously, once I triggered the error the dashboard would not load at all. So, I guess we can assume that clearing the OpCache does eliminate the error until the OpCache fills again.

I just noticed this error on the Site Kit Dashboard about 2 hours ago. I have track the introduction of this error to the 1.2.0 upgrade.

When you start analysing this error you discover that it does not trigger on the page immediately. After updating to 1.2.0 I can view the Site Kit Dashboard for about 3-5 seconds, then the dashboard page is replaced with the error message. After the error is triggered I can no longer view the Site Kit Dashboard at all. Any attempt to view or refresh the Site Kit Dashboard page just brings up the error message.

I am still able to view the Search Console page, the Analytics page and the Setting page.

Full text of the error message follows:

Cannot read property ‘performance’ of undefined
in t in u in t in Unknown in WithFilters(t) in div in div in div in t in div in t in Unknown in WithFilters(t) in t in t in div in div in div in div in t in t

I noted that the error message I am seeing is identical to that of @anguschang007. If I was to speculate, I would say that some line of code or command in the code is not terminated properly.

Looking forward to the next bug fix update.

Warm regards,

Marcus

Problem(s) solved. Both symptoms – WP that page does not exist and stats discrepancies were both cause by a conflict between wp_stats and wordfence. The conflict only occurs when you use wordfence’s simple cache option. I have not tested if the conflict also occurs with wordfence’s falcon cache.

I will cross post this as a wordfence issue. At the end of the day it is up to your guys to see if the conflict can be resolve or whether users using both plugins are warned not to use the wordfence cache option.

Flushing the db table had no effect. Moving on to other plug-ins. I am focusing on one in particular. Won’t mention any names just yet. The two plug-in have been working together harmoniously for a year, but I have my suspicions about one of the setup options. Stay tuned.

I have just flushed the settings from the db table and re-configured everything. We’ll see how that goes. Thanks for all your efforts. If it wasn’t such a great plug-in I would not be so piss-off about breaking it.

@greg Ross – no such luck. I have now purge the first 4 months of data from the database. Nil impact on the problem(s). I have also been live monitoring the hosting resource usage with cPanel on the back end. The site is no where near the resource limits.

It cannot be a coincidence that after I fiddled with the wp_stats settings to try resolving the page loading problem that reported hits search referrals tanked. Monitoring the sites backend very carefully before I started fiddling, the search referral data was not affected when I first started looking at the page loading problem.

Snooping around the stats some more I have noticed that the daily hit count on individual pages has tanked by a similar percentage to the search engine referral count. However, the visitor hit count and visits hit count are unaffected.

Any idea how wp_stats can record the 300 visitors and over 1,000 visits and yet not correctly record the pages being visited?

P.S. I am holding off on deleting everything and reinstalling so that we might get to the bottom of this.

Excellent work. Thanks Greg.

P.S. Excellent plug-in

Yep! That seems to have fixed it.

I went back to some of the other sites and noticed they did not have browscap usage Activated.

As a precaution, should we go back to all sites and force the browscap update after updating to 8.1.1?

I have a number of WP sites I manage for clients (basically half a dozen all with the same theme and plug-in set) all hosted with godaddy. Two days ago, WP Statistics stop recording visits, visitors and search referrals on one (and only one) of these sites.

Details as follows;

Resources

Memory usage in PHP: 7,096,120 Byte

PHP Memory Limit: 256M
The memory limit a script is allowed to consume, set in php.ini.
Number of rows in the wp_statistics_useronline table: 1 Row

Number of rows in the wp_statistics_visit table: 171 Row

Number of rows in the wp_statistics_visitor table: 7,273 Row

Number of rows in the wp_statistics_exclusions table: 575 Row

Number of rows in the wp_statistics_pages table: 1,436 Row

Version Info

WP Statistics Version: 8.1
The WP Statistics version you are running.
PHP Version: 5.4.31
The PHP version you are running.
PHP Safe Mode: No
Is PHP Safe Mode active. The GeoIP code is not supported in Safe Mode.
jQuery Version: 1.11.1
The jQuery version you are running.
cURL Version: 7.24.0
The PHP cURL Extension version you are running. cURL is required for the GeoIP code, if it is not installed GeoIP will be disabled.
BC Math: Installed
If the PHP BC Math Extension is installed. BC Math is no longer required for the GeoIP code and is listed here only for historical reasons.

Have spoken to Godaddy support and there is nothing but green lights on the hosting account.

Anything else I should check? Any other ideas what could be causing this?

Marcus

@greg Ross – Never got a chance to try your fix. Just saw the 5.4 upgrade notification, upgraded from 5.3 to 5.4 and all is working.