After upgrade to PHP 5.4, site displays a blank page..

I'm stumped as to what the issue is.. I have seen in the Zen Cart Wiki that PHP 5.4 works with Zen Cart v1.5.1 with some patches.. I've seen some posts about the sessions.php file. is this the "patches" that are needed?? Are there other patches??

DivaVocals:

I'm stumped as to what the issue is.. I have seen in the Zen Cart Wiki that PHP 5.4 works with Zen Cart v1.5.1 with some patches.. I've seen some posts about the sessions.php file. is this the "patches" that are needed?? Are there other patches??

While not able to find the similar thread from a few weeks ago or so that asked the same question, there is this thread started to address this:

http://www.zen-cart.com/showthread.php?211639-PHP-5-4-patch-list

DivaVocals:

I'm stumped as to what the issue is.. I have seen in the Zen Cart Wiki that PHP 5.4 works with Zen Cart v1.5.1 with some patches.. I've seen some posts about the sessions.php file. is this the "patches" that are needed?? Are there other patches??I have had this happen on 3 zen 1.5.1 sites when I switched to php 5.4.
I would switch back to php 5.3 and the website would work fine.

These were sites that had been around for several years and progressively upgraded to zen 1.5.1
php 5.4 finds that the password used for database access had been created with an older encryption method and it refused to access the database until I created a new database password.

I went into cpanel deleted the current user for the database
Created a new user (with the same name and database password)

Result: The sites worked immediately with php 5.4

It might not be your problem, but it worked for me.
It took a while to find this as there were no error log files.
Just a blank page.
I can't remember how I managed to find the error (it did show up eventually somewhere)

gilby:

I have had this happen on 3 zen 1.5.1 sites when I switched to php 5.4.
I would switch back to php 5.3 and the website would work fine.

These were sites that had been around for several years and progressively upgraded to zen 1.5.1
php 5.4 finds that the password used for database access had been created with an older encryption method and it refused to access the database until I created a new database password.

I went into cpanel deleted the current user for the database
Created a new user (with the same name and database password)

Result: The sites worked immediately with php 5.4

It might not be your problem, but it worked for me.
It took a while to find this as there were no error log files.
Just a blank page.
I can't remember how I managed to find the error (it did show up eventually somewhere)I'll give the password change a shot.. because at this point I'm desperate.. and like you I am getting NO error logs either.. Not sure this will work since the WordPress site shares the database with Zen Cart and it is having no issues..

I switched the live site back to PHP 5.2 so for now it's working, but this is a bandaid as HostMonster has said in one week they will be disabling PHP 5.2 support altogether.. Now I have a very short window to get this worked out on the dev site..

Grrrrrrrrrrrrr...............

A few things I found on the web regarding this (possible) problem

www(dot)simplemachines.org/community/index.php?topic=491636.0 (see post 6)
forum(dot)mediatemple(dot)net/topic/7204-wordpress-upgrading-php-version-to-54/
discussion(dot)dreamhost(dot)com/thread-137852.html (post 6)

gilby:

A few things I found on the web regarding this (possible) problem

www(dot)simplemachines.org/community/index.php?topic=491636.0 (see post 6)
forum(dot)mediatemple(dot)net/topic/7204-wordpress-upgrading-php-version-to-54/
discussion(dot)dreamhost(dot)com/thread-137852.html (post 6)

I'll give the database reset a try after I try a few other things.. but the WordPress part of this site is working just fine.. all my issues are related to Zen Cart.. and they share the same DB..

gilby:

A few things I found on the web regarding this (possible) problem

www(dot)simplemachines.org/community/index.php?topic=491636.0 (see post 6)
forum(dot)mediatemple(dot)net/topic/7204-wordpress-upgrading-php-version-to-54/
discussion(dot)dreamhost(dot)com/thread-137852.html (post 6)

Alas deleting and recreating the DB user did not solve the issue.. I wasn't hopeful this was the answer anyway since the WordPress part of the site is functioning fine..

DivaVocals:

I'm stumped as to what the issue is..

Does the problem exist with the entire site, or is it just the backend or front end?

If you have SSL enabled, have you tried disabling it to see if the problem still exists?

Does the problem still exist if you revert back to the 'classic' template?

Cheers
RodG

RodG:

Does the problem exist with the entire site, or is it just the backend or front end?

If you have SSL enabled, have you tried disabling it to see if the problem still exists?

Does the problem still exist if you revert back to the 'classic' template?

Cheers
RodG

• Front-end issue. Admin works just fine.
• SSL is not the issue as it exists on both the dev site (which does NOT have SSL enabled) and on the live site (which does have SSL enabled)
• Removing the template brings the site back but generates LOTS of error messages from various add-ons (for example SNAF being one) because of missing files. I am confident these errors are unrelated to the root issue . (FYI.. I typically delete classic from my installs and replace it with the Barebones template.. I DESPISE Classic)

So yes I am looking at my installed add-ons among other things (like eliminating the server the site is hosted on as a possible contributing factor since all is well once I switch the site back to PHP 5.2)

Interestingly other clients with pretty much the same setup and add-ons are not having issues with PHP 5.4..

Anyway a fellow Zenner was kind enough to share the list of v1.5.1 mods/bugs/issues I asked after.. So I can at LEAST cross that off my list.. The lack of ANY error logs is what makes this a PITA..

