Ceon URI Mapping v4.x

[mc12345678]

Now I got it working, but now when I mouse over my subcategories on the main store I don't see my products. I get Error: 404 Page Not Found.

One reason to get a 404 error relates to the either newly added or otherwise modified .htaccess file. ZC does not ship (because it does not need) with an htaccess file in the root of the store. This plugin (like other URI Rewriters that have been seen to work properly) requires a properly formatted/sequenced htaccess file. As has been done times before, the entire .htaccess file may need to be provided (though please obscure the admin directory name as it is provided in the template generated by the plugin.)

Also besides reviewing the instructions about the file and 404 issues, it is important to understand how this store is incorporated into the server with consideration of other stores on the server and any htaccess files in the directories above (before) the current store's root.

Now, all that said, you mentioned that there is a 404 issue when hovering over the images, does that mean you have been able to navigate the site with the rewritten uris, but only the images have an issue?

[mc12345678]

1031 to 1038

if (isset($_SERVER['HTTP_REFERER']) && preg_match("~^".HTTP_SERVER."~i", $_SERVER['HTTP_REFERER']) ) {
      //if (isset($_SERVER['HTTP_REFERER']) && strstr($_SERVER['HTTP_REFERER'], str_replace(array('http://', 'https://'), '', HTTP_SERVER) ) ) {
        $link= $_SERVER['HTTP_REFERER'];
      } else {
        $link = zen_href_link(FILENAME_DEFAULT);
      }
      $_SESSION['navigation'] = new navigationHistory;
    }

Is this store hosted on a Windows machine? Does the HTTP_SERVER value found in includes/configure.php use a backslash (\) instead of a forwards slash (/) to identify a sub-directory for the store?

[Nick1973]

Is this store hosted on a Windows machine? Does the HTTP_SERVER value found in includes/configure.php use a backslash (\) instead of a forwards slash (/) to identify a sub-directory for the store?

It's on a Linux Server however the domain name is not live and uses something like http://00.00.00.000/~MYWEBSITE to get to it

[mc12345678]

It's on a Linux Server however the domain name is not live and uses something like http://00.00.00.000/~MYWEBSITE to get to it

And somewhere in ~MYWEBSITE is there a v? Possibly just after the tilde?

[Nick1973]

And somewhere in ~MYWEBSITE is there a v? Possibly just after the tilde?

No there isn't

[mc12345678]

No there isn't

Because of the use of the tilde in the HTTP_SERVER string, recommend modifying:

