Ian Pegg

Hello @jeroenrotty

Thanks for taking the time to test for this issue. I’ve just tried upgrading to the latest release again – and this time I updated translations before going to the settings page. Doing this fixed both issues!

I didn’t stop to consider that an outdated translation set could cause a fatal in JS. Perhaps the plugin could be configured to fall back to the stock US English when issues like this arise?

Hello @maybellyne

Thank you for getting back to me. Most of the sites I manage are using UK English translations rather than the stock US English. I’ve seen the error on all UK sites I’ve tested so far.

As an aside, I had also noticed that one of the headings on the top settings page appears to be in Mandarin. I suspect this is related to the above issue?

• This reply was modified 2 years ago by Ian Pegg. Reason: Added extra information about incorrectly translated heading

That makes perfect sense, @rogierlankhorst, thanks for the explanation! It sounds like any assumptions the plugin makes might turn out to be unfounded until the wizard has been completed, at least up to a certain point.

If v7 can resolve this, that would be fantastic! In the meantime, perhaps the wizard could make it clear that the scan will need to be run again after the admin interacts with the banner?

Thanks @rogierlankhorst. I noticed this morning that those cookies disappeared from the policy by themselves. I then ran the wizard again because I’d made some changes to the site and they reappeared. However, after clearing the transients and page cache they disappeared again so this ties in with what you’ve said.

I notice now that the policy includes Complianz’s own cookies as I’d interacted with the consent popup before running the wizard a second time. This is the correct and complete behaviour I believe but is it intentional for these to be left out of the policy after the initial setup?

Whether the admin has these cookies set or not when they run the scan, I believe most of these cookies will be set for every user to indicate whether or not they have consented to tracking etc.

Fab! Thanks, @qtwrk!

Hello @maybellyne

Thanks for getting back to me. The process you describe is precisely what I’ve already done. The issue persisted under all test conditions described in my original post.

What is the next step?

I suspected that was your reasoning. What matters is that it appears to be working. If I were to enable ‘Serve Stale’ then I can imagine that could cause the 403 response to be served even after 1 second has passed – until the cache is rebuilt?

Could be worth adding a note to the LiteSpeed docs or the in-product documentation that explains the above behaviour.

Thanks for your help!

Thanks @qtwrk – touch wood, this appears to have fixed the problem.

I would like to understand why this has fixed the problem though. It seems counterintuitive to set 403 cache expiry to 1 second when what I actually want is for 403s to not be cached at all. Is this a bug or a feature?

Hi @qtwrk, thanks for your help so far. I’ve just raised a ticket (#316201). If you could let me know what email address to use then I can create an admin login for you.

Cheers!

It exhibits the same behaviour both before and after adding the new nonce.

Yes, immediate 403 but not after refreshing the whole page – only after the first set of feed items have been injected into the DOM after the XHR. A full page reload would work just fine.

Hello @qtwrk

Thanks for your response. I just tried those steps but sadly no luck.

After the first click, I’m still getting corrupted values for _wpnonce that look like this rather than like this.

Any other thoughts?

Hello @qtwrk – yes that’s right. This is not standard WP pagination.

Hello @giucu91 – turns out it was my bad this time! I overlooked the fact that the staging site was requesting protected resources from the live site and the live site was rejecting those requests (presumably on the basis of the referrer?).

I’ve just updated to 4.5.1 and everything is now working as expected.

Thanks, @giucu91 – you’re right, it could be something else but it could be an unintended outcome caused by the same bug that was never fully resolved.

Is there a way to contact you privately so I can create an account for you on the site in question? As it is a staging site, it is not publicly available.

I’m not quite clear what you mean about downloading plugin settings?

Cheers!

Hello @giucu91,

I’m sorry to report that the latest update (4.4.14) reverts the fix in 4.4.13. Download URLs are now redirecting to the homepage with a 302.

I can confirm that the URLs in question are known to work correctly. Our staging environment uses a clone of the codebase and database and is exhibiting the above regression after the update, whereas our live site (which is still running 4.4.13) is still behaving as expected.

Please, could you advise?