Yet another "issue" that potentially is "known" attempting to use ceon uri rewriter on more than one site/subdirectory of the same domain. Yes, there is potentially problems, but I can say that I have ceon installed on two different sub directories on a single domain name, but it is working.

Oh and yes in htaccess files, sequence is almost everything. :)

As long as I have the "error" part before the "other pages" part it is all good.
And doing this basically makes causes the second block (from Ultimate URLs) to never be triggered... Same as removing the block...

The example shipped with Ultimate URLs 2.212 and Zen Cart 1.5.x do not include following block of code:

# Handle when a resource is not found (404 Error Page)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index\.php?main_page=page_not_found&%{QUERY_STRING} [L]

The above snippet should not be added to the .htaccess file for a site with either CEON URI Mapping or Ultimate URLs installed. It does not add any benefit and may confuse people reading the .htaccess file.

robbie269:

Could not get it to do the error on the test site. Maybe it is something with my main .htaccess file??
You may want to post the entire .htaccess files you are using (use CODE blocks). Post the one in the Zen Cart installation and any .htaccess file located in a parent folder. Be sure to obscure any reference to the Zen Cart admin URL. Additionally when using CEON URI Mapping, make sure none of your Zen Cart pages (products, categories, ex-pages, etc) start with name as your admin folder (or any other items excluded by Rewrite Conditions).

Error reporting in Zen Cart does not start until partway through Zen Cart loading (Zen Cart does have to load the error handling code before it will log errors)... So just enabling STRICT_ERROR_REPORTING may not reveal anything... You can also enable DEBUG_AUTOLOAD (set to true) in order to see the progress of Zen Cart loading and the last step before the HTTP/500 occurs...

But the best long term method to catch 99% of PHP errors / warnings is to tell PHP to log them to a dedicated file. This allows one to track down PHP related errors before Zen Cart (or any other PHP application) enables internal logging... For example the following settings in "php.ini" will log PHP errors and warnings to the file /home/username/php_errors.txt:

error_reporting = E_ALL | E_STRICT
log_errors = On
display_errors = Off
error_log = /home/user/php_errors.txt

You may need to talk to your hosting provider on what methods they allow to enable logging of PHP errors.

lhungil:

You may want to post the entire .htaccess files you are using (use CODE blocks). Post the one in the Zen Cart installation and any .htaccess file located in a parent folder. Be sure to obscure any reference to the Zen Cart admin URL. Additionally when using CEON URI Mapping, make sure none of your Zen Cart pages (products, categories, ex-pages, etc) start with name as your admin folder (or any other items excluded by Rewrite Conditions).
This is the .htaccess file in public_html. My website is in the sub directory "store" and there is no .htaccess file there.

RewriteOptions inherit
# Inserted By Customer Control Panel
SetENV PHPRC /home/#####/public_html

RewriteEngine on
RewriteCond %{HTTP_HOST} ^thehorsestall\.com\.au$ [OR]
RewriteCond %{HTTP_HOST} ^www\.thehorsestall\.com\.au$
RewriteRule ^/?$ "http\:\/\/www\.thehorsestall\.com\.au\/store\/" [R=301,L]

## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"
</IfModule>
## EXPIRES CACHING ## 

RewriteCond %{HTTP_HOST} ^horsestallgifts\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.horsestallgifts\.com$
RewriteRule ^/?$ "http\:\/\/www\.thehorsestall\.com\.au\/store\/" [R=301,L]

RewriteCond %{HTTP_HOST} ^horsestallgifts\.com\.au$ [OR]
RewriteCond %{HTTP_HOST} ^www\.horsestallgifts\.com\.au$
RewriteRule ^/?$ "http\:\/\/www\.thehorsestall\.com\.au\/store\/" [R=301,L]

RewriteCond %{HTTP_HOST} ^thehorsestall\.gift$ [OR]
RewriteCond %{HTTP_HOST} ^www\.thehorsestall\.gift$
RewriteRule ^/?$ "http\:\/\/www\.thehorsestall\.com\.au\/store\/" [R=301,L]

###############################################################################
# Common directives
###############################################################################
# NOTE: Replace /shop/ with the relative web path of your catalog in the "Rewrite Base" line below:

Options +FollowSymLinks
RewriteEngine on
RewriteBase /store/

###############################################################################
# Start Ultimate SEO URLs
###############################################################################

