Ceon URI Mapping v4.x

[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?

[torvista]

I cast an eye over this thread but get dizzy with the details.

I would say that back in the day it was this mod that required me to use virtual hosts for local development work as detailed in my previous posts. No other method (alias) would work.

Long ago I updated this code for php7 and other bits, and to keep it alive posted it on Github.

I see someone has posted a "new" version in the plugins.
This I have not compared to mine so I cannot vouch for it.

I know mine works....so maybe you should compare it.

[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.

I've now pushed one of the domain names live and still the problem of a blank installation check page exists. So obviously its nothing to do with the tilde.

[mc12345678]

I've now pushed one of the domain names live and still the problem of a blank installation check page exists. So obviously its nothing to do with the tilde.

So you're saying that the error generated is still:

[04-Sep-2018 16:53:54 UTC] Request URI: /~MYWEBSITEDIRECTORY/, IP address: 00.00.00.000
#1  preg_match() called at [/home/MYWEBSITEDIRECTORY/public_html/includes/functions/functions_general.php:1031]
#2  zen_back_link() called at [/home/MYWEBSITEDIRECTORY/public_html/includes/templates/template_default/templates/tpl_page_not_found_default.php:54]
#3  require(/home/MYWEBSITEDIRECTORY/public_html/includes/templates/template_default/templates/tpl_page_not_found_default.php) called at [/home/MYWEBSITEDIRECTORY/public_html/includes/templates/venturezen/common/tpl_main_page.php:179]
#4  require(/home/MYWEBSITEDIRECTORY/public_html/includes/templates/venturezen/common/tpl_main_page.php) called at [/home/vgd/public_html/index.php:97]

[04-Sep-2018 16:53:54 UTC] PHP Warning:  preg_match(): Unknown modifier 'v' in /home/MYWEBSITEDIRECTORY/public_html/includes/functions/functions_general.php on line 1031