Ceon URI Mapping (SEO)

[DivaVocals]

Nevertheless, the answer you are looking for is that you create a .htaccess file for each store and put these files in the individual stores' directories. Your server will check the .htaccess file in the root directory first, then it will check any subdirectories to see if they have .htaccess files.. so the .htaccess file for the appropriate store will be loaded when the webserver attempts to open /store or /test-store (i.e. /store/.htaccess or /test-store/.htaccess).

As both stores are in a subdirectory of the root of the site, you should use the appropriate rewrite rule example for stores which are in a subdirectory.

As long as your root .htaccess file doesn't interfere with the subdirectory .htaccess files, everything should be smooth enough

IMO, you did a fantastic job explaining how to setup the .htaccess per directory in your read me docs.. All of my client sites are set up in a dev environment with subdirectories for each client.. Your instructions got me up and running in NO time..

[conor]

Hi,

IMO, you did a fantastic job explaining how to setup the .htaccess per directory in your read me docs.. All of my client sites are set up in a dev environment with subdirectories for each client.. Your instructions got me up and running in NO time..

That's good to hear and nice of you to say, thanks! :)

All the best...

Conor
ceon

[scatzc]

Notes (that will hopefully help others) regarding installing Ceon URI Mapping when the hideCategories add-on is already installed:

There are no conflicting files between these two add-ons - except for one file:

admin/categories.php

Inside that admin/categories.php file, there are two distinct segments that, using a file compare utility like WinMerge, can simply be copied over to the original admin/categories.php from v1.3.8a. They are marked with the lines:

//Begin hideCategories code.
...
//End hideCategories code. 

Applying admin/categories.php patches from Ceon 3.2.4 to the admin/categories.php from v1.3.8a can be done in the same manner: distinct segments that can simply be copied over. They are marked with the lines:

// BEGIN CEON URI MAPPING n of 5
...
// END CEON URI MAPPING n of 5 

(of course, when either of these add-ons are applied to the original v1.3.8a file, the entire admin/categories.php can simply be copied, overwriting the original one).

Using the same "segmented-copy" approach, we can copy over the Ceon 3.2.4 segments, one-by-one, verbatim to their respective positions in admin/categories.php that has already been patched with hideCategories -- except for the last one (5 of 5)!

The last one is "special" in the sense that, if you use a file compare utility like WinMerge, it overlaps with the last segment from hideCategories. You can't just "copy over".

Therefore, care must be taken when applying this change:

1. Do any of these last segments need to be modified (requiring programmer's code examination)?
2. If not, which one comes first? Do we insert the Ceon 3.2.4 segment before the hideCategories segment or after it?

As of now, it appears that the correct answers are:

1. No need to modify any of these two "last segments".
2. The Ceon 3.2.4 segment should be inserted before the hideCategories segment

If I discover anything that contradicts the above, I will post an update here.

[scatzc]

IMO, you did a fantastic job explaining how to setup the .htaccess per directory in your read me docs.. All of my client sites are set up in a dev environment with subdirectories for each client.. Your instructions got me up and running in NO time..

Now that I finally finished adding this module to my test store, I can say that I agree whole heatedly.

What an amazing job Conor did. One of the reasons it took me so long to add this module was the fact that I had to add it to a system that already had quite a few add-ons already integrated. I had to be very careful in comparing and applying every change - in addition to not really understanding every line of code or .htaccess statement.

Not only does Conor explains each and every step (and different cases/possibilities/configurations for each step), he also formats the document in a way that I haven't seen in any add-on.

I am thrilled at how this worked for me in the first attempt (knock wood...) without interfering with the hideCategories add-on.

Thank you, Conor!

[DivaVocals]

What an amazing job Conor did. One of the reasons it took me so long to add this module was the fact that I had to add it to a system that already had quite a few add-ons already integrated. I had to be very careful in comparing and applying every change - in addition to not really understanding every line of code or .htaccess statement.

So did I.. In fact, I was adding this to not one but TWO different sites. Conor made this work easy by CLEARLY identifying all the core files that might be overwritten. For me this made the WinMerge process loads easier since all I had to do was compare the clearly marked files to the ones already in place on both sites.

Overall Conor did an excellent job in packaging, documenting, and supporting this add-on.. Looking over the support thread, no question has been too small or too dumb. However, for my money IMO his documentation really explained EVERYTHING well.. I don't have to exactly understand what each line in the .htaccess does, but I do have to understand what I need to do to set it up for this add-on to work.. Which is why I said that IMO, Conor did a fantastic job explaining how to setup the .htaccess per directory in his readme docs..

[scatzc]

Question regarding FAQ #4: After "ticking" a few products (in the operational site) and verifying that this ingenious add-on works, I indeed encountered the appended “?cPath” at the the end of a product's URI.

I then referred to the FAQ which confirmed that this is not a bug, it is by design. It says:

There is no way to avoid the cPath parameter being added for linked products.

I then noticed that if I manually delete that “?cPath” suffix from the browser's address bar, the URI now corrects itself and whenever I search for a product or click a link to it, its URI always shows up without the “?cPath” suffix.

This is a great but now I wonder: Is this how it is supposed to behave? Are there undesired "side effects" to this?

Thanks.

[scatzc]

I then noticed that if I manually delete that “?cPath” suffix from the browser's address bar, the URI now corrects itself and whenever I search for a product or click a link to it, its URI always shows up without the “?cPath” suffix.

Update: None of my products are of the "Linked" type. Yet, some products (not all) get the “?cPath” appended upon URI creation. As stated before, if I manually Backspace the “?cPath” suffix, it will not re-appear.

I wonder whether I am the only one having this "problem" (not really a problem, at least for now).

[sarabz]

I implemented this on our upgraded site, everything looked great and we went live a couple days ago. I was slowly converting all our pages, categories, products, manufacturers, etc over to the pretty URL's, and it was brought to my attention that the manufacturer pages were not letting you "add to cart" when they have a new URL. It just refreshes the page. Since this is my live site, I removed the URI Mappings for the manufacturers, although I had to do it through the database and not the admin utility, even when I deleted the text, it stuck around, and would not go back to the zen default urls.

Since my test site is down, and my live site I had to remove the errors to prevent further sales loss, I cannot show this to you at the moment, but I will try to get my test site back up in the next couple of days if needed.

Summary, since I kind of rambled, is:

1) My major issue: on Manufacturer pages, when anything besides the default zen path is used, cannot do the multiple add to cart (when the products have no attributes). It just refreshes the page.

