Ceon URI Mapping (SEO)

Hey Conor,

thanks as always for your prompt reply. I understand why you say that it is not a Ceon thing but at the same time the only rewriting on the site is that group of rules. It's a bit weird.

Anyway, pragmatism eventually ruled the day and I changed the rules to:

Code:

---

RewriteCond %{HTTP_HOST} !^www\.starlessriver\.com$ [NC]
RewriteRule ^(.*)$ http://www.starlessriver.com/shop/$1 [L,R=301]

---

In other words added the directory in at that stage. Works fine - even though I am not sure why I had to do this and the rules actually seem wrong - ah well....

Thanks for your time

Nick

Hi,

Quote:

---

Originally Posted by niccol

thanks as always for your prompt reply. I understand why you say that it is not a Ceon thing but at the same time the only rewriting on the site is that group of rules. It's a bit weird.

---

Yes, but you have installed your own rewrite rule in addition to the Ceon one.. the one that you messed up with was your own one.. so Ceon URI Mapping was in no way to blame for that.

Just making sure others don't think there's a problem with our rule. :)

Quote:

---

Originally Posted by niccol

Anyway, pragmatism eventually ruled the day and I changed the rules to:

---

Did you try moving the rules to the .htaccess fle *below* the shop folder as I suggested?

All the best...

Conor
ceon

Conor,

First yes, I am a big admirer of this mod and have used it many times so definitely was not saying there was anything wrong with the standard rule. In my experience this is definitely the most solid rewriting module of the bunch.

Actually I have also used it many times with an extra rule to force www on all the URLs with no problem.

So, what I have here is definitely a install specific quirk. Yes, I did put the htaccess to root and had the same issue.

The problem was that the directory /shop/ was being lost in the rewrite to www from non-www . So, the hack solution was just to force that rewrite to add the /shop/ back in. It seems to work fine under all the circumstances I can come up with. And actually the non-www URLs are rarely seen by the user - search engines maybe.

Hi,

Quote:

---

Originally Posted by niccol

First yes, I am a big admirer of this mod and have used it many times so definitely was not saying there was anything wrong with the standard rule. In my experience this is definitely the most solid rewriting module of the bunch.

---

That's nice of you to say. Would you be interested in trying out 4.0.0RC2? I haven't gotten any feedback about it yet but am itching to release it as 4.0.0 final.

If so, please get in contact via this address.

Quote:

---

Originally Posted by niccol

The problem was that the directory /shop/ was being lost in the rewrite to www from non-www . So, the hack solution was just to force that rewrite to add the /shop/ back in.

---

I realise what was happening... my guess was that possibly the $1 variable was being built relative to the current folder the .htaccess file was placed in, therefore missing the /shop/ part.

That is indeed strange behaviour you are seeing on that server.

Possibly setting

RewriteBase /

might avoid having to use the "kludge" you are using. It may have no effect though.. I don't know.. this does sound like something's up with the server, at some config level.

Of course, this isn't something that you need to worry about too much , life is short and the kludge will do.. I just find myself getting annoyed by wee niggly things like this and not knowing "why" the kludge was needed. :)

All the best..

Conor
ceon

Oh, yeah, RewriteBase might have been a better way to go. I'll give that a try if I get a moment.

Yes, the 'why' is sometimes a bit frustrating. And in this case very strange as the store ran fine in 1.3.8a with a similar set up and htaccess file. The issue only emerged when it was upgraded to 1.3.9. So, doubly weird because it is not a absolute server configuration thing.

Anyway, kludge works. So, the pressure is off to sort it out. Now I can fiddle with it out of interest rather than necessity :-)

just an update for anyone using ceon url mapping add on with CAPTCHA Anti-Robot Registration,

i was getting no captcha showing at all

in /includes/templates/YOURTEMPLTE/ tpl_modules_create_account.php

at line 189

change to

PHP Code:

---