# Handles the new URL formats
RewriteRule ^(.*)-c-([0-9_]+)/(.*)-p-([0-9]+)(.*)$ index\.php?main_page=product_info&products_id=$4&cPath=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-c-([0-9_]+)/(.*)-pi-([0-9]+)(.*)$ index\.php?main_page=popup_image&pID=$4&cPath=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-c-([0-9_]+)/(.*)-pr-([0-9]+)(.*)$ index\.php?main_page=product_reviews&products_id=$4&cPath=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-c-([0-9_]+)/(.*)-pri-([0-9]+)(.*)$ index\.php?main_page=product_reviews_info&products_id=$4&cPath=$2&%{QUERY_STRING} [L]

# Original (unchanged) URL formats
RewriteRule ^(.*)-p-([0-9]+)(.*)$ index\.php?main_page=product_info&products_id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-m-([0-9]+)(.*)$ index\.php?main_page=index&manufacturers_id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-pi-([0-9]+)(.*)$ index\.php?main_page=popup_image&pID=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-pr-([0-9]+)(.*)$ index\.php?main_page=product_reviews&products_id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-pri-([0-9]+)(.*)$ index\.php?main_page=product_reviews_info&products_id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-ezp-([0-9]+)(.*)$ index\.php?main_page=page&id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-c-([0-9_]+)(.*)$ index\.php?main_page=index&cPath=$2&%{QUERY_STRING} [L]

robbie269:

This is the .htaccess file in public_html. My website is in the sub directory "store" and there is no .htaccess file there. ...
The instructions for Ultimate SEO URL state you need to put the .htaccess file for Ultimate SEO URLs in the root folder of your Zen Cart installation. In your case this would be in the folder "/store/". Placing them in the parent folder "as-is" will not work (and is probably the root cause of the issues you are experiencing).

I also highly dislike using rewrite rules to force users from "/" to "/store/". Far better in the long run to REMOVE those and just place Zen Cart in "/" instead of "/store/" (and update the configure.php files to match). This will save you from many future headaches.

So, been thinking about this a little more to try to help.

Two methods have come to mind on how to remap the CEON URIs to something else.

The first method I thought of was to redirect the ceon uri directly to the equivalent new uri rewritten address, but then thought, what happens when something about that changes, so the other way I was thinking of would maap the CEON URI back to the ZC standard URI which would then result in the htaccess remapping to whatever uri your site is set to.

If you export the ceon_uri_mappings table to a csv file, then basically in an e spreadsheet piece all of the data together to end up with two columns, the first is the ceOn URi, the second is the uri that would be seen/created by ZC for a product. Then, append/prepend the applicable redirect(s). Copy this new single column into your htaccess and away you go... I see though lhungil has provided some corrections to the previously provided htaccess file. Still seems like it is/was unnecessary in my opinion.

lhungil:

The instructions for Ultimate SEO URL state you need to put the .htaccess file for Ultimate SEO URLs in the root folder of your Zen Cart installation. In your case this would be in the folder "/store/". Placing them in the parent folder "as-is" will not work (and is probably the root cause of the issues you are experiencing).

I tried this and it stopped the website from loading. But maybe it was due to the problem with the .htaccess file in "/".

lhungil:

I also highly dislike using rewrite rules to force users from "/" to "/store/". Far better in the long run to REMOVE those and just place Zen Cart in "/" instead of "/store/" (and update the configure.php files to match). This will save you from many future headaches.

Bit unclear what you mean. Do you mean move the whole website to the public_html folder or is there a better way to direct people to the website in the store folder?

robbie269:

I tried this and it stopped the website from loading. But maybe it was due to the problem with the .htaccess file in "/".
Well it was that rotten redirect to /store/ that was causing the problem. Removed it and the site still worked OK. Looks like it was never needed at all!
Moved all the Ultimate SEO URL bits to their own .htaccess file under /store/ and it is all seems to be working OK.
Thanks lhungil.

robbie269:

Well it was that rotten redirect to /store/ that was causing the problem. Removed it and the site still worked OK. Looks like it was never needed at all!
Moved all the Ultimate SEO URL bits to their own .htaccess file under /store/ and it is all seems to be working OK.
Thanks lhungil.
No sorry I jumped in too soon. That did not work!! www.theh####.com.au just went to a directory listing. I have gone back to how it was for now.
Can you explain to me again about redirects regarding "/" and "/store/".

When I put the Ultimate SEO URL bits in a .htaccess file in /store/ I get the following error when trying to open the website:
"The page isn't redirecting properly. Firefox has detected that the server is redirecting the request for this address in a way that will never complete."

mc12345678:

So, been thinking about this a little more to try to help.

