Upgrading to PHP 5.3.x

[laurelsstitchery]

I'm using Zencart 1.5.1. Upgraded from 1.5.0 using official procedures.

My webhost is getting ready to stop supporting PHP 5.2 (I'm currently using 5.2.17). They automatically upgraded me to 5.3.27 and I was having an issue with a random error as detailed here: http://www.zen-cart.com/showthread.p...eckout-process, so I downgraded back to 5.2.17 and have had zero problems since then.

I would like to upgrade back to 5.3.x, since they're not going to be supporting 5.2.x, but I need to know if there's anything special I'm supposed to do on the zencart side before or after I change the PHP version. Thanks! :)

[RixStix]

Can't really help with your specific question but our host has been running php 5.3.21 for quite a while and we haven't knowingly done anything different.

Host has upgrade to 5.3.27 scheduled for this week since anything less will now fail a PCI scan with the highest level of vulnerability.

Host upgrade to 5.4.x will require patching according to This Doc

[RodG]

I need to know if there's anything special I'm supposed to do on the zencart side before or after I change the PHP version. Thanks!

Nothing as far as I'm aware of. Is there anything in the error log files to provide a clue?

Since yours seems to be a 'random' problem, my thoughts are along the lines that it probably has something to do with the SESSION data/handling.

Probably a longshot, but with *one* of the many hosts I've worked on I came across a problem where the admin sessions were timing out prematurely, and I traced this back to the PHP session.gc_maxlifetime being set to an abnormally low value as a result of a PHP upgrade.
http://stackoverflow.com/questions/3...ut-too-quickly

Although I state this was a problem with the admin functions, it is quite likely that a similar issue would have been occurring with the non admin functions as well and the admin simply noted the problem before any customers reported it as an issue.

As I say, it's a longshot....

Cheers
RodG

[laurelsstitchery]

Nothing as far as I'm aware of. Is there anything in the error log files to provide a clue?

Since yours seems to be a 'random' problem, my thoughts are along the lines that it probably has something to do with the SESSION data/handling.

Probably a longshot, but with *one* of the many hosts I've worked on I came across a problem where the admin sessions were timing out prematurely, and I traced this back to the PHP session.gc_maxlifetime being set to an abnormally low value as a result of a PHP upgrade.
http://stackoverflow.com/questions/3...ut-too-quickly

Although I state this was a problem with the admin functions, it is quite likely that a similar issue would have been occurring with the non admin functions as well and the admin simply noted the problem before any customers reported it as an issue.

As I say, it's a longshot....

Cheers
RodG

Thanks for your response! :) All the session times were set up correctly after the upgrade, so I'm sure that's not it. The error was happening instantaneously upon hitting the confirm order button, so there wasn't even a second or two before the timeout. Very weird. :)

[RodG]

Thanks for your response! :) All the session times were set up correctly after the upgrade,

Not trying to be argumentative, but you know this how?
So, out of curiosity, what is the value of your session.gc_maxlifetime ?

so I'm sure that's not it.

You've convinced yourself. Now see if you can convince me :)

The error was happening instantaneously upon hitting the confirm order button, so there wasn't even a second or two before the timeout.

That is *exactly* what I would expect if this setting is as low as the one that plagued me.

Very weird. :)

Even more weirder is that you *appear* to be debunking this possibility without giving it any consideration at all, and for *assuming* that this would cause some kind of delay rather than happening the instant the button is pressed.

Although I stated it's a longshot, do you have any better ideas? Has anyone else come up with a better idea? Surely it's worth some kind of followup?

Cheers
RodG

[laurelsstitchery]

Not trying to be argumentative, but you know this how?
So, out of curiosity, what is the value of your session.gc_maxlifetime ?

I printed out the settings in the server info section before I downgraded back to 5.2. The settings are all the same, but magically, it's working correctly now. session.gc_maxlifetime is set to 900 local and 1440 master.

I don't see any reason to be rude. I came here asking for help.

[mc12345678]

I don't see any reason to be rude. I came here asking for help.

The statements previously provided and inquiries asked were not to be taken as rude. None of us are able to see the values that you have in your setup (without being granted access). We are only able to help based on the amount of information provided, preferably with hard facts. (Similar to what was added into the quote of the above message.)

It appeared that the problem had persisted, and being familiar with all things Zen, the question was asked for validation that the suspected cause was not in fact the reason.

Having tagged this thread because I have seen some odd behavior on my own site with regards to some visitors getting unexpectedly timed out, it appeared that the most probable cause was the session.gc_maxlifetime value. Earlier it was stated that effort was taken to verify/set the values, but unfortunately sometimes in troubleshooting an issue changes are made that need to be undone. Whether that specifically is the case here or not, we don't know. At the very least now by confirming the values (and possibly resaving the settings so that they took) it seems your issue has been resolved.

I guess I could go on and on, you have come to the right place to seek help and it is very very rare that there are any personal issues/rudeness. The vast majority of those that offer their free help by openly posting here do so because they are trying to help and can really only do that to the maximum that others try to help them. A good starting point is the general posting guidelines and then to also frame the current situation so that there are no misunderstandings and sufficient info is available to diagnose. Hopefully two things, 1) you don't have any further issues (knock on wood) and 2) that when you do, you'll come back to seek assistance again.

[laurelsstitchery]

At the very least now by confirming the values (and possibly resaving the settings so that they took) it seems your issue has been resolved.

The issue was "resolved" by downgrading back to PHP 5.2, which means the issue hasn't really been resolved. I'm now afraid to upgrade back to PHP 5.3.x because of this issue, but my host is going to stop supporting 5.2 soon.

[mc12345678]

The issue was "resolved" by downgrading back to PHP 5.2, which means the issue hasn't really been resolved. I'm now afraid to upgrade back to PHP 5.3.x because of this issue, but my host is going to stop supporting 5.2 soon.

So to confirm understanding. When you said the ession.gc_maxlifetime is set to 900 local and 1440 master, is that the setting under 5.2 as it is currently? It is not clear in the previous post as to which version those settings applied.

[laurelsstitchery]

So to confirm understanding. When you said the ession.gc_maxlifetime is set to 900 local and 1440 master, is that the setting under 5.2 as it is currently? It is not clear in the previous post as to which version those settings applied.

Those were the settings under 5.2 and 5.3. Before I downgraded back to 5.2, I printed out the settings and then compared them once I downgraded. All of them were the same, but everything was working just fine after the downgrade.

My plan for tomorrow is to re-upgrade back to 5.3 because I have a batch of auto ship orders to enter for some customers. I'm hoping the problem will reoccur while I have the Zen Trace plugin activated so that I can run it by the author of that plugin to see if he can find the problem. I will update after that. Hoping to get an answer soon. :)