Ultimate SEO v3 (and v2.200) [Support Thread]

[John Large]

yaa, i feel your pain. as i looked at this closer, i remember burning many hours on it many moons ago. pretty clear it does not work (or i could not find a solution) to me.

i've been running with that line commented out for a minimum of 6 years. that redirect code was in there starting 9 years ago (at least as far as i can tell from github).

perhaps off topic, but what does this have to do with sanitizing vars? is that not the script we are in?

@carlwhat, out of curiosity, which version of USU do you have installed at the moment? When I started troubleshooting this I was on 3.0.6 and ipgraded to 3.0.8 when trying to fix it.

[carlwhat]

@carlwhat, out of curiosity, which version of USU do you have installed at the moment? When I started troubleshooting this I was on 3.0.6 and ipgraded to 3.0.8 when trying to fix it.

i think you are heading down the wrong path. you stated:

"...a fairly old version of ZC to the then current 1.5.6c..."

and then:

"...This last month Google has started highlighting redirect loop errors for deleted products.."

so whether this problem existed in your fairly old version, you can not say... or perhaps you can... and if not for google, you would be humming along no problem at all...

don't forget about dead cats... (do they say that in the UK? aha... a simple wikipedia search says they do!)

in any event, i'm current running 3.0.7; but i have looked at the newer USU changes which currently have no effect on my clients sites.

in addition, ever since @lat9 took over the maintenance of this plugin, it is SOO much better than before.

best.

[John Large]

i think you are heading down the wrong path. you stated:

"...a fairly old version of ZC to the then current 1.5.6c..."

and then:

"...This last month Google has started highlighting redirect loop errors for deleted products.."

so whether this problem existed in your fairly old version, you can not say... or perhaps you can... and if not for google, you would be humming along no problem at all...

don't forget about dead cats... (do they say that in the UK? aha... a simple wikipedia search says they do!)

in any event, i'm current running 3.0.7; but i have looked at the newer USU changes which currently have no effect on my clients sites.

in addition, ever since @lat9 took over the maintenance of this plugin, it is SOO much better than before.

best.

Possibly, but over the last few months we've started cleaning up the website, cleaning up product names & deleting old products, which has probably exacerbated the issue. Also, as the redirect errors increased, our impressions and general organic traffic decreased, including core web vitals showing fewer pages as "good", but no pages as "needs improvement" or "poor", which suggested Googlebot was having some crawling issues. This made it a priority to figure out what was causing the redirect loop dead ends for crawlers.

Since fixing the redirect error, a further 500 pages have been deemed core web vitals good urls. With the upcoming changes to the seacrh algorithm in May it's important that as many pages as possible report as good. We've been hovering at around 1400 pages marked good for a month or so now, when before that number was 4000+ pages for a long time, so these fixes have either helped, or it's a coincidence.

[DrByte]

lets look at the code for a quick second, and specifically this var $_SESSION['check_valid_prod']:

/**
 * validate products_id for search engines and bookmarks, etc.
 */
  if (isset($_GET['products_id']) && (!isset($_SESSION['check_valid_prod']) || $_SESSION['check_valid_prod'] != false)) {
    $check_valid = zen_products_id_valid($_GET['products_id']) && !empty($_GET['main_page']);
    if (!$check_valid) {
      $_GET['main_page'] = zen_get_info_page($_GET['products_id']);
      /**
       * do not recheck redirect
       */
      $_SESSION['check_valid_prod'] = false;
      zen_redirect(zen_href_link($_GET['main_page'], 'products_id=' . $_GET['products_id']));
    }
  } 

the redirect is only suppose to happen once! we are first checking if that session var is set and not false. if so, lets set it to false, and then redirect. now the next time here, we should NOT hit the redirect as the session var is now false. but empirically we know that is happening.

while done with good intentions, this bit of code seems adrift to me. and has been for years.

but i am completely open to another opinion on it.

@carlwhat, the more I look at that section of code, the more I wonder about it.

1. We're looking for a link with a products_id variable (once per session), so if someone's pounding on a site with multiple links all with invalid products_id values, we're only going to see the first one?

2. We've found a products_id that isn't valid ... so we're going to use that invalid value to look up its non-existent _info page and use that known invalid products_id as part of the redirection link?

I've got a headache ...

yaa, i feel your pain. as i looked at this closer, i remember burning many hours on it many moons ago. pretty clear it does not work (or i could not find a solution) to me.

i've been running with that line commented out for a minimum of 6 years. that redirect code was in there starting 9 years ago (at least as far as i can tell from github).

perhaps off topic, but what does this have to do with sanitizing vars? is that not the script we are in?

1. it's in init_sanitize.php because at that point in time that was the best location for doing that particular sanity check (which has mostly the same letters as 'sanitize')
2. outside of this USU plugin where is this code causing problems? I note that the ajax issues mentioned by mc12345678 separately for DPU are already resolved.
3. what do you propose is a better implementation?

