webberman Posted May 3, 2007 Share Posted May 3, 2007 I see you're using the default root.php There is a note in the document and in that file:Can you make sure the portion is directly copied from your own application_top.php? Afterwards in the root.php change this code: if ($request_type == 'NONSSL') { define('DIR_WS_CATALOG', DIR_WS_HTTP_CATALOG); } else { define('DIR_WS_CATALOG', DIR_WS_HTTPS_CATALOG); } to this: if ($request_type == 'NONSSL') { define('DIR_WS_CATALOG', DIR_WS_HTTP_CATALOG); $g_relpath = HTTP_SERVER . DIR_WS_CATALOG; $g_server = HTTP_SERVER; } else { define('DIR_WS_CATALOG', DIR_WS_HTTPS_CATALOG); $g_relpath = HTTPS_SERVER . DIR_WS_CATALOG; $g_server = HTTPS_SERVER; } I will update the documentation about it with the next version to clarify it. So far I tried that file here and the part of the application_top.php but I do not see anything wrong. Hi again, I made the changes you gave me to the root file. I'm using the stock OSC applications top file, as I have made no modifications in that file. Anyway after the changes the results were the same. When I turn off the Master SEO- G Switch I get URL's like this: http://uscountyhistories.com/usch/catalog/...?products_id=31 and http://uscountyhistories.com/usch/catalog/shipping.php and the product or page displays properly. When I turn on the SEO- G Master Switch I get URL's like this: http://uscountyhistories.com/usch/catalog/...h-carolina.html and http://uscountyhistories.com/usch/catalog/shipping.html and a Blank page is displayed; whether it is a product or a page like Shipping or Contact Us. Here is the root file as I modified it: <?php /* //---------------------------------------------------------------------------- // Copyright © 2006-2007 Asymmetric Software - Innovation & Excellence // Author: Mark Samios // http://www.asymmetrics.com // SEO-G Root page // Main handler script // Includes part of the includes/application_top.php from osCommerce to // initialize the database. //---------------------------------------------------------------------------- // Script is intended to be used with: // osCommerce, Open Source E-Commerce Solutions // http://www.oscommerce.com // Copyright © 2003 osCommerce //---------------------------------------------------------------------------- // Released under the GNU General Public License //---------------------------------------------------------------------------- // MAKE SURE THE FOLLOWING SECTION IS COPIED DIRECTLY FROM YOUR OWN // catalog\includes\application_top.php // See documentation for details. //---------------------------------------------------------------------------- */ //---------------------------------------------------------------------------- //-MS- Beginning of application_top.php section //---------------------------------------------------------------------------- // start the timer for the page parse time log define('PAGE_PARSE_START_TIME', microtime()); // set the level of error reporting error_reporting(E_ALL & ~E_NOTICE); // check if register_globals is enabled. // since this is a temporary measure this message is hardcoded. The requirement will be removed before 2.2 is finalized. if (function_exists('ini_get')) { ini_get('register_globals') or exit('Server Requirement Error: register_globals is disabled in your PHP configuration. This can be enabled in your php.ini configuration file or in the .htaccess file in your catalog directory.'); } // Set the local configuration parameters - mainly for developers if (file_exists('includes/local/configure.php')) include('includes/local/configure.php'); // include server parameters require('includes/configure.php'); if (strlen(DB_SERVER) < 1) { if (is_dir('install')) { header('Location: install/index.php'); } } // define the project version define('PROJECT_VERSION', 'osCommerce 2.2-MS2'); // set the type of request (secure or not) $request_type = (getenv('HTTPS') == 'on') ? 'SSL' : 'NONSSL'; // set php_self in the local scope if (!isset($PHP_SELF)) $PHP_SELF = $HTTP_SERVER_VARS['PHP_SELF']; if ($request_type == 'NONSSL') { define('DIR_WS_CATALOG', DIR_WS_HTTP_CATALOG); $g_relpath = HTTP_SERVER . DIR_WS_CATALOG; $g_server = HTTP_SERVER; } else { define('DIR_WS_CATALOG', DIR_WS_HTTPS_CATALOG); $g_relpath = HTTPS_SERVER . DIR_WS_CATALOG; $g_server = HTTPS_SERVER; } // include the list of project filenames require(DIR_WS_INCLUDES . 'filenames.php'); // include the list of project database tables require(DIR_WS_INCLUDES . 'database_tables.php'); // customization for the design layout define('BOX_WIDTH', 125); // how wide the boxes should be in pixels (default: 125) // include the database functions require(DIR_WS_FUNCTIONS . 'database.php'); // make a connection to the database... now tep_db_connect() or die('Unable to connect to database server!'); // set the application parameters $configuration_query = tep_db_query('select configuration_key as cfgKey, configuration_value as cfgValue from ' . TABLE_CONFIGURATION); while ($configuration = tep_db_fetch_array($configuration_query)) { define($configuration['cfgKey'], $configuration['cfgValue']); } //---------------------------------------------------------------------------- //-MS- End of application_top.php section //---------------------------------------------------------------------------- //---------------------------------------------------------------------------- // SEO-G Section starts here. This part is required for proper operation // Do not override the code below //---------------------------------------------------------------------------- require(DIR_WS_CLASSES . 'seo_url.php'); $g_seo_url = new seoURL; $osc_url = $osc_params = $osc_parse = ''; if( $g_seo_url->get_osc_url($g_server . $_SERVER['REQUEST_URI'], $osc_url, $osc_params, $osc_parse) ) { $PHP_SELF = $HTTP_SERVER_VARS['PHP_SELF'] = $_SERVER['PHP_SELF'] = $_SERVER['SCRIPT_NAME'] = $osc_parse['path']; if(basename($_SERVER['PHP_SELF']) == 'root.php' ) { exit(); } for($i=0, $j=count($osc_params); $i<$j; $i++ ) { $array_equal = explode('=', $osc_params[$i]); if( is_array($array_equal) ) { if( isset($array_equal[1]) ) { $HTTP_GET_VARS[$array_equal[0]] = $array_equal[1]; $_GET[$array_equal[0]] = $array_equal[1]; } else { $HTTP_GET_VARS[$array_equal[0]] = ''; $_GET[$array_equal[0]] = ''; } } } $g_script = basename($PHP_SELF); $g_seo_flag = true; require(basename($PHP_SELF)); } elseif( file_exists(basename($osc_parse['path']))) { $PHP_SELF = $HTTP_SERVER_VARS['PHP_SELF'] = $_SERVER['PHP_SELF'] = $_SERVER['SCRIPT_NAME'] = $osc_parse['path']; if(basename($_SERVER['PHP_SELF']) == 'root.php' ) { exit(); } $g_script = basename($PHP_SELF); $g_seo_flag = true; require(basename($osc_parse['path'])); } else { // Script not found. Initiate redirection header("HTTP/1.1 " . SEO_DEFAULT_ERROR_HEADER); header('Location: ' . $g_relpath . SEO_DEFAULT_ERROR_REDIRECT); } exit(); ?> When I preview this post the SEO- G URL appeared differently than what I typed for the post! This part ->: catalog/...h-carolina.html should have appeared as ->: catalog/product_history-of-edgecombe-county-north-carolina.html Thanks for helping Quote Link to comment Share on other sites More sharing options...
Guest Posted May 3, 2007 Share Posted May 3, 2007 (edited) Hi again, I made the changes you gave me to the root file. I'm using the stock OSC applications top file, as I have made no modifications in that file. Anyway after the changes the results were the same. When I turn off the Master SEO- G Switch I get URL's like this: http://uscountyhistories.com/usch/catalog/...?products_id=31 and http://uscountyhistories.com/usch/catalog/shipping.php and the product or page displays properly. When I turn on the SEO- G Master Switch I get URL's like this: http://uscountyhistories.com/usch/catalog/...h-carolina.html and http://uscountyhistories.com/usch/catalog/shipping.html and a Blank page is displayed; whether it is a product or a page like Shipping or Contact Us. Here is the root file as I modified it: After checking your store I also thought of something else. It's possible your host performs a redirect here: RewriteRule ^(.*).html$ root.php?%{QUERY_STRING} I don't know why they would do something like that, but ended up with the $_SERVER array not showing anywhere the URL/path typed on the browser. (specifically the REQUEST_URI where according to php manual: http://www.php.net/reserved.variables) 'REQUEST_URI'The URI which was given in order to access this page; for instance, '/index.html'. In your case it was showing the root.php so it crossed my mind it could had happened if a redirect took place from some script your host may have in place. The rewrite rule as is above won't issue a redirect. For this type of problems you can modify the root.php to print some error message so it can help with its resolution. So change the 2 instances where currently root.php exits silently: The first from: if(basename($_SERVER['PHP_SELF']) == 'root.php' ) { exit(); } to: if(basename($_SERVER['PHP_SELF']) == 'root.php' ) { echo '<b>SEO-G Error</b>: Invalid Self-Request - Check recorded URLs'; exit(); } and the second instance from: if(basename($_SERVER['PHP_SELF']) == 'root.php' ) { exit(); } to: if(basename($_SERVER['PHP_SELF']) == 'root.php' ) { echo '<b>SEO-G Error</b>: Invalid Self-Request, passed URI Request: ' . $_SERVER['REQUEST_URI']; exit(); } I will also include it with the next version. Edited May 3, 2007 by enigma1 Quote Link to comment Share on other sites More sharing options...
WebbyIT Posted May 3, 2007 Share Posted May 3, 2007 At the end of the order process when you click on the "Continue" button on the checkout_success page(4th step-'Finished'), with the SEO-G master switch set to true, you are taken to the SEO-G redirect page (Default-cookie_usage.php) instead of the index. I ran through the order process a second time with SEO-G master switch set to false and the "Continue" button works correctly (sends you to the index). In the known issues section of the readme.htm you mention problems with this page but I don't know if this issue is related. Should I just change the link or are there other isssues that I need to deal with to resolve a bigger issue? Quote Link to comment Share on other sites More sharing options...
Guest Posted May 4, 2007 Share Posted May 4, 2007 since there is an issue with the final notification form in catalog\checkout_success.php I would recommend to use the exclusion list and insert the checkout_success.php. But if you're in safe mode you shouldn't need to do anything as these pages won't be processed at all. Quote Link to comment Share on other sites More sharing options...
WebbyIT Posted May 4, 2007 Share Posted May 4, 2007 since there is an issue with the final notification form in catalog\checkout_success.php I would recommend to use the exclusion list and insert the checkout_success.php. But if you're in safe mode you shouldn't need to do anything as these pages won't be processed at all.This happened with Safe Mode set to true and all the "checkout_?" pages on the exclude list already. Quote Link to comment Share on other sites More sharing options...
Guest Posted May 4, 2007 Share Posted May 4, 2007 This happened with Safe Mode set to true and all the "checkout_?" pages on the exclude list already. I cannot replicate it here (regardless of the exclusion list), what other modules you have that may affect the checkout_sucess.php page? And what version of the module are you're using v1.11? Quote Link to comment Share on other sites More sharing options...
WebbyIT Posted May 4, 2007 Share Posted May 4, 2007 I cannot replicate it here (regardless of the exclusion list), what other modules you have that may affect the checkout_sucess.php page? And what version of the module are you're using v1.11?V1.10 I don't know of any mods that would affect the checkout_success page. Is it possible that the problem is with the redirect, tep_redirect(tep_href_link(FILENAME_DEFAULT, $notify_string) Quote Link to comment Share on other sites More sharing options...
webberman Posted May 4, 2007 Share Posted May 4, 2007 After checking your store I also thought of something else. It's possible your host performs a redirect here:RewriteRule ^(.*).html$ root.php?%{QUERY_STRING} I don't know why they would do something like that, but ended up with the $_SERVER array not showing anywhere the URL/path typed on the browser. (specifically the REQUEST_URI where according to php manual: http://www.php.net/reserved.variables) In your case it was showing the root.php so it crossed my mind it could had happened if a redirect took place from some script your host may have in place. The rewrite rule as is above won't issue a redirect. For this type of problems you can modify the root.php to print some error message so it can help with its resolution. So change the 2 instances where currently root.php exits silently: The first from: if(basename($_SERVER['PHP_SELF']) == 'root.php' ) { exit(); } to: if(basename($_SERVER['PHP_SELF']) == 'root.php' ) { echo '<b>SEO-G Error</b>: Invalid Self-Request - Check recorded URLs'; exit(); } and the second instance from: if(basename($_SERVER['PHP_SELF']) == 'root.php' ) { exit(); } to: if(basename($_SERVER['PHP_SELF']) == 'root.php' ) { echo '<b>SEO-G Error</b>: Invalid Self-Request, passed URI Request: ' . $_SERVER['REQUEST_URI']; exit(); } I will also include it with the next version. Changing the root.php file resulted in the following message: SEO-G Error: Invalid Self-Request, passed URI Request: /usch/catalog/root.php Quote Link to comment Share on other sites More sharing options...
AoM_Scott Posted May 4, 2007 Share Posted May 4, 2007 This is a great contribution :thumbsup: but for future reference in order to use Chemo's Page Cache contribution, I had to change the root.php file like so: $query_string = ''; for($i=0, $j=count($osc_params); $i<$j; $i++ ) { $array_equal = explode('=', $osc_params[$i]); if( is_array($array_equal) ) { if( isset($array_equal[1]) ) { $HTTP_GET_VARS[$array_equal[0]] = $array_equal[1]; $_GET[$array_equal[0]] = $array_equal[1]; } else { $HTTP_GET_VARS[$array_equal[0]] = ''; $_GET[$array_equal[0]] = ''; } } if ($i !== 0) { $query_string .= '&'; } $query_string .= $osc_params[$i]; } $HTTP_SERVER_VARS['QUERY_STRING'] = $_SERVER['QUERY_STRING'] = $query_string; This is so the correct $_SERVER['QUERY_STRING'] is used to cache variations of pages. Scott Quote no outside links please Link to comment Share on other sites More sharing options...
Guest Posted May 4, 2007 Share Posted May 4, 2007 V1.10 I don't know of any mods that would affect the checkout_success page. Is it possible that the problem is with the redirect, tep_redirect(tep_href_link(FILENAME_DEFAULT, $notify_string) can you post your checkout_success.php? I will try it here see if I can replicate it. I don't think is the redirect alone because it used in other places throughout your store. You have anything else that alters the tep_href_link function in html_output.php? Quote Link to comment Share on other sites More sharing options...
Guest Posted May 4, 2007 Share Posted May 4, 2007 (edited) This is a great contribution :thumbsup: but for future reference in order to use Chemo's Page Cache contribution, I had to change the root.php file like so: $query_string = ''; for($i=0, $j=count($osc_params); $i<$j; $i++ ) { $array_equal = explode('=', $osc_params[$i]); if( is_array($array_equal) ) { if( isset($array_equal[1]) ) { $HTTP_GET_VARS[$array_equal[0]] = $array_equal[1]; $_GET[$array_equal[0]] = $array_equal[1]; } else { $HTTP_GET_VARS[$array_equal[0]] = ''; $_GET[$array_equal[0]] = ''; } } if ($i !== 0) { $query_string .= '&'; } $query_string .= $osc_params[$i]; } $HTTP_SERVER_VARS['QUERY_STRING'] = $_SERVER['QUERY_STRING'] = $query_string; This is so the correct $_SERVER['QUERY_STRING'] is used to cache variations of pages. Scott Yes this is true, I will include it with the next version. Thanks a lot. Also have a look in the Cache HTML and Advanced Cache. They provide separate cache layers in addition to the page cache. http://www.oscommerce.com/community/contributions,5029 http://www.oscommerce.com/community/contributions,2873 Edited May 4, 2007 by enigma1 Quote Link to comment Share on other sites More sharing options...
Guest Posted May 4, 2007 Share Posted May 4, 2007 (edited) Changing the root.php file resulted in the following message: SEO-G Error: Invalid Self-Request, passed URI Request: /usch/catalog/root.php Yes, I know, that's what I saw which indicates some sort of redirection when the rewriterule is executed with the script your host has. Because I checked the request_uri before the rule executed and was correct. Afterwards it changed. So again your host should have a answer about it. None of the server variables had the originally typed url in. Edited May 4, 2007 by enigma1 Quote Link to comment Share on other sites More sharing options...
emax75 Posted May 4, 2007 Share Posted May 4, 2007 Hy, SEO-G is implemented for multilanguage ? ex : www.site.it/en/brand/prod.htm or www.site.it/it/firma/prd.htm ? Tanks Ema Quote Link to comment Share on other sites More sharing options...
AoM_Scott Posted May 4, 2007 Share Posted May 4, 2007 Yes this is true, I will include it with the next version. Thanks a lot. Also have a look in the Cache HTML and Advanced Cache. They provide separate cache layers in addition to the page cache. http://www.oscommerce.com/community/contributions,5029 http://www.oscommerce.com/community/contributions,2873 Thanks, I've seen both of those caches before. Your Cache HTML I recently installed just yesterday and the other I have yet to look into, as I assume it requires you to decide parts to be cached. Cache HTML does look like an interesting client side solution but I've yet to completely get my head around the configuration and workings. I also fear that a contribution or piece of code will not get executed server side because of my poor configuration so I have temporarily disabled it (probably best as the new store in question is still under development). Scott Quote no outside links please Link to comment Share on other sites More sharing options...
WebbyIT Posted May 4, 2007 Share Posted May 4, 2007 can you post your checkout_success.php? I will try it here see if I can replicate it. I don't think is the redirect alone because it used in other places throughout your store. You have anything else that alters the tep_href_link function in html_output.php?I updated to V1.11. In an attempt to isolate the problem, I loaded checkout_success.php,v 1.49 from BU of original install but the "Continue" button problem persists. My html_output.php is the same as your version in 1.11 except for 2 changes in the image size function that are inconsequential. I uploaded html_output.php from V1.11 to confirm. If I rem out "// $link = $g_seo_url->get_seo_url($link, $separator);" in html_output.php the "Continue" button functions correctly. Quote Link to comment Share on other sites More sharing options...
Guest Posted May 4, 2007 Share Posted May 4, 2007 I updated to V1.11. In an attempt to isolate the problem, I loaded checkout_success.php,v 1.49 from BU of original install but the "Continue" button problem persists. My html_output.php is the same as your version in 1.11 except for 2 changes in the image size function that are inconsequential. I uploaded html_output.php from V1.11 to confirm. If I rem out "// $link = $g_seo_url->get_seo_url($link, $separator);" in html_output.php the "Continue" button functions correctly. what's the "BU" have you tried the stock osc one? See if it works with that one then tell me the exact link or post your checkout_success.php here. http://www.oscommerce.com/solutions/downloads And also try to see if the notification string causes this. In the checkout_success.php change: tep_redirect(tep_href_link(FILENAME_DEFAULT, $notify_string)); to tep_redirect(tep_href_link(FILENAME_DEFAULT)); Does it work in that case? Quote Link to comment Share on other sites More sharing options...
Guest Posted May 4, 2007 Share Posted May 4, 2007 Hy,SEO-G is implemented for multilanguage ? ex : www.site.it/en/brand/prod.htm or www.site.it/it/firma/prd.htm ? Tanks Ema No, it's not. Quote Link to comment Share on other sites More sharing options...
WebbyIT Posted May 4, 2007 Share Posted May 4, 2007 what's the "BU" have you tried the stock osc one? See if it works with that one then tell me the exact link or post your checkout_success.php here.http://www.oscommerce.com/solutions/downloads That's what I did to isolate the problem to see if any mods in my checkout_success.php were causing the problem. Sorry I was not clear. BU=backup. I used the stock checkout_success.php,v 1.49, from a backup I made when OSC was first installed to confirm that any mods made subsequently were not causing the problem. And also try to see if the notification string causes this. In the checkout_success.php change: tep_redirect(tep_href_link(FILENAME_DEFAULT, $notify_string)); to tep_redirect(tep_href_link(FILENAME_DEFAULT)); Does it work in that case? Making this change does not resolve issue. Quote Link to comment Share on other sites More sharing options...
Guest Posted May 4, 2007 Share Posted May 4, 2007 (edited) That's what I did to isolate the problem to see if any mods in my checkout_success.php were causing the problem. Sorry I was not clear. BU=backup. I used the stock checkout_success.php,v 1.49, from a backup I made when OSC was first installed to confirm that any mods made subsequently were not causing the problem. Making this change does not resolve issue. well one other thing I noticed was with ssl pages. It is critical that with SSL pages the $request_type variable is identified correctly inside the root.php and application_top.php for SEO-G to work properly. If you have your SSL pages filtered through SEO-G and it does not work, it could explain this issue. Are you on SSL? The default code: // set the type of request (secure or not) $request_type = (getenv('HTTPS') == 'on') ? 'SSL' : 'NONSSL'; not always works because it's host dependent. In some cases you should use: $request_type = (getenv('HTTP_X_FORWARDED_HOST') == 'secure_domain_goes_here') ? 'SSL' : 'NONSSL'; and some other cases: $request_type = (getenv('SERVER_PORT') == '443') ? 'SSL' : 'NONSSL'; so the secure port/domain is sever dependent. I will make few notes with the next release but you could try and confirm this. Edited May 4, 2007 by enigma1 Quote Link to comment Share on other sites More sharing options...
WebbyIT Posted May 4, 2007 Share Posted May 4, 2007 well one other thing I noticed was with ssl pages. It is critical that with SSL pages the $request_type variable is identified correctly inside the root.php and application_top.php for SEO-G to work properly. If you have your SSL pages filtered through SEO-G and it does not work, it could explain this issue. Are you on SSL? I have an active SSL cert on the site but since this is a remodel of an existing (active) site I can't transfer the domain name until it is done. Since the active SSL cert is tied to the domain name, but the site is tied to the IP for development, it may be causing a problem. Until I migrate to the new site and the SSL cert is recognized, I don't know if we will be able to resolve this unless you think it is worth messing with before migrating and you know of a way to troubleshoot under these circumstances. The default code: // set the type of request (secure or not) $request_type = (getenv('HTTPS') == 'on') ? 'SSL' : 'NONSSL'; not always works because it's host dependent. In some cases you should use: $request_type = (getenv('HTTP_X_FORWARDED_HOST') == 'secure_domain_goes_here') ? 'SSL' : 'NONSSL'; and some other cases: $request_type = (getenv('SERVER_PORT') == '443') ? 'SSL' : 'NONSSL'; so the secure port/domain is sever dependent. I will make few notes with the next release but you could try and confirm this. I will do whatever I can to help this project, which is why I brought this to your attention instead of just manually changing the link, but I don't know if being set up for the SSL cert without it being recognized will enable us to get accurate results to work from. Quote Link to comment Share on other sites More sharing options...
Guest Posted May 4, 2007 Share Posted May 4, 2007 (edited) I have an active SSL cert on the site but since this is a remodel of an existing (active) site I can't transfer the domain name until it is done. Since the active SSL cert is tied to the domain name, but the site is tied to the IP for development, it may be causing a problem. Until I migrate to the new site and the SSL cert is recognized, I don't know if we will be able to resolve this unless you think it is worth messing with before migrating and you know of a way to troubleshoot under these circumstances. I will do whatever I can to help this project, which is why I brought this to your attention instead of just manually changing the link, but I don't know if being set up for the SSL cert without it being recognized will enable us to get accurate results to work from. Ok first let make sure the SSL has something to do with it. So change your catalog\includes\configure.php set enable ssl directive to false. define('ENABLE_SSL', false); // secure webserver for checkout procedure? Then put an item to the cart, go through the checkout (verify the pages show the regular http://), see if you're getting the same problem. If you do, is not the ssl so we have to look elsewhere. Edited May 4, 2007 by enigma1 Quote Link to comment Share on other sites More sharing options...
WebbyIT Posted May 4, 2007 Share Posted May 4, 2007 Ok first let make sure the SSL has something to do with it. So change your catalog\includes\configure.php set enable ssl directive to false. define('ENABLE_SSL', false); // secure webserver for checkout procedure? Then put an item to the cart, go through the checkout (verify the pages show the regular http://), see if you're getting the same problem. If you do, is not the ssl so we have to look elsewhere. It works with SSL set to false. Quote Link to comment Share on other sites More sharing options...
Guest Posted May 4, 2007 Share Posted May 4, 2007 It works with SSL set to false. ok so it is the SSL and the $request_type variable is not identified properly. That's what I saw in a couple of other cases. So you need to identify it. Create a simple script (say server_info.php) with the following code: <?php phpinfo(); ?> place it in the catalog folder. Then call it with the browser with the secure url. like https://mysite321.com/server_info.php Next identify what are the server variables for the SSL, so scroll down to php variables see what it shows there that matches one of the above secure samples I posted. Is there a _SERVER["HTTPS"] or a reference to 443 or 'HTTP_X_FORWARDED_HOST' There must be a parameter there. That parameter needs to go into application_top.php and root.php as I mentioned earlier. So the $request_type will be identified accurately. Once you do that you will be able to use the secure pages without problem. It's server dependent and with the next release I will place few notes about it as well as update the seo url class to handle some extra cases. Quote Link to comment Share on other sites More sharing options...
WebbyIT Posted May 4, 2007 Share Posted May 4, 2007 Next identify what are the server variables for the SSL, so scroll down to php variables see what it shows there that matches one of the above secure samples I posted. Is there a _SERVER["HTTPS"]or a reference to 443 or 'HTTP_X_FORWARDED_HOST' There must be a parameter there. That parameter needs to go into application_top.php and root.php as I mentioned earlier. So the $request_type will be identified accurately. Once you do that you will be able to use the secure pages without problem. It's server dependent and with the next release I will place few notes about it as well as update the seo url class to handle some extra cases. The only thing I see are the environment and server variables for port 443 _ENV["SERVER_PORT"] 443 and _SERVER["SERVER_PORT"] 443 Should I contact the website host? Quote Link to comment Share on other sites More sharing options...
Guest Posted May 4, 2007 Share Posted May 4, 2007 (edited) The only thing I see are the environment and server variables for port 443 _ENV["SERVER_PORT"] 443 and _SERVER["SERVER_PORT"] 443 Should I contact the website host? not really you don't need them because you have the info now. so the request type should be: // $request_type = (getenv('HTTPS') == 'on') ? 'SSL' : 'NONSSL'; $request_type = (getenv('SERVER_PORT') == '443') ? 'SSL' : 'NONSSL'; in both application_top.php and root.php just comment the other lines out and use it as shown above. Then re-enable the ssl in the configure.php and test the checkout. I think it should go through without problems because the $request_type variable is identified properly. Edited May 4, 2007 by enigma1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.