php 5.2.0 update problem

Hi,

today we've tried to upgrade our server from php 5.1.6 to 5.2.0. After this no one is able to log in anymore, neither customers nor admins. We've reverted back now to 5.1.6 and everything is working fine like before. Nevertheless we would like to upgrade because of all the bugs and security issues in php <= 5.1.6. Does anyone know what the problem with ZC and php 5.2.x could be?

Also: if a customer requests a new password (with php 5.2) the password is send but when trying to use it/log in then apache is closing the connection and php is throwing the same error all the time:

[03-Nov-2006 13:39:48] PHP Fatal error: Call to a member function Execute() on a non-object in /xxx/includes/functions/sessions.php on line 61

which is

$total = $db->Execute($qid);

in ZC 1.3.x

So neither old passwords or new ones can be used with php 5.2.0 :huh:

Thanks for any help!

What are your compile-options and php.ini options related to sessions settings in your 5.2.0 setup ?

hi DrByte, our php.ini settings have not been changed for 2 years or so since php 4.3.x or so, IIRC. The session related settings are:

www:~ # php -i | grep -i session
session
Session Support => enabled
session.auto_start => Off => Off
session.bug_compat_42 => On => On
session.bug_compat_warn => On => On
session.cache_expire => 30 => 30
session.cache_limiter => nocache => nocache
session.cookie_domain => no value => no value
session.cookie_lifetime => 0 => 0
session.cookie_path => / => /
session.cookie_secure => Off => Off
session.entropy_file => no value => no value
session.entropy_length => 0 => 0
session.gc_divisor => 100 => 100
session.gc_maxlifetime => 1440 => 1440
session.gc_probability => 1 => 1
session.hash_bits_per_character => 5 => 5
session.hash_function => 0 => 0
session.name => PHPSESSID => PHPSESSID
session.referer_check => no value => no value
session.save_handler => files => files
session.save_path => /tmp => /tmp
session.serialize_handler => php => php
session.use_cookies => On => On
session.use_only_cookies => Off => Off
session.use_trans_sid => 0 => 0
WDDX Session Serializer => enabled

php gets compiled as always for apache worker 2.x, the same applies since about 2 years but now we're using apache 2.2.3 on an Opteron system with 1MB RAM (hence the lib64 param but otherwise nothing's been changed in the configure at all, I'm using a script for it so no error on this part, mysql version is 4.1.21 BTW), here are the php ./configure options:

Configure Command => './configure' '--with-libdir=lib64' '--prefix=/usr/share' '--bindir=/usr/bin' '--datadir=/usr/share/php' '--includedir=/usr/include' '--infodir=/usr/share/info' '--libdir=/usr/share' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--mandir=/usr/share/man' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--with-apxs2=/usr/sbin/apxs2-worker' '--with-config-file-path=/etc' '--with-cyrus' '--with-dom=/usr' '--with-exec-dir=/usr/lib/php/bin' '--with-layout=GNU' '--with-_lib=lib' '--with-bz2' '--with-curl' '--with-db4' '--with-expat-dir=/usr' '--with-ftp' '--with-gd' '--with-gd-dir=/usr/local/lib' '--with-gdbm' '--with-gettext' '--with-gmp' '--with-freetype' '--with-freetype-dir=/usr' '--with-iconv' '--with-jpg' '--with-jpeg-dir=/usr' '--with-ldap' '--with-mcal=/usr' '--with-mcrypt' '--with-mhash' '--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--with-ncurses' '--with-ndbm' '--with-openssl' '--with-pcre-regex' '--with-pear=/usr/share/pear' '--with-png' '--with-png-dir=/usr' '--with-readline' '--with-regex=php,apache,system' '--with-snmp=/usr' '--with-tiff-dir=/usr' '--with-ttf' '--with-xml' '--with-xml-rpc' '--with-xpm-dir=/usr/X11R6' '--with-xslt-sablot' '--with-zlib' '--with-zlib-dir=/usr' '--without-oci8' '--enable-bcmath' '--enable-calendar' '--enable-ctype' '--enable-dbase' '--enable-dbx' '--enable-dio' '--enable-discard-path' '--enable-exif' '--enable-fastcgi' '--enable-filepro' '--enable-ftp' '--enable-force-cgi-redirect' '--enable-gd-imgstrttf' '--enable-gd-native-ttf' '--enable-inline-optimization' '--enable-maintainer-zts' '--enable-mcal' '--enable-magic-quotes' '--enable-mbstr-enc-trans' '--enable-mbstring' '--enable-mbregex' '--enable-memory-limit' '--enable-pic' '--enable-shmop' '--enable-sigchild' '--enable-sockets' '--enable-sysvsem' '--enable-sysvmsg' '--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid' '--enable-ucd-snmp-hack' '--enable-wddx' '--enable-xslt' '--enable-yp' '--enable-zend-multibyte' '--disable-debug'

