wp-cron jobs generates headers already sent warnings

[therealgilles]

Describe the bug
I have wp-cron.php run by wget. Everything it runs, I get the following warnings:

[09-Mar-2019 06:16:01 UTC] PHP Warning: session_set_save_handler(): Cannot change save handler when headers already sent in .../public_html/wp-content/plugins/wp-session-manager/vendor/ericmann/sessionz/php/Manager.php on line 133
[09-Mar-2019 06:16:01 UTC] PHP Warning: session_start(): Cannot start session when headers already sent in .../public_html/wp-content/plugins/wp-session-manager/wp-session-manager.php on line 139

Any idea why headers would already be sent when running wp-cron.php?

The stack trace looks like this:
• public_html/wp-cron.php - line 39 - require_once('wp-load.php')
• public_html/wp-load.php - line 37 - require_once('wp-config.php')
• public_html/wp-config.php - line 129 - require_once('wp-settings.php')
• public_html/wp-settings.php - line 374 - do_action('plugins_loaded')
• public_html/wp-includes/plugin.php - line 465 - $wp_filter[ $tag ]->do_action( $args )
• public_html/wp-includes/class-wp-hook.php - line 310 - apply_filters('', $args)
• public_html/wp-content/plugins/wp-session-manager/wp-session-manager.php - line 49 - EAMann\Sessionz\Manager::initialize()
• public_html/wp-content/plugins/wp-session-manager/vendor/ericmann/sessionz/php/Manager.php - line 133 - session_set_save_handler($manager)

I cannot see where the headers would have been sent.

[therealgilles]

I am wondering if this is possibly caused by wp-cron.php running fastcgi_finish_request().

[therealgilles]

Confirmed with https://bugs.php.net/bug.php?id=75946&edit=2.

Now I have no idea how to deal with this issue with the plugin.

[therealgilles]

I implemented a custom workaround. I copied wp-cron.php to wp-cron-custom.php, moved the fastcgi_finish_request() call to after the loading of wp-load.php, and updated my cron job to use the custom file. A bit of a hack but it's the best I could come up with.

[glagonikas]

Have you tried calling wp-cron.php on your browser to see what you get?

If it shows anything other than a white page, it could explain this warning.

[therealgilles]

@glagonikas, I am not understanding your comment. Which PHP >= 7.0.16, wp-cron.php calls fastcgi_finish_request() so that the http request is finished early. This sends the headers and creates the issue with the session plugin. The corresponding wp-cron.php code is below:

/* Don't make the request block till we finish, if possible. */
if ( function_exists( 'fastcgi_finish_request' ) && version_compare( phpversion(), '7.0.16', '>=' ) ) {
  fastcgi_finish_request();
}

There is nothing wrong with what happens when wp-cron.php runs. The problem is the interaction with the plugin trying to call session_set_save_handler/session_start. My best guess is that the plugin should be modified to handle the case where DOING_CRON is set. A session does not make sense when running cron.

[glagonikas]

We're currently on 7.1 and haven't noticed this error on our logs, which is why I'm question whether your problem is definitely caused by that PHP bug or it's just a coincidence.

If your server is configured to show the errors on the screen (usually on development) and you have some notices, warnings or errors shown when wp-cron.php runs, it might cause the "headers already sent" warning.

The same would happen if you have anything shown on the page (say an echo) when wp-cron.php runs.

You said you call wp-cron.php via where (same like we do) so you won't see the output (unless you log it somewhere). This is why I've asked you to visit yoursite.com/wp-cron.php on your browser and see if anything is shown.

If the above are not happening, I'll check our code to see why i don't get the same issue on our logs

[therealgilles]

@glagonikas, thank you for providing context.

The problem will only show if you are running wp-cron through a wget/curl request. If you are instead using a local cron job and calling it directly through php, there is no request so no headers and no issue.

Running yoursite.com/wp-cron.php on my site does not show anything.

[glagonikas]

ah, that would explain why we don't have this issue then. We call this via local cron job.

Your suggestion about DOING_CRON would probably make sense but i doubt Eric would be keen in fixing this. You could send a PR or offer him some incentives in the form of a donation.

Also, it would probably make sense to have a filter to stop the plugin from loading in certain situations. For example, you might want to maintain a list of known bots and not create a session each time they visit, as they'd also create a session, even after your fix. If such filter was in place, you could probably use it to resolve issue.

[therealgilles]

@glagonikas, thank you for your reply.

I am not sure I am qualified to create a PR. My first idea would be to add !defined(DOING_CRON) or a filter to this code:

    // Start up session management, if we're not in the CLI.
    if (session_status() !== PHP_SESSION_DISABLED && (!defined('WP_CLI') || false === WP_CLI)) {
        add_action('plugins_loaded', 'wp_session_manager_initialize',    1,  0);
        add_action('plugins_loaded', 'wp_session_manager_start_session', 10, 0);
    }

Without modifying the plugin, I think I could add the following to functions.php:

if (defined(DOING_CRON)) {
  remove_action('plugins_loaded', 'wp_session_manager_initialize', 1);
  remove_action('plugins_loaded', 'wp_session_manager_start_session', 10);
}

[therealgilles]

Hmm I wonder if this will interfere with the cleanup cron job.

[ericmann]

We can wire in the cleanup jobs to run without initializing a session. Marked as a bug so I can follow up.

[matiyin]

I have the same issue, on a live server with Nginx and fast-cgi, but not on a development server with apache. The plugin can initialize when I disable cron, but doens't want to write any session data to the database.

[mkormendy]

Thank you for posting this issue and resolution! My logs were reporting these sort of issues, and I couldn't pin down if it was an upgrade to a plugin that was causing my issue, or if something in core that changed. Then I forgot that I fixed my system cron calls recently as well and that started triggering the reporting of these warnings in my logs for some plugins I had created.