if (isset($_SERVER['HTTP_REFERER']) && preg_match("~^".HTTP_SERVER."~i", $_SERVER['HTTP_REFERER']) ) {       //if (isset($_SERVER['HTTP_REFERER']) && strstr($_SERVER['HTTP_REFERER'], str_replace(array('http://', 'https://'), '', HTTP_SERVER) ) ) {         $link= $_SERVER['HTTP_REFERER'];       } else {         $link = zen_href_link(FILENAME_DEFAULT);       }       $_SESSION['navigation'] = new navigationHistory;     }

To:

if (isset($_SERVER['HTTP_REFERER']) && preg_match("~^".preg_quote(HTTP_SERVER, "~")."~i", $_SERVER['HTTP_REFERER']) ) {       //if (isset($_SERVER['HTTP_REFERER']) && strstr($_SERVER['HTTP_REFERER'], str_replace(array('http://', 'https://'), '', HTTP_SERVER) ) ) {         $link= $_SERVER['HTTP_REFERER'];       } else {         $link = zen_href_link(FILENAME_DEFAULT);       }       $_SESSION['navigation'] = new navigationHistory;     }

I don't see any other instance on the catalog side where this style of preg_match is used against that specific string. I didn't look on the admin side. Note, that based on the error log that the page to be loaded was a page not found page. Why that particular direction was chosen I do not know based on what has been provided or what has been performed to generate URIs, but the above would prevent running into a clash. An alternative to adding in the preg_quote function is to modify the two uses of the tilde to say a non-uri like character, perhaps a semi-colon (;) or some other "odd" character.

[mc12345678]

Because of the use of the tilde in the HTTP_SERVER string, recommend modifying:

if (isset($_SERVER['HTTP_REFERER']) && preg_match("~^".HTTP_SERVER."~i", $_SERVER['HTTP_REFERER']) ) {       //if (isset($_SERVER['HTTP_REFERER']) && strstr($_SERVER['HTTP_REFERER'], str_replace(array('http://', 'https://'), '', HTTP_SERVER) ) ) {         $link= $_SERVER['HTTP_REFERER'];       } else {         $link = zen_href_link(FILENAME_DEFAULT);       }       $_SESSION['navigation'] = new navigationHistory;     }

To:

if (isset($_SERVER['HTTP_REFERER']) && preg_match("~^".preg_quote(HTTP_SERVER, "~")."~i", $_SERVER['HTTP_REFERER']) ) {       //if (isset($_SERVER['HTTP_REFERER']) && strstr($_SERVER['HTTP_REFERER'], str_replace(array('http://', 'https://'), '', HTTP_SERVER) ) ) {         $link= $_SERVER['HTTP_REFERER'];       } else {         $link = zen_href_link(FILENAME_DEFAULT);       }       $_SESSION['navigation'] = new navigationHistory;     }

I don't see any other instance on the catalog side where this style of preg_match is used against that specific string. I didn't look on the admin side. Note, that based on the error log that the page to be loaded was a page not found page. Why that particular direction was chosen I do not know based on what has been provided or what has been performed to generate URIs, but the above would prevent running into a clash. An alternative to adding in the preg_quote function is to modify the two uses of the tilde to say a non-uri like character, perhaps a semi-colon (;) or some other "odd" character.

I neglected to also state that the specific error encountered in includes/functions/functions_general.php when trying whatever uri on the store was attempted is not directly associated with this plugin as it would have occurred regardless of being installed or not. The cause of getting a page not found error may have been a result of some aspect of its installation (possibly incomplete), incorrect use, or other some other factor, but there has not been sufficient information provided to identify why a page not found response was provided.

Generally speaking when using Zen Cart, it is expected that the uri to the store would be a "full" uri, not one using an ip address/temp folder. There are other threads in the forum where this is discussed and it is not necessarily associated with this plugin. I encourage seeking assistance with this aspect in either an existing thread directly related to the issue or by beginning a new one. Note that while this forum contains a lot of useful information that there are many Internet search tools outside of it that may find related discussions better than the forum's search tool. The recent recommendation of others is to add Zen Cart to the end of any such search.

[Nick1973]

I neglected to also state that the specific error encountered in includes/functions/functions_general.php when trying whatever uri on the store was attempted is not directly associated with this plugin as it would have occurred regardless of being installed or not. The cause of getting a page not found error may have been a result of some aspect of its installation (possibly incomplete), incorrect use, or other some other factor, but there has not been sufficient information provided to identify why a page not found response was provided.

Generally speaking when using Zen Cart, it is expected that the uri to the store would be a "full" uri, not one using an ip address/temp folder. There are other threads in the forum where this is discussed and it is not necessarily associated with this plugin. I encourage seeking assistance with this aspect in either an existing thread directly related to the issue or by beginning a new one. Note that while this forum contains a lot of useful information that there are many Internet search tools outside of it that may find related discussions better than the forum's search tool. The recent recommendation of others is to add Zen Cart to the end of any such search.

Yes totally understand what you are saying but any professional web developer WILL NOT put a url live until it is absolutely completed, and plus there is the problem of google picking up incorrect url's, especially if the site is large and each url has to be generated manually as in the free version of CEON SEO URL's. This is a situation which could in some cases take more than one day, and in which case by that time the google crawler could have then picked up the standard zen cart url. Which then poses a problem as it then means the zen url may then appear in the google search results instead of the CEON URL. That can then take weeks or even months to fix in some cases.

Most professional Web Developers these days develop locally through tools such as MAMP and run PHP and MYSQL on their local machine. Partly because it is faster and partly because of the issues outlined above. Putting a site under a live url while under development can cause endless headaches with SEO later on, which is why there is a need to develop this way. Hence the requirement for 'SOME' modules to work in those kinds of environments and/or under temp url's on a testing environment.

I already use google to do searches and add Zen Cart in that search request to find answers as you are right, there are other places where answers can be found.

[Nick1973]

Does the latest release have all the files in it for a complete installation or is there a requirement to have a previous version installed?

[Nick1973]

Yes totally understand what you are saying but any professional web developer WILL NOT put a url live until it is absolutely completed, and plus there is the problem of google picking up incorrect url's, especially if the site is large and each url has to be generated manually as in the free version of CEON SEO URL's. This is a situation which could in some cases take more than one day, and in which case by that time the google crawler could have then picked up the standard zen cart url. Which then poses a problem as it then means the zen url may then appear in the google search results instead of the CEON URL. That can then take weeks or even months to fix in some cases.

Most professional Web Developers these days develop locally through tools such as MAMP and run PHP and MYSQL on their local machine. Partly because it is faster and partly because of the issues outlined above. Putting a site under a live url while under development can cause endless headaches with SEO later on, which is why there is a need to develop this way. Hence the requirement for 'SOME' modules to work in those kinds of environments and/or under temp url's on a testing environment.

I already use google to do searches and add Zen Cart in that search request to find answers as you are right, there are other places where answers can be found.

I tried your fix and it gave me the same issue, plus it broke the front end.

Essentially are you saying it will work once the website is given a live URL?