HeathenMagic:
Sorry for the delay in replying. I can confirm that disabling this does allow google / websniffer to do its thing. I turned it back on for now just in case and will see what else I can find out
My best guess is: One of your WordPress plugins relies upon an active session (and starts one when a session is not present). When you have Zen Cart configured to "Prevent Spider Sessions", no session is started and output may start before WordPress is loaded in "html_header.php". This then causes a PHP error, because the output occurred before the WordPress plugin attempted to start a session.
If the above guess holds true, simplest fix is to allow Zen Cart to start sessions for "Spiders" (these include SE bots/crawlers). Because when a WordPress plugin requires the use of sessions, the gain from preventing spider sessions in Zen Cart will be minimal. A more complex fix is to determine which WordPress plugin is attempting to use sessions, then replace with a different WordPress plugin (which does not require sessions) or modify the WordPress plugin to also detect and prevent spider sessions.
DivaVocals:
Since the change to the html_header.php required for this module only adds a call to the WorPress wp-load.php file in Zen Cart (required so this module can display the WordPress sidebox content inside Zen Cart), I can't help but wonder if the errors you are getting are ACTUALLY coming from your WordPress blog..
Agreed, probably from one of the installed WordPress plugins. I've posted my stab in the dark above!
HeathenMagic:
... I have been trying to do some log error solving, and it is still the same. ... On the zencart side, the only thing I have noticed since also December (weird) is that error logs are not being created. ...
The out-of-box WordPress disables portions of PHP error reporting. This will result in overriding of the Zen Cart PHP error reporting. When trying to track down an issue / error, one can add the following in "wp-config" to have WordPress enable all PHP error reporting and save them to a file (debug.log). Be aware the error log will probably contain a larger number of warnings about the use of deprecated functions/methods (these are not going to be the cause of the HTTP 500).
I would caution against leaving WP_DEBUG enabled on a production server unless one understands the ramifications.
/**
* For developers: WordPress debugging mode.
*
* Change this to true to enable the display of notices during development.
* It is strongly recommended that plugin and theme developers use WP_DEBUG
* in their development environments.
*/
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
NOTE: Reference Debugging WordPress for more details regarding the above options.
