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

[John Large]

Wondering if anyone can help.

I've been using this add-onn for as long as I can remember & never had an issue.

Last year after a long migration process we upgraded from a fairly old version of ZC to the then current 1.5.6c. Everything went fine with the upgrade and the site has been working well. This last month Google has started highlighting redirect loop errors for deleted products. After having a dig through the settings, it would appear that if I enable automatic rewrites in utlimate URLS & then try to visit the url for a now deleted product, it will fire a redirect loop in firefox. This confirms the behaviour I'm seeing in search console.

if I disable automatic rewrites, the "sorry, product not found" page will show and after a 302 redirect will show a 404 header.

I've used the automatic redirects in ultimate urls for years & never noticed a problem, but for some reason it is now not playing ball. I don't know where to start. My .htaccess is the same as when it did work on the older version of Zen Cart. I've compared the two and all ultimate URLS rewrites are present & correct. For now I've disabled automatic rewrites & will let google uses the canonical/nofollows generated by zen cart. The changes include the newer version of ZC & now running on php 7.3.27

Can anyone point me in the right direction? I tried uninstaling ultimate URLS completely & have freshly installed version 3.0.8 from numinix website. Still can't get it to work as expected. Any help would be greatly appreciated.

Thanks, John.

Didn't mean numinix website, that was for easy google anlytics plugin I also upgraded. Apologies, 3.0.8 of this plugin was installed directly from the ZC plugins page.

[lat9]

Confirmed bug . I've opened the following GitHub issue to track the correction: https://github.com/lat9/usu/issues/42

[John Large]

Confirmed bug . I've opened the following GitHub issue to track the correction: https://github.com/lat9/usu/issues/42

Well that makes me feel a lot better after going around in circles trying to figure out what I'd done wrong. Glad I posted. Hope it's not too dificult a fix.

[lat9]

Well that makes me feel a lot better after going around in circles trying to figure out what I'd done wrong. Glad I posted. Hope it's not too dificult a fix.

Well, it only took me 3 hours to figure out what the heck is going on! I'll call that difficult.

The underlying issue is the (unwanted) help provided by /includes/init_includes/init_sanitize.php when an invalid products_id variable is included in the URL. That module, for the current v3.0.8 and earlier versions of USU, is loaded prior to the USU intercept of calls to the zen_href_link function. When that module finds an invalid products_id, it performs a redirect to main_page=product_info&products_id=xxx ... which doesn't match the USU-generated link for that invalid product.

That mismatch, once USU gets activated, causes USU to issue a redirect to its 'proper' URL form which results in init_sanitize (on the redirect) to redirect to the base form ... you get the drift.

The update's going to be a tad complicated due to prerequisites, since the base language session variables aren't (by default) loaded until later in the start-up processing. Essentially, the USU start-up will now load itself prior to that init_sanitize module's load and will also register those base language variables (via init_languages.php) as part of its start-up.

I should have a beta version of USU v3.0.9 available shortly for 3rd party testing.

[lat9]

v3.0.9-beta1 now available for download: https://github.com/lat9/usu/releases/tag/v3.0.9-beta1

I'll plan to make this a formal v3.0.9 release early next week unless I receive feedback that the correction doesn't work.

[John Large]

v3.0.9-beta1 now available for download: https://github.com/lat9/usu/releases/tag/v3.0.9-beta1

I'll plan to make this a formal v3.0.9 release early next week unless I receive feedback that the correction doesn't work.

Thanks lat9.

Invalid or deleted product ids are now redirecting to the product not found page & sending a 404.

One problem is, old urls arent rewriting to new ones. For example if originally my product was named and available at https://www.koolbadges.co.uk/japanes...es-p-3121.html but after being renamed is now at https://www.koolbadges.co.uk/cute-bl...es-p-3121.html with the rewrite I would expect the old url to redirect to the new to reflect the name change, however both urls are returning a 200 response and are valid.

[lat9]

Thanks lat9.

Invalid or deleted product ids are now redirecting to the product not found page & sending a 404.

One problem is, old urls arent rewriting to new ones. For example if originally my product was named and available at https://www.koolbadges.co.uk/japanes...es-p-3121.html but after being renamed is now at https://www.koolbadges.co.uk/cute-bl...es-p-3121.html with the rewrite I would expect the old url to redirect to the new to reflect the name change, however both urls are returning a 200 response and are valid.

@John Large, I'm guessing that the 'failure to redirect' is after applying the changes posted in GitHub? Please advise.

[John Large]

Yes.

The failure to redirect is after installing the beta. You can potentially write any url string to create links as long as the product id is val, and it will return a 200 response. I'm not sure if this has always been the case with the plugin, it's not something I've tested before, but since google started complaing about our website I've been digging into it. Possibly better to 301 any requests where the url string doesn’t match the canonical to the canonical address for duplicate content/seo benefits?

[John Large]

Yes.

The failure to redirect is after installing the beta. You can potentially write any url string to create links as long as the product id is val, and it will return a 200 response. I'm not sure if this has always been the case with the plugin, it's not something I've tested before, but since google started complaing about our website I've been digging into it. Possibly better to 301 any requests where the url string doesn’t match the canonical to the canonical address for duplicate content/seo benefits?

Just updated on github, but will put it here for anyone else following this thread.


Just tested further, if I manually enter a url in the old format such as

https://www.koolbadges.co.uk/index.p...roducts_id=904

It now doesn't redirect with the beta to the SEO url. That will return a 200 response. The rewritten url is https://www.koolbadges.co.uk/camo-pi...4.html?cPath=9 so the 301 automatic rewrites now don't seem to be working.

Reverted to 3.0.8 and the redirects work as I mentioned, redirecting any changes in the url to the canonical, so the automatic rewrites appear to have been broken by the changes in the beta. It would seem that by fixing the redirect loop on deleted products it has broken the automatic rewrites on valid products

[carlwhat]

@lat9

in commit #42, in the usu class, it seems you have deleted line 100 which had the following code:

// Determine canonical (if needed)
        $this->canonical(); 

was this on purpose?

in my testing, this changes causes the automatic redirects to not happen.

now, whether that line of code is pertinent to the original redirect problem, i can not say, as i did not reproduce the original error.

john,
what happens if you add that line back?

starting at line 94 of includes/classes/usu.php, make it look like so:

            } elseif (IS_ADMIN_FLAG) { is was is causing the
                // Message Stack will be available when loaded from the admin
                $GLOBALS['messageStack']->add(sprintf(USU_PLUGIN_WARNING_TABLE, TABLE_USU_CACHE), 'warning');
            }
        }

        // Determine canonical (if needed)
        $this->canonical();

        // Start logging
        $this->debug = false;
        if (defined('USU_DEBUG') && USU_DEBUG == 'true') { 

does this fix your redirect as well as preserve the fix to your original problem?