Two methods have come to mind on how to remap the CEON URIs to something else.

The first method I thought of was to redirect the ceon uri directly to the equivalent new uri rewritten address, but then thought, what happens when something about that changes, so the other way I was thinking of would maap the CEON URI back to the ZC standard URI which would then result in the htaccess remapping to whatever uri your site is set to.

If you export the ceon_uri_mappings table to a csv file, then basically in an e spreadsheet piece all of the data together to end up with two columns, the first is the ceOn URi, the second is the uri that would be seen/created by ZC for a product. Then, append/prepend the applicable redirect(s). Copy this new single column into your htaccess and away you go... I see though lhungil has provided some corrections to the previously provided htaccess file. Still seems like it is/was unnecessary in my opinion.

Thanks for the idea mc12345678.

Exported the list into MS Excel. After a bit of tweeking it has all been added to the .htaccess file.

robbie269:

Thanks for the idea mc12345678.

Exported the list into MS Excel. After a bit of tweeking it has all been added to the .htaccess file.

No problem, albeit that I've worked out a way to basically do the reverse process. Or at least to use the same tools.

robbie269:

Thanks for the idea mc12345678.

Exported the list into MS Excel. After a bit of tweeking it has all been added to the .htaccess file.

I had the same idea myself but couldn't get product redirects to work.

Category redirects in the form

Redirect 301 /category http://domain.com/index.php?main_page=index&cPath=1

work just fine, but product redirects in the form

Redirect 301 /category/product http://domain.com/index.php?main_page=product_info&cPath=1&products_id=2

show in the browser address bar in the form

http://domain.com/index.php?main_page=index&cPath=1/product

... which show the category product listing pages but not the product_info pages!

I'm thinking it has something to do with the / in the CEON URL but can't figure out how to get round it. What tweeks do I need to make?

imac:

I had the same idea myself but couldn't get product redirects to work.

Category redirects in the form

Redirect 301 /category http://domain.com/index.php?main_page=index&cPath=1

