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

coucho:

... My initial install (year ago) is working fine. Are there any real world advantages to upgrading and possibly breaking the site. ...
I would not recommend upgrading if there was no real world advantages. There are some important notes in the 2.215 release announcement. The short answer to "Why upgrade?" is: bugfixes, enhancements, wider compatibility, and performance improvements.

The long answer to "Why upgrade?" is download a copy and read the included documentation. The Beta Team and I spent a long time creating and refining new documentation for this release (complete with more friendly instructions, compiled lists of workarounds, a changelog, and the use of images and color). So please do download a copy and take a few moments to enjoy the vast improvements (if I do say so myself)!

As with any other changes made to a live website: mistakes, other modifications present, and server configurations can potentially complicate the process of upgrading or making changes.¹ As previously noted, before upgrading make sure you do not have an ancient version of this module installed.²

NOTE 1: One should always keep up to date backups (especially before and after installation / changes) and test all changes in a "staging" (test, development, temporary, etc) copy of your live website. Regular backups so will help avoid extended downtime if something goes wrong. And when the changes are being made on a "copy" of the live website (not the live website itself), if anything goes wrong it does not impact the live website. This gives one time to "test" first and address any issues which occur (as well as take very good notes as to why and what needs to be done when later applying the changes to the live website).

NOTE 2: One can check what version is currently installed by going to the configuration menu for this plugin in the Zen Cart administrative interface. If the version is not listed, the installed version is ancient (3+ years old) and I would recommend first uninstalling whatever version is installed (files, file changes, and database entries) before installing the latest version. This will help avoid potential complications.

lhungil:

I would not recommend upgrading if there was no real world advantages. There are some important notes in the 2.215 release announcement. The short answer to "Why upgrade?" is: bugfixes, enhancements, wider compatibility, and performance improvements.

The long answer to "Why upgrade?" is download a copy and read the included documentation. The Beta Team and I spent a long time creating and refining new documentation for this release (complete with more friendly instructions, compiled lists of workarounds, a changelog, and the use of images and color). So please do download a copy and take a few moments to enjoy the vast improvements (if I do say so myself)!

As with any other changes made to a live website: mistakes, other modifications present, and server configurations can potentially complicate the process of upgrading or making changes.¹ As previously noted, before upgrading make sure you do not have an ancient version of this module installed.²

NOTE 1: One should always keep up to date backups (especially before and after installation / changes) and test all changes in a "staging" (test, development, temporary, etc) copy of your live website. Regular backups so will help avoid extended downtime if something goes wrong. And when the changes are being made on a "copy" of the live website (not the live website itself), if anything goes wrong it does not impact the live website. This gives one time to "test" first and address any issues which occur (as well as take very good notes as to why and what needs to be done when later applying the changes to the live website).

NOTE 2: One can check what version is currently installed by going to the configuration menu for this plugin in the Zen Cart administrative interface. If the version is not listed, the installed version is ancient (3+ years old) and I would recommend first uninstalling whatever version is installed (files, file changes, and database entries) before installing the latest version. This will help avoid potential complications.

Thanks for the information.

Hi lhungil

I have a problem to use the EasyPopulate 4.0 after install ultimate_urls-215 at admin-end. When I export the "Complete Products" file, I got an error as "Call to undefined function zen_get_info_page() in ...\includes\classes\usu.php on line 324". There are no issues when other files were exported. When the "Complete Products" file was exported, the product urls from products_description table would be fetched. This is may the point. Could you help to find the problem?

Zne-Cart: v1.5.4
EasyPopulate: v4.0.28