Additionally we use imap and pdflib modules plus eaccelerator, but even without all that the error from line 61 remains. Otherwise the shop is loading fine, it's just the login that doesn't work but I didn't have time to check everything since the shop has to be operational so I went back to 5.1.6 for now. Because there are no other errors then I guess something must have been changed which breaks the ZC login in some way. Been looking around in open bugs/php.net but couldn't find anything related yet ... :sleepy:

Oops, sorry, I meant 1GB RAM of course ;)

Quote:

---

Originally Posted by ca18

Been looking around in open bugs/php.net but couldn't find anything related yet ...

---

Well ... it was only released yesterday.

Yes, but they had some problems and there where several RC's so I guess not much(other than the security issues reported by Esser etc) should've changed since the latest RC. So any 5.2.0 problems, RC or not, should be known by now with the "final".

The only one similar would be this one:

http://bugs.php.net/bug.php?id=39331

I got the exact same error after upgrading to php v5.2.0 this morning. Looks like $db is not initialized in session.php?

Thanks for the info linksys, at least I'm not alone with it now :smile:

Quote:

---

Originally Posted by linksys

I got the exact same error after upgrading to php v5.2.0 this morning. Looks like $db is not initialized in session.php?

---

Yes, it is, on line 51 (as far as line 61 is concerned).

Quote:

---

Originally Posted by DrByte

Yes, it is, on line 51 (as far as line 61 is concerned).

---

Or the new PHP altered the behavior of the "global" statement so the value of $db is not passed into functions or got overwritten?

I am poking around in the code...just baffled. Interesting...

I just installed PHP 5.2.0 on a test windows machine running IIS, along with Zen Cart v1.3.6, and it works without any errors.

I have found something interesting:

http://drupal.org/node/61900

Quote:

---

Originally Posted by DrByte

I just installed PHP 5.2.0 on a test windows machine running IIS, along with Zen Cart v1.3.6, and it works without any errors.

---

I have a little different setup:
1) On CentOS 4.4
2) Upgraded from Zencart 1.3.5.0.2 to v1.3.6. Worked all good with PHP 5.1.6

Then I upgraded PHP to 5.2.0 and got this error.

SuSE 10.0 with kernel 2.6.x.y here.

Quote:

---

Originally Posted by ca18

I have found something interesting:

http://drupal.org/node/61900

---

Hey DrByte, I think the above link likely addresses the same issue here. Look at the "Finally Tracked This Down" part and the "Problem Background" part:

Quote:

---

Finally Tracked This Down

This is a bug PHP's behavior with global variables. I have a simplified test case which shows the problem in operation and offers a fix.

This has been hard to resolve - this "login issue" can manifest itself from other bugs that involve session ID's and cookies. This is yet another issue.

---

Looks similar. I don't see a resolution there that's of much use to anyone other than the PHP folks ... :mellow:

I put a var_dump($db) before line 61 in sessions.php and it printed NULL.

The question is, why this global variable issue only affects the session code? Other zen-cart functions all work well - browsing products, adding to cart, etc... I would expect other functions also use "global" to pass in class objects, don't they?

:sleepy: My clients on my server also have the same issue... There seems to be a issue with ZenCart and php-5.2. In order to correct the issue I had to roll back php to 5.1.6.

Any Idea when a fix/patch will be released?

If one of you is interested in providing me with FTP+admin access to your PHP 5.2.0 server, I'll be happy to debug and come up with a solution.

