ailtait:

DivaVocals ... thanks, kind of. "I personally will not spend any time troubleguessing on anyone's issue". Don't feel you have to input any further. I was merely asking in the hope someone might have experienced something similar. If you didn't want to answer, you shouldn't have. I'm sorry to see such rude aggression so quickly. I didn't answer some of the questions initially because I was still working on the problem to try and provide more concrete findings to my post. Apologies if it wasn't detailed or prompt enough for you first time around. I know these forums can often be filled with people asking questions without having investigated the issue themselves, and no providing information. I go to pains to try and solve issues first, before posting on forums just for that reason ... I know there are a lot of people like you on here, dedicating time free of charge to help. So I don't want to waste that valuable time.

Unfortunate though that I'm spoken to in such a tone so quickly. The contrast between the response of Ihungil and you is significant.
Right.. sigh

There was no TONE to my response.. I simply wanted to emphasize that DETAILS get more HELPFUL responses.. From my POV I didn't see details in your initial posts which happens more often than not on this forum. So no.. there was no tone, no attitude, no "aggression" at all.. but you are certainly FREE to read any emotions you think are behind my post into my words..

That said, as has been stated/implied, the most COMMON cause of issues with this module usually center around a missed fie, or file merging gone awry. If you cannot use the live site, then perhaps restoring the live site to your test/dev site is a first step to troubleshooting this so you can do a true apples to apples comparison.. Once you have an updated test/dev store up, the very first thing you need to do is switch to the default template.. Because like others who have responded to you I suspect the issue is in something hardcoded into your tempate being the cause of the issues you are having..

ailtait:

... If you didn't want to answer, you shouldn't have. ... I know there are a lot of people like you on here, dedicating time free of charge to help. ...
If "we" did not want to help, we'd just not respond... But anyhow we are getting off track. Basically, the behavior you are seeing is not something we can replicate in our test environments (working copy of Zen Cart with a functioning template and CEON URI Mapping)...

So the question becomes "What is different on your installation?". Right now we do not know (possibly because you do not know exactly what is different in your installation from a stock Zen Cart 1.5 installation)...

ailtait:

... Other links, such as the header and footer links are hard coded into template. ...
All links should be using zen_href_link to "populate" the HTML "href" attribute (dynamic not hard coded). This holds true for templates, modules, plugins, and anything else inside Zen Cart's installation folder. I cannot stress this enough!

ailtait:

