Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Serious issues with PHP v4.3.0


dreamscape

Recommended Posts

sorry if this is a double post, but I swore there was a thread on php v4.3.0 and searching turn up nothing at all and I've gone through the last 50 or so pages of threads and didn't find it.

 

anyways my host just upgraded to PHP v4.3.0... the admin works fine, but my catalog is dead.

 

IE 6.0 returns a blank page.

 

NS7 returns this:

Query was empty - Query was empty

 

Query was empty

 

[TEP STOP]

 

Opera 6.0 returns this:

Query was empty - Query was empty

 

Query was empty

 

[TEP STOP]

 

Query was empty - Query was empty

 

Query was empty

 

[TEP STOP]

 

 

Warning: Unknown(): A session is active. You cannot change the session module's ini settings at this time. in Unknown on line 0

 

what in gods name is going on

The only thing necessary for evil to flourish is for good men to do nothing

- Edmund Burke

Link to comment
Share on other sites

  • Replies 65
  • Created
  • Last Reply

Joshua;

 

Try this one http://www.oscommerce.com/forums/viewtopic.php...ght=upgrade+php

I don't know if it addresses your specific issue, but there are links in it to a couple of additional threads.

... if you want to REALLY see something that doesn't set up right out of the box without some tweaking,

try being a Foster Parent!

Link to comment
Share on other sites

no those didn't help at all...

 

I think the problem may be that PHP v4.3.0 no longer supports the global variables like $HTTP_POST_VARS, etc... instead it only uses there other (newer) form: $_POST, etc... (I think so anyways... I read that somewhere)...

 

I used dreamweaver to change all the unsupported superglobals to their supported versions... I am uploading now and hopefully that will fix the problem. If it does I will post back here with all the superglobal variables that needed changed and what they were changed to.

The only thing necessary for evil to flourish is for good men to do nothing

- Edmund Burke

Link to comment
Share on other sites

yes yes that was it... apparently PHP v4.3.0 no longer supports the old superglobals and only uses there newer versions introduced in php v4.1

 

anyone running PHP v4.3:

Change all instances the superglobals to their new versions

 

$HTTP_SERVER_VARS -> $_SERVER

$HTTP_ENV_VARS -> $_ENV

$HTTP_COOKIE_VARS -> $_COOKIE

$HTTP_GET_VARS -> $_GET

$HTTP_POST_VARS -> $_POST

$HTTP_POST_FILES -> $_FILES

$HTTP_SESSION_VARS -> $_SESSION

 

using a program that can search over multiple files and replace all instances, this only takes about 5 minutes. I used dreamweavers option to search and replace all in the current local site.

 

PLEASE PLEASE for the love of god can we get this made into a sticky. As new hosts switch over to PHP v4.3.0, inevitably people will encounter problems because OSC still favors the old superglobals. We have the solution here (until OSC switches to the new superglobals), so there is no viable reason that people should not be informed of this, unless it gets pushed into the depths of the forum... so PLEASE PLEASE make this a sticky in one of the forums somewhere.

The only thing necessary for evil to flourish is for good men to do nothing

- Edmund Burke

Link to comment
Share on other sites

Hi,

 

In PHP 4.2.0 and later, the default value for the PHP directive register_globals is off. This is a major change in PHP. Having register_globals off affects the set of predefined variables available in the global scope. For example, to get DOCUMENT_ROOT you'll use $_SERVER['DOCUMENT_ROOT'] instead of $DOCUMENT_ROOT, or $_GET['id'] from the URL http://www.example.com/test.php?id=3 instead of $id, or $_ENV['HOME'] instead of $HOME.

 

Click here for more detail:

http://www.php.net/manual/en/language.vari....predefined.php

 

All you need to do is to set register_globals to on in your php.ini.

 

If you don't have access to php.ini, then you can set it in your .htaccess file:

php_flag register_globals on

 

Regards,

Bn

Link to comment
Share on other sites

My host has made the change to 4.3.0 - aarrgggg!

 

I only new about it when customers came to me several days later complaining they couldn't get through the checkout process!

 

I'm ready and willing to change all the 'superglobals' on my site, but I have one small problem -

 

