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

carlwhat:

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?

:huh:

@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.

John Large:

@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.

carlwhat:

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.

carlwhat:

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.

> **lat9:**
>
> @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 ...

> **carlwhat:**
>
> 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?
> 
> :huh:


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.

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.

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.

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).

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

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!

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!
Short answer, remove that index.html file from your root directory.:P What function is it providing (it's not a 'stock' Zen Cart file)?

lat9:

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

Yes, I know! Remove the file.... LOL! I had the file there redirecting people to another place to purchase my items until a website was built. But still not good to be picking it up. Thank you!

v1.5.5f USU v3.08 SitemapXML v 3.9.5

I believe there was a fix for this some time back but for the life of me I cannot find it anywhere in this forum or sitemapxml forum.

sitemapproducts.xml is producing article links from images/large/category with the _LRG suffix ... the problem is that my images are not in images/large ... they reside in images/category .... needless to say Google cannot find these images which is not condusive to good SEO.

so image links are looking like this
/images/large/tol/clip-on-earrings-419_LRG.gif
but should be
/images/tol/clip-on-earrings-419.gif

I cannot recall but I think the fix suggested a modification to a file in USU .... any assistance greatly appreciated.

cheers,
Mike

Mike, why is this posted in the USU support-thread instead of that for IH-5 (https://www.zen-cart.com/showthread.php?222983-Image-Handler-5-%28for-v1-5-5%29-Support-Thread)?

The update required for the IH-5 integration with SitemapXML is documented on the front page of the IH-5 readme.

lat9:

Mike, why is this posted in the USU support-thread instead of that for IH-5 (https://www.zen-cart.com/showthread.php?222983-Image-Handler-5-%28for-v1-5-5%29-Support-Thread)?

The update required for the IH-5 integration with SitemapXML is documented on the front page of the IH-5 readme.

Many thanks Cindy - I didn't realize (or more likely had forgotten) that IH controlled that aspect of sitemapxml.

cheers, Mike

Greetings zen-friends.
I have installed the ultimate URL module and works very good.
One of the issues I have is:
when my link has
"0.5" I need it to be shown as "0.5"
"-" dash I need to keep the "-"dash
"." I need to keep the "." period
"A - Z" capitals I need to keep the capitals in the link.
Any help is much appreciated.

sigatek:

Greetings zen-friends.
I have installed the ultimate URL module and works very good.
One of the issues I have is:
when my link has
"0.5" I need it to be shown as "0.5"
"-" dash I need to keep the "-"dash
"." I need to keep the "." period
"A - Z" capitals I need to keep the capitals in the link.
Any help is much appreciated.

i'm thinking you will need to modify code in this area:

https://github.com/lat9/usu/blob/457f840a3592aeb9fb7179d0ae2e409cb6e625d7/includes/classes/usu.php#L970-L1018

commenting out line 1007 and 1009 should address your capitalization issues.

the period and dash are no doubt in 982 - 1004.

best.

Setting up the .htaccess file is intimidating me into inaction.
Im not sure what to do with these instructions:

Open up and edit the supplied sample ".htaccess" file with a plaintext editor (such as notepad). Adjust the Apache directives (especially RewriteBase) as needed for the web server where Zen Cart is installed.

The hashed out instructions in the sample .htaccess say to match what is in your configure.php

my configure.php looks like

define('DIR_WS_CATALOG', '/');
define('DIR_WS_HTTPS_CATALOG', '/');
define('DIR_FS_CATALOG', '/home/kayak/public_html/');

So does that mean my .htaccess file should look like this?

##################################
#RewriteBase /shop/
//
####################

My existing htaccess file currently active on my site has the first line

RewriteOptions inherit

Should that be pasted into the top of the new htaccess sample or should that not be carried over?

angst:

Setting up the .htaccess file is intimidating me into inaction.
Im not sure what to do with these instructions:

The hashed out instructions in the sample .htaccess say to match what is in your configure.php

my configure.php looks like

define('DIR_WS_CATALOG', '/');
define('DIR_WS_HTTPS_CATALOG', '/');
define('DIR_FS_CATALOG', '/home/kayak/public_html/');

> 
> So does that mean my .htaccess file should look like this?
> 
> ```
##################################
#RewriteBase /shop/
//
####################

My existing htaccess file currently active on my site has the first line

RewriteOptions inherit

> 
> 
> Should that be pasted into the top of the new htaccess sample or should that not be carried over?
.htaccess files can be quite intimidating.  Be sure to make a copy of your current file so that you can quickly revert if you receive a dreaded Server 500 message.

I believe that you can safely edit (after making that copy!) the current .htaccess, simply appending all the directives present in USU's as-delivered version.

OK, I give up. Why does the install ask us to copy the plugin to a temp directory, then copy from the temp dir to the store directory?

pixelpadre:

OK, I give up. Why does the install ask us to copy the plugin to a temp directory, then copy from the temp dir to the store directory?
From the readme:

The location "/temp" in this section refers to the temporary location where the zip-file distribution for Ultimate URLs has been extracted.