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.
Printable View
Confirmed bug :oops:. I've opened the following GitHub issue to track the correction: https://github.com/lat9/usu/issues/42
Well, it only took me 3 hours to figure out what the heck is going on! I'll call that difficult.:blink:
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.
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.
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
@lat9
in commit #42, in the usu class, it seems you have deleted line 100 which had the following code:
was this on purpose?PHP Code:
// Determine canonical (if needed)
$this->canonical();
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:
does this fix your redirect as well as preserve the fix to your original problem?PHP Code:
} 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') {