Tarindel

Update for anyone else who finds this: https://www.ads-software.com/plugins/replytocom-controller/ removes the ?replytocom parameter.

It means people who aren’t running JS won’t be able to reply, but imo that’s a fair trade for not having my cache file blown out every day.

Another user just emailed: “i disabled my adblock and vpn and i am still unable to post a question.”

Disabling a VPN should change the user’s IP address, so it seems like maybe it’s not related to that.

I’ve asked this user to try in private/incognito mode.

And he wrote back and said he’s able to comment in incognito mode now.

I’m at a little bit of a loss for what to have him try next, since this seems to be erratic (like what I’d expect from an uninitialized variable or race condition).

He says same computer from earlier (unable to post) and later (able to post). He must have been assigned a different dynamic IP address.

This is quite peculiar.

Some more data:

One of the users who emailed me earlier in the day was able to post later in the day from a different IP Address. I’m trying to collect more info from him to determine if this was a work/home situation or what.

He tried this evening from home and was able to successfully post in normal browser mode. However, when he went into Chrome incognito mode, he was unable to get past the captcha.

I’m unable to replicate this myself.

Sure, will do.

Thanks for the response.

Definitely no theme changes, I haven’t updated my theme in like a year.

It’s possible there were some other plugin updates, as I tend to update plugins in batches when I have time to validate them. I likely updated Jetpack.

No server changes that I’m aware of.

What’s most peculiar about this is that only certain people seem to be impacted, and it doesn’t seem to be browser, machine, or country related.

Another user:

> It happens to me on every page. I’m using google chrome and I’ve tried on different PCs without succeed.

> Time: August 11, 2016 at 1:44 pm
> IP Address: 190.1.101.87 (Argentina)

Here’s some supplemental information from one user encountering issues:

> By the way, I’ve tried leaving comments on both Opera and Firefox, and I am using Lubuntu 16.04.

> Time: August 10, 2016 at 6:07 pm
> IP Address: 73.160.215.75

The IP Address is in New Jersey.

I don’t know much about htaccess rewrite rules, but apparently it’s possible to check if a cookie exists as well (so the rewrite rule would only fire if the cookie didn’t exist):

https://stackoverflow.com/questions/19382160/htaccess-compare-cookie-value-and-redirect-if-evaluation-returns-true-false

Thanks again for the response, Chouby. Seriously, your level of commitment to this project is incredible.

Totally understand the tradeoffs and challenges here. Here’s another idea: what if the redirection code was added into .htaccess as a URL rewrite rule?

Something akin to this:

https://www.giuseppeurso.eu/en/url-redirection-according-to-browser-language-apache-mod_rewrite/

WPSuperCache and a few other plugins (WP All in One Security) already modify .htaccess for their purposes, and it seems like an ideal solution to this kind of problem, since the redirect would happen before the page ever loaded.

And I just realized this morning that the reason it was working when I was logged in is because I have caching disabled for logged in users (so my editors can always see a non-cached page).

I’m guessing there’s no workaround for this other than to rewrite the language redirection code in Javascript or as a WP Super Cache plugin.

And sure enough, just after posting, I just found https://www.ads-software.com/support/topic/polylang-does-not-redirect-to-preferred-language?replies=13, which is the same issue I’m having.

Disabling caching on just the home page fixes the issue, though I’d rather be able to leave caching on.

So after a bunch of random things, such as reverting my theme options, disabling widgets, disabling plugins, it like the issue may be related to the WP Super Cache plugin. As soon as I disable it, the redirection works like expected. As soon as WP Super Cache is re-enabled, the redirection no longer works.

Given the popularity of WP Super Cache and Polylang, I would think that someone else had run into this issue before, but a Google search didn’t turn up anything.

Should this work out of the box?

Thanks Chouby, you’re a star.

I can’t imagine where else a conflict would be coming from. I’ve disabled all my plugins without success.

Atahualpha has a LOT of internal settings, perhaps it’s the way I have my theme configured. I’ll look at reverting back to default settings and see if that fixes the issue, then perhaps I can isolate a specific setting that’s causing the issue.

Yes, PLL_AJAX means PLL_AJAX_ON_FRONT is set to true.

Thanks again for the response. I’ll keep digging with the additional insight you’ve given me.

Polylang is great!