Confirmed Bug in Ultimate URLs 2.215 (Ticket #28)
Thank You su35 for reporting!

Symptoms
When a URL is generated from the Zen Cart administrative interface the following error is encountered: "Call to undefined function zen_get_info_page()".

How to Fix
Edit "/admin/includes/functions/extra_functions/usu.php". Add the following at the very end of the file:

// This function is available for use on the catalog side of Zen Cart and
// needed on the admin side for Ultimate URLs to lookup the product_info page.
if(!function_exists('zen_get_info_page')) {
	function zen_get_info_page($zf_product_id) {
		global $db;
		$sql = "select products_type from " . TABLE_PRODUCTS . " where products_id = '" . (int)$zf_product_id . "'";
		$zp_type = $db->Execute($sql);
		if ($zp_type->RecordCount() == 0) {
			return 'product_info';
		}
		else {
			$zp_product_type = $zp_type->fields['products_type'];
			$sql = "select type_handler from " . TABLE_PRODUCT_TYPES . " where type_id = '" . (int)$zp_product_type . "'";
			$zp_handler = $db->Execute($sql);
			return $zp_handler->fields['type_handler'] . '_info';
		}
	}
}

Hi lhungil

It work now, thanks

Client wants to make a bunch of changes to products and categories.. He needs to delete a BUNCH of his products, move others to new categories, and many more moves to move linked products from one category to another. I want to mitigate any issues before he does this work..

I could create a bunch of 301 redirects in his .htaccess file, but I'd rather dynamically redirect visitors who hit one of these old product links to a category link instead.. Did some digging and found this post: http://www.zen-cart.com/showthread.php?150706-I-ve-deleted-products-How-do-I-redirect-customers-to-new-ones-or-to-search-instead&p=859577#post859577 and then an article based on that post here: http://pro-webs.net/blog/2010/03/21/deleted-out-of-stock-products/.

In particular the section below is what I am thinking about implementing. It is the last paragraph that is relevant to this module that I am questioning. I've not applied this code yet. I wanted to first do a temperature check to make sure that the situation suggested in the highlighted paragraph does not in fact apply to this module.. As the article was written in 2010, I wanted to find out if the many changes made to this module make that highlighted section a non issue..

In the forum thread we noted earlier, Zenner 7thVeil suggested using a php redirect to move these pages to the category page for their original location. This is an excellent technique for a dynamic solution. The code change supplied by 7thVeil, was very smart, but incomplete as it was returning a 302 in the header. We definitely do not want to return a 302, as this is a temporary redirect, but a permanent headache for your SEO campaign.

So I tweaked his alteration for the following which will send disabled and deleted products to their category page with a permanent 301 redirect. If no category exists they are sent to the product not found page.
In /includes/modules/pages/product_info/main_template_vars.php around line 31 find:

if ( $res->fields['total'] < 1 ) {

>  
> ```
$tpl_page_body = '/tpl_product_info_noproduct.php'; 
```Replace this line with
> 
>  
>     ```
$requeststring = (isset($_GET['cPath']))?'&cPath='. (int)$_GET['cPath']:'';         header( "HTTP/1.1 301 Moved Permanently" );         header('location:index.php?main_page=index'.$requeststring); 
```Remember this is really a very dynamic solution and you are giving up  the ultimate control over where this product page url should be sent.  **There is also the possibility, if you are using a SEO rewrite module,  that this tweak will result in a double redirect. This is not a good  situation, so if you apply this and the header for the pages is sending a  double redirect, or worse, a loop... then this solution is not for you.**

DivaVocals:

Client wants to ... move ... (products) to new categories ... and ... move linked products from one category to another. ...
When categories or products are moved around (or linked), no need to do anything special. When done, just reset the URL cache (if enabled) to see the changes immediately. As long as the product ID and Category ID are not changed, both the old and new locations will be handled automatically without any issues. Additionally, the generated canonical will contain the new URL (unless your theme disables the canonical link handling built into Zen Cart). One can also enable automatic redirects to force a 301 redirect to the new URL (if desired).

DivaVocals:

Client ... needs to delete a BUNCH of his products ... I'd ... (like to) dynamically redirect visitors who hit one of these old product links to a category link instead...
Let me first put on my "SEO Hat" and place it on my head.
From an SEO perspective, I would strongly recommend against this approach. Redirecting multiple different pages with different content to a single page (also with different content compared to the original pages) can result in a mess (or even a nightmare). Sends chills up and down my spine when I hear thoughts along these lines... But carry on if this is NOT what you are talking about...

Now let me take of the "SEO Hat" and instead put on my "Customer Hat".
Let's say six moths ago I ordered a "green widget". I was very happy with the "green widget" and now want to order another matching widget (or share a link to the product I bought with a friend). So I go back to the store, sign into my account, and pull up my order history. My expectation is I will be able to view my past order and click on a link to the "green widget" previously ordered.

If the product has been deleted from the store... This link (if enabled) brings me to a 404... Or worse, it brings me to the home page of the store (or some other page such as a category)... And in the second case, now I am confused (because I clicked on a link for a "green widget" and was brought somewhere else). Either way I no longer have a way to quickly (and easily) review the product details or specifications for the "green widget" I previously purchased... So now even if I find a new version of a product (or a similiar product) at the store, I do not have the information about the "green widget" I purchased to look at and compare against... Not the best experience...

Now if the product is still present in the store... The link does bring me to the old products page. And ideally, the store owner has made some minor edits to the product. For example: setting the product so it cannot be added to the shopping cart, added big bold obvious text letting me know the product is no longer available, added a link to the replacement (or comparable product), etc. Not only can I still review the information and details regarding my previously purchased "green widget"... But I also know the product is no longer available (and have a link to view or purchase a comparable / replacement product matching my "green widget"). For me this would be a good customer experience.

Now let me take of the "Customer Hat" and instead put on my "Consultant Hat".
The above code to dynamically redirect deleted product pages to their category is flawed. It will affect all "product pages" where a product_id is not present in the database including pages for products which never existed (and should generate a 404). There is no guarantee $_GET['cPath'] will be present (this is true even with stock Zen Cart URLs), so in some cases it will redirect to the store root instead of the expected parent category. The code fails to call zen_href_link (failing to call this may in some cases cause the customer session to be lost). The code directly access $_GET (I would avoid this), the variable $cPath will already be populated by Zen Cart and contain the correct cPath (or '' if not present).

So additional logic will be needed with the above code changes if one wants to selectively redirect certain products (or only in certain cases)... Kinda defeating the purpose of modifying the PHP code in the first place... And of course once additional PHP code is added (or existing files edited), added complexity is in play... The possibility (and risk) of multiple chained redirects increases... Troubleshooting "redirect" issues (if they occur) becomes more time consuming... Upgrading Zen Cart becomes slightly more time consuming...

I'd personally avoid using such redirects in the first place... But if the client is adamant about deleting products and using redirects... Make sure to update the code previously presented. At the minimum use zen_href_link() and $cPath... Ideally some additional logic could be added to call the home page (no "&cPath=" when no cPath is available). Time permitting, some code could also be added to make sure the redirect only occurs on a "deleted" product (not on product IDs which do not yet exist / have not yet been used).

NOTE 1: Disabling / deleting a category is a whole different beast. In most cases, I would avoid the need and simply change the content... But sometimes one may desire to make such a change (especially if inheriting a site with overly nested categories)... I'd think about a 301 redirect (using mod_rewrite) if there is another category with very similiar content... Otherwise I'd let the 404 page handle the situation...

NOTE 2: Not really on topic, but something I should probably mention... I'd recommend (with or without redirects) one create / supply a good 404 page for customers. Ideally a good 404 page has: easy to use navigation, a search box, content customized to the broken URL (pre-populated search results, a link to the containing category when known, etc), and possibly some form of humor.

NOTE 3: Remember SEO and Best Practices tend to change over time. Any advice or opinions on this (or any site) should always be taken with a grain of salt. Make sure you do your research (including A/B testing) to determine the most beneficial course of action for your specific store. And always keep a backup handy!

NOTE 4: The highlighted portion only applies to Ultimate URLs when "automatic redirects" are enabled and the 3rd party code does not call zen_href_link(). This will not apply if the 3rd party code is updated to correctly utilize zen_href_link().

lhungil:

When categories or products are moved around (or linked), no need to do anything special. When done, just reset the URL cache (if enabled) to see the changes immediately. As long as the product ID and Category ID are not changed, both the old and new locations will be handled automatically without any issues. Additionally, the generated canonical will contain the new URL (unless your theme disables the canonical link handling built into Zen Cart). One can also enable automatic redirects to force a 301 redirect to the new URL (if desired).

Let me first put on my "SEO Hat" and place it on my head.
From an SEO perspective, I would strongly recommend against this approach. Redirecting multiple different pages with different content to a single page (also with different content compared to the original pages) can result in a mess (or even a nightmare). Sends chills up and down my spine when I hear thoughts along these lines... But carry on if this is NOT what you are talking about...

Now let me take of the "SEO Hat" and instead put on my "Customer Hat".
Let's say six moths ago I ordered a "green widget". I was very happy with the "green widget" and now want to order another matching widget (or share a link to the product I bought with a friend). So I go back to the store, sign into my account, and pull up my order history. My expectation is I will be able to view my past order and click on a link to the "green widget" previously ordered.

If the product has been deleted from the store... This link (if enabled) brings me to a 404... Or worse, it brings me to the home page of the store (or some other page such as a category)... And in the second case, now I am confused (because I clicked on a link for a "green widget" and was brought somewhere else). Either way I no longer have a way to quickly (and easily) review the product details or specifications for the "green widget" I previously purchased... So now even if I find a new version of a product (or a similiar product) at the store, I do not have the information about the "green widget" I purchased to look at and compare against... Not the best experience...

Now if the product is still present in the store... The link does bring me to the old products page. And ideally, the store owner has made some minor edits to the product. For example: setting the product so it cannot be added to the shopping cart, added big bold obvious text letting me know the product is no longer available, added a link to the replacement (or comparable product), etc. Not only can I still review the information and details regarding my previously purchased "green widget"... But I also know the product is no longer available (and have a link to view or purchase a comparable / replacement product matching my "green widget"). For me this would be a good customer experience.

Now let me take of the "Customer Hat" and instead put on my "Consultant Hat".
The above code to dynamically redirect deleted product pages to their category is flawed. It will affect all "product pages" where a product_id is not present in the database including pages for products which never existed (and should generate a 404). There is no guarantee $_GET['cPath'] will be present (this is true even with stock Zen Cart URLs), so in some cases it will redirect to the store root instead of the expected parent category. The code fails to call zen_href_link (failing to call this may in some cases cause the customer session to be lost). The code directly access $_GET (I would avoid this), the variable $cPath will already be populated by Zen Cart and contain the correct cPath (or '' if not present).

So additional logic will be needed with the above code changes if one wants to selectively redirect certain products (or only in certain cases)... Kinda defeating the purpose of modifying the PHP code in the first place... And of course once additional PHP code is added (or existing files edited), added complexity is in play... The possibility (and risk) of multiple chained redirects increases... Troubleshooting "redirect" issues (if they occur) becomes more time consuming... Upgrading Zen Cart becomes slightly more time consuming...

I'd personally avoid using such redirects in the first place... But if the client is adamant about deleting products and using redirects... Make sure to update the code previously presented. At the minimum use zen_href_link() and $cPath... Ideally some additional logic could be added to call the home page (no "&cPath=" when no cPath is available). Time permitting, some code could also be added to make sure the redirect only occurs on a "deleted" product (not on product IDs which do not yet exist / have not yet been used).

NOTE 1: Disabling / deleting a category is a whole different beast. In most cases, I would avoid the need and simply change the content... But sometimes one may desire to make such a change (especially if inheriting a site with overly nested categories)... I'd think about a 301 redirect (using mod_rewrite) if there is another category with very similiar content... Otherwise I'd let the 404 page handle the situation...

NOTE 2: Not really on topic, but something I should probably mention... I'd recommend (with or without redirects) one create / supply a good 404 page for customers. Ideally a good 404 page has: easy to use navigation, a search box, content customized to the broken URL (pre-populated search results, a link to the containing category when known, etc), and possibly some form of humor.

NOTE 3: Remember SEO and Best Practices tend to change over time. Any advice or opinions on this (or any site) should always be taken with a grain of salt. Make sure you do your research (including A/B testing) to determine the most beneficial course of action for your specific store. And always keep a backup handy!

NOTE 4: The highlighted portion only applies to Ultimate URLs when "automatic redirects" are enabled and the 3rd party code does not call zen_href_link(). This will not apply if the 3rd party code is updated to correctly utilize zen_href_link().
Right.. Except the client is pretty adamant about wanting to remove these products from the store.. He DOES NOT want customers to view any discontinued or otherwise unavailable product, and I simply want to contain the damage by making sure that they are re-directed to a place of our choosing and NOT sent to a 404 page (and for this site a category page will indeed work).. and yes I've explained the reasons not to do this to him. He is WELL aware of the risks, and he still wants to proceed.. I will figure something out.. Thanks for the response..

Re: Note 2.. Out-the-box, the Zen Cart 404 page has a site map and not much else.. Not doubting that it shouldn't be what you state, but it's not even close to this today, and probably over the heads of most (including myself) to customize to that level..:smile:

Seems that I am having a re direct problem I dont know but everytime I click on a product it just goes back to the main page and not the product page after installing the URL mod.

http://staging.tricountyhobbies.com

Sean Kersten:

Seems that I am having a re direct problem I dont know but everytime I click on a product it just goes back to the main page and not the product page after installing the URL mod.

http://staging.tricountyhobbies.com
When I attempt to access your development site I am seeing the standard Zen Cart "setup" prompts. Not sure if changes have been made since your initial post, but I would guess some have. Based upon the information presented a number of potential issues / conflicts caused by the server configuration exist:

• Multiple directories are set to not allow write access (including the cache, logs, and backup folders).
• There is an extra "/" in the path presented by $_SERVER["SCRIPT_FILENAME"]. This can cause potentially cause some issues with parsing of path information.
• The webserver is running nginx (without support for .htaccess files).

As you are running under nginx, you will need to convert the .htaccess files into native nginx configuration instructions. Once you have converted (and verified the nginx instructions), they will need to be added to the nginx configuration (not just the .htaccess file from Ultimate URLs - but also the ones from Zen Cart). The same step is needed for those running under IIS (without support for .htaccess files). Alternately you could just install Apache instead of nginx (Zen Cart works best under an AMP stack). Apache supports .htaccess files natively.

Next I would tackle the path issue. This could affect far more than just Ultimate URLs. I would guess there is an errant "/" in the php-fpm configuration for nginx. If you switched to Apache, just check to make sure the paths output by phpinfo are correct (and do not include extraneous slashes).

Afterwards (just to make life easier), I would create a user specifically for accessing the server document root (via FTP, SMB, and for the php-fpm pool). This way only that user will have access to the files (and can be given full control). Alternately you could run PHP under php-cgi and suPHP (doing something similiar). This will result in a setup similiar to how most shared hosting providers will be configured.

I've found spending the extra time to create such a setup can save ALOT of time during the course of development and reduce potential issues when deploying to a production webserver. The goal is always to match the final environment as closely as possible :smile:

Yes I took it down to try something but I put it back up. Maybe you can see something I am missing now but I will have the one who set up the server look at it.
Thanks

Zen Cart (and Ultimate URLs) was designed to run on a LAMP stack (**L**inux, **A**pache, **M**ySQL, **P**HP).¹

As previously posted, you are attempting to run your "staging" website on a LEMP stack (nGinx instead of Apache). The nGinx web server does NOT natively support the use of .htaccess files. Both Zen Cart and Ultimate URLs use .htaccess files (one to add security and performance tweaks, the other to handle incoming URLs).

The quickest (and easiest) method to get your "staging" server up and running would be to use a LAMP stack on your "staging" server (and configure it to load / allow the required Apache modules).

Alternately, you (or your server admin) can convert the various .htaccess files from both Zen Cart and Ultimate URLs and add the corresponding entries into the nGinx configuration files.

Note 1: See the Zen Cart Server Requirements for more details.

I read a little about it last night. The weird thing is that the site runs perfect and super fast but once I install the Ultimate URL mod it redirects itself. Ill have the guy who set up the server look into it. Thanks for the replies

Not weird at all (and not a bug with Ultimate URLs).

If you use a webserver other than Apache (such as nGinx or IIS), you will need to manually recreate the functionality added by the .htaccess files (from both Zen Cart and Ultimate URLs).

Running without converting the Zen Cart directives negatively impacts security and performance. Running without converting the Ultimate URL directives means your webserver does not know how to handle the URLs generated by Ultimate URLs.

Got an error with the new version - may be site specific but don't see how.

htmlspecialchars(): charset `utf8' not supported, assuming iso-8859-1 in /home/user/public_html/includes/classes/usu.php on line 241

filling up the logs folder!

Looks like an invalid CHARSET may be defined in one or more of the affected store's language files. For example the main language files for english: "/includes/languages/english.php" and "/admin/includes/languages/english.php".

For stores returning HTML with UTF-8 character encoding either "utf-8" or "UTF-8" can be used.

NOTE: In Zen Cart the constant CHARSET is used for PHP functions. In Zen Cart the constant DB_CHARSET is used for the MySQL connection. These are different. For example PHP uses the name "UTF-8", but MySQL uses the name "utf8".

Thanks for that explanation. I didn't realize there were two different ways.

The english file had define('CHARSET', 'utf8'); Adding in that dash fixed it. When I know why things are done, I'm more likely to remember and do it right!!

You are welcome. Knowing is half the battle!

Documentation missing in the latest version

I would love to try installing the software but when and after I have unzipped it there is no documentation. This is after it says the documentation will show up after you unzip. I have no idea how to install can someone send me the documentation or a link to the documentation please.

C

ckfs1:

Documentation missing in the latest version

I would love to try installing the software but when and after I have unzipped it there is no documentation. This is after it says the documentation will show up after you unzip. I have no idea how to install can someone send me the documentation or a link to the documentation please.

C

After you extract the Zip, look for index.hml in the readme folder.