DivaVocals:

Anyway a fellow Zenner was kind enough to share the list of v1.5.1 mods/bugs/issues I asked after.. So I can at LEAST cross that off my list.. The lack of ANY error logs is what makes this a PITA..

Sharing back with the community to also help those that may be looking?

mc12345678:

Sharing back with the community to also help those that may be looking?

I will be happy to do so later..:smile: (it's in an external document) right now (as I'm sure you can understand) THIS is a bigger priority for me..

DivaVocals:

• Front-end issue. Admin works just fine.

Ahh... I didn't realize your problem was only with the front end.
The issue I had affected the entire site, front and back end, so it can't be the same as the problems I had.

Does your host give you the option of using php 5.3 as an interim (possible) solution?

gilby:

Ahh... I didn't realize your problem was only with the front end.
The issue I had affected the entire site, front and back end, so it can't be the same as the problems I had.

Does your host give you the option of using php 5.3 as an interim (possible) solution?
Unfortunately no.. it's PHP 5.4 or bust.. :laugh:

Like I said I was fairly certain it's wasn't the DB user thing for no other reason than WordPress was working just fine.. only the Zen Cart front end is mis-behaving..

DivaVocals:

Unfortunately no.. it's PHP 5.4 or bust.. :laugh:

Like I said I was fairly certain it's wasn't the DB user thing for no other reason than WordPress was working just fine.. only the Zen Cart front end is mis-behaving..

Maybe a long shot, but do you have any php short tags in your code? Often those are disabled by default in php 5.4. My experencie is the can give white pages without error logs too

Design75:

Maybe a long shot, but do you have any php short tags in your code? Often those are disabled by default in php 5.4. My experencie is the can give white pages without error logs too

No shorttags.. Unfortunately I am out of ideas.. So I am going to re-build the test site from scratch.. Along the way I am going to find the add-on that is the cause of the issue.. I have two possible culprits in mind, and this exercise should confirm my suspicions.. I will totally report back my findings here and on the support thread(s) of any suspect add-ons..

It would really be good to see if error logging is working. Check your php.ini for error log location (or put phpinfo() into a page). Usually logs go to the cache folder so check there first. If not, maybe in apache logs, or system error log location.

You're really in the dark without error logs to tell you what went wrong (I'm sure you know that!).

avibodha:

It would really be good to see if error logging is working. Check your php.ini for error log location (or put phpinfo() into a page). Usually logs go to the cache folder so check there first. If not, maybe in apache logs, or system error log location.

You're really in the dark without error logs to tell you what went wrong (I'm sure you know that!).

Thanks for trying to help.. a few things...

I'm running ZC v1.5.1 so the error logs (if any) will go to the "logs" folder not the "cache" folder.. To be thorough I have already checked BOTH folders anyway.. I've also checked the server error logs..

When I stated that I have NO error logs, I really mean I have NO error logs anywhere.. Which is why I really have no CLUE what the cause of the issue is for this site.. No other client sites with similar configurations have this issue..

That's really strange to have no logs showing anything.

Try this, put this in any php file that runs:
error_log('testing error logs');

You could add it as an extra file in includes/extra_configures, or just add it to a template file somewhere. Check and make sure you can see this message in a log file. If not, something is misconfigured...first guess would be permissions on the cache or logs folders.

If you can log this, but nothing else shows up, you could try installing xdebug (xdebug.org) as a php plugin and see if that gives more information. Otherwise, put in error_log statements throughout the store index.php and change the text on each. See how many get logged to narrow down on where the problem is. But that's last resort.

You could also put phpinfo(); into a file to double-check that logging is turned also, and where the path is.

avibodha:

That's really strange to have no logs showing anything.

Try this, put this in any php file that runs:
error_log('testing error logs');

You could add it as an extra file in includes/extra_configures, or just add it to a template file somewhere. Check and make sure you can see this message in a log file. If not, something is misconfigured...first guess would be permissions on the cache or logs folders.

If you can log this, but nothing else shows up, you could try installing xdebug (xdebug.org) as a php plugin and see if that gives more information. Otherwise, put in error_log statements throughout the store index.php and change the text on each. See how many get logged to narrow down on where the problem is. But that's last resort.

You could also put phpinfo(); into a file to double-check that logging is turned also, and where the path is.

Other error logs show just fine (see my earlier response to Rod about what happens if I turn off the template and use the default template) so there isn't a permissions error for the error logs folders.. They worked just fine before.. permissions have not changed.. The ONLY change was the webhost's update to PHP 5.4..

DivaVocals:

Other error logs show just fine (see my earlier response to Rod about what happens if I turn off the template and use the default template) so there isn't a permissions error for the error logs folders.. They worked just fine before.. permissions have not changed.. The ONLY change was the webhost's update to PHP 5.4..

When the host allows the change from one PHP version to the other, does the contents of the php.ini file change say if using the "default"? (Of course backup before selecting something that would modify the php.ini file. When I upgraded from 5.2 to 5.3 I had to go through line by line to confirm that options shown were in fact still available and I reviewed the 5.3 "update" guide (somewhere) to confirm thati could still use whatever option in question.

Of course I had done things the hard way at the time, because I didn't just do what I suggested above (select a "default" php.ini for the version being used.) Really don't know if any of that would help, sorry for the "shot-in-the-dark" approach. :(