what exactly is a superglobal ???? - ie what should I be looking for and what should I be changing this to ?

 

 

Ta much

Brian

Link to comment
Share on other sites

what exactly is a superglobal ???? - ie what should I be looking for and what should I be changing this to ?

 

 

Ta much

Brian

 

do you not see the list I posted? here I will post it again:

 

Change all instances the superglobals to their new versions

 

$HTTP_SERVER_VARS -> $_SERVER

$HTTP_ENV_VARS -> $_ENV

$HTTP_COOKIE_VARS -> $_COOKIE

$HTTP_GET_VARS -> $_GET

$HTTP_POST_VARS -> $_POST

$HTTP_POST_FILES -> $_FILES

$HTTP_SESSION_VARS -> $_SESSION

The only thing necessary for evil to flourish is for good men to do nothing

- Edmund Burke

Link to comment
Share on other sites

All you need to do is to set register_globals to on in your php.ini.

 

If you don't have access to php.ini, then you can set it in your .htaccess file:

php_flag register_globals on

 

Regards,

Bn

 

I don't think that is true at all. register_globals is turned on with my host and the $HTTP_whatever vars don't work at all... I've read they are NOT supported at all in PHP v4.3.0. I will try and find the article i read this in.

The only thing necessary for evil to flourish is for good men to do nothing

- Edmund Burke

Link to comment
Share on other sites

opps I was just being a bit thick :oops:

 

I understand now that instances of

 

$HTTP_SERVER_VARS should be replaced with $_SERVER

 

etc etc ....

 

For those of us new to php, this wasn't clear - but thanks for the help anyway :D

Link to comment
Share on other sites

You are correct the old $HTTP_XXXX_PHP variable arrays were actually deprecated in PHP 4.1.0 and eliminated completely in 4.3.0.

 

OSCommerce uses them to be backwards compatible with PHP 3.0. Performing the change listed above can help or you can assign the new variables back to their deprecated counterparts in catalog/includes/application_top.php which should also solve the problem as long as register_globals is on which OSC requires anyway at this time. It is unfortunate that the work to make register_globals = Off the standard for OSC is relegated to MS4 especially since register_globals leads to 95% of all PHP exploits on the Internet and is a major security risk.

Link to comment
Share on other sites

....or you can assign the new variables back to their deprecated counterparts in catalog/includes/application_top.php ...

 

I did as Wayne recommended and put he following code in application_top.php at the beginning....

 

$HTTP_SERVER_VARS = $_SERVER;

$HTTP_ENV_VARS = $_ENV;

$HTTP_COOKIE_VARS = $_COOKIE;

$HTTP_GET_VARS = $_GET;

$HTTP_POST_VARS = $_POST;

$HTTP_POST_FILES = $_FILES;

$HTTP_SESSION_VARS = $_SESSION;

 

However I am still getting the following error when a customer clicks continue on the credit card payment page (which goes to checkout_confirmation.php):

Error!

 

Unable to determine the page link!

 

Query was empty - Query was empty

 

Query was empty

 

[TEP STOP]

 

 

Warning: Unknown(): A session is active. You cannot change the session module's ini settings at this time. in Unknown on line 0

 

I believe this is coming from html_output.php and a printing the variables sent to that script produced the following:

 

page: ../index.php parameters:

page: checkout_address.php parameters:

page: 1 parameters: 1

 

Obviously it is the third call that is causing the page not found error, but this is called from so many places, I have not been able to find the error.

 

Any help would be greatly appreciated.

Link to comment
Share on other sites

I'm now getting a strange error - that I believe is related.

 

When choosing cc as the payment method, the user is being returned to the default(main) page - but here's the really strange thing - if you persevere and try to go through the payment process again - it is successful on the third attempt !

 

Can anyone suggest anything on this ?

Link to comment
Share on other sites

I've solved my strange error by disabling cift certificates and discount coupons - there must be some code in here that is affected by the changes in php 4.3.0

 

This may be a quick fix for anyone experiencing similar problems.

Link to comment
Share on other sites

 

I did as Wayne recommended and put he following code in application_top.php at the beginning....

 

