.
Zen Cart - putting the dream of business ownership within reach of anyone!
Donate to: DrByte directly or to the Zen Cart team as a whole
Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.
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.
.
Zen Cart - putting the dream of business ownership within reach of anyone!
Donate to: DrByte directly or to the Zen Cart team as a whole
Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.
Thanks for your reply. I have the following in that file:-
I left untouched as didn't want to break anything lol.// define('DIR_FS_SQL_CACHE' ...
// define('DIR_FS_DOWNLOAD' ...
// define('DIR_FS_LOGS' ...
Hosts got back to me with this:-
logs still show paypal so my search continues.........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]#
Zen cart installation / maintenance / customisation / hosting
Supported Modules: Dutch language pack, Multi site, Dynamic Price Updater and more.
Thanks, @Design75, I need to keep up!
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.
ZC Installation/Maintenance Support <- Site
Contribution for contributions welcome...
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:That'll rule out whether some of the extra decoration of error message data may be something the server is denying use of.Code:// set_error_handler('zen_debug_error_handler', $errors_to_log);
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.
.
Zen Cart - putting the dream of business ownership within reach of anyone!
Donate to: DrByte directly or to the Zen Cart team as a whole
Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.
Bookmarks