Thanks for the detailed report and for explaining the things you’ve tried so far. Let’s see if we can sort this out with you.
Interestingly, if I look into JetPack through WordPress.com, everything is correct.
[…]
I also know that it is not a problem with my browser, since I have the same behavior when accessing it from iOS, Windows or MAC.
This would seem to point us toward a potential conflict with another plugin on your site, something that may stop the stats from loading properly in your dashboard.
When in the Stats dashboard screen, could you check for Javascript errors, as explained here:
https://wordpress.org/support/article/using-your-browser-to-diagnose-javascript-errors/
Let me know what you find!
Hello Jeremy.
I have tried steps 1 and 2 without any success.
I am attaching at the end the results of step 3 from https://depuertoenpuerto.com/wp-admin/admin.php?page=stats#!/stats/insights/depuertoenpuerto.com?page=stats.
After testing, I have reverted the blog to its normal state, eliminating the line define(‘SCRIPT_DEBUG’, true); from wp-config.php. Let me know if you need me to include it again. In debug mode the blog seemed to be very slow.
Greetings and thank you.
[Log] JQMIGRATE: Migrate is installed with logging active, version 3.4.1 (jquery-migrate.js, line 104)
[Warning] Missing data from PHP (wpNotesArgs). (admin-bar-v2.js, line 1)
[Warning] JQMIGRATE: jQuery.fn.click() event shorthand is deprecated (jquery-migrate.js, line 136)
[Log] Rastrear
migrateWarn (jquery-migrate.js:138)
(función anónima) (jquery-migrate.js:170)
(función anónima) (feedback.js:11)
mightThrow (jquery.js:3489)
(función anónima) (jquery.js:3557)
[Warning] JQMIGRATE: jQuery.fn.submit() event shorthand is deprecated (jquery-migrate.js, line 136)
[Log] Rastrear
migrateWarn (jquery-migrate.js:138)
(función anónima) (jquery-migrate.js:170)
(función anónima) (feedback.js:32)
mightThrow (jquery.js:3489)
(función anónima) (jquery.js:3557)
[Error] Warning: ReactDOM.render is no longer supported in React 18. Use createRoot instead. Until you switch to the new API, your app will behave as if it’s running React 17. Learn more: https://reactjs.org/link/switch-to-createroot
printWarning (react-dom.js:73)
error (react-dom.js:47)
render (react-dom.js:29680)
zq (build.min.js:105:995087)
T (build.min.js:70:405606)
(función anónima) (build.min.js:105:995686)
T (build.min.js:70:405606)
zy (build.min.js:105:995868)
T (build.min.js:70:405606)
b$ (build.min.js:105:932168)
T (build.min.js:70:405606)
(función anónima) (build.min.js:105:811080)
T (build.min.js:70:405606)
(función anónima) (build.min.js:105:811133)
E (build.min.js:70:405690)
(función anónima) (build.min.js:70:405700)
(función anónima) (build.min.js:70:404804)
(función anónima) (build.min.js:105:997765)
[Debug] 3PC blocked (admin-bar-v2.js, line 1, x2)
[Error] Warning: ReactDOM.render is no longer supported in React 18. Use createRoot instead. Until you switch to the new API, your app will behave as if it’s running React 17. Learn more: https://reactjs.org/link/switch-to-createroot
printWarning (react-dom.js:73)
error (react-dom.js:47)
render (react-dom.js:29680)
zq (build.min.js:105:995087)
T (build.min.js:70:405606)
(función anónima) (build.min.js:105:995686)
T (build.min.js:70:405606)
(función anónima)
[Error] Failed to load resource: the server responded with a status of 403 (Forbidden) (index.mjs.map, line 0)
Failed to load resource: the server responded with a status of 403 (Forbidden)
That seems to be the source of the problem here.
Looking at recent changes on your site from my end, I notice a few conflicts with a different site URL, test.depuertoenpuerto.com. Do you happen to have a testing site that you use from time to time, that is copied from the production version of your site?
If so, could you try to enable Jetpack’s Staging mode on that test site, to ensure it doesn’t come conflict with the production site? You can do so by adding the following code snippet to the test site:
add_filter( 'jetpack_is_staging_site', '__return_true' )
Once you’ve done so, could you try to disconnect the production site from your WordPress.com account via the link at the bottom of the Jetpack dashboard at Jetpack > Dashboard, and then reconnect your site?
Let us know how that goes.
Yes, I have a local copy of the site in testing.
I had to create it when I moved the blog hosting. Previously, for organizational reasons, I had the blog in a subdirectory (depuertoenpuerto.com/wordpress). When moving it to a new hosting, I decided to take it to the root directory, to have a more “conventional” installation of WordPress. Since I had problems migrating the blog, I ended up moving it from the old hosting to a local server, running on MAMP. Once I managed to get it running in the root, I moved it to the current hosting. The test site was left in offline mode. Furthermore, I barely used it and almost always have MAMP turned off.
At least at first, I didn’t have any problems with the statistics, other than WordPress not recognizing the old ones as being from the same blog and they had to be reconnected manually from WordPress support. For several weeks, everything worked perfectly.
Anyway, I have made the change that you indicated and, right now, the local server is both in offline mode and in development mode. I have also disconnected and reconnected, on a couple of occasions, the actual blog.
The problem does not seem to have been resolved. The statistics still work perfectly on wordpress.com, but behave strangely and erratically if I enter Jetpack Stats from depuertoenpuerto.com.
Hi @depuertoenpuerto ,
Based on your description, it looks like the issue may be related to the local environment of your site and how it interacts with the Jetpack plugin.
Since Jetpack Stats work properly on WordPress.com but not on your self-hosted site, this indicates likely a conflict or error specific to your WordPress installation or server setup.
I suggest checking if you have a caching plugin or server-side caching, try to clear cache and see if it resolves the issue. Caches can sometimes cause outdated data to appear.
It may also be useful to test for plugin conflicts by deactivating all other plugins, except for Jetpack, and see if the stats update correctly then. If the issue resolves, reactivate each plugin one by one to identify the conflicting one. We have an in-depth guide on how to go about that here: https://jetpack.com/support/troubleshooting-plugin-and-theme-conflicts/
If these steps do not resolve the issue, please consider reaching out directly with a link to this thread via our contact form so we can investigate further. Please include screenshots of the problem areas: https://wordpress.com/support/make-a-screenshot/.
Thank you!
