Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

[Contribution] SEO-G


Guest

Recommended Posts

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

Link to comment
Share on other sites

  • Replies 1.1k
  • Created
  • Last Reply

Top Posters In This Topic

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 by enigma1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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)
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

no outside links please

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by enigma1
Link to comment
Share on other sites

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 by enigma1
Link to comment
Share on other sites

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

no outside links please

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.
Link to comment
Share on other sites

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 by enigma1
Link to comment
Share on other sites

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.
Link to comment
Share on other sites

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 by enigma1
Link to comment
Share on other sites

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.
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?
Link to comment
Share on other sites

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 by enigma1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...