Jump to content
Sign in to follow this  
enigma1

[Contribution] SEO-G

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

Share this post


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

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
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)

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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?

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×