-
Re: CEON URL working with Multi-language SEO URLs
As for the ezpage menu option pointing to the "right" location, we're back to what Diva Vocals pointed out. The Ez-page points internally to a uri. That uri is rewritten, CEON URI Mapping does not provide rewrite support for rewritten uris. Before anyone says I'm wrong, what I mean by that is if your ezpage redirects to site/index.php?main_page=specials, then the rewritten ez-page will show that as the link. But, if in the ezpage, you set the internal link to site/specials, then the rewritten ezpage will show that as the link... And it will then work as desired...
What I'm trying to get at is that if the last destination is something that needs to be translated by ceon uri mappings, and there are link after link embedded to get to that last link, the last link (or really the second from where the first link points) will not get translated. Only the link off of the current page is translated.
So again, in this case, go into your ezpage editor and change the link to which it goes from site/index.php?main_page=specials to site/specials. And done.
-
Re: CEON URL working with Multi-language SEO URLs
Quote:
Originally Posted by
pexter
URI= /specials
Language_id= 1
current_uri= 1
main_page= specials (it used to say "page" but I changed it just now to specials, the others still says page)
query_string_parameters= NULL
associated_db_id= 17
alternate_uri= NULL
redirection_type_code= NULL
date_added= (the date it was added)
Check the specials link again, it now points somewhere but the link addresses hasen't changed on the website, shouldn't the links automatically change to /specials /new-products etc...?
/Peter
From the readme
Quote:
- Use software such as PHPMyAdmin to add a new record to the ceon_uri_mapping table.
- The URI mapping to be mapped from should be entered in the uri field. (Remember to begin the URI with a slash ‘/’).
- The number representing the language ID this URI mapping applies for should be entered in the language_id field.
- The current_uri field should be set to “1” to make this the “current” URI.
- The Zen Cart page to be mapped to should be entered in the main_page field.
- The date/time this URI mapping was added should be set in the date_added field (or just use the “NOW()” SQL function).
- The query_string_parameters, associated_db_id and alternate_uri fields are not used, they must be left as “NULL”. The redirection_type_code is not used either so it doesn't matter what value it has (it can just be left at the default value of 301).
I don't know where/how you determined a value for or WHY you have an associated_db_id for the specials page, but my guess is THAT is the issue. Take that out.. what happens???
and if you haven't done so remove those EZ-Page redirects you created.
-
Re: CEON URL working with Multi-language SEO URLs
I have a couple of sites where I have utilized CEON URI Mapping. It works great except when Google caches web pages. For some reason, the CSS and JS links are broken and I'm assuming it has something to do with the rewrite rule, but just a guess. When the urls are basic such as www.domain.com/content, then Google caches it correctly. However, if another level is added to the url such as www.domain.com/content/more-content, this is where the caching becomes a problem. Does anyone have any ideas as to how to correct this? In advance, thanks.
Version used: 4.4.2
Zen Cart Version: 1.5.1
Effected URL: www.l i v i n g a v e n u e .com
Working cached page: https://l i v i n g a v e n u e .com/rick-warren
Working cached page at Google: http://webcache.googleusercontent.co...&ct=clnk&gl=us
Incorrect cached page: https://l i v i n g a v e n u e .com/introductory-logic-student/james-nance/1591280338
Incorrect cached page at Google: http://webcache.googleusercontent.co...&ct=clnk&gl=us
-
Re: CEON URL working with Multi-language SEO URLs
Quote:
Originally Posted by
DivaVocals
From the readme
I don't know where/how you determined a value for or WHY you have an associated_db_id for the specials page, but my guess is THAT is the issue. Take that out.. what happens???
and if you haven't done so remove those EZ-Page redirects you created.
The why has to do with the how... There is/was an entry for the ezpage to go to specials, that ezpage had a value of 17. When attempting to create a redirect for just main_page=specials, the instructions were only partially followed/understood and the associated_db_id was not properly set/nulled.
-
Re: CEON URL working with Multi-language SEO URLs
Quote:
Originally Posted by
DivaVocals
From the readme
I don't know where/how you determined a value for or WHY you have an associated_db_id for the specials page, but my guess is THAT is the issue. Take that out.. what happens???
and if you haven't done so remove those EZ-Page redirects you created.
Disregard that last part..
-
Re: CEON URL working with Multi-language SEO URLs
Quote:
Originally Posted by
mc12345678
The why has to do with the how... There is/was an entry for the ezpage to go to specials, that ezpage had a value of 17. When attempting to create a redirect for just main_page=specials, the instructions were only partially followed/understood and the associated_db_id was not properly set/nulled.
Right.. It was a rhetorical statement.. wasn't really looking for the logic behind the decision of adding a associated_db_id.. I posted the readme instructions to point out that it wasn't needed..
-
Re: CEON URL working with Multi-language SEO URLs
Quote:
Originally Posted by
jmcdougal
... For some reason, the CSS and JS links are broken and I'm assuming it has something to do with the rewrite rule, but just a guess. ...
It appears the "cached" page from October 17th, 2014 has an out of date base element (does not match the current site's base element as of November 10, 2014). The out of date / incorrect URL in the base element on the "cached" page is why the external CSS, JS, and images are not being loaded.
-
Re: CEON URL working with Multi-language SEO URLs
Quote:
Originally Posted by
lhungil
It appears the "cached" page from October 17th, 2014 has an out of date
base element (does not match the current site's base element as of November 10, 2014). The out of date / incorrect URL in the base element on the "cached" page is why the external CSS, JS, and images are not being loaded.
Thanks for the reply, but the base elements are indeed the same from the cached date and today. Are you possibly looking at the base element Google creates on the cached page? Thanks again.
-
Re: CEON URL working with Multi-language SEO URLs
Yay! It works! The associated_db_id was automatically created by CEON, but when I nulled it and changed the internal link in EZpages, it works.
However, I did immediately run into some problems when trying to fix the FAQs link... don't know why though, it must be something else, got a 404 so I have reverted it back to original until I find a solution.
Thanks everybody, great work! :D
-
Re: CEON URL working with Multi-language SEO URLs
Quote:
Originally Posted by
pexter
The associated_db_id was automatically created by CEON
Not by Ceon, but perhaps your mySQL editor added it??? In any case the readme instructions clearly state not to use it..
In any case glad you have it working now..
Quote:
Originally Posted by
pexter
However, I did immediately run into some problems when trying to fix the FAQs link... don't know why though, it must be something else, got a 404 so I have reverted it back to original until I find a solution.
Leaving it at the original is CORRECT (as per the EZ Page on page usage instructions) I wouldn't spend any time trying to "fix" that..
-
Re: CEON URL working with Multi-language SEO URLs
@jmcdougal
If Google is still not supporting retaining the base element for cached pages (instead of clobbering it with their own), you will need to apply the same fixes as were needed to handle images with the FaceBook OpenGraph crawler. Option #1 or Option #2 from that post are probably your best bet at this time.
For option #2: Most themes currently use page relative links instead of zen_href_link() when linking to a CSS or JS file. This needs to be changed in your theme as part of option #2. The file in most themes generating links to CSS and JS resources is: "/includes/templates/your_theme_name/common/html_header.php".
NOTE: "zen_href_link($page_relative_link, null, $request_type);" should work nicely as long as everything in "/includes/configure.php" is correct.
-
Re: CEON URL working with Multi-language SEO URLs
Quote:
Originally Posted by
lhungil
@jmcdougal
If Google is still not supporting retaining the base element for cached pages (instead of clobbering it with their own), you will need to apply
the same fixes as were needed to handle images with the FaceBook OpenGraph crawler. Option #1 or Option #2 from that post are probably your best bet at this time.
For option #2: Most themes currently use page relative links instead of zen_href_link() when linking to a CSS or JS file. This needs to be changed in your theme as part of option #2. The file in most themes generating links to CSS and JS resources is: "/includes/templates/your_theme_name/common/html_header.php".
NOTE: "zen_href_link($page_relative_link, null, $request_type);" should work nicely as long as everything in "/includes/configure.php" is correct.
Thanks again for your help. I wasn't able to reply until now, but I had tested absolute url paths on one of the css files shortly after making the original post and it worked. Again, thanks for the insight. I truly appreciate it.
-
Re: CEON URL working with Multi-language SEO URLs
Quote:
Originally Posted by
DivaVocals
Not by Ceon, but perhaps your mySQL editor added it??? In any case the readme instructions clearly state not to use it..
In any case glad you have it working now..
Leaving it at the original is CORRECT (as per the EZ Page on page usage instructions) I wouldn't spend any time trying to "fix" that..
It must have been CEON since the entry was already there the first time I looked in the DB and the entry points to the EZ page id number (like it would point to a product id number in the DB), so it must have been entered when I used the "automatically create URI..." in EZ pages.
-
Re: CEON URL working with Multi-language SEO URLs
Quote:
Originally Posted by
pexter
It must have been CEON since the entry was already there the first time I looked in the DB and the entry points to the EZ page id number (like it would point to a product id number in the DB), so it must have been entered when I used the "automatically create URI..." in EZ pages.
Right, but that is because you were trying to generate an invalid URI from your EZ Pages.. If you were to have entered these directly URI's in the DB (as suggested in the readme) this would not have happened..
-
Re: CEON URL working with Multi-language SEO URLs
Quote:
Originally Posted by
DivaVocals
Right, but that is because you were trying to generate an invalid URI from your EZ Pages.. If you were to have entered these directly URI's in the DB (as suggested in the readme) this would not have happened..
So I think that is recognized. The posting was made to clear up the fact that the number 17 was not entered manually, and therefore had been autogenerated by the plugin. Further there was no attempt at this point to generate a wrong uri, the attempt was to generate the entry to redirect using the documented process/information, but it was not accurately implemented. All rewrites being applied were being properly considered (a rewrite for the ezpage and a rewrite for the internal uri destination) but they were not properly integrated.
So, yes, had the OP already known the need for the ezpage to internally point to a rewritten URI and that URI had to already be rewritten through database entry in order to take advantage of that aspect, then the initial quuestioning would not have occurred to bring us to this conversation.
-
Re: CEON URL working with Multi-language SEO URLs
Quote:
Originally Posted by
mc12345678
So I think that is recognized. The posting was made to clear up the fact that the number 17 was not entered manually, and therefore had been autogenerated by the plugin. Further there was no attempt at this point to generate a wrong uri, the attempt was to generate the entry to redirect using the documented process/information, but it was not accurately implemented. All rewrites being applied were being properly considered (a rewrite for the ezpage and a rewrite for the internal uri destination) but they were not properly integrated.
Not to belabor this anymore, but my point was and still is that you CANNOT generate a URI for an EZ Page which is an internally linked page.. Conor had stated this many time in this support thread. I merely reiterated this point in response to the OP's original question.
Quote:
Originally Posted by
mc12345678
So, yes, had the OP already known the need for the ezpage to internally point to a rewritten URI and that URI had to already be rewritten through database entry in order to take advantage of that aspect, then the initial quuestioning would not have occurred to bring us to this conversation.
The OP does not need for the EZ Page internal link to be the rewritten URI at all. If one wants, you CAN in fact use the native internal link. Alternatively, yes you can use the correct URI. In either case you should not attempt to generate an EZ Page URI, and instead manually add the URI to the DB following the instructions in the readme. If you do use the native page link instead of the rewritten URI, you will find that Ceon URI will apply it's magic to the EZ Page header or footer menu links and direct visitors to the correct URI.
-
Re: CEON URL working with Multi-language SEO URLs
Hi,
http://www.****.com/index.php?main_page=products_all now turned to http://www.****.com/all-products
but when i open http://www.****.com/all-products in my browser, there is nothing, while open http://www.****.com/index.php?main_page=products_all,
it shows all my products...i don't know what is going on ? Can someone help ? thank you.
-
Re: CEON URL working with Multi-language SEO URLs
Quote:
Originally Posted by
jemmylien
1.
sorry, this problem has been solved, i think it is because i wrote wrong in the phpmyadmin, now it works.
http://www.***.com/index.php?main_page=reviews changed to http://www.***.com/reviews
but in the source file, the link is still http://www.***.com/index.php?main_page=reviews, it there any thing can do to change it to http://www.***.com/reviews ?
2.
All my products' links are www.***.com/greenpant?cPath=1_33& , with a "?cPath=1_33&" at the end.
how to remove ?cPath=1_33&...
3.
For all products show, its link is www.***.com/all-products?disp_order=1&page=2
how can i set the rule in phpmyadmin to map it ?
Thank you,
-
Re: CEON URL working with Multi-language SEO URLs
Quote:
Originally Posted by
jemmylien
To answer #1, you need to provide an ACTUAL link to your site.. otherwise we'll ALL be guessing.. The contents of your .htaccess file wouldn't hurt either.. Please use the code tag on the toolbar (the # symbol) to enclose your code.. (makes it easier to read, and stops the forum software from parsing your code)
The answers to 2 & 3 are covered in the readme document..
From the reame document (installation tab)
Quote:
OPTIONAL but RECOMMENDED Take a note of the FAQs
Lots of people ask us the same questions. It's worth reading the FAQs.
At the very least, here are some of the most popular questions that are covered.
Re #3 - Short answer is that products with sub-categories will ALWAYS display this way.. The readme covers WHY (Item #9 of the FAQs), and if you search this thread you will see that this frequently asked question has been addressed by the late author and others..
Re #4 - Again this is covered in the readme Module Features --> Canonical URIs
-
Re: Ceon URI Mapping v4.x
I'm on a fresh new install of v. 1.53 and on the latest versions of PHP and MySQL. My zencart developer found a conflict between this mod and Fast and Easy Checkout and the checkout does not work and she said I needed to hire a programmer. I'd like to use both mods. Has anyone else had this issue and was able to solve it? www.enlita.com/shop
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
drpearsall
I'm on a fresh new install of v. 1.53 and on the latest versions of PHP and MySQL. My zencart developer found a conflict between this mod and Fast and Easy Checkout and the checkout does not work and she said I needed to hire a programmer. I'd like to use both mods. Has anyone else had this issue and was able to solve it?
www.enlita.com/shop
Well except you don't say what "this issue" is.. Saying there is a conflict with this module and Fast and Easy doesn't really give and indication as to what kind of issue you are having.. What part of the checkout doesn't work?? Why do you think it's an issue with this module and not something with Fats & Easy??? Why does your web developer say you need to hire a programmer?? What does your web developer think this programmer needs to do???
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
DivaVocals
Well except you don't say what "this issue" is.. Saying there is a conflict with this module and Fast and Easy doesn't really give and indication as to what kind of issue you are having.. What part of the checkout doesn't work?? Why do you think it's an issue with this module and not something with Fats & Easy??? Why does your web developer say you need to hire a programmer?? What does your web developer think this programmer needs to do???
I have used CEON both with the free and the paid version of FEAC, and there never was a problem. I think it is safe to say the problem lies somewhere else, and not in the compatibility between the two mods.
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
Design75
I have used CEON both with the free and the paid version of FEAC, and there never was a problem. I think it is safe to say the problem lies somewhere else, and not in the compatibility between the two mods.
I agree.. I think a LOT more detail on the exact nature of the issue will reveal that this is indeed the case here..
-
Re: Ceon URI Mapping v4.x
Hi I will get all the details from my Zencart helper. I'm sorry for the incomplete post and will correct this today.
-
Re: Ceon URI Mapping v4.x
v.1.3.9h
Hello,
There is a known issue with Ultimate SEO URLS and FEC. I have both installed and have had to turn of Ultimate for checkout to work.
Question - can I install CEON URI Mapping module (which does not have any compatibility issues with FEC) without uninstalling Ultimate?, i.e. just leave Ultimate turned off and use Ceon?
cheers, Mike
-
Re: Ceon URI Mapping v4.x
Given that folks have both FEC and Ultimate. SEO working together says that there isn't a KNOWN issue or the author of Ultimate SEO would have included instructions to mitigate a KNOWN issue..(as he HAS indeed done before)
To answer your question, no you cannot install BOTH Ceon URI and Ultimate. SEO together..
Quote:
Originally Posted by
shags38
v.1.3.9h
Hello,
There is a known issue with Ultimate SEO URLS and FEC. I have both installed and have had to turn of Ultimate for checkout to work.
Question - can I install CEON URI Mapping module (which does not have any compatibility issues with FEC) without uninstalling Ultimate?, i.e. just leave Ultimate turned off and use Ceon?
cheers, Mike
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
DivaVocals
Given that folks have both FEC and Ultimate. SEO working together says that there isn't a KNOWN issue or the author of Ultimate SEO would have included instructions to mitigate a KNOWN issue..(as he HAS indeed done before)
To answer your question, no you cannot install BOTH Ceon URI and Ultimate. SEO together..
Minor correction, they can be "installed" with the intent of replacing one with the other. They can't both be fully installed for normal operation.
Besides why would one want to leave code behind that does not serve a functional purpose. There are instructions that indicate it is possible to convert from another URI rewriter to CEON URI Mappings by keeping the other rewriter active while transitioning to CEON URI Mappings.
I thought also that USU used .htaccess rules so there would more than likely end up being a conflict of some type anyways to have both fully setup at the same time.
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
DivaVocals
Given that folks have both FEC and Ultimate. SEO working together says that there isn't a KNOWN issue or the author of Ultimate SEO would have included instructions to mitigate a KNOWN issue..(as he HAS indeed done before)
To answer your question, no you cannot install BOTH Ceon URI and Ultimate. SEO together..
Hello Diva,
There IS INDEED an issue with Ultimate SEO and FEC evidenced by days of dialogue on forums and according to everyone else, including Numinix AND ihungil, author of the plugin. Obviously you have not used both plugins on site.
cheers, Mike
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
mc12345678
Minor correction, they can be "installed" with the intent of replacing one with the other. They can't both be fully installed for normal operation.
Besides why would one want to leave code behind that does not serve a functional purpose. There are instructions that indicate it is possible to convert from another URI rewriter to CEON URI Mappings by keeping the other rewriter active while transitioning to CEON URI Mappings.
I thought also that USU used .htaccess rules so there would more than likely end up being a conflict of some type anyways to have both fully setup at the same time.
Thanks for the informative response, pretty much confirms what I expected but thought I would ask the question anyway - if I do install CEON I will be deleting Ultimate after the successful working of CEON with FEC on my site :). Firstly though I will seek a solution with Ultimate.
cheers, Mike
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
shags38
Thanks for the informative response, pretty much confirms what I expected but thought I would ask the question anyway - if I do install CEON I will be deleting Ultimate after the successful working of CEON with FEC on my site :). Firstly though I will seek a solution with Ultimate.
cheers, Mike
Technically and to prevent one from inaccurately saying "this doesn't work with that", the desired test should be run on a test site (non-production) before swapping back and forth and further claiming the success/failure of one with another. Sometimes it really is just a setup/install issue, but that is something to address on the other forum thread.
Be advised that swapping to CEON URI Mapping on an existing store will require some form of work to give/assign rewritten URIs to all of the existing products.
-
Re: Ceon URI Mapping v4.x
Correct, one should not have multiple "alternative" URL modules installed. One could leave the Ultimate URLs .htaccess in place (before the CEON rules), but doing so will probably cause unneccessary redirects. As part of switching - One would want to enter the old (Ultimate) URLs into the CEON URI database.
Quote:
Originally Posted by
shags38
Hello Diva,
There IS INDEED an issue with Ultimate SEO and FEC evidenced by days of dialogue on forums and according to everyone else, including Numinix AND ihungil, author of the plugin. Obviously you have not used both plugins on site.
cheers, Mike
Actually both Ultimate URLs and FEC can operate together. I've posted on this topic before and Diva is one of the contributors who helped narrow down the issue (caused by Numinix altering the default Zen Cart administrative configuration flow - and - Ultimate URLs depending on the stock Zen Cart administrative page for managing configuration options). They are not incompatible with the appropriate patches to the Numinex code installed.
Any further discussion on the topic of Ultimate URLs and Numinix modifications to the Zen Cart administrative configuration process does not belong in the CEON URI thread, but over at the Ultimate URLs (or FEC) support threads.
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
lhungil
Correct, one should not have multiple "alternative" URL modules installed. One could leave the Ultimate URLs .htaccess in place (before the CEON rules), but doing so will probably cause unneccessary redirects. As part of switching - One would want to enter the old (Ultimate) URLs into the CEON URI database.
Actually both Ultimate URLs and FEC can operate together. I've posted on this topic before and Diva is one of the contributors who helped narrow down the issue (caused by Numinix altering the default Zen Cart administrative configuration flow - and - Ultimate URLs depending on the stock Zen Cart administrative page for managing configuration options). They are not incompatible with the appropriate patches to the Numinex code installed.
Any further discussion on the topic of Ultimate URLs and Numinix modifications to the Zen Cart administrative configuration process does not belong in the CEON URI thread, but over at the Ultimate URLs (or FEC) support threads.
BOOM! But what the heck do I know since I've "obviously" never used these two together...
-
Re: Ceon URI Mapping v4.x
Hi all, Ive recently migrated a ZC site from one server to another using the transfer tool. Currently the site, after this transfer, cannot access the admin folder, or /blog. /blog/wp-admin does work though. /admin/login.php gives a blank page and /admin/ gives a 500.shtml error page not found.
What could I check here? The new server is using php 5.3 same as the old, ZC is 1.39h. Ive tried renaming the htaccess files in root and admin but with no success. It looks to me like CEON is the cause but cant say for sure. Perhaps theres a way to disable it via phpmyadmin?
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
Chargin
Hi all, Ive recently migrated a ZC site from one server to another using the transfer tool. Currently the site, after this transfer, cannot access the admin folder, or /blog. /blog/wp-admin does work though. /admin/login.php gives a blank page and /admin/ gives a 500.shtml error page not found.
What could I check here? The new server is using php 5.3 same as the old, ZC is 1.39h. Ive tried renaming the htaccess files in root and admin but with no success. It looks to me like CEON is the cause but cant say for sure. Perhaps theres a way to disable it via phpmyadmin?
Well its all fixed, turns out it was php being at 5.3 and zend was not enabled. Nothing to do with CEON!
-
Re: Ceon URI Mapping v4.x
First of all, I have had this module installed for several years, so my server host does have the required specifications.
Now I have created a fresh install of zc 153 and I am trying to install this module again.
I have uploaded all the files. When I try to log into admin I get a blank page 500, error.
If I upload all the backup files the same error occurs.
If I delete all the CEON- files in admin and upload the backup files, I am able to log in to admin again.
Any suggestions to what may be the problem?
ps: I can't link to the page with the problem because its a live environment so I had to delete the module to be able to use admin.
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
panservolvo
First of all, I have had this module installed for several years, so my server host does have the required specifications.
Now I have created a fresh install of zc 153 and I am trying to install this module again.
I have uploaded all the files. When I try to log into admin I get a blank page 500, error.
If I upload all the backup files the same error occurs.
If I delete all the CEON- files in admin and upload the backup files, I am able to log in to admin again.
Any suggestions to what may be the problem?
ps: I can't link to the page with the problem because its a live environment so I had to delete the module to be able to use admin.
Is the admiin folder the same now as it was/covered in your .htaccess file? How did you do your upgrade, etc...(Fom the posting guidelines.)
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
mc12345678
Is the admiin folder the same now as it was/covered in your .htaccess file? How did you do your upgrade, etc...(Fom the posting guidelines.)
admin folder has the same name as the old folder had.
I did not upgrade, I ran a complete new install of 153.
The .htaccess is from the old 150 istallation though.
here is the rewrite part from the .htaccess
Code:
# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
RewriteCond %{REQUEST_URI} !\.[a-z]{2,5}$ [NC]
# Don't rewrite admin directory
RewriteCond %{REQUEST_URI} !^/MyAdminFolder [NC]
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
panservolvo
ps: I can't link to the page with the problem because its a live environment so I had to delete the module to be able to use admin.
Two things..
1. NEVER upgrade your live site.. ALWAYS ALWAYS create a development site which is a clone of your live site (the recommended upgrade path)
2. Not sure what HARM you think will come from posting the site URL, but it will certainly assist the community in helping you with your issue. If you are concerned about the search engines picking it up, then OBSCURE the URL.. (e.g. http://yoursite(dot)com)
Quote:
Originally Posted by
panservolvo
admin folder has the same name as the old folder had.
I did not upgrade, I ran a complete new install of 153.
The .htaccess is from the old 150 istallation though.
here is the rewrite part from the .htaccess
Code:
# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
RewriteCond %{REQUEST_URI} !\.[a-z]{2,5}$ [NC]
# Don't rewrite admin directory
RewriteCond %{REQUEST_URI} !^/MyAdminFolder [NC]
Post the WHOLE file contents please.. it will speed things along here so folks won't have to keep lobbing guesses at you..
-
Re: Ceon URI Mapping v4.x
1: I did not upgrade a live site, i had a dev site which I now have live
2: no harm in posting the site url, but as I said I have rolled back to my backup to have a working admin. In other words, no CEON URI and no error now
3:
Code:
#
# @copyright Copyright 2003-2010 Zen Cart Development Team
# @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
# @version $Id: .htaccess 18695 2011-05-04 05:24:19Z drbyte $
#
# This is used with Apache WebServers
#
# The following blocks direct HTTP requests to all filetypes in this directory recursively, except certain approved exceptions
# It also prevents the ability of any scripts to run. No type of script, be it PHP, PERL or whatever, can normally be executed if ExecCGI is disabled.
# Will also prevent people from seeing what is in the dir. and any sub-directories
#
# For this to work, you must include either 'All' or at least: 'Limit' and 'Indexes' parameters to the AllowOverride configuration in your apache/conf/httpd.conf file.
# Additionally, if you want the added protection offered by the OPTIONS directive below, you'll need to add 'Options' to the AllowOverride list, if 'All' is not specified.
# Example:
#<Directory "/usr/local/apache/htdocs">
# AllowOverride Limit Options Indexes
#</Directory>
###############################
##ROOT##
ExpiresActive On
ExpiresByType text/css "access plus 500 days"
ExpiresByType application/javascript "access plus 500 days"
<Files stylesheet.css>
ExpiresByType text/css "access plus 350 days"
</Files>
<FilesMatch \.(swf)$>
ExpiresDefault "access plus 700 days"
</FilesMatch>
<FilesMatch \.(svg)$>
ExpiresDefault "access plus 3000 days"
</FilesMatch>
ExpiresByType image/gif "access plus 1500 days"
ExpiresByType image/jpg "access plus 1500 days"
ExpiresByType image/jpeg "access plus 1500 days"
ExpiresByType image/png "access plus 1500 days"
ExpiresByType image/bmp "access plus 1500 days"
# 48 weeks
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf|JPG|woff)$">
Header set Cache-Control "max-age=29030400, public"
</FilesMatch>
<files *>
order allow,deny
deny from 80.212.29.94
deny from 74.50.57.39
deny from 24.189.60.120
deny from 84.17.15.2
deny from 211.167.110.2
deny from 91.201.64.26
deny from 65.208.189
deny from 65.211.195
#deny from 195.1.61
allow from all
</files>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^madasahatter.no$ [NC]
RewriteRule ^(.*)$ http://madasahatter.no/$1 [L,R=301]
# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
RewriteCond %{REQUEST_URI} !\.[a-z]{2,5}$ [NC]
# Don't rewrite admin directory
RewriteCond %{REQUEST_URI} !^/MyAdminFolder [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/editors [NC]
# Don't rewrite cPanel directories
RewriteCond %{REQUEST_URI} !/cpanel [NC]
RewriteCond %{REQUEST_URI} !/frontend [NC]
# Don't rewrite ajax directory
RewriteCond %{REQUEST_URI} !^/ajax/ [NC]
# Don't rewrite bmz_cache directory
RewriteCond %{REQUEST_URI} !^/bmz_cache/ [NC]
# Handle all other URIs using Zen Cart (index.php)
# RewriteRule .* index.php?%{QUERY_STRING} [L]
RewriteCond %{HTTP_HOST} ^maah.no$ [OR]
RewriteCond %{HTTP_HOST} ^www.maah.no$
RewriteRule ^/?$ "http\:\/\/madasahatter\.no\/" [R=301,L]
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
panservolvo
1: I did not upgrade a live site, i had a dev site which I now have live
2: no harm in posting the site url, but as I said I have rolled back to my backup to have a working admin. In other words, no CEON URI and no error now
3:
Code:
#
# @copyright Copyright 2003-2010 Zen Cart Development Team
# @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
# @version $Id: .htaccess 18695 2011-05-04 05:24:19Z drbyte $
#
# This is used with Apache WebServers
#
# The following blocks direct HTTP requests to all filetypes in this directory recursively, except certain approved exceptions
# It also prevents the ability of any scripts to run. No type of script, be it PHP, PERL or whatever, can normally be executed if ExecCGI is disabled.
# Will also prevent people from seeing what is in the dir. and any sub-directories
#
# For this to work, you must include either 'All' or at least: 'Limit' and 'Indexes' parameters to the AllowOverride configuration in your apache/conf/httpd.conf file.
# Additionally, if you want the added protection offered by the OPTIONS directive below, you'll need to add 'Options' to the AllowOverride list, if 'All' is not specified.
# Example:
#<Directory "/usr/local/apache/htdocs">
# AllowOverride Limit Options Indexes
#</Directory>
###############################
##ROOT##
ExpiresActive On
ExpiresByType text/css "access plus 500 days"
ExpiresByType application/javascript "access plus 500 days"
<Files stylesheet.css>
ExpiresByType text/css "access plus 350 days"
</Files>
<FilesMatch \.(swf)$>
ExpiresDefault "access plus 700 days"
</FilesMatch>
<FilesMatch \.(svg)$>
ExpiresDefault "access plus 3000 days"
</FilesMatch>
ExpiresByType image/gif "access plus 1500 days"
ExpiresByType image/jpg "access plus 1500 days"
ExpiresByType image/jpeg "access plus 1500 days"
ExpiresByType image/png "access plus 1500 days"
ExpiresByType image/bmp "access plus 1500 days"
# 48 weeks
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf|JPG|woff)$">
Header set Cache-Control "max-age=29030400, public"
</FilesMatch>
<files *>
order allow,deny
deny from 80.212.29.94
deny from 74.50.57.39
deny from 24.189.60.120
deny from 84.17.15.2
deny from 211.167.110.2
deny from 91.201.64.26
deny from 65.208.189
deny from 65.211.195
#deny from 195.1.61
allow from all
</files>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^madasahatter.no$ [NC]
RewriteRule ^(.*)$ http://madasahatter.no/$1 [L,R=301]
# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
RewriteCond %{REQUEST_URI} !\.[a-z]{2,5}$ [NC]
# Don't rewrite admin directory
RewriteCond %{REQUEST_URI} !^/MyAdminFolder [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/editors [NC]
# Don't rewrite cPanel directories
RewriteCond %{REQUEST_URI} !/cpanel [NC]
RewriteCond %{REQUEST_URI} !/frontend [NC]
# Don't rewrite ajax directory
RewriteCond %{REQUEST_URI} !^/ajax/ [NC]
# Don't rewrite bmz_cache directory
RewriteCond %{REQUEST_URI} !^/bmz_cache/ [NC]
# Handle all other URIs using Zen Cart (index.php)
# RewriteRule .* index.php?%{QUERY_STRING} [L]
RewriteCond %{HTTP_HOST} ^maah.no$ [OR]
RewriteCond %{HTTP_HOST} ^www.maah.no$
RewriteRule ^/?$ "http\:\/\/madasahatter\.no\/" [R=301,L]
And this is working on the live site? Almost wonder how, all server references are rewritten to not be maah.no therefore it appears that the CEON rewriterule is never respected...
Also, by having two versions of the site, are they both on the same host? Is the .htaccess above in some way conflicting with another rule, or the setup?
Fyi, I thought the reason not to post the "link" wasbecause the problem appeared in the admin and didn't want to post the admin path which is appropriate not to post... Certainly might be able to gain some insight into the store side from having the information (which is now provided it would seem.)
-
Re: Ceon URI Mapping v4.x
the maah-part is there because the maah.no is just a "shortcut" to madasahatter.no if you type maah.no you instantly get redirected to madasahatter.no
this is set up in cpanel.
the admin-folder is not the same as in the htaccess i posted over, I changed the name for security reasons
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
panservolvo
the maah-part is there because the maah.no is just a "shortcut" to madasahatter.no if you type maah.no you instantly get redirected to madasahatter.no
this is set up in cpanel.
the admin-folder is not the same as in the htaccess i posted over, I changed the name for security reasons
Understood about the rename of the admin folder in the .htaccess (appropriate action for posting it) andunderstood that the maah.no uri gets rewritten before the ceon rewrite, but a problem is that the ceon rewrite expects the uri to contain either of the two hosts that contain maah in them. At the point this portion of the .htaccess is performed the host name should have already been rewritten and therefore the ceon rewrite never successfully rewrites if I am correct.
-
Re: Ceon URI Mapping v4.x
I dont quite get what you're saing.
If I type madasahatter.no/myAdmin the ceon will never "see" the maah-domain, and htaccess is saying dont rewrite /myAdmin.
the maah is strictly for use as a shortcut name, nothing else
-
Re: Ceon URI Mapping v4.x
I found out what was causing the error.. Besides myself...
I had forgotten to change from the dev environtment path in the admin/includes/configuration.php
-
Re: Ceon URI Mapping v4.x
What I'm saying is that for the arrangement that you have, the .htaccess should look like below.
Reason: between rewriteconds each rewriterule is evaluated. If a rewriterule is false, then the rewritecond is not performed. Because yours has/had a check for the host_name being maah.no, then that evaluates as false every time because of the previous rewrite to make all http_host values to be madasahatter. Therefore the rewritecond never executes. In the case of trying to access the admin directory and although that issue was for another reason, the rewritecond is also not met and not performed whiich is by design. Assuming that there is no data currently to perform the rewrite (brand new install without transferring the previous database that had this plugin installed) then the issue would not have been identified until the first rewrite was entered/tested.
I'm somewhat assuming though that you did rebuild your site using your previous database and unless you disabled this plugin before upgrading the ceon tables are still present and technically the rewrites should be happening now as we speak (provided that the .htaccess directs the rewrite).
Code:
#
# @copyright Copyright 2003-2010 Zen Cart Development Team
# @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
# @version $Id: .htaccess 18695 2011-05-04 05:24:19Z drbyte $
#
# This is used with Apache WebServers
#
# The following blocks direct HTTP requests to all filetypes in this directory recursively, except certain approved exceptions
# It also prevents the ability of any scripts to run. No type of script, be it PHP, PERL or whatever, can normally be executed if ExecCGI is disabled.
# Will also prevent people from seeing what is in the dir. and any sub-directories
#
# For this to work, you must include either 'All' or at least: 'Limit' and 'Indexes' parameters to the AllowOverride configuration in your apache/conf/httpd.conf file.
# Additionally, if you want the added protection offered by the OPTIONS directive below, you'll need to add 'Options' to the AllowOverride list, if 'All' is not specified.
# Example:
#<Directory "/usr/local/apache/htdocs">
# AllowOverride Limit Options Indexes
#</Directory>
###############################
##ROOT##
ExpiresActive On
ExpiresByType text/css "access plus 500 days"
ExpiresByType application/javascript "access plus 500 days"
<Files stylesheet.css>
ExpiresByType text/css "access plus 350 days"
</Files>
<FilesMatch \.(swf)$>
ExpiresDefault "access plus 700 days"
</FilesMatch>
<FilesMatch \.(svg)$>
ExpiresDefault "access plus 3000 days"
</FilesMatch>
ExpiresByType image/gif "access plus 1500 days"
ExpiresByType image/jpg "access plus 1500 days"
ExpiresByType image/jpeg "access plus 1500 days"
ExpiresByType image/png "access plus 1500 days"
ExpiresByType image/bmp "access plus 1500 days"
# 48 weeks
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf|JPG|woff)$">
Header set Cache-Control "max-age=29030400, public"
</FilesMatch>
<files *>
order allow,deny
deny from 80.212.29.94
deny from 74.50.57.39
deny from 24.189.60.120
deny from 84.17.15.2
deny from 211.167.110.2
deny from 91.201.64.26
deny from 65.208.189
deny from 65.211.195
#deny from 195.1.61
allow from all
</files>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^madasahatter.no$ [NC]
RewriteRule ^(.*)$ http://madasahatter.no/$1 [L,R=301]
# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
RewriteCond %{REQUEST_URI} !\.[a-z]{2,5}$ [NC]
# Don't rewrite admin directory
RewriteCond %{REQUEST_URI} !^/MyAdminFolder [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/editors [NC]
# Don't rewrite cPanel directories
RewriteCond %{REQUEST_URI} !/cpanel [NC]
RewriteCond %{REQUEST_URI} !/frontend [NC]
# Don't rewrite ajax directory
RewriteCond %{REQUEST_URI} !^/ajax/ [NC]
# Don't rewrite bmz_cache directory
RewriteCond %{REQUEST_URI} !^/bmz_cache/ [NC]
# Handle all other URIs using Zen Cart (index.php)
# RewriteRule .* index.php?%{QUERY_STRING} [L]
RewriteRule ^/?$ "http\:\/\/madasahatter\.no\/" [R=301,L]
-
Re: Ceon URI Mapping v4.x
Thanks for helping out. Your rewrite part didnt work, probably because of the # before the .* index.php?
I have changed my rewrite part to this and its working.
Any comments?
Code:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^madasahatter.no$ [NC]
RewriteRule ^(.*)$ http://madasahatter.no/$1 [L,R=301]
## BEGIN CEON URI MAPPING REWRITE RULE
# 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} !^/SuperSecretAdminPath [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/editors/ [NC]
# Don't rewrite logs directory
RewriteCond %{REQUEST_URI} !^/logs/ [NC]
# Don't rewrite bmz_cache directory
RewriteCond %{REQUEST_URI} !^/bmz_cache/ [NC]
# Don't rewrite min directory
RewriteCond %{REQUEST_URI} !^/min/ [NC]
# Handle all other URIs using Zen Cart (its index.php)
RewriteRule .* index.php [QSA,L]
-
Re: Ceon URI Mapping v4.x
First is that in many places I had the wrong statement (corrected below in red).
Quote:
Originally Posted by
mc12345678
What I'm saying is that for the arrangement that you have, the .htaccess should look like below.
Reason: between rewrite
rules each rewrite
cond is evaluated. If a rewrite
cond is false, then the rewrite
rule is not performed. Because yours has/had a check for the host_name being maah.no, then that evaluates as false every time because of the previous rewrite to make all http_host values to be madasahatter. Therefore the rewrite
rule never executes. In the case of trying to access the admin directory and although that issue was for another reason, the rewritecond is also not met and not performed which is by design. Assuming that there is no data currently to perform the rewrite (brand new install without transferring the previous database that had this plugin installed) then the issue would not have been identified until the first rewrite was entered/tested.
I'm somewhat assuming though that you did rebuild your site using your previous database and unless you disabled this plugin before upgrading the ceon tables are still present and technically the rewrites should be happening now as we speak (provided that the .htaccess directs the rewrite).
Code:
#
# @copyright Copyright 2003-2010 Zen Cart Development Team
# @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
# @version $Id: .htaccess 18695 2011-05-04 05:24:19Z drbyte $
#
# This is used with Apache WebServers
#
# The following blocks direct HTTP requests to all filetypes in this directory recursively, except certain approved exceptions
# It also prevents the ability of any scripts to run. No type of script, be it PHP, PERL or whatever, can normally be executed if ExecCGI is disabled.
# Will also prevent people from seeing what is in the dir. and any sub-directories
#
# For this to work, you must include either 'All' or at least: 'Limit' and 'Indexes' parameters to the AllowOverride configuration in your apache/conf/httpd.conf file.
# Additionally, if you want the added protection offered by the OPTIONS directive below, you'll need to add 'Options' to the AllowOverride list, if 'All' is not specified.
# Example:
#<Directory "/usr/local/apache/htdocs">
# AllowOverride Limit Options Indexes
#</Directory>
###############################
##ROOT##
ExpiresActive On
ExpiresByType text/css "access plus 500 days"
ExpiresByType application/javascript "access plus 500 days"
<Files stylesheet.css>
ExpiresByType text/css "access plus 350 days"
</Files>
<FilesMatch \.(swf)$>
ExpiresDefault "access plus 700 days"
</FilesMatch>
<FilesMatch \.(svg)$>
ExpiresDefault "access plus 3000 days"
</FilesMatch>
ExpiresByType image/gif "access plus 1500 days"
ExpiresByType image/jpg "access plus 1500 days"
ExpiresByType image/jpeg "access plus 1500 days"
ExpiresByType image/png "access plus 1500 days"
ExpiresByType image/bmp "access plus 1500 days"
# 48 weeks
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf|JPG|woff)$">
Header set Cache-Control "max-age=29030400, public"
</FilesMatch>
<files *>
order allow,deny
deny from 80.212.29.94
deny from 74.50.57.39
deny from 24.189.60.120
deny from 84.17.15.2
deny from 211.167.110.2
deny from 91.201.64.26
deny from 65.208.189
deny from 65.211.195
#deny from 195.1.61
allow from all
</files>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^madasahatter.no$ [NC]
RewriteRule ^(.*)$ http://madasahatter.no/$1 [L,R=301]
# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
RewriteCond %{REQUEST_URI} !\.[a-z]{2,5}$ [NC]
# Don't rewrite admin directory
RewriteCond %{REQUEST_URI} !^/MyAdminFolder [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/editors [NC]
# Don't rewrite cPanel directories
RewriteCond %{REQUEST_URI} !/cpanel [NC]
RewriteCond %{REQUEST_URI} !/frontend [NC]
# Don't rewrite ajax directory
RewriteCond %{REQUEST_URI} !^/ajax/ [NC]
# Don't rewrite bmz_cache directory
RewriteCond %{REQUEST_URI} !^/bmz_cache/ [NC]
# Handle all other URIs using Zen Cart (index.php)
# RewriteRule .* index.php?%{QUERY_STRING} [L]
RewriteRule ^/?$ "http\:\/\/madasahatter\.no\/" [R=301,L]
Quote:
Originally Posted by
panservolvo
Thanks for helping out. Your rewrite part didnt work, probably because of the # before the .* index.php?
I have changed my rewrite part to this and its working.
Any comments?
Code:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^madasahatter.no$ [NC]
RewriteRule ^(.*)$ http://madasahatter.no/$1 [L,R=301]
## BEGIN CEON URI MAPPING REWRITE RULE
# 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} !^/SuperSecretAdminPath [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/editors/ [NC]
# Don't rewrite logs directory
RewriteCond %{REQUEST_URI} !^/logs/ [NC]
# Don't rewrite bmz_cache directory
RewriteCond %{REQUEST_URI} !^/bmz_cache/ [NC]
# Don't rewrite min directory
RewriteCond %{REQUEST_URI} !^/min/ [NC]
# Handle all other URIs using Zen Cart (its index.php)
RewriteRule .* index.php [QSA,L]
As to the above new rewrite rule, I do not currently have an answer as I am unable to review an existing functional version to determine if the .htaccess conditions and rules are correct. Suggest though using the admin tool to autogenerate the htaccess rules to validate.
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
panservolvo
Thanks for helping out. ... I have changed my rewrite part to this and its working. ...
I would recommend removing the directive "RewriteBase /" (not needed, just increases processing time).
If after removing the other directives from the .htaccess file (like the example) everything works, most likely the new hosting provider does not support one those removed directives. When a directive is found in a .htaccess file and has been disabled or disallowed by the server configuration, it often results in a HTTP 500. There should be records in the server's error log indicating the cause of the HTTP 500.
-
Re: Ceon URI Mapping v4.x
Hi, we are using this module on a site that is also using a Google Sitemap XML file generator plugin.
Our output file is only giving us the old, standard Zen Cart product ID URL - which Google really doesn't like inside XML sitemaps as it requires a 200 response header rather than a 301.
The documentation states that the module deals with this and how to set it up, but the output is only ever the same, with the original URL.
Is there anyway to pull the new URL out (generated by CEON module) and input it into the Sitemap XML file? The info should be inside the database somewhere...
Cheers,
dp
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
dp-web
Hi, we are using this module on a site that is also using a Google Sitemap XML file generator plugin.
Our output file is only giving us the old, standard Zen Cart product ID URL - which Google really doesn't like inside XML sitemaps as it requires a 200 response header rather than a 301.
The documentation states that the module deals with this and how to set it up, but the output is only ever the same, with the original URL.
Is there anyway to pull the new URL out (generated by CEON module) and input it into the Sitemap XML file? The info should be inside the database somewhere...
Cheers,
dp
Verify your installation of both products, as we are using the same and have no issues... XML files reflect the rewritten URLs. Also, helps to identify the version(s) of the software, but this may be something to address in the Google Sitemap XML thread as it seems that it is what is not working correctly, or on a separate thread as these two products work together when the applicable files are properly merged/installed. (Successfully working on ZC 1.5.1 and expect no different on ZC 1.5.3)
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
mc12345678
Verify your installation of both products, as we are using the same and have no issues... XML files reflect the rewritten URLs. Also, helps to identify the version(s) of the software, but this may be something to address in the Google Sitemap XML thread as it seems that it is what is not working correctly, or on a separate thread as these two products work together when the applicable files are properly merged/installed. (Successfully working on ZC 1.5.1 and expect no different on ZC 1.5.3)
Hi, we're running on Zen Cart v1.5.1. Our Ceon version is v4.4.1. Our Sitemap is called Sitemap XML and is v3.2.12 19.09.2013.
Your confirmation that both of these modules work together and output as needed is good, and it really is an installation issue somewhere along the line.
Cheers,
dp
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
dp-web
Our output file is only giving us the old, standard Zen Cart product ID URL - which Google really doesn't like inside XML sitemaps as it requires a 200 response header rather than a 301.
Not a true statement.. Google doesn't CARE as long as the URL is VALID.. but that is ANOTHER topic..
Quote:
Originally Posted by
dp-web
The documentation states that the module deals with this and how to set it up, but the output is only ever the same, with the original URL.
Is there anyway to pull the new URL out (generated by CEON module) and input it into the Sitemap XML file? The info should be inside the database somewhere...
The issue is the Google Sitemap XML module.. Search this thread or the Google Sitemap XML support thread.. there is a posted fix which has sounds like NEVER made it's way into the Google Sitemap XML module..
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
DivaVocals
Not a true statement.. Google doesn't CARE as long as the URL is VALID.. but that is ANOTHER topic..
The issue is the Google XML module.. Search this thread or the Google XML support thread.. there is a posted fix which has sounds like NEVER made it's way into the Google XML module..
Hi Diva,
Thanks for your response. On my reading travels I've come across a lot of sites saying 301's are not good. But, I've just finished a Google Hangout with John Mueller Google WMT engineer) today and he did confirm that yes, Google DON'T care about the 301's redirects in the sitemap, in fact he said up to 5 is okay (ideally non but it's not always possible). So, with your confirmation as well, I can cross this off my list as possible causes for a dip in traffic.
I'll dig through the XML Sitemap thread to find the fix you mentioned. The module doesn't appear to have been updated in a while so might not have been added.
Thanks again.
dp
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
dp-web
Hi Diva,
Thanks for your response. On my reading travels I've come across a lot of sites saying 301's are not good. But, I've just finished a Google Hangout with John Mueller Google WMT engineer) today and he did confirm that yes, Google DON'T care about the 301's redirects in the sitemap, in fact he said up to 5 is okay (ideally non but it's not always possible). So, with your confirmation as well, I can cross this off my list as possible causes for a dip in traffic.
I'll dig through the XML Sitemap thread to find the fix you mentioned. The module doesn't appear to have been updated in a while so might not have been added.
Thanks again.
dp
The fix I speak of is in the Google XML support thread.. It was posted some time back so be prepared to dig a little.. try searching the thread specifically for "Ceon"
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
DivaVocals
The fix I speak of is in the Google XML support thread.. It was posted some time back so be prepared to dig a little.. try searching the thread specifically for "Ceon"
Thanks again. I've found the fix, and yes it was out of date, but I've corrected the code but the module still only outputs the URL's in the original zen format. :dontgetit
The CEON module works as it should (and there are only a few options anyway) so I know its doing what its supposed to in terms of URL rewriting.
I un-installed the Sitemap XML module, cleared out the files, re-installed and set it back up, but its still not working. Not sure where else to go now with it.
dp
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
dp-web
Thanks again. I've found the fix, and yes it was out of date, but I've corrected the code but the module still only outputs the URL's in the original zen format. :dontgetit
The CEON module works as it should (and there are only a few options anyway) so I know its doing what its supposed to in terms of URL rewriting.
I un-installed the Sitemap XML module, cleared out the files, re-installed and set it back up, but its still not working. Not sure where else to go now with it.
dp
All I can do is suggest you check your install of BOTH modules again..
Honestly if it's the Sitemap that's not generating the correct URI's the issue really is with the sitemap module (see post from the original Ceon author below).. Unfortunately the author of the Sitemap module isn't interested in figuring out the fix.. But the most likely REASON why is clearly stated below..
Quote:
Originally Posted by
conor
Hi,
Must be a problem with that module. Ceon URI Mapping will output the static URI for any code that uses zen_href_link(). It has no concept of what module is using it via that function.
Best ask your question on the thread for this other module.
Sorry I can't be more help than that but at least you know the issue isn't with Ceon URI Mapping.
All the best..
Conor
ceon
-
Re: Ceon URI Mapping v4.x
Hello
I have installed this module on Zen Cart 1.5.3 and everything is showing as OK in the installation and configuration checker. I am however having an issue with the redirects, in that every custom url returns to the homepage. I have tried the fix of adding the / to the .htaccess rule
the site is a b a c a o r g a n i c . co.uk and you can see the behaviour by clicking 'mattresses' then 'pocket sprung'
Any suggestions on this much appreciated.
Many thanks
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
whitsolltd
Hello
I have installed this module on Zen Cart 1.5.3 and everything is showing as OK in the installation and configuration checker. I am however having an issue with the redirects, in that every custom url returns to the homepage. I have tried the fix of adding the / to the .htaccess rule
the site is a b a c a o r g a n i c . co.uk and you can see the behaviour by clicking 'mattresses' then 'pocket sprung'
Any suggestions on this much appreciated.
Many thanks
Maybe something in the .htaccess file is fowling the CEON rewrite? Could you provide a copy of your .htaccess file, but be sure to obscure your admin directory as it is one of the rewritecond's included... Also, if there is anything else that is to remain obscured, at least identify that there is something there, but do not provide the details of what it was. Otherwise, perhaps the installation wasn't complete?
-
Re: Ceon URI Mapping v4.x
Thanks for coming back so quickly. I have reinstalled a couple of times to no avail. Here is the .htaccess info.
## BEGIN CEON URI MAPPING REWRITE RULE
RewriteEngine On
Options +SymLinksIfOwnerMatch
# 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} !^/XXXXX [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/editors/ [NC]
# Don't rewrite logs directory
RewriteCond %{REQUEST_URI} !^/logs/ [NC]
# Don't rewrite new directory
RewriteCond %{REQUEST_URI} !^/new/ [NC]
# Don't rewrite abaca directory
RewriteCond %{REQUEST_URI} !^/abaca/ [NC]
# Don't rewrite cgi-bin directory
RewriteCond %{REQUEST_URI} !^/cgi\-bin/ [NC]
# Don't rewrite blog directory
RewriteCond %{REQUEST_URI} !^/blog/ [NC]
# Don't rewrite tempEP directory
RewriteCond %{REQUEST_URI} !^/tempEP/ [NC]
# Don't rewrite magicscroll directory
RewriteCond %{REQUEST_URI} !^/magicscroll/ [NC]
# Handle all other URIs using Zen Cart (its index.php)
RewriteRule .* index.php [QSA,L]
## END CEON URI MAPPING REWRITE RULE
-
Re: Ceon URI Mapping v4.x
And that is the content of your entire .htaccess file? Nothing before, nothing after the CEON added code?
I have in the RewriteRule a slight difference to what you have. I have:
Code:
RewriteRule ^(.*)$ /index.php [QSA,L]
What I consider the significant difference being ^(.*)$ instead of .* alone.
Still, that is the entirety of your .htaccess file? I had gone through similar iterations on the site to obtain fully satisfactory results with the setup at the time. The differences may be inconsequential; however, I don't want to modify what isn't broke as there have been no issues with the rewrites after applying the above.
-
Re: Ceon URI Mapping v4.x
Thanks again. Yes this is the entire .htaccess file. Everything works properly with the rewrites turned off.
I have tried changing to your code without any difference in the result. There is nothing in the error logs.
Interestingly though, I have just discovered that putting anything after the url generates the same. e.g. /asfawrf (just random characters) also goes back to the homepage. Might this shed any clues?
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
whitsolltd
Thanks again. Yes this is the entire .htaccess file. Everything works properly with the rewrites turned off.
I have tried changing to your code without any difference in the result. There is nothing in the error logs.
Interestingly though, I have just discovered that putting anything after the url generates the same. e.g. /asfawrf (just random characters) also goes back to the homepage. Might this shed any clues?
Having tried the same (or similar) that was what led me to the two suggested causes. Either .htaccess issue (and if that is the entire .htaccess file, then my second thought would be a partial install. The browser's uri is being modified/keeps the entered uri; however, the site is not responding as such. Missed a merge maybe or some file didn't get uploaded fully/properly (occasionally happens to anyone/everyone). I'm not sure off the top of my head what "action" has been omitted to result in an entered rewrite not showing the information that is expected...
-
Re: Ceon URI Mapping v4.x
Once again, thanks very much for taking the time to help with this.
I have just performed a complete installation again. This time 1 file at a time and on replacing 'includes/autoloaders/config.ceon_uri_mapping.php' I was asked to replace a file with a size of 0 bytes. This appears to have fixed it.
Hate myself right now. Thanks again for your assistance
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
whitsolltd
There is nothing in the error logs.
Quote:
Originally Posted by
whitsolltd
Once again, thanks very much for taking the time to help with this.
I have just performed a complete installation again. This time 1 file at a time and on replacing 'includes/autoloaders/config.ceon_uri_mapping.php' I was asked to replace a file with a size of 0 bytes. This appears to have fixed it.
Hate myself right now. Thanks again for your assistance
Ahh, no big deal on that being the problem like said, it happens and is not an experience related issue, just sometimes in the middle of a transfer a hiccup occurs and the file doesn't make it to the server in its entirety. It does explain why there were no error logs, because the file (by name) was present, but it didn't have any code to "do" anything. :)
Not sure what ftp program you are using as some work "better" than others.
Good luck with populating your store with all of your links, hopefully all will go well from here on out. :)
-
Re: Ceon URI Mapping v4.x
I have this module installed and my EZ pages are not playing nicely. The problem might have to do with my template but I don't know how to add it to EZ pages. when I create a new EZ page like: FAQs and I check the box to let the URI auto-generate I get this URI: /faqs. So if I then go to page: http://www.mysite.com/faqs manually the page shows just fine.
My template adds my EZ pages to the footer if I define the page as Chapter 1 and give it a TOC order. The link that is added to the footer looks like this: http://wwww.mysite.com/faqs?chapter=1
So it seems as if my template adds the additional ?chapter=1 to the URI but this EZ page does not show properly. Basically my footer adds additional information and EZ pages tries and strips this same information causing my EZ pages to not display.
I tried adding the ?chapter=1 to the end of the URI but it strips the ?. How can I add ?chapter=1 to the end of each URI so it will display properly?
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
sports guy
I have this module installed and my EZ pages are not playing nicely. The problem might have to do with my template but I don't know how to add it to EZ pages. when I create a new EZ page like: FAQs and I check the box to let the URI auto-generate I get this URI: /faqs. So if I then go to page:
http://www.mysite.com/faqs manually the page shows just fine.
My template adds my EZ pages to the footer if I define the page as Chapter 1 and give it a TOC order. The link that is added to the footer looks like this:
http://wwww.mysite.com/faqs?chapter=1
So it seems as if my template adds the additional ?chapter=1 to the URI but this EZ page does not show properly. Basically my footer adds additional information and EZ pages tries and strips this same information causing my EZ pages to not display.
I tried adding the ?chapter=1 to the end of the URI but it strips the ?. How can I add ?chapter=1 to the end of each URI so it will display properly?
Honestly it's not clear what you have done.. (a REAL link to your site might help) SO let me just say this.. If you search through this thread for EZ Pages, I think you will probably find the answers you seek.. Most issues with EZ pages tend to be related to improperly using EZ pages to created URIs for other site pages instead of adding those pages to the database (as the readme explains how to do).
Basically if you are creating EZ Pages to create URIs for pages like this "http://yoursite.com/index.php?main_page=SOME-ZEN-CART-PAGE", this is why it's not working and you need to INSTEAD add the URI to the database as per the instructions..
-
Re: Ceon URI Mapping v4.x
Can anyone tell me what advantages thier is using CEON over Ultimate SEO?
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
jodean
Can anyone tell me what advantages thier is using CEON over Ultimate SEO?
So like all things there are good and bad. Advantages that I considered, and perhaps USU can do this without issue was that CEON doesn't require any type of numbers or other product/category default formatting to be in the uri so that when we are out in public to advertise our cause, we just speak/type/write the uri and it is easy to remember for all. Another advantage is that the store owner/operator has full control over what the uri(s) are to go to a given page. One can enter almost any number of uri options to get to a single page, for example say the login page, well could have: /login, /log-in, /log_in, /LogMeIn, /loggin, /enter, /opensesame,/opensaysme, etc... Capitalization used for emphasis of where the words are divided. Another advantage that I considered before use was the quality/completeness of the instructions. They were written now well over two years ago, and well, basically gave all of the requirements necessary to use the software. They may in some cases be obscurely written, but perhaps the functionality desired wasn't considered so necessary at the time to consolidate the thoughts into a single paragraph or sentence. From a programming side, CEON URI Mapping somewhat forces the use of ZC standard programming and helps identify where such is not used. It rewrites the coded version of a uri, not the "typed in" version and it becomes that much easier to spot when someone has taken a shortcut to provide a uri as compared to using the zen_href_link method of building a uri.
That said, now some disadvantages. The original author has passed and further development of this plugin has dwindled. Support of the plugin has been primarily it's users, not those that took on it's "development". Even the author (current/former) of USU chimes in with support. Possibly the biggest drawback for established stores is the need to populate the database with uris of existing product as compared to USU autogenerating the uri on the fly. There are tools to do this population even posts here and there, but it is perhaps the one biggest drawback to using CEON as viewed by a store owner/operator. I'm not sure if it is a plus or minus as I am not highly familiar with the details of USU, but misspellings of a uri using CEON lead to whatever page-not-found is to be loaded as CEON does not use any type of "best guess" of the uri, it is whatever is populated in the database. The .htaccess rewrite as originally developed includes a specific coding for the admin directory and requires updating when new directories are created off of the store's path. Also, as part of the uri "maintenance", if the store's uris change as compared to the HTTP_SERVER path, then the rewritten uris need to be modified/duplicated in the database. (Ie, mystore[dot]com/store moves mystore[dot]com/shop needs a database mod, but mystore[dot]com/store to hisstore[dot]com/store does not need a database mod provided all information is/was copied one-for-one from the other database.)
Hopefully that helps in determining the route to go, whether it is CEON or some other rewriter. I think most of these plusses and minuses though are already in the instructions, so unfortunately again say, read the manual. :P
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
mc12345678
That said, now some disadvantages. The original author has passed and further development of this plugin has dwindled. Support of the plugin has been primarily it's users, not those that took on it's "development". Even the author (current/former) of USU chimes in with support.
Want to emphasize this part because it's a biggie.. The current maintainers of this module have made it clear that support for the free version of this module will not be forthcoming from them.. They have instead clearly chosen to focus their efforts on the commercial version of this module. So support (including bug fixes discovered since the original author's passing) for the free Ceon URI module has largely been left to the community -- including the current maintainer of the USU module.. I am not saying that this is a bad thing.. but this is something that shopowners need to consider when installing this module..
So one must consider required changes to this module needed to keep up with current versions of Zen Cart, PHP versions, mySQL versions, etc.. It's unclear if the current maintainers (given their stance that no support for the free version of this module will be forthcoming) will keep up with these kinds of changes/updates as needed. Will they ONLY update the commercial version leaving the free module orphaned??? Dunno.. I'm posing the question as something to consider.. Shop owners should be cautious installing something that may already be obsolete..
This current status of this module is IMHO why a similar module (Simple SEO) died.. Like the free Ceon URI module, SSU's suthor stopped all support for it's free modules, and in that case the community never picked up the baton.. Bug fixes and even support dried up for SSU..
-
Re: Ceon URI Mapping v4.x
I upgraded from 4.4.1 to 4.4.3 by transferring the files to our site ffpetsupplies.com.
Now the categories and product don't load. There is just a blank white page.
I can load all product from the top menu. If I turn URI Mapping off everything works but with out the static URLs.
I will leave the mapping on for a while so that someone might be willing to have a look at it.
If I upload my recently backed up file and over write what is there now will the site revert back to the 4.4.1 version?
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
14all41
I upgraded from 4.4.1 to 4.4.3 by transferring the files to our site ffpetsupplies.com.
Now the categories and product don't load. There is just a blank white page.
I can load all product from the top menu. If I turn URI Mapping off everything works but with out the static URLs.
I will leave the mapping on for a while so that someone might be willing to have a look at it.
If I upload my recently backed up file and over write what is there now will the site revert back to the 4.4.1 version?
It was the .htaccess file some how I replaced it with one that did not have the dot before the h. I used the file from my back up. Back up your back ups. It's great insurance.
-
Re: Ceon URI Mapping v4.x
One other note about advantages and disadvantages. Because the links are stored in the database, if you have a lot of products, it can lead to a site slowdown. I have seen this once with a customer. Normal sites I wouldn't think it would be noticeable.
-
Re: Ceon URI Mapping v4.x
Just throwing this out there. Is there a way to bulk generate uri's? The uri is generated when product is manually added or updated. Is there a way to automate this?
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
14all41
Just throwing this out there. Is there a way to bulk generate uri's? The uri is generated when product is manually added or updated. Is there a way to automate this?
There is a commercial version of the module which does this.. You will need to contact the vendor for more details than that as any in depth discussions of commercial modules is forbidden on this forum..
Otherwise I do know that others have created spreadsheets and scripts to do the initial product and category loads.. If you are comfortable with SQL, you could do this..
-
Re: Ceon URI Mapping v4.x
Are there any updates forthcoming for ZC1.5.4?
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
michaelchu
Are there any updates forthcoming for ZC1.5.4?
You could ask jsweb what their plans are, since they took over the module after Conor passed.
-
Re: Ceon URI Mapping v4.x - issue with installation in 1.5.3
Quote:
Originally Posted by
DrByte
You could ask jsweb what their plans are, since they took over the module after Conor passed.
Quote:
Originally Posted by
michaelchu
Are there any updates forthcoming for ZC1.5.4?
As DrByte indicated you will have to ask JSWeb. JSWeb has made it clear that the free version of this module is not something they will be actively supporting.
Quote:
Originally Posted by
Ryk
Incorrect - supporting Conor's free contributions was never part of our original agreement with Ceon. However, when we get the time, we will endeavour to update the free contributions when necessary.
It would appear that this includes notices about upgrades, bugfixes, etc.. Given that they did submit an update when v1.5.3 was released, apparently they will submit updates as needed. Perhaps they will submit a v1.5.4 upgrade as well.
Again since JSWeb does not actively participate on this support thread, you will have to ask them directly what the plan is..
-
Re: Ceon URI Mapping v4.x - issue with installation in 1.5.3
and I'm thinking it does not work correctly on 1.5.4. I'm definitely having problems on one website with the product list page not adding to cart.
I am severely disappointed that JSWeb had decided Conor's mods are a great way to just generate income. I know he would be upset to know what they have done with all of this.
-
Re: Ceon URI Mapping v4.x
Sorry, fuller report - no, it does seem to work on 1.5.4. None of the core files on the catalog side have changed from version 1.5.3 to 1.5.4. There are changes on the admin side but it may be that they are simply the addition of the new zen_record_admin_activity function. I will not edit the files and upload a new version. I don't want to be responsible for this train wreck. But if you use the old files, at a minimum part of the new PCI compliance code will be eliminated. This is not recommended by anyone - least of all me.
If you do not use the modified core files from admin, you will not to be able to create the urls in the database for new products, but the existing rewrites will continue to work. My advice is to use the catalog side files so that you won't lose the existing links and SEO for the moment, but to NOT CONTINUE TO CREATE ANYMORE. Continuing on this path probably guarantees that at some point your SEO will be impacted even more than necessary. Plan for a future without this mod.
The realization that this mod may be dead in the next version has prompted me to start looking at how to extricate my clients from this mod. Since it allows the site owner to edit the urls directly, it has been a great SEO tool for some. That very ability can make the change to a new SEO writer (and I would suggest Ultimate SEO as the best alternative) incredibly challenging.
One client specifically has over a 1000 products. I don't know if he has actually edited any of those urls and there's really no way to find that out. I'm looking at two options:
1. a new htaccess rule that will convert the old urls to the new ones. (not my expertise)
2. a way to collect all the old urls and rewrite all of them individually making that one of the largest htaccess files ever!
Just ow!
The reason why I'm posting is folks need to be warned. Do not be complacent and think you can just deal with this change when it happens to you. Start making plans now. The free ride with this is at an end.
Sigh, Conor, I miss you personally and professionally.
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
delia
I am severely disappointed that JSWeb had decided Conor's mods are a great way to just generate income.
**nods in agreement**:yes:
You are speaking plainly and publicly, let me support YOU by doing the same.. You have said what I think MANY of us have been thinking and DEFINITELY saying privately.. I said this in a round about way in some of my posts (and was accused of being "disparaging":shocking:), because ACTIONS (or lack thereof) have indicated that all of Conor's free modules were not on the active maintainer's radar.. So THANK YOU for putting it out there..
Quote:
Originally Posted by
delia
I know he would be upset to know what they have done with all of this.
This is so much truer than you know my friend..
Quote:
Originally Posted by
delia
Sorry, fuller report - no, it does seem to work on 1.5.4. None of the core files on the catalog side have changed from version 1.5.3 to 1.5.4. There are changes on the admin side but it may be that they are simply the addition of the new zen_record_admin_activity function. I will not edit the files and upload a new version. I don't want to be responsible for this train wreck. But if you use the old files, at a minimum part of the new PCI compliance code will be eliminated. This is not recommended by anyone - least of all me.
lat9 has a module that may help bridge the gap. Read more here: http://www.zen-cart.com/showthread.p...ile-overwrites. In this post I ask for clarification about how the script she wrote works and it is NOW available in the free downloads.. I do believe that this module will bridge the gap between the currently available version of this module and Zen Cart v1.5.4.
Quote:
Originally Posted by
delia
The realization that this mod may be dead in the next version has prompted me to start looking at how to extricate my clients from this mod. Since it allows the site owner to edit the urls directly, it has been a great SEO tool for some. That very ability can make the change to a new SEO writer (and I would suggest Ultimate SEO as the best alternative) incredibly challenging.
I too am looking to convert the clients stilll using this mod. Ultimate SEO is my choice as a replacement since the active maintainer is as talented as Conor and he SUPPORTS his modules the same way Conor did..
Quote:
Originally Posted by
delia
One client specifically has over a 1000 products. I don't know if he has actually edited any of those urls and there's really no way to find that out. I'm looking at two options:
1. a new htaccess rule that will convert the old urls to the new ones. (not my expertise)
2. a way to collect all the old urls and rewrite all of them individually making that one of the largest htaccess files ever!
Just ow!
I will have to look for it, and maybe mc12345678 will chime in, but there is a tutorial for how to generate an .httaccess file with the correct 301 redirects for those converting from this module to Ultimate SEO.. Personally it would be nice to have some kind of "conversion" module that would read the Ceon URI table and does this automagically.. but I digress, the tutorial looks like it will do the trick..
Quote:
Originally Posted by
delia
The reason why I'm posting is folks need to be warned. Do not be complacent and think you can just deal with this change when it happens to you. Start making plans now. The free ride with this is at an end.
**nods in agreement**:yes:
Quote:
Originally Posted by
delia
Sigh, Conor, I miss you personally and professionally.
Ditto!!!
-
Re: Ceon URI Mapping v4.x
I *do*/*will* have more to say on the issue, but the first thing is, never should someone apply the files provided (in this module by version) blindly. Yes, copying 1.5.3 files onto 1.5.4 files *will* remove functionality/action of the 1.5.4 files. They should always be reviewed/merged. If not mistaken the docs for this module even suggest the same... The important thing to know/understand/recognize is if the files being "replaced" have been modified by anything else... Something that has made installation of this module "easy" in the past has been the inclusion of the zc specific version of the file(s). Therefore the simplest of sites could blindly apply the plugin and continue forward without missing a beat. It is that part (to start) of this plugin that is missing for 1.5.4 and then any potentially needed logging associated with the added PCI compliance feature of 1.5.4.
Regarding "recovery" of existing/past uris, the data is all in the database and merely needs to be retrieved/handled at the right point in the code or .htaccess as identified above.
-
Re: Ceon URI Mapping v4.x
Quote:
never should someone apply the files provided (in this module by version) blindly.
EXACTLY. And not from ANY mod.
I think mods requiring edits to core files should provide the edits and not the files to force people to merge, take more care and more importantly LEARN.
For the 1000th time I repeat mods are very rarely "plugins" in any sense of the word, they are modifications.
I am using this mod in 1.54 with no problems, and with respect, I never expected to see "train wreck" and "Conor" mentioned in the same thread!
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
torvista
I think mods requiring edits to core files should provide the edits and not the files to force people to merge, take more care and more importantly LEARN.
I have to disagree with this for the simple fact that there are modules which modify the SAME files as other modules.. having JUST the edits out of context with the rest of the file makes it difficult for NOVICE DIY shopowners to know exactly HOW and WHERE to place the code changes.. and not everyone knows how to write CLEAR, EASY TO UNDERSTAND user docs.. I have seen this first hand at play with some of the modules that I have submitted updates for.. The support threads for these modules were LITTERED with questions from novice shopowners who tried to follow the instructions on how/where to add the code edits only to get the white page of death or worse happening.. I'm all for people LEARNING.. but learning should have to be a struggle.. IJS..:smile:
-
Re: Ceon URI Mapping v4.x
I'm going to go with DivaVocals on this one.
I spoke with one store-owner who has very little coding experience and the POODLE change required to the PayPal payment's curl function (commenting out a single line) was causing him major heartburn. Having the changes (even minimal) pre-canned but well-commented will help everyone understand what's going on.
-
Re: Ceon URI Mapping v4.x
Okay, I'm back and this is ***NOT SHORT***... Wanted to give this post some appropriate consideration. A lot has been stated in the last few posts, and if I may address some of it. I would like to state up front that personally I like this mod and that it appears to fit the very public structure of the organization that uses it, but professionally, I have nothing against any of the other uri rewriters (albeit any/all be supported by at least someone, and preferably appropriately upgraded relatively close to the release date of new versions).
So, regarding updates and anyone just starting to read this thread:
Quote:
Originally Posted by
delia
I will not edit the files and upload a new version. I don't want to be responsible for this train wreck.
This is a completely personal decision. We all (everyone that offers assistance) does so as they see fit, as they desire, as they can, etc... Free support... Free time... Just because delia (and others) may have made modifications to get the plugin to work on ZC 1.5.4, does not mean that they/us need to share with everyone/anyone, not to mention that by providing the file(s) one does feel a sense of responsibility for all that follows.
If I may summarize some of what followed the above message excerpt... A workaround was suggested about how to continue to operate under ZC 1.5.4 effectively without taking action to incorporate the changes needed for full functionality of the plugin, equivalent to halfway installing the plugin effectively disabling the ability to extend its operability. (This to an extent led to discussion about how best to provide plugins/code/code changes.) Yet again, the discussion of this or any uri rewriter impacting "SEO" is yet to be proven. Just because the acronym appears in a programs title doesn't make it so.
Somewhat surprisingly the actual code inserted into ZC is relatively simple/small, but calls ever more complex code in the background. Anyways, any module could be "dead" at any next revision, if no one does anything to address it. Certainly, if JSWeb has taken to a financial perspective only, either they will transition from providing any support at all for this free module and only offer for pay versions moving this particular functionality availability away from the masses. I would be surprised to see if the requested rates are truly reaping the supposed value. Anyways, the use of a uri rewriter (any) can have its downside. Here we are talking about how to transition from one to another, meanwhile the question tends to be, why have one in the first place. About three years ago now, our organization was trying to figure out how best we could get people to remember us and quickly find us as a service organization. It came to light that one of the easiest ways was to have a uri that was memorable and not to just funnel all traffic to one page (main page), but to deliver into the area(s) applicable to the activity considered.. So, yes there were some choices to be made and difficulties initially. The instructions and the individual version files made things easier/better. Reading through the installation as well as potential removal and interaction with other URI mapping programs, it was obvious that once a store starts to use something like this, it appears to be somewhat a commitment to using it into the future.. That is unless/until action is taken to "undo" the rewrites. Now I'm not out to either force this code to remain in place, nor am I out to tear it down. It accomplishes what is desired, and can be used with newer versions when the necessary changes are considered. Yes, it is more involved than a simple copy and paste, and the overall complexity of it is simplified by these files being provided, but perhaps the transition is one to where the plugin is installed by only those that understand how to apply the code differences, rather than by the "masses". At the same time I have also recently seen an installer that supposedly will self integrate with existing code. I haven't tested this out yet, but it if it works as described, then it is a step in the right direction.
So, as I said, I'm not out to tear down this (or any) plugin/code modification/whatever you want to call it. I can say that there is an application that can assist with several of the aspects of interest of this code. Want to create uris from products existing or newly added to the database? It can support it/it is available. Want to convert uri's, well the github available version has a feature that could help in either direction (coming from another uri rewriter to this one or going from this one to another), using an admin control. Yes, generating an .htaccess file to rewrite a rewrite for the purpose of another rewriter to rewrite the result is a bit ridiculous, but I believe the code discussed in this paragraph could handle that generation in a few clicks and again in either direction. Incorporating a method to continue the rewriting of existing uris to support a mix of the old and new is nearly equivalent to operating with two or more uri rewriters at once, but I'm sure that there is a way to make that sort of transition occur...
In regards to some of the specific statements:
Quote:
Originally Posted by
delia
One client specifically has over a 1000 products. I don't know if he has actually edited any of those urls and there's really no way to find that out.
Not sure I understand what is considered to have been "edited", but if the client has used this module as designed (and not manually modified the database table), then such modifications are still held in the database and are potentially still doing their function of redirecting customers to the currently active product uri. I'm afraid that if that central functionality is not understood that there is a flavor of not understanding the module that is also a bit disconcerting in light of the strong message to abandon it.. (again there are those that advocate never using any such thing to begin with.)
Quote:
Originally Posted by
DivaVocals
lat9 has a module that may help bridge the gap. Read more here:
http://www.zen-cart.com/showthread.p...ile-overwrites. In this post I ask for clarification about how the script she wrote works and it is NOW available in the free downloads.. I do believe that this module will bridge the gap between the currently available version of this module and Zen Cart v1.5.4.
lat9's adaptation of the new code in ZC 1.5.4 to be applied to code that would/could be used in previous versions of ZC, is certainly valuable to any module that is broadly applicable to any/most ZC versions. It is far more necessary for a module that doesn't contain unique application/design for the applicable ZC version... So, in the case of this module, if the next modification is "entered" to support ZC 1.5.4, there would be no need for lat9's plugin, because a folder for ZC version 1.5.4 will be created to be applied against that version of ZC which already has the necessary files to process the PCI commands. Further, because the ZC 1.5.3 folder applies to ZC 1.5.3 and ZC 1.5.3 and below do not use the PCI commands, then the plugin also does not apply. If, however, the code were written as a "one-size" fits all, then lat9's file(s) would be needed. For example EasyPopulate v4 is a single set of files that functions in ZC 1.3.9 all the way up to ZC 1.5.4 (not including ZC 1.5.2 on purpose), because of that lat9's plugin is relatively crucial, because the code could attempt to log a PCI event; however, none will be logged because the underlying functionality doesn't exist in the earlier versions.
As for rewriting the rewrites, one aspect about it has to do with sequencing... I don't know how everyone is at algebra or simple substitution:
All cats have fur
All fur is long hair
All long hair is on a mammal
All mammals breath air, then one would/could say reading left-to-right and downward that all cats breath air...
But in reverse order the following is not true, and substitution would not occur:
All air breathers are mammals
All mammals have long hair.
All long hair is fur,
All fur is on cats...
The first set has logical statements that are true leading to a result, the second set also has logical statements (even if they are not true statements) that lead to central location for the answer. Thing is I would say that the first one is one where more substitution is performed than desired (each step downward) as compared to a single substitution step of resultradcon is working to the DR to verify that the work has been complete.
So, like described in the article referenced (though not verified to be correct), the category rewrites should follow (come after) the product rewrites to ensure the right product is being rewritten with the right name.
-
Re: Ceon URI Mapping v4.x
Okay, So I have read over the last few pages and It seems that this module is only partially working with 1.5.4? It seems that lat9's module that has been linked provides a way to circumvent the problem but unfortunately I am only a novice and Im not too sure what to do with that mod. So do I install this and figure it out myself and try and use lat9's workaround or does it look likely that something will be submitted that works on 1.5.4?
It seems very disheartening that conor made all these modules and supplied so much effort and now this has been left to a company who seem to just be in it for the money by selling his versions of the modules with DRM! Offering no support for the free modules and in effect forcing people to consider forking out lots of money for the only version of the module that is actually working!
Please help!
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
DannyVarley
Okay, So I have read over the last few pages and It seems that this module is only partially working with 1.5.4? It seems that lat9's module that has been linked provides a way to circumvent the problem but unfortunately I am only a novice and Im not too sure what to do with that mod. So do I install this and figure it out myself and try and use lat9's workaround or does it look likely that something will be submitted that works on 1.5.4?
It seems very disheartening that conor made all these modules and supplied so much effort and now this has been left to a company who seem to just be in it for the money by selling his versions of the modules with DRM! Offering no support for the free modules and in effect forcing people to consider forking out lots of money for the only version of the module that is actually working!
Please help!
So, I have thought about the above and my LAP. If the code that is added by this module (ie, the classes) is to contain the recording of the PCI information and not the ZC version specific files, then yes lat9's plugin would be needed for "backward's" compatibility.
To you kind individual, installation of lat9's plugin referenced here ought to be simple and have almost no visible effect on the store when installed alone. I haven't reviewed the package specifically but I have used the "original" code as posted elsewhere on the forum.
As for the functionality, when merged appropriately, the module has been shown to function. That said, ZC 1.5.4 has included additional actions support PCI compliance. Part of this has been to log changes made to the database through the admin console or admin files. This plugin modifies the database when creating, editing, deleting products and rewritten uris... Further, the module itself does spit out pretty much the information that would be desired to capture as a message to the screen... This goes back to whether the plugin is needed or if the information could simply be captured by documenting the messages that come back from the code.
Let's see, software has been issued for over three weeks now. It may have been available to the for preliminary testing/beta testing, but let's assume not. Last time the ZC version changed, how long was it before the compatible version was posted? Has anyone followed the process of notifying JSWeb through their site about the issues they are having with installing the module on ZC 1.5.4 requesting that they make it available or something?
-
Re: Ceon URI Mapping v4.x
Thank you mc12345678 for that
Quote:
Has anyone followed the process of notifying JSWeb through their site about the issues they are having with installing the module on ZC 1.5.4 requesting that they make it available or something?
The answer is no.
I'm not at all sure we deserve this current wave of hostility from some people round here, but I am not prepared to waste time entering into a debate.
All I will say this:
1. It is almost certain that every single person who has posted on this forum is either making money out of ZenCart or is hoping to make money out of ZenCart, whether it be building a successful ecommerce business or by using their knowledge to implement and enhance the software.
And that includes our detractors.
2. Although it is absolutely no business of anyone else whatsoever, JSWeb have an agreement with Ceon Ltd which began prior to the loss of Conor (who, by the way, worked so closely with JSWeb that he attended several of our periodic company meetings in Dublin & Birmingham, was instrumental in the management of our servers and was in more or less daily discussions about the way forward for both Ceon & JSWeb - so how anyone on this forum can presume to know what Conor would have thought is both outrageous and offensive).
The original agreement was that JSWeb would sell Conor's commercial modules at whatever price our market would support and pay Ceon Ltd the amount he would have charged. After his passing, the agreement with Ceon Ltd was adjusted so that we would continue to market those same modules and would also assume the support and maintenance of them, continuing to pay commission on each sale. That we still do, and will continue to do so.
Free modules were not, and are not, included in our agreement. Such modules are put into the public domain and ANYONE can modify them as they see fit - a fact which seems to be overlooked by those bad-mouthing us. Should someone choose not to do so, then that is their decision, but that does not give reason to criticise us for not doing so.
We have no legal - nor indeed, moral - obligation to support the free modules supplied by Ceon, but as I've said in the past when we get the time we will endeavour to update the free contributions when necessary.
3. JSWeb focus MUST be on servicing our paying clients' requirements. That includes keeping the Ceon commercial modules up to date. Over the past year we have upgraded/rebuilt various modules to handle API changes by couriers, payment gateways etc - and of course, keep them up to date with ZenCart version changes. IF changes are relevant to one of the free modules, then we would implement them too, but there are no free versions of those particular modules.
After the experience of 1.3.9 a-d in rapid succession from Apr-Jun 2010 (then e-h by Oct 2010!), we always wait a few weeks before encouraging our clients to upgrade (it's one thing keeping your own site upgraded with quick-fire releases - entirely different when you have a couple of hundred to manage). During that period we assess the commercial modules to see if there will be any impact so we can implement ZC upgrades without breaking sites. URI Mapping is not essential for a successful website whereas a functioning payment gateway integration/shipping module is, so it was not top of our list. Once the necessary changes have been identified, they will also be applied to the free version ..unless someone else has, as they are perfectly entitled to do, already uploaded a new version to the forum.
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
mc12345678
It may have been available to the for preliminary testing/beta testing, but let's assume not.
It was made available to those who regularly maintain certain modules or are participating in the v1.6 community..
-
Re: Ceon URI Mapping v4.x
Sooooooooo having an opinion about a topic and expressing that opinion in a DISCUSSION forum makes one a "hostile" and a "detractor" eh??:laugh: Hmmmmmmm.. well okay.. Everyone is entitled to interpret my words ANY WAY they like.
I personally had NO REASON to contact ANYONE about this module because based on my OWN observations it was clear that this module would no longer be a maintained in a manner that made it a reliable tool for me to CHOOSE to use on my client's site.. Expressing that is not hostile, it is my OPINION, and since this is a DISCUSSION forum I expressed that opinion..
So let me be clear:
- I could CARE LESS what Ceon and JSWeb's arrangement is
- I don't think JSWeb is in any way OBLIGATED to maintain ANY of the Ceon free modules
- I agree with the point made that ANYONE in the community COULD pick up the ball and maintain this module
On this last point I think the reason no one has picked up this or any other Ceon module is that everyone looks at modules as being "owned" by whomever they perceive is the active maintainer. So they don't want to step on toes by taking over the care and upkeep of these modules. I saw this first hand with Edit Orders. People asked me if I had gotten Scott's "permission" to submit an update. In the case of this and other Ceon modules, upon Conor's death, JSWeb communicated that they would be assuming responsibility for Conor's modules. What was not clear in that announcement and subsequent communications (until recently) was the fact that this did NOT necessarily include the free modules Conor developed. Not having this bit of information is likely partially WHY no one in the community has stepped up and taken the baton so-to-speak on this or ANY of Conor's other modules. Speaking personally for myself, it was my observation that free support ended with Conor's death, and I began considering other options for my clients.. However, for most folks it was clear that they were unsure of the state of things. (as demonstrated by the discussions here)
Regardless as to WHY the free Ceon module will not be maintained by JSWeb is not important.. I could care less WHY.. All I know is that this IS the state of the Ceon free modules. There's NOTHING hostile about laying the cards out on the table on this..
Now there are some folks who have an expectation that free modules will be maintained forever, and many small business owners don't have a realistic plan for what happens when that free module they NEED stops being maintained.. Anyone who's read any of my posts knows that I have expressed opinions about free module development expectations, the need for small business owners to include paying for professional assistance when needed, and that it's unrealistic to build a business without paying a DIME for technical assistance on occasion. So though JSWeb has labeled me a "detractor" or "hostile", I am in fact neither..
What I am is of the opinion that until this module has a regular active maintainer, it is not something I will continue to install on my client's site. So YES I am actively looking for options to migrate my current Ceon URI clients to Ultimate SEO (which will delay the v1.5.4 upgrade for these clients). Finally I will continue to express THAT opinion. If expressing an HONEST opinion is considered being a "detractor" or "hostile", then color me a "hostile detractor":smile:.. Personally I consider myself one who is zealously looking out for my clients.
one last note.. it is "both outrageous and offensive" to assume that Conor (or his family) never spoke with anyone else on this forum.. Some folks have formed their own opinions based on their OWN interactions with Conor..
-
Re: Ceon URI Mapping v4.x
We will shortly release an updated version of the free Ceon URI Mapping module which will work with all versions of ZenCart 1.5+ . This should be uploaded to the ZC plugins section as normal within the next 48 hours.
There is no new functionality but it will now work with ZC 1.5.4 by circumventing the zen_record_admin_activity function which we have been advised by Wilt is not required of 3rd party code as such code is not part of the PA-DSS certification for ZenCart.
We apologise for the delay - our reasons have been stated previously and I won't bore anyone by going over it again.
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
Ryk
by circumventing the zen_record_admin_activity function
huh? Did you actually mean "circumvent" as in "break/bypass/disable" for even the built-in features? or did you mean "we won't *use* [the] function in all our modules' own customised add/remove/update/edit activities"?
I strongly advise that you LEAVE EXISTING calls to zen_record_admin_activity ALONE.
You don't need to add more, but removing or disabling built-in functionality, especially things that aid in security, is not particularly prudent.
I'm aware of the content of your discussion with wilt. But he certainly didn't tell you to go ahead and cripple or remove built-in functionality.
I realize that may make distributing 1 set of files for all 1.5.x versions a little more challenging, but the bridge contributed by lat9 would simplify that concern easily.
-
Re: Ceon URI Mapping v4.x
I understand that the clarification was made for more than just JSWeb, but if I may interject. If the package is assembled for ZC 1.5.4 as it has for previous versions of ZC, and there are no additional calls to zen_record_admin_activity, then it would seem that the additional bridge would not be necessary. The files applicable to ZC 1.5.4 would already include the base ZC code for ZC 1.5.4 (maintaining existing zen_record_admin activity calls) with the modifications necessary for the plugin to operate under that environment and no backwards compatibility with zen_record_admin_activity would be necessary.
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
DrByte
huh? Did you actually mean "circumvent" as in "break/bypass/disable" for even the built-in features? or did you mean "we won't *use* [the] function in all our modules' own customised add/remove/update/edit activities"?
I strongly advise that you LEAVE EXISTING calls to zen_record_admin_activity ALONE.
You don't need to add more, but removing or disabling built-in functionality, especially things that aid in security, is not particularly prudent.
I'm aware of the content of your discussion with wilt. But he certainly didn't tell you to go ahead and cripple or remove built-in functionality.
I realize that may make distributing 1 set of files for all 1.5.x versions a little more challenging, but the
bridge contributed by lat9 would simplify that concern easily.
Dr Byte,
Nothing has been removed, or crippled in the updates to URI Mapping. You can take a deep breath and calm down :)
URI mapping is merged into version 1.5.4 files with all calls to zen_record_admin_activity intact.
zen_record_admin_activity was however added to the relevant product_book files to include them in the new activity reporting.
The bridge you mentioned has been included in the fileset that will be submitted, but purely as a safety net should issues have arisen without it.
However, it was not deemed necessary to have every single action of a URI module to write to the admin logs, and as you are aware, this was discussed with Wilt.
The URI module does not have a 'one set of files fits all' architecture. There are specific files, correctly merged for each version of ZC from 1.3.8a to 1.5.4
-
Re: Ceon URI Mapping v4.x
My apologies for using the wrong phrase then. Not being a programmer myself, I was just putting it in what i thought was simple English. Thank you @strelitzia for the fuller explanation.
-
Re: Ceon URI Mapping v4.x
For anyone who requires the latest version of the free CEON URI Mapping plugin compatible with 1.5.4 before it has been moderated and posted in the plug-ins, you can get it from http://www.jsweb.uk/zen-cart-plugins...-friendly-urls
-
Re: Ceon URI Mapping v4.x
-
Re: Ceon URI Mapping v4.x
I have this module installed but there is a problem with images.
The problem happens in Internet Explorer 11, not in Chrome.
Absolutely all images on page disappears if the path contains two "folders" For example http://madasahatter.no/hatter works fine, but http://madasahatter.no/hatter/flosshatt don't.
I have <base href="http://madasahatter.no/" /> before any js or css in the header.
If I in Developer tools add a leading / to the src, the image pops up, but this shouldn't be necessary? The base ref has a / at the end, and src points directly to images/image.jpg
Another thing; I can’t add / to all images on page, it’s almost impossible to find all the images.
There has to be a bug somewhere since it only happens when there is two "folders" in the url?
Here's my .htaccess :
Code:
#
# @copyright Copyright 2003-2010 Zen Cart Development Team
# @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
# @version $Id: .htaccess 18695 2011-05-04 05:24:19Z drbyte $
#
# This is used with Apache WebServers
#
# The following blocks direct HTTP requests to all filetypes in this directory recursively, except certain approved exceptions
# It also prevents the ability of any scripts to run. No type of script, be it PHP, PERL or whatever, can normally be executed if ExecCGI is disabled.
# Will also prevent people from seeing what is in the dir. and any sub-directories
#
# For this to work, you must include either 'All' or at least: 'Limit' and 'Indexes' parameters to the AllowOverride configuration in your apache/conf/httpd.conf file.
# Additionally, if you want the added protection offered by the OPTIONS directive below, you'll need to add 'Options' to the AllowOverride list, if 'All' is not specified.
# Example:
#<Directory "/usr/local/apache/htdocs">
# AllowOverride Limit Options Indexes
#</Directory>
###############################
#ErrorDocument 404 /oppgradering.html
##ROOT##
ExpiresActive On
ExpiresByType text/css "access plus 500 days"
ExpiresByType application/javascript "access plus 500 days"
<Files stylesheet.css>
ExpiresByType text/css "access plus 350 days"
</Files>
<FilesMatch \.(swf)$>
ExpiresDefault "access plus 700 days"
</FilesMatch>
<FilesMatch \.(svg)$>
ExpiresDefault "access plus 3000 days"
</FilesMatch>
ExpiresByType image/gif "access plus 1500 days"
ExpiresByType image/jpg "access plus 1500 days"
ExpiresByType image/jpeg "access plus 1500 days"
ExpiresByType image/png "access plus 1500 days"
ExpiresByType image/bmp "access plus 1500 days"
# 48 weeks
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf|JPG|woff)$">
Header set Cache-Control "max-age=29030400, public"
</FilesMatch>
<files *>
order allow,deny
deny from 80.212.29.94
deny from 74.50.57.39
deny from 24.189.60.120
deny from 84.17.15.2
deny from 211.167.110.2
deny from 91.201.64.26
deny from 65.208.189
deny from 65.211.195
#deny from 195.1.61
allow from all
</files>
RewriteEngine On
RewriteCond %{HTTP_HOST} !^madasahatter.no$ [NC]
RewriteRule ^(.*)$ http://madasahatter.no/$1 [L,R=301]
# RewriteBase /
# add trailing slash if missing
# rewriteRule ^(([a-z0-9\-]+/)*[a-z0-9\-]+)$ $1/ [NC,R=301,L]
# 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} !^/d49ogknott [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/editors/ [NC]
# Don't rewrite logs directory
RewriteCond %{REQUEST_URI} !^/logs/ [NC]
# Don't rewrite min directory
RewriteCond %{REQUEST_URI} !^/min/ [NC]
# Don't rewrite cgi-bin directory
RewriteCond %{REQUEST_URI} !^/cgi\-bin/ [NC]
# Don't rewrite .htpasswds directory
RewriteCond %{REQUEST_URI} !^/\.htpasswds/ [NC]
# Don't rewrite sitemap directory
RewriteCond %{REQUEST_URI} !^/sitemap/ [NC]
# Don't rewrite bmz_cache directory
RewriteCond %{REQUEST_URI} !^/bmz_cache/ [NC]
# Handle all other URIs using Zen Cart (its index.php)
RewriteRule .* index.php [QSA,L]
-
Re: Ceon URI Mapping v4.x
Additional info: when i am in a "subfolder" the image path is as follows: http://madasahatter.no/hatter/images/image.jpg
The "hatter" folder get added for some reason to the base href
-
Re: Ceon URI Mapping v4.x
Quote:
Originally Posted by
panservolvo
I'm guessing that the issue stems from an incorrect path in your configure.php files.. which is to say that I don't think the issue stems from this module, but is ILLUMINATED when you turn this module on..