... Debug log: There are some, which I'm trying to work my way through. I don't think any are connected to this, but i'll double check. ...
Usually when these are created something is wrong... Sometimes seemingly unrelated errors can be the root cause... I usually advise clients to start by cleaning up all existing errors (especially after an upgrade)... If you posted some snippets (please use the # code blocks), we may be able to help (although if you feel they are unrelated, feel free to search for a more appropriate thread or start a new one)...

ailtait:

... In terms of the installation, the hosting company updated ZC to the latest version, and updated the CEON plugin around the same time. My hunch is that something hasn't been installed properly ...
Ahhh, so it was not a clean Zen Cart 1.5 installation, but an upgrade from a previous version... I would be asking the hosting company HOW they upgraded the installation... Did they try to use fantastico, scriptalicous, etc (which can cause some serious headaches on customized sites)? Did they just attempt to merge changes from 1.5 into 1.3 files? Did they follow the steps outlined on this site by the Zen Cart team for doing an upgrade? In what ways did they deviate (if any)? Did they restart from scratch (does not sound like it)?

I'd say your hunch is correct... Something was broken during the upgrade of Zen Cart, another module, or this module...

ailtait:

... We have customised some quite a bit of functionality on the site, but most of that customisation was done around initial build. ...
Zen Cart 1.3 and 1.5 have significant differences. One example is changes to the handling of admin menus / pages (plugins need to be upgraded to work correctly).

When upgrading, many of us recommend only doing an upgrade of the database and configure.php files... And starting with clean files from Zen Cart 1.5 and slowly re-adding any needed customizations to the Zen Cart files...

This avoids bad "merges" and makes it easier to determine "when and what" went wrong during the upgrade... Another reason is some older plugins and modifications are no longer needed with Zen Cart 1.5 (and leftover files / merged code can cause issues)...

ailtait:

... Unfortunately we had help with the update, and as such I'm not 100% sure where it's gone wrong, barring uninstalling and reinstalling. ...
Crux of the issue here... It sounds like you are not aware of exactly what was done...

Walking thought the installation steps (for this module) again should help verify where something is off (have you done this?)... As will going though the debug logs... One can also compare their current site against a clean 1.5 installation to see what changes have been made...

But in the end if whoever upgraded your Zen Cart installation and plugins made a mistake (and was paid)... I'd be giving them a call... Otherwise, manually starting over the upgrade and installation (on a development site) may be a safe last resort...

Installed latest version with ZC 1.5.1. The individual products are working properly with the friendly URL on links and address bar. However, product categories are not working. Scratching my head on this one. Any assistance is greatly appreciated!!!

ElPoderoso15:

Installed latest version with ZC 1.5.1. The individual products are working properly with the friendly URL on links and address bar. However, product categories are not working. Scratching my head on this one. Any assistance is greatly appreciated!!!

Will need more information about "not working". Something not seen correctly in the admin area? Not seeing the results anywhere a category is referenced on the site? Not seeing the proper rewritten link only in aa category drop down? Was at least one category assigned a rewritten uri from the admin?

I don't want to troubleguess further. Please as able follow the posting guidelines, attempt to answer questions as asked. In this case more than likely haven't "told" the rewriter how to rewrite the category.

lhungil:

If "we" did not want to help, we'd just not respond...
Exactly.. thank you!:smile:

To you and anyone else that thinks that Diva or someone else around here does not want to help. We all need help and some of us have had problems just like someone else's problem and can chime in with what we did....but.....

When it comes to ANY problems experienced by ALL of us is easier helped with when we give as much information as possible and and answer questions that are asked of us. Without those answers a better answer or solution is very hard to reach. Also the store version and link to the store aids in getting results cause they can go see the problem for themselves (sometimes our explaination is not quite what we think it is) and can help us even better.

I ahve had similar things happening with this mod and links myself and sure enough, I found by going through each and every one of my vendors/categories/products that it is something that I have either written wrong or not had the url changed for....for instance, I have some products with [ ] or * in the titles. Those were generating the shortened url plus the ?with cpath also, not having done a category gave me the cpath link or a non working link.

At times we think some questions are silly or not needed but what we don't realize is that we have done so much traversing between our store and what we thought was the problem solution that we left out a very simple thing.

My client was having trouble with hers working right and we had to remove all her old store files and reupload fresh ones then add the mods one at a time....to get her store to behave.

Now I will get off my box...sorry for that not smacking your hands just want all who ask questions in this forum to maybe see this info...and be a bit more patient, no response or solution is something that is immediate...unless it is the idiotic ones that I can come up with where the solutions was so simple I did not think those terms but actually looked for something difficult.

Thanks Diva and the others for all you have helped me with and others too.

lhungil:

If "we" did not want to help, we'd just not respond... But anyhow we are getting off track. Basically, the behavior you are seeing is not something we can replicate in our test environments (working copy of Zen Cart with a functioning template and CEON URI Mapping)...

So the question becomes "What is different on your installation?". Right now we do not know (possibly because you do not know exactly what is different in your installation from a stock Zen Cart 1.5 installation)...

All links should be using zen_href_link to "populate" the HTML "href" attribute (dynamic not hard coded). This holds true for templates, modules, plugins, and anything else inside Zen Cart's installation folder. I cannot stress this enough!

Usually when these are created something is wrong... Sometimes seemingly unrelated errors can be the root cause... I usually advise clients to start by cleaning up all existing errors (especially after an upgrade)... If you posted some snippets (please use the # code blocks), we may be able to help (although if you feel they are unrelated, feel free to search for a more appropriate thread or start a new one)...

Ahhh, so it was not a clean Zen Cart 1.5 installation, but an upgrade from a previous version... I would be asking the hosting company HOW they upgraded the installation... Did they try to use fantastico, scriptalicous, etc (which can cause some serious headaches on customized sites)? Did they just attempt to merge changes from 1.5 into 1.3 files? Did they follow the steps outlined on this site by the Zen Cart team for doing an upgrade? In what ways did they deviate (if any)? Did they restart from scratch (does not sound like it)?

I'd say your hunch is correct... Something was broken during the upgrade of Zen Cart, another module, or this module...

Zen Cart 1.3 and 1.5 have significant differences. One example is changes to the handling of admin menus / pages (plugins need to be upgraded to work correctly).

When upgrading, many of us recommend only doing an upgrade of the database and configure.php files... And starting with clean files from Zen Cart 1.5 and slowly re-adding any needed customizations to the Zen Cart files...

This avoids bad "merges" and makes it easier to determine "when and what" went wrong during the upgrade... Another reason is some older plugins and modifications are no longer needed with Zen Cart 1.5 (and leftover files / merged code can cause issues)...

Crux of the issue here... It sounds like you are not aware of exactly what was done...

Walking thought the installation steps (for this module) again should help verify where something is off (have you done this?)... As will going though the debug logs... One can also compare their current site against a clean 1.5 installation to see what changes have been made...

But in the end if whoever upgraded your Zen Cart installation and plugins made a mistake (and was paid)... I'd be giving them a call... Otherwise, manually starting over the upgrade and installation (on a development site) may be a safe last resort...

I have to agree with all of this.. Since this is an install and upgrade NOT performed by the OP, this makes it DOUBLY difficult to troubleshoot since the OP may not have a full handle on all that was done.. I'm thinking that a bit of a re-do is in order.. Much like the rebuild of my client's dev site I had to do a few months back to get to the bottom of a PHP5.4 compatibility issue, the OP may need to consider a fresh Zen Cart v1.5.1 install in his dev/test area and then apply the DB to run through the upgrade. Then the OP can install all of his mods one by one starting with this mod, and testing along the way to make sure things continue to work..

DarkAngel:

Thanks Diva and the others for all you have helped me with and others too.:hug:Thanks DarkAngel!!! I owe much to community support and I do like to give back.. thanks for your "non" hand smack..:smile: Good reminder for all of us..

Couldn't agree more DarkAngel. I know that folks such as yourself (and DivaVocals) put in a huge effort to help on here. I used to contribute to a lot of forums myself back in the day, helping others, so I absolutely appreciate the effort that goes in to it. Genuinely could not agree more with all that you've said. Given my own history of using forums in the past to offer help, and the length I go to solve problems before jumping straight on here to ask for help ... I probably just took it a bit personal that one of my first responses had big bold red letters and capital words. Followed by a sigh. It's patronising, or at least that's how it comes across.

Still, happy to take it on the chin. If nothing else, it highlight that the written word can be interpreted in many ways. I'm a relative newbie to this forum, and I don't yet know all the characters :-)

Anyhoo, it's all getting off topic and becoming a conversation that doesn't need to be had.

Ihungil ... another great response. Thank you. That gives me a few things to go and work on. I'll get in touch with the hosting company and see if they have a record of how they upgraded. I'll also update CEON on our test site. If it continues to work, then the only difference between test and live will be the version of ZC, and that I installed CEON myself. So either something in our custom code conflicts with something ZC 1.5.1, or they've not installed CEON correctly. Given that most of our customisations were written using the ZC language, I'm leaning more towards CEON not being installed properly. Just adds to the confusion that the redirects do actually work and that the install check says all is fine.

I'll make a start. If / when I find the issues, I'll post an update, just incase anyone else encounters a similar problem in future.

Thanks for the help, as always.

Clicking on a product category link while on the online store with CEON URI mapping configured will display the home page. It takes a second for it to happen as if it is trying to locate the page. All other pages are working properly including product pages and ez pages.

Sample product page:
http://www.spellex.com/new/estore/handheld-medical-spell-check

Sample ez page:
http://www.spellex.com/new/estore/mission-statement

Sample category page (fails):
http://www.spellex.com/new/estore/handheld-spelling-solutions

Thanks!

ElPoderoso15:

Clicking on a product category link while on the online store with CEON URI mapping configured will display the home page. It takes a second for it to happen as if it is trying to locate the page. All other pages are working properly including product pages and ez pages.

Sample product page:
http://www.spellex.com/new/estore/handheld-medical-spell-check

Sample ez page:
http://www.spellex.com/new/estore/mission-statement

Sample category page (fails):
http://www.spellex.com/new/estore/handheld-spelling-solutions

Thanks!
Well since I am not seeing CLEARLY on your site where one would see that category link, I would have to say that the behavior you see is happening because the URI/URL doesn't exist.. Can you walk us through the exact path one would take to find that URL on your site?? Also have you gone through and saved ALL of your product categories so that they all generate the new URIs?? because it doesn't appear that you have done so.. You have product URIs but no category URIs..

DivaVocals:

Well since I am not seeing CLEARLY on your site where one would see that category link, I would have to say that the behavior you see is happening because the URI/URL doesn't exist.. Can you walk us through the exact path one would take to find that URL on your site?? Also have you gone through and saved ALL of your product categories so that they all generate the new URIs?? because it doesn't appear that you have done so.. You have product URIs but no category URIs..

Thanks for the reply. I have configured the URI in the product categories. However, since we are testing some of the pages in-house I disabled them for the time being to avoid broken links. I updated all product categories from the blue hover menu to have URI for the sake of troubleshooting the behavior.

Here's the path generated from zencart:
http://www.spellex.com/new/estore/index.php?main_page=index&cPath=72
Here's the path with the URI
http://www.spellex.com/new/estore/handheld-spell-check

You can use the hover menu

Start by answering more of the questions found in the "Posting Tips".
The "Posting Tips" can be found while replying to a thread by scrolling up.
They are also listed in the Forum Do's and Don'ts.

Some other important questions to answer:
Which version of CEON URI Mapping you are attempting to install / configure?
Did you upgrade from a previous version of CEON URI Mapping?
Did you acquire your copy of CEON URI Mapping from this site? If you did not where did you acquire your copy from?
Are there any Zen Cart debug logs? If so, what are in the logs?
Are there any PHP / Server error logs? If so, what are in the logs?
Have you altered the .htaccess file generated by CEON URI Mapping? If so what did you modify?
Do the same issues occur when using the "classic" template included with Zen Cart 1.5?

ElPoderoso15:

... However, since we are testing some of the pages in-house I disabled them for the time being to avoid broken links. ...
Can you make your "in-house" testing location public (on a different domain and perhaps with no-index configured)? This way a link could be provided to allow those reading the forums to see the described behavior while not impacting your "live" store.

ElPoderoso15:

...
I updated all product categories from the blue hover menu to have URI for the sake of troubleshooting the behavior. ...
I am going to assume the "blue hover menu" is the main navigation in the header... If this is true, go back right now and replace all those hard coded "href" attributes with zen_href_link function calls. Hard coded links will just make troubleshooting more difficult.

If you are not already, I'd recommend using one of the navigation plugins designed for Zen Cart as these will usually generate the correct links automatically (for enabled categories and products).

ElPoderoso15:

... Clicking on a product category link while on the online store with CEON URI mapping configured will display the home page. ...
Please disable automatically redirecting to the homepage when a page is not found. This will allow us to see if the problem is caused by CEON URI Mapping not recognizing your category URLs -or- caused by something else.

One can change the behavior to "Show a 404 Page" from the Zen Cart administrative interface. Once logged in select "Configuration" --> "My Store" and change the option for "Missing Page Check" to "Page Not Found".

lhungil:

Some other important questions to answer:
Which version of CEON URI Mapping you are attempting to install / configure?
Did you upgrade from a previous version of CEON URI Mapping?
Did you acquire your copy of CEON URI Mapping from this site? If you did not where did you acquire your copy from?
Are there any Zen Cart debug logs? If so, what are in the logs?
Are there any PHP / Server error logs? If so, what are in the logs?
Have you altered the .htaccess file generated by CEON URI Mapping? If so what did you modify?
Do the same issues occur when using the "classic" template included with Zen Cart 1.5?
I'm using version 4.4.1 of CEON URI Mapping.
Clean install, no upgrade.
Acquired module CEON from this site.
No debug logs.
No php/server errors.
Did not alter .htaccess file.

lhungil:

Can you make your "in-house" testing location public (on a different domain and perhaps with no-index configured)? This way a link could be provided to allow those reading the forums to see the described behavior while not impacting your "live" store.
The location is public. The online store is not live, it is a test site.

lhungil:

I am going to assume the "blue hover menu" is the main navigation in the header... If this is true, go back right now and replace all those hard coded "href" attributes with zen_href_link function calls. Hard coded links will just make troubleshooting more difficult.
OK, will do.

lhungil:

Please disable automatically redirecting to the homepage when a page is not found. This will allow us to see if the problem is caused by CEON URI Mapping not recognizing your category URLs -or- caused by something else.

One can change the behavior to "Show a 404 Page" from the Zen Cart administrative interface. Once logged in select "Configuration" --> "My Store" and change the option for "Missing Page Check" to "Page Not Found".
The site has that option already set to "Page Not Found". The home page displays as part of the behavior. If you try a bogus page like http://www.spellex.com/new/estore/internet-medical-spell-checkerxxx the page not found page is displayed. However trying to access a product category page with URI configured forwards to the home page.

Thanks again!

Hey guys, I'm currently have some trouble with this module. It was installed on our site and working correctly, but we recently updated our site and now the store, which was in the root directory of our website is now in a subdirectory (/shop/). However, because of this, I cannot get the category/product pages to display correctly. I have tried prepending the subdirectory to the rules in my rewrite map, as well as having the module generate a new sample mapping and then using that one. However, all I have been able to do is get every static URI to rewrite to the home page! Unfortunately, this is on a test site, so the live site, which is not using the updated site information, still works and can be found here. Again, this is the old, un-updated site that the module currently works on.

Helpful information:
Zencart Version: 1.5.0
Ceon URI Vesion: 4.2.0
Web server: IIS (Using a web.config for URL rewrites)
Output from Installation Check: All checks passed

Any help would be greatly appreciated!

ElPoderoso15:

... The site has that option already set to "Page Not Found". ... If you try a bogus page like http://www.spellex.com/new/estore/internet-medical-spell-checkerxxx the page not found page is displayed. However trying to access a product category page with URI configured forwards to the home page. ...
Please post the entire contents of your .htaccess file (change the admin folder references to "admin") wrapped by code tags (the # on the editing toolbar). Also make sure no .htaccess files exist in "/" or "/new/" (as they run before the rules in the "/new/estore/" folder and can cause problems).

P.S. Why does "/new/estore/" redirect to "/new/"? This may be one of the contributing factors!

Pheogia:

... was in the root directory of our website is now in a subdirectory (/shop/). ... However, all I have been able to do is get every static URI to rewrite to the home page! ...
If you are testing on the same domain as the live store, make sure all "redirects" or "rewrites" in the "/" folder exclude the path "/shop/".

P.S. Why does "/shop/" redirect to "/"? This may be one of the contributing factors!

Pheogia:

Hey guys, I'm currently have some trouble with this module. It was installed on our site and working correctly, but we recently updated our site and now the store, which was in the root directory of our website is now in a subdirectory (/shop/). However, because of this, I cannot get the category/product pages to display correctly. I have tried prepending the subdirectory to the rules in my rewrite map, as well as having the module generate a new sample mapping and then using that one. However, all I have been able to do is get every static URI to rewrite to the home page! Unfortunately, this is on a test site, so the live site, which is not using the updated site information, still works and can be found here. Again, this is the old, un-updated site that the module currently works on.

Helpful information:
Zencart Version: 1.5.0
Ceon URI Vesion: 4.2.0
Web server: IIS (Using a web.config for URL rewrites)
Output from Installation Check: All checks passed

Any help would be greatly appreciated!

I was actually able to fix my own problem and I wanted to post it here, in case it could help someone else. The problem with my site was that the HTTPS_SERVER and DIR_WS_CATALOG were actually being redefined in my includes/config-sites/sites_switch.php file (I'm not sure why). This redefinition actually defined the HTTPS_SERVER as including the /shop/ directory, which made all of the CEON URI Mapping URL's look right.

Once I changed this, all of the URL maps were going to https://www.driedinsects.com/remapping instead of https://www.driedinsects.com/shop/remapping. This caused me to go into the module configuration on the admin section and change the URI Mapping for my categories and products and the links then worked.

Pheogia:

I was actually able to fix my own problem and I wanted to post it here, in case it could help someone else. The problem with my site was that the HTTPS_SERVER and DIR_WS_CATALOG were actually being redefined in my includes/config-sites/sites_switch.php file (I'm not sure why). This redefinition actually defined the HTTPS_SERVER as including the /shop/ directory, which made all of the CEON URI Mapping URL's look right.

Once I changed this, all of the URL maps were going to https://www.driedinsects.com/remapping instead of https://www.driedinsects.com/shop/remapping. This caused me to go into the module configuration on the admin section and change the URI Mapping for my categories and products and the links then worked.

So it's clear to anyone following this thread the "includes/config-sites/sites_switch.php" is not part of this mod nor is it part of the default Zen Cart fileset..

lhungil:

Please post the entire contents of your .htaccess file (change the admin folder references to "admin") wrapped by code tags (the # on the editing toolbar). Also make sure no .htaccess files exist in "/" or "/new/" (as they run before the rules in the "/new/estore/" folder and can cause problems).

## BEGIN CEON URI MAPPING REWRITE RULE

RewriteEngine On

# ONLY rewrite URIs beginning with /new/estore/
RewriteCond %{REQUEST_URI} ^/new/estore/ [NC]
# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
RewriteCond %{REQUEST_URI} !\.[a-z]{2,5}$ [NC]
# Don't rewrite any URIs for some, popular specific file format extensions,
#   which are not covered by main file extension condition above
RewriteCond %{REQUEST_URI} !\.(mp3|mp4|h264)$ [NC]
# Don't rewrite any URIs for some specific file format extensions,
#   which are not covered by main file extension condition above
#   Uncomment the following line to apply this condition! (Remove the # at the start of the next line)
#RewriteCond %{REQUEST_URI} !\.(3gp|3g2|h261|h263|mj2|mjp2|mp4v|mpg4|m1v|m2v|m4u|f4v|m4v|3dml)$ [NC]
# Don't rewrite admin directory
RewriteCond %{REQUEST_URI} !^/new/estore/admin [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/new/estore/editors/ [NC]
# Don't rewrite font directory
RewriteCond %{REQUEST_URI} !^/new/estore/font/ [NC]
# Don't rewrite logs directory
RewriteCond %{REQUEST_URI} !^/new/estore/logs/ [NC]
# Don't rewrite temp directory
RewriteCond %{REQUEST_URI} !^/new/estore/temp/ [NC]
# Handle all other URIs using Zen Cart (its index.php)
RewriteRule .* /new/estore/index.php [QSA,L]

## END CEON URI MAPPING REWRITE RULE


<IfModule mod_rewrite.c>


    RewriteEngine On
#    RewriteBase /new/
RewriteCond %{REQUEST_URI} ^/new/ [NC]
	
    #Removes access to the system folder by users.
    #Additionally this will allow you to create a System.php controller,
    #previously this would not have been possible.
    #'system' can be replaced if you have renamed your system folder.	


    RewriteCond %{REQUEST_URI} ^system.*
    RewriteRule ^(.*)$ /index.php?/$1 [L]
    RewriteCond %{REQUEST_URI} ^application.*
    RewriteRule ^(.*)$ /index.php?/$1 [L]

    #Checks to see if the user is attempting to access a valid file,
    #such as an image or css document, if this isn't true it sends the
    #request to index.php

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
	RewriteRule ^(.*)$ index.php?/$1 [L]
	
</IfModule>


<IfModule !mod_rewrite.c>

    # If we don't have mod_rewrite installed, all 404's
    # can be sent to index.php, and everything works as normal.
    # Submitted by: ElliotHaughin

    #ErrorDocument 404 /index.php

</IfModule>  

The .htaccess has additional information to handle the root section (/new/) of the site. That section uses a CodeIgniter based solution. I've tried commenting out and even removing that portion with no luck.

lhungil:

P.S. Why does "/new/estore/" redirect to "/new/"? This may be one of the contributing factors!
I'm actually not sure where that setting is configured. I am not the original author of this project.

Thanks!

ElPoderoso15:

BEGIN CEON URI MAPPING REWRITE RULE

RewriteEngine On

ONLY rewrite URIs beginning with /new/estore/

RewriteCond %{REQUEST_URI} ^/new/estore/ [NC]

Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])

RewriteCond %{REQUEST_URI} !.[a-z]{2,5}$ [NC]

Don't rewrite any URIs for some, popular specific file format extensions,

which are not covered by main file extension condition above

RewriteCond %{REQUEST_URI} !.(mp3|mp4|h264)$ [NC]

Don't rewrite any URIs for some specific file format extensions,

which are not covered by main file extension condition above

Uncomment the following line to apply this condition! (Remove the # at the start of the next line)

#RewriteCond %{REQUEST_URI} !.(3gp|3g2|h261|h263|mj2|mjp2|mp4v|mpg4|m1v|m2v|m4u|f4v|m4v|3dml)$ [NC]

Don't rewrite admin directory

RewriteCond %{REQUEST_URI} !^/new/estore/admin [NC]

Don't rewrite editors directory

RewriteCond %{REQUEST_URI} !^/new/estore/editors/ [NC]

Don't rewrite font directory

RewriteCond %{REQUEST_URI} !^/new/estore/font/ [NC]

Don't rewrite logs directory

RewriteCond %{REQUEST_URI} !^/new/estore/logs/ [NC]

Don't rewrite temp directory

RewriteCond %{REQUEST_URI} !^/new/estore/temp/ [NC]

Handle all other URIs using Zen Cart (its index.php)

RewriteRule .* /new/estore/index.php [QSA,L]

END CEON URI MAPPING REWRITE RULE

RewriteEngine On

RewriteBase /new/

RewriteCond %{REQUEST_URI} ^/new/ [NC]

#Removes access to the system folder by users.
#Additionally this will allow you to create a System.php controller,
#previously this would not have been possible.
#'system' can be replaced if you have renamed your system folder.	


RewriteCond %{REQUEST_URI} ^system.*
RewriteRule ^(.*)$ /index.php?/$1 [L]
RewriteCond %{REQUEST_URI} ^application.*
RewriteRule ^(.*)$ /index.php?/$1 [L]

#Checks to see if the user is attempting to access a valid file,
#such as an image or css document, if this isn't true it sends the
#request to index.php

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?/$1 [L]

<IfModule !mod_rewrite.c>

# If we don't have mod_rewrite installed, all 404's
# can be sent to index.php, and everything works as normal.
# Submitted by: ElliotHaughin

#ErrorDocument 404 /index.php

Regarding the second question of new/estore redirecting tonew, it should be noticeable that the second rewrite group doesn't exclude new/estore and therefore ttempts to rewrite whatever result from the first rewrite in the second rewrite. (Perhaps another way to prevent it, but I would check that the uri is not new/estore), this does mean that in the "second" store, the path of estore can not/should not be used for any rewrites in the admin.)