Too many redirects error when using custom cache buster

Hi,
EDD has issues with custom query strings. I generally suggest people who are running eCommerce sites to use the worker mode inside the plugin rather than the default page rule mode which relies on cache buster query string.

I would suggest you to first enable the worker mode inside the plugin and then also inside the plugin settings > others tab there is a section for SEO redirect, make sure it is set to NO. Then try your site and let me know.

Worker mode isn’t free and you literally recommend against using it in the plugin settings. I described what caused the issue and it seems like it could cause issues for all sites, because it even causes issues on logout, which has nothing to do with EDD.

If the query string on a URL simply contains the cache buster, even if the query string isn’t an exact match of the cache buster, then it will try to redirect the page. That’s a huge bug in your plugin, because it will cause redirects and break pages and probably screw up site indexing.

You should make it so it only redirects a page if the query strings contains the cache buster and ONLY the cache buster. Right now it can contain characters other than what’s in the cache buster, so long as the entire cache buster appears in the query string.

If you would like to change the cache buster from the default swcfpc that is possible and already mentioned in the FAQ section of the plugin settings: https://i.imgur.com/Vrzbnqq.jpeg

Coming to EDD and query string, EDD expect to query stings to be in the exact order that they set and any changes to that would cause issues.

Changing the cache buster doesn’t fix the problem. If the cache buster is swcfpc then it will try to redirect pages that have query strings like swcfpcu or swcfpcr7r or swcfpc7rui etc. It can be any query string so long as it contains the cache buster it will redirect it. You don’t think that’s a problem? Or you don’t think it’s something you can fix so that redirects ONLY happen on pages which contain the cache buster and ONLY the cache buster without any additional characters before or after the cache buster?

Have you enabled the SEO redirection option inside the plugin settings > others tab?
Also can you share a screen recording with the issue?

Yes, the SEO redirection is what’s causing the problem, but I want to keep it enabled. You still cannot understand what I’m saying? It’s unbelievable. Can someone delete my WordPress account? I don’t want to be on this site anymore. Just delete this account.

The SEO Redirection is doing it’s job. The job that that option is that when a user is not considered as loggedin user it will redirect ant URL with that cache buster in it to the non cache buster version.

Coming to deleting your account, I do not have any authority to do so. You can google about how to delete WordPress account – hopefully that will help you.

Changing this line:

if( !is_user_logged_in() && isset($_SERVER[‘QUERY_STRING’]) && strlen($_SERVER[‘QUERY_STRING’]) > 0 && strpos( $_SERVER[‘QUERY_STRING’], $this->get_cache_buster() ) !== false )

to this line:

if( !is_user_logged_in() && isset($_SERVER[‘QUERY_STRING’]) && strlen($_SERVER[‘QUERY_STRING’]) > 0 && isset($_GET[$this->get_cache_buster()]) )

Fixes the problem I’m talking about. Do you see any reason this change will cause any issues?

So, here you have changed strpos( $_SERVER[‘QUERY_STRING’], $this->get_cache_buster() ) !== false ) to isset($_GET[$this->get_cache_buster()]) ).

Now strpos( $_SERVER[‘QUERY_STRING’], $this->get_cache_buster() ) !== false ) this line is checking is the cache buster is present in the $_SERVER[‘QUERY_STRING’]. Which it should. I mean even to pass isset($_GET[$this->get_cache_buster()]) ) the cache buster needs to be present in the query string.

So, I don’t understand how this can be causing the problem. Do you have any idea or explanation? As both are doing the same thing. One is checking if the cache buster query string is present in the list of query strings while the other is checking if the cache buster query string is set or not.

The only issue I see is that while executing the code (at that stage) the $_GET or $_REQUEST data might not be available to access and that’s why it relies on the $_SERVER data. But then again even if we discard that matter for a second, both codes are doing the same operation so I don’t see how that’s making any difference.

In your case I would suggest you that above the code you have changed you should do:

var_dump( $_SERVER['QUERY_STRING'] );
var_dump( $_GET[$this->get_cache_buster()]) );
die();

to see what data you are getting at that point. I mean that will paint a better picture.

You can do this test yourself. Make sure the 301 SEO Redirect is turned on. Then change the cache buster to just a lowercase L i.e. ?l=1 You can do that in the wp-config file. Then logout of the admin panel which should take you to this URL: domain.com/wp-login.php?loggedout=true&wp_lang=en_US And you will see it causes a “too many redirect” error. Then switch the line I told you I switched and go logout again and you will see no redirect error.

I think it’s due to how strpos vs isset works. I think strpos just looks for the first occurrence of a substring in a string, which is what I said is the problem. If the cache buster is simply a substring in a string then it tries to redirect. That’s why this page domain.com/wp-login.php?loggedout=true&wp_lang=en_US will try to redirect with the 301 SEO Redirect feature turned on, because the lowercase L cache buster is a substring of the string in this URL which is ?loggedout.

• This reply was modified 2 years, 7 months ago by m22878.
• This reply was modified 2 years, 7 months ago by m22878.