2) This is minor, but on the Admin Manufacturers edit page, cannot remove the URI Mapping, have to remove manually from the database.

Our website is the most current 1.3.8a, with the most current CEON SEO mod. We do have a handful of other mods installed (better together, rewards points, image handler, zen light box, and a few others), but I don't think they are interfering here, since it seems to work everywhere but the manufacturers pages. I did several winmerges to see if I missed anything in the uploads, and everything seems to be correct. Our current setting is to go to the shopping cart after an item has been added, not to stay on the product/category page, but I'm not sure that makes any difference.

Hopefully someone here can help me out, I'd really like the URI Mapping to be implemented on the manufactures pages as well.

Thanks
Sara
b a b y S N A Z Z .com

[DivaVocals]

Okay.. I'm ready to fire the trigger on this, and I was doing some final testing.. EVERYTHING works great with one exception..

After completing a sale, I get an error when I click the notifications button as follows:

Warning: urlencode() expects parameter 1 to be string, array given in /home/blahblahblah/public_html/includes/init_includes/init_ceon_uri_mapping.php on line 657

Warning: Cannot modify header information - headers already sent by (output started at /home/blahblahblah/public_html/includes/init_includes/init_ceon_uri_mapping.php:657) in /home/blahblahblah/public_html/includes/init_includes/init_ceon_uri_mapping.php on line 664

Warning: Cannot modify header information - headers already sent by (output started at /home/blahblahblah/public_html/includes/init_includes/init_ceon_uri_mapping.php:657) in /home/blahblahblah/public_html/includes/init_includes/init_ceon_uri_mapping.php on line 665

Any ideas what might be causing this??

[conor]

Hi,

Okay.. I'm ready to fire the trigger on this, and I was doing some final testing.. EVERYTHING works great with one exception..

That's great to hear! :)

After completing a sale, I get an error when I click the notifications button as follows:

Any ideas what might be causing this??

I can see what would cause the code to fail but not how you're arriving in the situation causing it.

The errors you have indicated would be caused by the redirection code in the module for a non-standard Zen Cart page incorrectly trying to encode a query string ($_GET) parameter which is an array.

I'm posting some code for you to prevent these errors appearing in the module but it's strange that you're reaching this point. It means that instead of your product notifications form using the POST method, as with any Zen Cart store/template I've seen, your store must be using the GET method. Also, you must have entered a URI manually for the account products notification page?

Anyway, replace the following loop in includes/init_includes/init_ceon_uri_mapping.php:

foreach ($_GET as $key => $value) {
                        $query_string .= '&' . urlencode($key) . '=' . urlencode($value);
                    } 

with:

if (is_array($value)) {
                            foreach ($value as $key2 => $value2) {
                                $query_string .= '&' . urlencode($key2) . '=' . urlencode($value2);
                            }
                        } else {
                            $query_string .= '&' . urlencode($key) . '=' . urlencode($value);
                        } 

It's kludgely and off the top of my head but that should work! I'll add better code to a future version of the module (a little recursive function of course).

All the best...

Conor
ceon