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

[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....ytes-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

[mc12345678]

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....ytes-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.

[DivaVocals]

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..

[DivaVocals]

* 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..

[RodG]

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/configu...nges.modes.php >

Cheers
RodG

[DivaVocals]

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/configu...nges.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..

[lhungil]

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.

[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..

[mc12345678]

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!

[DivaVocals]

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.. 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..

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