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

Sorry I missed that, right, so error logging in general is working on php 5.4.

My guess is that you are having a PHP fatal error before anything gets output. That's why nothing is in php's log - it died. If that's the case it should show up in your apache logs or the system logfile (on most linux '/var/log/messages'). Can you access these and do you see any Fatal Errors in them?

You might try updating the sessions.php file to the new one for 1.52, which includes a fix for this issue:
(https://www.zen-cart.com/showthread.php?207435-php-5-4-fatal-error-Allowed-memory-size-of-83886080-bytes-exhausted)

Here are the options I can think of:

• Set up a local test environment using Virtualbox. Use a php debugger and step through till you see the error. (this is a lot of work to set up)

• Install the Xdebug module (http://xdebug.org/docs/install) and see if you get a stack trace.

• Use the brute-force method of inserting error_log statements and narrow down where the crash is occuring. I think there's a module that logs all events - that would help tracking down where things stop.

Zen Cart Notifier Trace
https://www.zen-cart.com/downloads.php?do=file&id=1114

avibodha:

Sorry I missed that, right, so error logging in general is working on php 5.4.

My guess is that you are having a PHP fatal error before anything gets output. That's why nothing is in php's log - it died. If that's the case it should show up in your apache logs or the system logfile (on most linux '/var/log/messages'). Can you access these and do you see any Fatal Errors in them?

You might try updating the sessions.php file to the new one for 1.52, which includes a fix for this issue:
(https://www.zen-cart.com/showthread.php?207435-php-5-4-fatal-error-Allowed-memory-size-of-83886080-bytes-exhausted)

Here are the options I can think of:

• Set up a local test environment using Virtualbox. Use a php debugger and step through till you see the error. (this is a lot of work to set up)

• Install the Xdebug module (http://xdebug.org/docs/install) and see if you get a stack trace.

• Use the brute-force method of inserting error_log statements and narrow down where the crash is occuring. I think there's a module that logs all events - that would help tracking down where things stop.

Zen Cart Notifier Trace
https://www.zen-cart.com/downloads.php?do=file&id=1114

In regards to the issues on this one server that Diva Vocals is having problems, it doesn't seem like setting up the local server would help her. Other carts setup elsewhere appear to be working fine under 5.4, it's this one that is causing her grief and her time is running out for resolving the issue with the cart as is. There was some discussion of rebuilding to identify what "one" thing is messing it up, and I assume that is being done in parallel, but there seems to still be some underlying reason it is not working.

mc12345678:

In regards to the issues on this one server that Diva Vocals is having problems, it doesn't seem like setting up the local server would help her. Other carts setup elsewhere appear to be working fine under 5.4, it's this one that is causing her grief and her time is running out for resolving the issue with the cart as is. There was some discussion of rebuilding to identify what "one" thing is messing it up, and I assume that is being done in parallel, but there seems to still be some underlying reason it is not working.

You are right.. I do not have the luxury of time to setup a local server to try every possible way to make an error log appear JUST to get an error log to register.. I am on a ticking time clock.. I need to test on the server where the issue exists... So at this point I've opted for rebuilding the dev site from scratch and going through each module one by one until I get to the ONE thing that is messing things up.. I will post my findings when I get to the bottom of things..

avibodha:

• Use the brute-force method of inserting error_log statements and narrow down where the crash is occuring. I think there's a module that logs all events - that would help tracking down where things stop.

Zen Cart Notifier Trace
https://www.zen-cart.com/downloads.php?do=file&id=1114
This module caught my attention.. Installed this and whle I get a log file, nothing in it is any different than what the live site produces..

Going back to what I have been doing to track down the errant code, building a new dev site.. I'm still open to ideas.. because the lack of error logs is what is killing me.. An error log would help me get to the bottom of this..

DivaVocals:

I'm still open to ideas.. because the lack of error logs is what is killing me.. An error log would help me get to the bottom of this..

A handy trick to pick up parse errors in test_file.php if you can't set display_errors in php.ini or use .htaccess:

<?php
error_reporting  (E_ALL);
ini_set ('display_errors', true);
include('./test_file.php');
?>

<ref: http://www.php.net/manual/en/configuration.changes.modes.php >

Cheers
RodG

RodG:

A handy trick to pick up parse errors in test_file.php if you can't set display_errors in php.ini or use .htaccess:

<?php error_reporting (E_ALL); ini_set ('display_errors', true); include('./test_file.php'); ?>

> 
> <ref:  <http://www.php.net/manual/en/configuration.changes.modes.php> >
> 
> Cheers
> RodG

Thanks for this.. Error logs are working that's not the problem.. the issue is that whatever the cause of the blank page is, it's NOT creating any error logs.. Makes this hard to troubleshoot since I've no idea what code is failing and in which file..

Almost done re-building the dev site.. We'll see what the last modifications/installs bring to light..

Making sure additional logging (other than the built in Zen Cart logging system) is where I would start... Enabling PHP logging will catch errors occuring before Zen Cart's logging code is started. I typically just edit php.ini directly (hosting provider permitting):

error_reporting = E_ALL | E_STRICT
display_errors = On
display_startup_errors = On
log_errors = On
error_log = /home/account/php_errors.log

Visual Output File Output

Setting error_log will cause PHP to not attempt to send the errors to the SAPI or SYSTEM error logger and instead log directly to a file. This makes it far easier to find PHP related errors without having to ask the host for access to their webserver / system error logs.

If no errors are found / logged by the above, then move on to checking where in the execution flow (using something like the TRACE_NOTIFIER plugin) the script is "dying" or failing to output the expected data.

If switching the template makes the site show back up, I would probably double check any "override" folders... Especially those specific to the problematic template.

NOTE: Do not leave visual display of errors enabled on a production server, it should only be enabled while actively debugging.

Well there appears to be a light at the end of my preverbial tunnel..

GOLD STAR to lhungil for providing me with a REASON why I'm not getting error logs.. two words.. data corruption..

With this info, I was able to narrow down the problem to the configuration table.

Working on a final resolution.. Replaced the configuration, configuration_group, and **admin_page **tables on the current dev site with the like tables from the re-created dev site, and the dev site came back up under PHP 5.4.. This has me hopeful in resolving what has been a frustrating experience..

I will be doing more testing, and once I am satisfied that this is the right solution/direction, then I am going to push the configuration, configuration_group, and **admin_page **tables from the dev site database to the live site database.

and before anyone asks.. I haven't a CLUE what specific data in the configurationtables on the dev site is THE offending data.. and YES I dumped the data and used Beyond Compare to compare the data dumps.. the problem is that past the Zen Cart default values, unless I installed add-ons which add configuration table values in the SAME order, the configuration data won't line up without manipulation of the data.. Since time is not a luxury I have (host says that support for PHP 5.2 will end this weekend) I had to let got of finding out the EXACT offending data and work towards getting things WORKING.. I think I am finally moving in that direction..

Thanks for everyone's help, suggestions, and support..

Hope this thread helps someone else with similar issues..

DivaVocals:

Well there appears to be a light at the end of my preverbial tunnel..

GOLD STAR to lhungil for providing me with a REASON why I'm not getting error logs.. two words.. data corruption..

With this info, I was able to narrow down the problem to the configuration table.

Working on a final resolution.. Replaced the configuration, configuration_group, and **admin_page **tables on the current dev site with the like tables from the re-created dev site, and the dev site came back up under PHP 5.4.. This has me hopeful in resolving what has been a frustrating experience..

I will be doing more testing, and once I am satisfied that this is the right solution/direction, then I am going to push the configuration, configuration_group, and **admin_page **tables from the dev site database to the live site database.

and before anyone asks.. I haven't a CLUE what specific data in the configurationtables on the dev site is THE offending data.. and YES I dumped the data and used Beyond Compare to compare the data dumps.. the problem is that past the Zen Cart default values, unless I installed add-ons which add configuration table values in the SAME order, the configuration data won't line up without manipulation of the data.. Since time is not a luxury I have (host says that support for PHP 5.2 will end this weekend) I had to let got of finding out the EXACT offending data and work towards getting things WORKING.. I think I am finally moving in that direction..

Thanks for everyone's help, suggestions, and support..

Hope this thread helps someone else with similar issues..

YEAH!!!

At the very least there were good suggestions by others on how to do some troubleshooting!

mc12345678:

YEAH!!!

At the very least there were good suggestions by others on how to do some troubleshooting!

Indeed.. though there was an AWFUL lot of time dedicated to suggestions on how to make an error log appear despite me repeatedly stating that there was NO ISSUE with error logging for OTHER errors..:laugh: lhungil provided the HINT that got me moving in the right direction.. Error logs are nice, but when your data is the issue, I guess there just aren't error logs.. I also appreciate you emphasizing that I didn't have the luxury of TIME on my side.. :laugh:

Anyway.. I am hoping to put this behind me tomorrow..

DivaVocals:

Well there appears to be a light at the end of my preverbial tunnel..

GOLD STAR to lhungil for providing me with a REASON why I'm not getting error logs.. two words.. data corruption..

With this info, I was able to narrow down the problem to the configuration table.

Working on a final resolution.. Replaced the configuration, configuration_group, and **admin_page **tables on the current dev site with the like tables from the re-created dev site, and the dev site came back up under PHP 5.4.. This has me hopeful in resolving what has been a frustrating experience..

I will be doing more testing, and once I am satisfied that this is the right solution/direction, then I am going to push the configuration, configuration_group, and **admin_page **tables from the dev site database to the live site database.

and before anyone asks.. I haven't a CLUE what specific data in the configuration tables on the dev site is THE offending data.. and YES I dumped the data and used Beyond Compare to compare the data dumps.. the problem is that past the Zen Cart default values, unless I installed add-ons which add configuration table values in the SAME order, the configuration data won't line up without manipulation of the data.. Since time is not a luxury I have (host says that support for PHP 5.2 will end this weekend) I had to let got of finding out the EXACT offending data and work towards getting things WORKING.. I think I am finally moving in that direction..

Thanks for everyone's help, suggestions, and support..

Hope this thread helps someone else with similar issues..

So all is well and I wanted to share what I suspect is the POSSIBLE offending data..

After aligning nearly everything between the dev and live sites in terms of add-on installs and other configuration settings, the ONLY items left that would affect the configuration table were the various modules installed (payment, shipping, order totals). The dev site only has the free shipper, USPS shipping and Check/Money Order enabled. The live site had the same shipping options, but Authorize.net was the only payment module enabled. Though the order totals were identical between the dev and live site, I couldn't rule them out as a possible culprit. So to test my "theory", I did the following:

1. Turned off ALL the order total, shipping and payment modules in the dev site.
2. Backed up JUST the values in the configuration table for the order total, shipping and payment modules in the live site.
3. Put the dev site into maintenance mode
4. Pushed the configuration, configuration_group, and **admin_page **tables from the dev site database to the live site database, and re-enabled PHP 5.4 on the live site. The live site came back up in maintenance mode.. (whoo hoo!!)
5. Backed up the live site's newly populated configuration, configuration_group, and **admin_page **tables.
6. Restored on the live site JUST the configuration values for the payment, shipping, & order totals from backup I made in step 2

As I expected.. the live site died..

So I restored the configuration, configuration_group, and **admin_page **tables from the backup I made in step 5, and logged into the admin and manually configured all the order total, shipping and payment modules for the live site.

All is right with the world.. Sure was a very long journey to get here, and I still don't know the EXACT cause..

Thanks to everyone who posted here, or PM'd, or e-mailed to help.. You are all very much appreciated.. and it was all helpful in one way or another to getting to the end of this nightmare.. Hope I don't have to do this again..