PM me with details and I'll look at it this evening ...

Quote:

---

Originally Posted by sh33pz

:sleepy: My clients on my server also have the same issue... There seems to be a issue with ZenCart and php-5.2. In order to correct the issue I had to roll back php to 5.1.6.

Any Idea when a fix/patch will be released?

---

As a workaround: you don't have to roll back to php 5.1.6. Just change your session to be "file based" from "database based" in the ZenCart config file: includes/configure.php and admin/includes/configure.php

This way you can still run ZenCart while taking advantage of the PHP 5.2.0 security and bug fixes. But I would still prefer to switch back to database-based session for security sometime later when we find a solution.

Aww sweet, Thanks for the info.


Will try that out later tonite

Meanwhile others find the same problem:

http://community.mybboard.net/showth...d=13506&page=1

And it's been reported now:

http://bugs.php.net/bug.php?id=39381

So it's not ZC which is giving php a bad rep like this twit claims

http://caseysoftware.com/zend-conference-2006-day-2

but php.net themselves which first quarrel about 5.2.0 for several weeks and then YET again don't get it right so half the world is laughing about more bugged or better f***ed-up php-releases :shocking: Like last time 5.1.6 when they "forgot" something for the 64bit uP, unbelievable. This is really gonna start to pi55 me off now ... :cry:

And more from another completely different project:

http://www.dotproject.net/vbulletin/showthread.php?p=26051

:sleepy:

Thanks for the info bud :) So it's off to php.net to bug them for a fix Thanks to everyone for their help! My clients will be happy to know.. its php itself to blame not Zen Cart !!!

As fir the Zen Cart Coders... Keep up the good work! I kinda figured after.. it must be php itself.. I just couldn't see ya guys.. over look this!

It appears as though PHP has assigned the bug to someone for fixing.

However, in the meantime, you have two options:
a. use file-based caching instead of database-based (not really a good solution, but works around the problem, but is less secure and much less flexible for most hosting environments. 'db' is really the better choice except in the case of this PHP bug):
configure.php file:
define('STORE_SESSIONS', '');

OR:

A Suggested Bandage:
b. edit /includes/functions/sessions.php
and /admin/includes/functions/sessions.php, if it exists on your site:

Code:

---

    function _sess_write($key, $val) {
      global $db;
      global $SESS_LIFE;

---

change to:

Code:

---

    function _sess_write($key, $val) {
      // The following is only to work around a PHP 5.2.0 bug:
      global $db;
      if (!is_object($db)) {
        //PHP 5.2.0 bug workaround ...
        $db = new queryFactory();
        $db->connect(DB_SERVER, DB_SERVER_USERNAME, DB_SERVER_PASSWORD, DB_DATABASE, USE_PCONNECT, false);
      }

      global $SESS_LIFE;

---

Option (b) may or may not be "complete", and has only had preliminary testing. The best fix will be to have PHP fix their bug, of course.

NOTE: If this fix "works" for you, then you need to upgrade your version of Zen Cart ... sooner than later. The latest version of Zen Cart contains a number of fixes related to PHP5 and MySQL5. You should plan your upgrade ... soon.

Addendum: There are some other technical approaches which could be used to address the session_write_close() and register_shutdown_function() changes introduced in this new PHP version. These may be explored in the future. For now, the above approaches are the simplest to implement for those needing to make a quick-fix to their code.

Thanks

it is working now.

Thanks for the workaround DrByte! :clap: :cheers:

The related PHP bug (http://bugs.php.net/bug.php?id=39381) was updated by the PHP developer asking for sample code to reproduce. Anyone can provide one? DrByte? :)

Hello ! This is my first post on zen-cart forum ! I wanna thank you very much to DrByte ! Good job. Best regards!

php.net have marked their bug or better fcukup as bogus now so they won't fix it :shocking: :huh:

All--

Running into an interesting challenge with our store. We did an upgrade to our server for XML purposes, ran into the session challenge described in this thread. Using Dr. Byte's fix seemed to work...for a few days. Then one of our admin users (there are 5, using the main admin password) described getting kicked out of the Admin area....but only on some computers. We performed the usual cache and session clearing on her computer, plus installed Firefox since we're convinced that IE is the root of all internet evil. The problem seemed to right itself...at least for a few days.

We've gotten word that another user is having this problem, only clearing cache and switching to Firefox seems to do nothing. We've logged into her computer using a different user profile (running win xp) and the admin area works fine. However, no matter what we do, we can't get reports to work for her. The usual answer would be to fix the roaming profile she uses on the Win2k3 server, but roaming profiles are off....and the problem persists across any computer she jumps on in the office.

Anybody have any ideas at all? I'm convinced this is a profile issue, but we can't prove it.

Thanks,
Ben Peterson
Interactive Media Developer
Space Foundation

i tired this fix but got this error.

Fatal error: Cannot redeclare _sess_write() (previously declared in /home/bdmaxcl/public_html/store/includes/functions/sessions.php:34) in /home/bdmaxcl/public_html/store/includes/functions/sessions.php on line 53

please post fix asap.

Both of the sessions.php function files need to be updated ...

http://www.zen-cart.com/forum/showpo...7&postcount=26



/includes/functions/sessions.php

/admin/includes/functions/sessions.php

The files are pretty similar ... and the fix is more or less the same ...



NOTE: If this fix "works" for you, then you need to upgrade your version of Zen Cart ... sooner than later. The latest version of Zen Cart contains a number of fixes related to PHP5 and MySQL5. You should plan your upgrade ... soon.

Okay. I have done the session fix. While the error message is gone, when I "sign in", I don't get any further than the sign in page. That's right. It's like the sign in page is refreshing.

Marci

Make sure both look EXACTLY like this:

Code:

---

    function _sess_write($key, $val) {
      // The following is only to work around a PHP 5.2.0 bug:
      global $db;
      if (!is_object($db)) {
        //PHP 5.2.0 bug workaround ...
        $db = new queryFactory();
        $db->connect(DB_SERVER, DB_SERVER_USERNAME, DB_SERVER_PASSWORD, DB_DATABASE, USE_PCONNECT, false);
      }
      global $SESS_LIFE;

---

NOTE: If this fix "works" for you, then you need to upgrade your version of Zen Cart ... sooner than later. The latest version of Zen Cart contains a number of fixes related to PHP5 and MySQL5. You should plan your upgrade ... soon.

NOTE: this php 5.2.0 bug does have a temporary fix built into Zen Cart v1.3.7 ...

For this and other issues for security, bugfixes and additional features it is strongly recommended that you upgrade to Zen Cart v1.3.7 ...

Thanks for the workaround DrByte! Works like a charm! :happy:

NOTE: this is built into the current version of Zen Cart ... v1.3.7 ... might want to upgrade for this and many other bugfixes, security issues and features ...

Plus, if using PayPal ... keep an eye on the PayPal Patch thread:
http://www.zen-cart.com/forum/showthread.php?t=56216

On this and other threads, I'm seeing some people recommend this:
define('STORE_SESSIONS', '');

and some this:
define('STORE_SESSIONS', 'file');

Is there a difference between these two options? Is one of them better? They both seem to work.

Please explain me, People of Zen, what is happening with my test shop.
Users can't register, login. It gives the known error of 'Fatal error: Call to a member function... line 61'. BUT all my 2 session files are OK, as newly installed 1.3.7.
Shall I re-install 1.3.7 again for it again? :down:

Thank you in advance

Have you an URL where this error is happening?

Sorry Ajeh for long silence. I currently run and test it on my localhost. I re-installed it and it works fine now.

Howdy!

Our server Admin used http://www.zen-cart.com/forum/showth...587#post287587 to fix our problem when, over the weekend the Admin area stopped working and products would not get added to the cart.

The cart now works...and PayPal works fine, and orders processed through Paypal work fine, but the Authorize.net credit card orders are going through with Authorize.net, but none of them are showing up in ZenCart. The poor customers are getting charged (sometimes multiple times), but we are not getting any information on credit card orders in ZenCart. No invoices, no "orders" per se. All of this began happening at the same time (when I am assuming that our server was updated with the new PHP).

Any ideas why we are not getting ZenCart orders when done via credit card?

Thanks!
Matt Thomas
Maui Excellent



OoopS!

Sorry Ididn't attach the version and server info.

And by the way, I will officially upgrade to 1.2.7, but that will take me some time to implement. In the meantime, it's urgent I get just this one issue fixed...everything else is working fine. Any suggestions at all, or even where to start looking????

VERSION INFO:

Server Host: kauai.vibechild.com (66.206.18.191) Database Host: localhost (127.0.0.1)
Server OS: Linux 2.6.17-13mdv Database: MySQL 5.0.37-log
Server Date: 05/03/2007 19:13:46 Database Date: 05/03/2007 19:13:46
Server Up Time: 19:13:46 up 6 days, 4:22, 0 users, load average: 0.24, 0.28, 0.36
PHP Version: 5.2.1 (Zend: 2.2.0)
HTTP Server: Apache/2.2.4 (Mandriva Linux/PREFORK-6mdv2007

ZEN CART 1.2.5, Database 1.2.5, PHP 5.2.1

System Linux kauai.vibechild.com 2.6.17-13mdv #1 SMP Fri Mar 23 19:03:31 UTC 2007 i686
Build Date Apr 18 2007 09:21:05
Configure Command This is irrelevant, look inside the /usr/share/doc/libphp5_common5-5.2.1/configure_command file. urpmi is your friend, use it to install extensions not shown below.
Server API Apache 2.0 Handler
Virtual Directory Support disabled
Configuration File (php.ini) Path /etc/php.ini
Scan this dir for additional .ini files /etc/php.d
additional .ini files parsed /etc/php.d/12_ctype.ini, /etc/php.d/13_curl.ini, /etc/php.d/19_domxml.ini, /etc/php.d/21_openssl.ini, /etc/php.d/21_zlib.ini, /etc/php.d/22_ftp.ini, /etc/php.d/23_gd.ini, /etc/php.d/24_gettext.ini, /etc/php.d/26_iconv.ini, /etc/php.d/27_imap.ini, /etc/php.d/28_ldap.ini, /etc/php.d/29_mbstring.ini, /etc/php.d/30_mcrypt.ini, /etc/php.d/36_mysql.ini, /etc/php.d/37_mysqli.ini, /etc/php.d/43_posix.ini, /etc/php.d/47_session.ini, /etc/php.d/49_simplexml.ini, /etc/php.d/50_snmp.ini, /etc/php.d/54_hash.ini, /etc/php.d/57_sysvsem.ini, /etc/php.d/58_sysvshm.ini, /etc/php.d/60_tokenizer.ini, /etc/php.d/62_xml.ini, /etc/php.d/62_xmlrpc.ini, /etc/php.d/63_xmlreader.ini, /etc/php.d/64_xmlwriter.ini, /etc/php.d/65_yp.ini, /etc/php.d/66_bcmath.ini, /etc/php.d/81_filter.ini, /etc/php.d/82_json.ini, /etc/php.d/99_eaccelerator.ini, /etc/php.d/A10_adodb-ext.ini, /etc/php.d/A13_radius.ini, /etc/php.d/A60_timezonedb.ini, /etc/php.d/Z99_suhosin.ini
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
IPv6 Support enabled
Registered PHP Streams tftp, ftp, telnet, dict, ldap, http, file, https, ftps, compress.zlib, php, data
Registered Stream Socket Transports tcp, udp, unix, udg, ssl, sslv3, sslv2, tls
Registered Stream Filters zlib.*, convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed

This server is protected with the Suhosin Patch 0.9.6.2
Copyright (c) 2006 Hardened-PHP Project

This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
with eAccelerator v0.9.5, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
with Suhosin v0.9.18, Copyright (c) 2002-2006, by Hardened-PHP Project

I just upgraded from php4 to php5.2.4 and encountered the same problem. The above solution took care of it in no time, thank you DrByte.

Thanks again, David

My hosting company of preference (and that of my clients) have started upgrading PHP and as a result this issue is surfacing. Perhaps make this into a sticky... i have a feeling this will be very useful for others as well.