“Cannot modify header information”

  • Resolved ericr23

    (@ericr23)


    1 year, 11 months ago

    I know this has been raised before, and I’m pretty sure the issue arises because my WordPress module is in a subdirectory of my site and the header information is coming from files in the root directory. I’m also pretty sure it doesn’t matter, except that it fills the site’s “error” log.

    So I’m raising the issue again just to note the possibility that it’s related to being in a subdirectory.

    On the other hand, I have 3 WordPress installations, each in its own subdirectory and all with the same plugins, themes, settings, etc, and the “Cannot modify header information” occurs with only one of them.

    Of other possible relevance, it used to be that Wordfence’s “extended protection” would cause the “Cannot modify header information” warning, but only when it was catching a “known malicious user-agent” (also with only one of my 3 WP installations). But now it doesn’t – WP Super Cache appears to be getting there first!

Viewing 12 replies - 1 through 12 (of 12 total)
  • Plugin Support Alin (a11n)

    (@alinclamba)

    Hi @ericr23,

    Thanks for letting us know about that. From what I understand, this happens only on one specific site of yours and not on others with a similar setup. Can you please share the URL of that specific site so we can have a closer look?

    If you don’t want to make it public, you can contact us using this form and mention this forum thread.

    Thank you!

    Thread Starter ericr23

    (@ericr23)

    Sure: The warning occurs with: https://www.wind-watch.org/news/

    It doesn’t with: https://www.wind-watch.org/documents/

    They use completely custom templates (stuck in the mid-2000s). The index and single pages start with a line loading nwwdoctype.inc from the root directory, which writes the header. Then after creating the title, they load nwwmeta2.inc (also from the root), which besides adding a bunch of site-wide meta info, determines if the requester is a bot or mobile. Then they write more meta info themselves specific to the module, and load nwwheader.inc, which is the banner (not the “header”). It’s nwwheader.inc that is referred to in the warning:

    “PHP Warning: Cannot modify header information – headers already sent by (output started at /home/…/public_html/nwwheader.inc:1) in /home/…/public_html/news/wp-content/plugins/wp-super-cache/wp-cache-phase2.php on line 1486”

    Could it be because the first line is “<div id=header…”? (I’ll experiment with changing that.) But again, why just the news module?

    Both of them have the following plugins:

    Classic Editor
    Google XML Sitemaps
    Wordfence Security
    WP Super Cache
    WP-EMail
    WP-Print
    WW-MODs

    And the documents module also has WP Offload Media Lite. (WW-MODs is a custom plugin handling several hooks.)

    Note, the warning is in the root error.log. One stray warning did occur with the documents module: “PHP Warning: Cannot modify header information – headers already sent by (output started at /home/…/public_html/videofeed.php:11) in /home/…/public_html/documents/wp-content/plugins/wp-super-cache/wp-cache-phase2.php on line 1486”. That’s an RSS feed that supplies random videos that sometimes reside in the documents posts (most of the site’s video pages are in the root directory), requiring videofeed.php to load wp-load.php from that directory. videofeed.php, of course itself sets an rss/xml header.

    Thread Starter ericr23

    (@ericr23)

    Fixed to some extent, perhaps: The warning has become rarer. Turns out the Microsoft Clarity script in nwwmeta2.inc was missing the closing script tag. (And apparently I never went to the Clarity site to discover that it wasn’t working.)

    • This reply was modified 1 year, 11 months ago by ericr23.
    Thread Starter ericr23

    (@ericr23)

    I also found that nwwmeta2.inc was writing “<html>” twice, which may have been a problem.

    Thread Starter ericr23

    (@ericr23)

    Neither of those is fully getting rid of the warnings, however. And I’m still mystified as to why it occurs in with one module (“news”) and not the other (“documents”).

    • This reply was modified 1 year, 11 months ago by ericr23.
    Plugin Support Erina (a11n)

    (@eri32s98)

    Hi @ericr23 , good to see you’ve done some headway.

    For context, PHP is fussy about when HTTP headers are set. They have to be sent at the very beginning of the HTTP response, so PHP will give a warning if you try to set a header after the page contents have started to be sent.

    It looks like nwwheader.inc is writing stuff before wp-super-cache gets a chance to run, so wp-super-cache cannot modify the HTTP headers, giving that PHP warning.

    You’ll want to double-check the nwwheader.inc file, and make it not write headers out before super cache runs.

    Thread Starter ericr23

    (@ericr23)

    How can I make nwwheader.inc not write headers out before Super Cache runs? As far as I know, I’m not setting any response header myself (and it’s mystifying that the warning appears only with 1 of my 3 WordPress modules). My index and single pages write <!DOCTYPE html> and then a bunch of <head> info, including an nwwmeta2.inc file and not until the <body> starts to be written do they call header.inc. The first PHP code is run after <head>.

    • This reply was modified 1 year, 11 months ago by ericr23.
    Thread Starter ericr23

    (@ericr23)

    *All 3 WP modules use the same files from the root directory: nwwdoctype, nwwmeta2, and header.inc.

    Thread Starter ericr23

    (@ericr23)

    A couple years ago in the Phast Press forum, the addition of 

    add_action('template_redirect', function () {
    ob_start();
});

    to the theme’s function.php file was reported to work. It didn’t make a difference in our case, however.

    It may or may not be relevant, and again it’s in all 3 of my WP modules and only 1 is creating the warning, but my function.php also includes this fix from some time ago:

    remove_action( 'shutdown', 'wp_ob_end_flush_all', 1 );
add_action( 'shutdown', function() {
   while ( @ob_end_flush() );
} );

    I tried removing that, but no difference there.

    • This reply was modified 1 year, 11 months ago by ericr23.
    • This reply was modified 1 year, 11 months ago by ericr23.
    Thread Starter ericr23

    (@ericr23)

    I wrapped those inc files in ob_start() and ob_flush(), and that appears to have solved the problem! (Still no idea why it was a problem in only 1 WP instance and not in the other 2.)

    Hi there,

    Glad to hear that you found a solution.

    Wrapping the included files in ob_start() and ob_flush() likely resolved the issue because it enabled output buffering for the included files, which prevented any output from being sent to the browser until all of the PHP code had finished executing. This helped to ensure that headers were not being sent prematurely and causing the “headers already sent” error.

    It is not entirely clear why the error was only occurring in one of the WordPress instances and not in the other two, as you mention, but it could potentially be related to differences in the PHP code or server configuration between the instances. Regardless, using output buffering with ob_start() and ob_flush() is a commonly recommended solution for resolving “headers already sent” errors in WordPress and other PHP applications.

    Thread Starter ericr23

    (@ericr23)

    Thanks for your patience and support!

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘“Cannot modify header information”’ is closed to new replies.