When I double-click on that item in the chrome developer console I get this message returned: {“status_code”:403,”status_text”:”The nonce you provided is invalid.”,”success”:false,”data”:[]}
Would this result in the behavior of continually reloading?
The page I need help with: [log in to see the link]
The WordPress noncesdo expire, so it is expected that if you attempt to hit the API URL with an old nonce that you will get a 403 status code returned.
Relating to the core issue (the page endlessly refreshing) this can happen if you had an additional cache (i.e., varnish, etc) that is caching the old version of the site. I can help debug if you’re able to provide a screen capture.
To debug further, send a screen capture in the following format. Please be sure to read the following instructions carefully before providing the capture.
1. Begin screen capture by showing three browser windows at the same time. These must remain visible during the entire screen capture process.
– One open on the admin page (where you’re attempting to refresh)
– One open on the page that keeps refreshing with the JavaScript console open (the end-user page you’re attempting to refresh)
2. Click “Force Refresh” on admin page.
3. Make sure that the screen capture shows the end-user page refreshing along with the output from the JavaScript console
I didn’t see direction for the third browser window, only one open to admin page, this is on the left, and one on the page that keeps refreshing, this is on the right:
The left hand screen just keeps refreshing over and over repeating the same few messages over and over again, there is no change after I click “Force Refresh Site” button at the dashboard top admin bar.
I’m not sure if this is relevant but when I manually stop the page load on the end-user page I see the following two messages in the console:
Hopefully I’ve provided what is needed, very much appreciate your time in looking into this!
This reply was modified 2 years, 5 months ago by joshdclarke.
This reply was modified 2 years, 5 months ago by joshdclarke.
Sorry about that! You only need two browsers, not three. My mistake!
Do you mind sending over screen captures instead of screenshots? Screen captures are video recordings of what’s going on that can help me isolate the issue.
No problem, thanks for getting back so quickly! I can see what you’re talking about now and was looking to debug further. The way the plugin works is that when it’s loaded, a hashed version of the current site version is stored. Then, periodically, the site will reach out to the WordPress API to see if the version has been updated. If the retrieved version differs from the stored version, then the site refreshes. In this case, even if the call the API is failing, the site should not refresh.
Issue has not returned since installing the new version of the plugin.
I notice in console after being up a few days without clearing cache, get the following in console:
‘storing version undefined’
Seems to return the following day. It’s not a big deal, still has the desired effect of not getting into a login loop, just passing along as an FYI! Will test across some of our other sites and report back anything significant, marking as resolved!
This reply was modified 2 years, 5 months ago by joshdclarke.
The interesting thing here is that I don’t see any logs that would indicate that the site would continually refresh. When this altered version needs to refresh, it just logs to the console. If you install the previous version, do you still get that error? I’m wondering if there is a conflict between my plugin and something else you’re using by chance.
Oh yeah no problem. One other thing that’s _also_ interesting now is that it appears those API calls to the WordPress backend now appear to be working.
Hey Jordan, happy Friday!
Just wanted to report in that after reinstalling the plugin the issue has returned:
took a quick video capture of the behavior: https://youtu.be/ehCbcV17sgU
Is there any other information I could provide that might be helpful? I should add that when we purge cloudflare cache the issue seems to go away for a day or so and then returns.
Thanks for letting me know that the issue is still present on your site. I’ll still have to isolate why this issue is happening to your site, and the info you sent about CloudFlare is helpful. By chance, did you purge the cache right after installing the debugging version of the plugin I sent over?
The reason why I ask is that the plugin itself is relatively simple. The plugin stores a hashed version of the current site (which is the date and time when a force refresh was requested). For purposes of explanation, I’ll just refer to dates here. Let’s say you request a refresh on Monday. Visitors to the site will see that the current version of the site is “Monday”. However, if the visitor is still on your page on Tuesday and, while they’re visiting, you request a refresh, the current version is set to Tuesday. The visitor on your site (which periodically reaches out to the WordPress API to get the current version) will see that the new version is “Tuesday” and since that doesn’t match “Monday”, the site will refresh. There’s other stuff happening under the hood, but that’s the basic premise.
The reason why I wanted to outline that to you is that the only difference between the version that is causing you issues and the debugging version I sent is that instead of actually refreshing, the site would just output that it intends to refresh. When I went to your site with the production version, I saw what you saw: which is that the site continually refreshed. However, when you installed the debugging version, it didn’t refresh. This is, of course, because the debugging version doesn’t actually refresh. Instead, it just logs that it intends to. But when I was looking at the console on your site, I didn’t see any logs that said that the site intends to refresh. This tells me that there might be a confounding variable here: possibly the CloudFlare cache.
I’m not sure exactly what’s going on, but I am determined to fix it. The best way to do that is if I can replicate the behavior using this debugging version and see why it’s continually refreshing. But to do that, I’d need to be able to see that the site is logging that it intends to refresh. Would it be possible to add the debugging version back and avoid clearing the CloudFlare cache? We’ll know it’s working if in the console, you see a bunch of debug logs that say, “Site would reload”.
Thanks again, and I hope you have a great weekend!
Quick update: trying to debug this issue on your site has illustrated another need for this plugin, which is centered around having more robust debugging tools. A year or so ago, I started work on this and decided that now might be a good time to implement it.
In any case, I have a new build for you here, (build notes are available here) which you can install like you did the previous version. This version, though, has a hidden feature. When you’re at the Force Refresh page (wp-admin/tools.php?page=force_refresh), click on “Force Refresh” three times quickly to get into the troubleshooting page. From here, you can enable debug mode which will run log out more data and prevent the refresh from actually happening.
In the future, this will be baked into a production release so we could do this type of debugging without having to ask folks to install a totally different plugin.
Let me know what you think! If you get it installed, let me know and I’ll see if that leads me to the issue on your site.
This reply was modified 2 years, 5 months ago by jordanleven.
Yeah will absolutely get it installed today, just circling back on the below!
Just wanted to circle back on the debug version, I did reinstall it Friday before I left and upon returning today and checking the console, it does appear to want to refresh each time.
Did a quick capture, and let it run 2 minutes just to capture a second refresh.
I did notice in the console, upon loading the site it immediately says site would reload. Then does so again at about 1 minute, and again at 2 minutes.
Do you want me to leave the current version on for now, in the event you need/want to check anything, or good to install the updated version?
No worries on uploading the version I sent over — I was able to get all the info I needed this morning. And with that, some good news! I think I’ve figured out what this is happening to you.
It appears that the cache you have on the site might be caching two things: 1) the first is cryptographic nonce that’s used to authenticate the request; and 2) the API return status code. Here’s what I have:
It looks like the request to the API isn’t outright failing (it’s getting a 200 return status code) but if you look at the logs, it say’s that it’s being returned an undefined version of the site, which is suspicious. So I did a call to the API and found that the return status code should be a 403, but is being returned as a 200. The problem here is that currently, Force Refresh only stops looking for refreshes with the returned HTTP status code is a non-200 code. So that’s issue number one.
The second issue is that the nonce itself is being cached by CloudFlare, which means that the call would fail no matter what. The issue is that what’s supposed to happen is that Force Refresh simply exits after learning that the API call has failed. But, of course, it doesn’t really know that since the status code that’s being returned is a 200. This is, in part, why the issue only happens a couple days after clearing the CloudFlare cache.
In any case, there’s nothing else for you to do here. I’m going to make some adjustments to work with this kind of setup. After I make those adjustments, I’m going to send you another beta version to install (just to make sure it actually fixes it) and after confirming that, it’ll be released as part of the public plugin as an update.
How does that sound?
This reply was modified 2 years, 5 months ago by jordanleven.