<?php
if (strstr($_SERVER['REQUEST_URI'],'create-account') && CREATE_ACCOUNT_VALIDATION == 'true' || strstr($_SERVER['REQUEST_URI'],'login') && CREATE_ACCOUNT_VALIDATION == 'true' || strstr($_SERVER['REQUEST_URI'],'create_account') && CREATE_ACCOUNT_VALIDATION == 'true') { 
?>

<?php
  if ($is_read_only == false || (strstr($_SERVER['REQUEST_URI'],'create-account')) || (strstr($_SERVER['REQUEST_URI'],'login')) || (strstr($_SERVER['REQUEST_URI'],'create_account'))) {
    $sql = "DELETE FROM " . TABLE_ANTI_ROBOT_REGISTRATION . " WHERE timestamp < '" . (time() - 3600) . "' OR session_id = '" . zen_session_id() . "'";
    if( !$result = $db->Execute($sql) ) { die('Could not delete validation key'); }
    $reg_key = generate_captcha_code();
    $sql = "INSERT INTO ". TABLE_ANTI_ROBOT_REGISTRATION . " VALUES ('" . zen_session_id() . "', '" . $reg_key . "', '" . time() . "')";
    if( !$result = $db->Execute($sql) ) { die('Could not check registration information'); }
?>

---

this works for me and lets you use captcha if ceon is on or off

and in includes/templates/YOURTEMPLATE/tpl_contact_us_default.php at line 83 change to

PHP Code:

---

<?php
if (strstr($_SERVER['REQUEST_URI'],'contact-us') && CONTACT_US_VALIDATION == 'true' || strstr($_SERVER['REQUEST_URI'],'contact_us') && CONTACT_US_VALIDATION == 'true' || strstr($_SERVER['REQUEST_URI'],'login') && LOGIN_VALIDATION == 'true') { 
?>

<?php
  if ($is_read_only == false || (strstr($_SERVER['REQUEST_URI'],'contact-us')) || (strstr($_SERVER['REQUEST_URI'],'contact_us')) || (strstr($_SERVER['REQUEST_URI'],'login'))) {
    $sql = "DELETE FROM " . TABLE_ANTI_ROBOT_REGISTRATION . " WHERE timestamp < '" . (time() - 3600) . "' OR session_id = '" . zen_session_id() . "'";
    if( !$result = $db->Execute($sql) ) { die('Could not delete validation key'); }
    $reg_key = generate_captcha_code();
    $sql = "INSERT INTO ". TABLE_ANTI_ROBOT_REGISTRATION . " VALUES ('" . zen_session_id() . "', '" . $reg_key . "', '" . time() . "')";
    if( !$result = $db->Execute($sql) ) { die('Could not check registration information'); }
?>

---

again this should let you use captcha with ceon offf or on.

hope this helps someone

bryan

Hi Bryan,

Thanks for contributing to the community.. :)

Quote:

---

Originally Posted by bn17311

just an update for anyone using ceon url mapping add on with CAPTCHA Anti-Robot Registration,

i was getting no captcha showing at all

---

I can see why you wouldn't. That's poor code the CAPTCHA module was using, very dependent on dynamic URIs. It could just have checked against the Zen Cart page variable instead of the URI! Tsk tsk!

Could you please send me a link to download for this module?

With v4.0.0. of Ceon URI Mapping I am including some modified files for third party modules, so they can work with Ceon URI Mapping.

It's either that or rewrite and re-release these other modules with compatibility for static URIs.. something I may do in future but don't have time for right now.

All the bet...

Conor
ceon

are the changes i made ok ? seems to work fine

thanks
Bryan

Hi Bryan,

Quote:

---

Originally Posted by bn17311

are the changes i made ok ? seems to work fine

---

Yes, but they suffer from the same hard-coding issues as the original.

You're depending on your create account page having 'create-account' or 'create_account' in the URI.

The module should really have been written to use something like:

PHP Code:

---

$_GET['main_page'] == 'create_account' 


---

in its test instead of

PHP Code:

---

strstr($_SERVER['REQUEST_URI'], 'create_account' 


---

I've added a FAQ with this information to v4.0.0 now about how to deal with modules like this that aren't coded properly.

I may modify the contribution you pointed me towards and include a "sample modified file" for it that fixes its code..

It seems like a popular enough module, the reason I'd say I haven't heard of this issue with it before is that most people haven't added mappings for their create account/login pages so this "bug" in this other module doesn't show on their site.

All the best...

Conor
ceon

so

PHP Code:

---

<?php
if ($_GET['main_page'] == 'create_account' && CREATE_ACCOUNT_VALIDATION == 'true' || $_GET['main_page'] == 'login' && LOGIN_VALIDATION == 'true') { 
?>

<?php
  if ($is_read_only == false || $_GET['main_page'] == 'create_account' || $_GET['main_page'] == 'login') {
    $sql = "DELETE FROM " . TABLE_ANTI_ROBOT_REGISTRATION . " WHERE timestamp < '" . (time() - 3600) . "' OR session_id = '" . zen_session_id() . "'";
    if( !$result = $db->Execute($sql) ) { die('Could not delete validation key'); }
    $reg_key = generate_captcha_code();
    $sql = "INSERT INTO ". TABLE_ANTI_ROBOT_REGISTRATION . " VALUES ('" . zen_session_id() . "', '" . $reg_key . "', '" . time() . "')";
    if( !$result = $db->Execute($sql) ) { die('Could not check registration information'); }
?>

---

and

PHP Code:

---

<?php
if ($_GET['main_page'] == 'contact_us') && CONTACT_US_VALIDATION == 'true' { 
?>

<?php
  if ($is_read_only == false || ($_GET['main_page'] == 'contact_us')) || (strstr($_SERVER['REQUEST_URI'],'login'))) {
    $sql = "DELETE FROM " . TABLE_ANTI_ROBOT_REGISTRATION . " WHERE timestamp < '" . (time() - 3600) . "' OR session_id = '" . zen_session_id() . "'";
    if( !$result = $db->Execute($sql) ) { die('Could not delete validation key'); }
    $reg_key = generate_captcha_code();
    $sql = "INSERT INTO ". TABLE_ANTI_ROBOT_REGISTRATION . " VALUES ('" . zen_session_id() . "', '" . $reg_key . "', '" . time() . "')";
    if( !$result = $db->Execute($sql) ) { die('Could not check registration information'); }
?>

---

is this the correct way ?

thanks for your help
bryan