I concede that setting the session var to boolean is inefficient. Setting it to GET['products_id'] and comparing against that would be a better way to avoid redirects for only the current invalid id.
But I'm guessing that's not all of what you're aiming for here.

[lat9]

v3.0.9-beta2 is now available on GitHub (https://github.com/lat9/usu/releases/tag/v3.0.9-beta2). This version corrects unwanted 302 redirects on missing/invalid link parameters as well as the staging required to ensure that the USU cache isn't regenerated after admin-level modifications.

Please review the comments present in this (https://github.com/lat9/usu/issues/42) GitHub issue, which identify how the USU storefront handling has been modified.

[John Large]

v3.0.9-beta2 is now available on GitHub (https://github.com/lat9/usu/releases/tag/v3.0.9-beta2). This version corrects unwanted 302 redirects on missing/invalid link parameters as well as the staging required to ensure that the USU cache isn't regenerated after admin-level modifications.

Please review the comments present in this (https://github.com/lat9/usu/issues/42) GitHub issue, which identify how the USU storefront handling has been modified.

Have updated to the beta on my ZC version 1.5.6c and can confirm points 1-3 (in the github notes) are correct. Without the commented out section in /includes/init_includes/init_sanitize.php it returns a 302 => 404 redirect (which google seems to dislike but seems to be the standard way zen deals with it). With the "recheck redirect" line commented out (line 140 of /includes/init_includes/init_sanitize.php in ZC 1.5.6c) it returns a straight 404 which google prefers.

I'll stick with the core file comment in /includes/init_includes/init_sanitize.php unless it can be done more elegantly within the USU plugin to override the standard ZC function.

Thank you so much for all the hard work with this lat9. It really is appreciated.

For those interested, I dug a little deeper into my own usage. I can see from my own investigation that on my old zencart which was a 1.5.1 version last updated in 2013, we used a much older version of this plugin and from my backup of the site i can see that the google_analytics.php file in templates has a date stamp in the code of

+----------------------------------------------------------------------+
	|	Ultimate SEO URLs For Zen Cart, version 2.212                      |
	+----------------------------------------------------------------------+
	|                                                                      |
	|	Derrived from Ultimate SEO URLs v2.1 for osCommerce by Chemo       |
	|                                                                      |
	|	Portions Copyright 2011-2012, Andrew Ballanger                     |

I started to move over from ZC 1.5.1 to 1.5.6c early in 202, but we only made the switch at the tail end of 2020 due to a lot of modifications & getting plugins/templates to play nicely with php 7. In early january over on Google Search Console, we had 212 pages linked from external sites which returned a 404. These would be old/deleted products as the site has been active since 2005. By last week, only 12 of those pages where still marked as 404, with the rest showing redirect loop errors. I can only assume that this bug has been present for a while, but wasn't a factor on the really old ZC/Plugin we had been using. I've been noticing a lot of weird crawler complaints & google relying more on canonical URLS than 301's so hopefully this will help other users with their stores & SEO. Also, google seems to give a bit of wiggle room & will check a resource a few times before changing it's status (I guess to account for short downtimes and other factors).

[lat9]

v3.0.9 of USU is now available for download.

This version contains changes associated with the following GitHub issues:

#42: Deleted product results in browser redirect loop.
#43: 'Old' URLs aren't being rewritten to their new homes.

[lat9]

v3.0.9 of USU is now available for download.

This version contains changes associated with the following GitHub issues:

#42: Deleted product results in browser redirect loop.
#43: 'Old' URLs aren't being rewritten to their new homes.

Now available for download: https://www.zen-cart.com/downloads.php?do=file&id=132

[shrimp-gumbo-mmmhhh]

Ultimate URLS 3.0.8

If a index.html file exists in the root directory of a store and the Product Listings > Display Multiple Products Qty Box Status and Set Button Location is set to 3, when a search for a term that will bring up multiple items is done and the "Add Selected Items" button is pushed the index.html file will show instead of the cart or the same page. If it should show the cart the url does not reflect that you are looking at the cart but shows that you are looking at the search page (ignoring the "Add to cart" go to cart instructions).

If I turn Ultimate URLS off the issue goes away.


I uploaded 3.0.9 and it still happens in that version too. Thank you!

[lat9]

Ultimate URLS 3.0.8

If a index.html file exists in the root directory of a store and the Product Listings > Display Multiple Products Qty Box Status and Set Button Location is set to 3, when a search for a term that will bring up multiple items is done and the "Add Selected Items" button is pushed the index.html file will show instead of the cart or the same page. If it should show the cart the url does not reflect that you are looking at the cart but shows that you are looking at the search page (ignoring the "Add to cart" go to cart instructions).

If I turn Ultimate URLS off the issue goes away.


I uploaded 3.0.9 and it still happens in that version too. Thank you!

Short answer, remove that index.html file from your root directory. What function is it providing (it's not a 'stock' Zen Cart file)?