10422 error code in logs, customer sees blank page instead

[DrByte]

What if anything is in your includes/configure.php file related to DIR_FS_LOGS?

It's probably fine, since the paypal logs are logging okay there.

The issue with PHP error logging seems to be something about the server configuration.

[lat9]

One distinction between those PayPal logs and the myDEBUG logs is that the PayPal logs are written directly (via fopen/fwrite/fclose) as opposed to the myDEBUG logs which are written as controlled by various ini_set settings.

If @HeathenMagic's host has disabled ini_set usage (as seen in a couple of other postings over the past year), that would explain why the PayPal logs are there and the debug-logs aren't.

[DrByte]

One distinction between those PayPal logs and the myDEBUG logs is that the PayPal logs are written directly (via fopen/fwrite/fclose) as opposed to the myDEBUG logs which are written as controlled by various ini_set settings.

If @HeathenMagic's host has disabled ini_set usage (as seen in a couple of other postings over the past year), that would explain why the PayPal logs are there and the debug-logs aren't.

True. One way to see what "disabled functions" have been set is to look in Admin->Tools->Server Info, in the top 3rd of the screen.

[HeathenMagic]

Thanks for your reply. I have the following in that file:-

// define('DIR_FS_SQL_CACHE' ...
// define('DIR_FS_DOWNLOAD' ...
// define('DIR_FS_LOGS' ...

I left untouched as didn't want to break anything lol.

[HeathenMagic]

One distinction between those PayPal logs and the myDEBUG logs is that the PayPal logs are written directly (via fopen/fwrite/fclose) as opposed to the myDEBUG logs which are written as controlled by various ini_set settings.

If @HeathenMagic's host has disabled ini_set usage (as seen in a couple of other postings over the past year), that would explain why the PayPal logs are there and the debug-logs aren't.

Hosts got back to me with this:-

I have checked the PHP configuration globally and verified that there are no disable functions, also set 'display_startup_errors = On'.
Please check if that helps in your case. If you have any specific settings to be verified from server side, let us know.

root@server [/opt/cpanel/ea-php70/root/etc]# grep disable_functions ./php.d/local.ini
disable_functions =
root@server [/opt/cpanel/ea-php70/root/etc]# grep disable_functions php.ini
disable_functions =
root@server [/opt/cpanel/ea-php70/root/etc]#

logs still show paypal so my search continues.........

[lat9]

Thanks for your reply. I have the following in that file:-



I left untouched as didn't want to break anything lol.

If "that file" really has those defines commented out, then that's your issue! Remove the leading // on each of those definitions; they're "expected" to be set.

[Design75]

If "that file" really has those defines commented out, then that's your issue! Remove the leading // on each of those definitions; they're "expected" to be set.

Not in a zc 1.5.5 configure file. those are the last lines of the file and are commented out by default, as these defines are now set in the file defined_paths.php.

[lat9]

Thanks, @Design75, I need to keep up!

[mc12345678]

Actually the next thing that would be checked if the previous PayPal log error was not found in the logs directory (don't think the specific location of where the file was found was identified), would be the includes/defined_paths.php file for the define of the DIR_FS_LOGS constant to be present and as "built" to give the directory that 1) exists, and 2) is writeable.

Otherwise, fallback to DrByte's previous statement that if the PayPal error log were found in the logs directory, the DIR_FS_LOGS is already defined (at least when processing via PayPal).

The fact that it was commented out in the includes/configure.php file is either as design75 pointed out or as applies to how the system was installed/upgraded, but either way it appears that the lack error logs is likely attributable to the permissions of modifying the ini_set characteristics.

[DrByte]

It's tough to diagnose something wrong with the server, especially when they'll rarely investigate "3rd party software".

So, to figure out why there aren't error logs, we can try to force a known error, and fiddle with the logging mechanism a bit.

Let's try commenting-out line 76 of /includes/extra_configures/enable_error_logging.php by adding // to the front of the line, like this:

  //     set_error_handler('zen_debug_error_handler', $errors_to_log);

That'll rule out whether some of the extra decoration of error message data may be something the server is denying use of.
Then go rename the /includes/init_includes folder to init_includes_TMP and try to visit the site. This should give a blank page, and fatal errors in the logs. Then rename it back so your visitors aren't impacted. Then go look at what's in the logs directory.


Next option might be to write a single-file php script that enables error reporting perhaps at its maximum level (which we don't usually do on a "production" site, for both performance and unsafe disclosure reasons), specifies a log directory, and then triggers an error that should be written. Then see what happens. Isolate the issue completely away from Zen Cart so the hosting company can see how a basic function isn't working, and then they can own the issue until it's fixed.
Or it may point to something that's been altered inside Zen Cart with plugins or broken php files etc.