> work just fine, but product redirects in the form
> ```
Redirect 301 /category/product http://domain.com/index.php?main_page=product_info&cPath=1&products_id=2

show in the browser address bar in the form

http://domain.com/index.php?main_page=index&cPath=1/product

> ... which show the category product listing pages but not the product_info pages!
> 
> I'm thinking it has something to do with the / in the CEON URL but can't figure out how to get round it. What tweeks do I need to make?

So, haven't looked up the answer, but basically what is happening is that the categories' rewrite is acting on the product's uri and keeping/adding the remaining portion to the end of the resulting URI.  So, there are several things that could be done, but one of which is to place the rewrites in the proper order so that actions like this do not occur. Also if going to provide one rewrite for each product instead of making some sort of rules of rewriting, then the rewritecondition side should indicate that the comparison is to be to all text and not just a portion of the text...

robbie269:

When I put the Ultimate SEO URL bits in a .htaccess file in /store/ I get the following error when trying to open the website:
"The page isn't redirecting properly. Firefox has detected that the server is redirecting the request for this address in a way that will never complete."

Why not do yourself a huge favour and get rid of the rewrites entirely?

Seriously. The original rewrites were added to fix something that was never broken, and now you are trying to fix this with something that is doing nothing more than compound the problems created by the 1st 'fix'.

I can't help but wonder the kind of mess you'll end up with should you ever decide to move your site to a different domain. Even if the original rewrites had some sort of SEO benefit (which it doesn't) any such benefits would now be lost due to rewriting of the rewrites. I can only speculate at the amount of time that has been wasted here.

What would I know though? I've only been running servers for almost a decade before the 'www' was even invented. :)

Cheers
RodG

RodG:

... What would I know though? I've only been running servers for almost a decade before the 'www' was even invented. :)
Ah, yes, I remember when Al Gore invented the web!:laugh: I'm so glad he did.

lat9:

Ah, yes, I remember when Al Gore invented the web!:laugh: I'm so glad he did.

Tim Berners-Lee invented the Web. Al gore invented the internet, and if you listen very carefully you can still hear the Algorithm.:onfire:

mc12345678:

So, haven't looked up the answer, but basically what is happening is that the categories' rewrite is acting on the product's uri and keeping/adding the remaining portion to the end of the resulting URI. So, there are several things that could be done, but one of which is to place the rewrites in the proper order so that actions like this do not occur.
Yes, that was the kind of thing I was thinking myself. In my first test I stupidly put the Redirects AFTER the Ultimate SEO Rewrites.

When it didn't work, the first thing I did was move them above the Rewrites, but it didn't make any difference!

BUT, encouraged by your analysis, I tried another test with a different product ... and it WORKED without any extra tweaks at all!!!

So I tested the first product again, and it didn't work. Which only proved I'd been doubly stupid and forgotten to clear the Cache! :blush: :blush:

The moral of the story being that if it hadn't have been for your reply I wouldn't have tried it again. So that's a big THANK YOU from me. :D

So, pulling it all together. For anyone who wants to redirect CEON URIs through Ultimate SEO URLs without creating new Rewrite rules, the solution is:

1. Export the ceon_uri_mappings table to a csv file
2. Load the csv file in a spreadsheet
3. Delete all columns except uri, main_page and associated_db_id
4. Sort rows (descending) using main_page as key
5. Delete all rows where main_page is not product_info or index
6. Insert new column (left) of associated_db_id
7. Move data in all rows where main_page is index from associated_db_id to new column
8. Relabel columns: <CEON URI>,<main_page>, <cPath>, <products_id>
9. Sort rows (ascending) on <CEON URI>
   10.. Autofill <cPath> data from index to product_info rows
10. Insert and Autofill columns to construct Redirect statements in the form:

# PRODUCTS (where main_page is product_info)
Redirect 301 <CEON URI> http://<MyDomain>/index.php?main_page=product_info&cPath=<cPath>&products_id=<products_id>

# CATEGORIES (where main_page is index)
Redirect 301 <CEON URI> http://<MyDomain>/index.php?main_page=index&cPath=<cPath>

12. Merge all columns into 1 single column
13. Copy this new single column into htaccess ABOVE '# Start Ultimate SEO URLs'

imac:

Yes, that was the kind of thing I was thinking myself. In my first test I stupidly put the Redirects AFTER the Ultimate SEO Rewrites.

When it didn't work, the first thing I did was move them above the Rewrites, but it didn't make any difference!

BUT, encouraged by your analysis, I tried another test with a different product ... and it WORKED without any extra tweaks at all!!!

So I tested the first product again, and it didn't work. Which only proved I'd been doubly stupid and forgotten to clear the Cache! :blush: :blush:

The moral of the story being that if it hadn't have been for your reply I wouldn't have tried it again. So that's a big THANK YOU from me. :D

So, pulling it all together. For anyone who wants to redirect CEON URIs through Ultimate SEO URLs without creating new Rewrite rules, the solution is:

1. Export the ceon_uri_mappings table to a csv file
2. Load the csv file in a spreadsheet
3. Delete all columns except uri, main_page and associated_db_id
4. Sort rows (descending) using main_page as key
5. Delete all rows where main_page is not product_info or index
6. Insert new column (left) of associated_db_id
7. Move data in all rows where main_page is index from associated_db_id to new column
8. Relabel columns: <CEON URI>,<main_page>, <cPath>, <products_id>
9. Sort rows (ascending) on <CEON URI>
   10.. Autofill <cPath> data from index to product_info rows
10. Insert and Autofill columns to construct Redirect statements in the form:

PRODUCTS (where main_page is product_info)

Redirect 301 <CEON URI> http://<MyDomain>/index.php?main_page=product_info&cPath=<cPath>&products_id=<products_id>

CATEGORIES (where main_page is index)

Redirect 301 <CEON URI> http://<MyDomain>/index.php?main_page=index&cPath=<cPath>

> 12. Merge all columns into 1 single column
> 13. Copy this new single column into htaccess ABOVE '# Start Ultimate SEO URLs'

Wow!!! Thanks for this.. found this looking for something else entirely.. Need to do this very thing for a client as I want to migrate them AWAY from Ceon URI to Ultimate SEO.. Didn't want to do it until I found a solution to re-direct the existing URIs..

DivaVocals:

Wow!!! Thanks for this.. found this looking for something else entirely.. Need to do this very thing for a client as I want to migrate them AWAY from Ceon URI to Ultimate SEO.. Didn't want to do it until I found a solution to re-direct the existing URIs..

All ya' had to do was ask... Thought you had already migrated others away from CEON, so I'm surprised you don't already have a process instead of reviving an old one.

mc12345678:

All ya' had to do was ask... Thought you had already migrated others away from CEON, so I'm surprised you don't already have a process instead of reviving an old one.

No I didn't which is why all my clients who still use this were on standby for the moment.. Too bad really.. I LOVED Ceon URI, but I'm not feeling very confident about the current support situation..