$HTTP_SERVER_VARS = $_SERVER;

$HTTP_ENV_VARS = $_ENV;

$HTTP_COOKIE_VARS = $_COOKIE;

$HTTP_GET_VARS = $_GET;

$HTTP_POST_VARS = $_POST;

$HTTP_POST_FILES = $_FILES;

$HTTP_SESSION_VARS = $_SESSION;

 

 

Query was empty - Query was empty

 

Query was empty

 

[TEP STOP]

 

 

after doing all this I'm still getting this error , sometime I get this error on first someone not, this is really frustrated. I think Development Team need to make a sticky.. I need a solution, loosing money every second

Link to comment
Share on other sites

I was successful in persuading my hosting service to rollback to PHP 4.2.3. and everything now functions fine, including the code that reassigns the superglobals to $http _xxxx_vars. Nevertheless, for security reasons they wish to move to 4.3.1 shortly. It is important we find a solution to this problem in the near future. I have personally spent many hours tryingto debug this, but unsuccessfully. I have 4 years PHP experience and have modified OScommerce extensively, but this has me stumped! I agree that the OScommerce developers need to resolve this, or OScommerce will wither on the vine if it cannot function under new PHP releases.

Link to comment
Share on other sites

I was successful in persuading my hosting service to rollback to PHP 4.2.3. and everything now functions fine, including the code that reassigns the superglobals to $http _xxxx_vars. Nevertheless, for security reasons they wish to move to 4.3.1 shortly. It is important we find a solution to this problem in the near future. I have personally spent many hours tryingto debug this, but unsuccessfully. I have 4 years PHP experience and have modified OScommerce extensively, but this has me stumped! I agree that the OScommerce developers need to resolve this, or OScommerce will wither on the vine if it cannot function under new PHP releases.

 

I agree , Oscommerce should Fix this problem

Link to comment
Share on other sites

Hi,

 

I have apache 1.3.27 and php 4.2.3.

 

After reading these posts I changed all these variables in my test site.

$HTTP_SERVER_VARS -> $_SERVER

$HTTP_ENV_VARS -> $_ENV

$HTTP_COOKIE_VARS -> $_COOKIE

$HTTP_GET_VARS -> $_GET

$HTTP_POST_VARS -> $_POST

$HTTP_POST_FILES -> $_FILES

$HTTP_SESSION_VARS -> $_SESSION

 

I left another site as is to test.

 

I then went to php.ini on my server and turned register_globals to Off

 

Both stores are working, one with the new superglobals and the one without.

 

If I upgrade to php 4.3 in the future I am guessing I will need to change all my sites to the superglobals...is this correct?

 

Is there any effect down the road by changing to the new superglobals and keeping php 4.2.3?

 

Is there anything else I need to change along with these superglobals?

 

Just want to be prepared.

 

Thanks!

Link to comment
Share on other sites

I agree , Oscommerce should Fix this problem

 

Don't hate me, but I have had absolutely no problems with 4.3.0 and 4.3.1 - all that I changed in php.ini was the register globals parameter.

 

I don't see the $HTTP_*_VARS disappearing for good anytime soon.

 

BTW, doing $HTTP_*_VARS = $_* is a bad thing. Instead the following should be done (where/when necessary):

 

$HTTP_GET_VARS =& $_GET;

....

 

Ie, they should be references, not copies.

:heart:, osCommerce

Link to comment
Share on other sites

I agree , Oscommerce should Fix this problem

 

Don't hate me, but I have had absolutely no problems with 4.3.0 and 4.3.1 - all that I changed in php.ini was the register globals parameter.

 

I don't see the $HTTP_*_VARS disappearing for good anytime soon.

 

BTW, doing $HTTP_*_VARS = $_* is a bad thing. Instead the following should be done (where/when necessary):

 

$HTTP_GET_VARS =& $_GET;

....

 

Ie, they should be references, not copies.

Herald

Thanks, I will do replace

$HTTP_GET_VARS =& $_GET;

 

Since I'm on shared hosting how do I change php.ini file. Do I have to change register globals to OFF mode or ON

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...