headers already sent by … waf.php

  • My WordPress installation is in a subdirectory, and when I enabled Wordfence’s “extended protection”, I get the following series of PHP warnings:

    [16-Jan-2023 09:10:01 UTC] PHP Warning: Cannot modify header information – headers already sent by (output started at /home/xxxx/public_html/header.inc:1) in /home/xxxx/public_html/news/wp-content/plugins/wordfence/vendor/wordfence/wf-waf/src/lib/waf.php on line 1157
    [16-Jan-2023 09:10:01 UTC] PHP Warning: Cannot modify header information – headers already sent by (output started at /home/xxxx/public_html/header.inc:1) in /home/xxxx/public_html/news/wp-content/plugins/wordfence/vendor/wordfence/wf-waf/src/lib/utils.php on line 749
    [16-Jan-2023 09:10:01 UTC] PHP Warning: Cannot modify header information – headers already sent by (output started at /home/xxxx/public_html/header.inc:1) in /home/xxxx/public_html/news/wp-content/plugins/wordfence/vendor/wordfence/wf-waf/src/lib/utils.php on line 750
    [16-Jan-2023 09:10:01 UTC] PHP Warning: Cannot modify header information – headers already sent by (output started at /home/xxxx/public_html/header.inc:1) in /home/xxxx/public_html/news/wp-content/plugins/wordfence/vendor/wordfence/wf-waf/src/lib/utils.php on line 751

    The header.inc file is simply the site banner. It’s called in my theme – in the body of course – thus:

    <?php include_once('/home/xxxx/public_html/header.inc'); ?>

    I think I understand the reason for the warning (Wordfence getting out in front of the theme), so is it possible to enable extended protection in a way to avoid the warning?

Viewing 8 replies - 1 through 8 (of 8 total)
  • Thread Starter ericr23

    (@ericr23)

    Notes: PHP 8.1, WordPress and Wordfence up to date. And these warnings are in the site’s base directory error.log, not in the WordPress (sub)directory.

    Plugin Support wfpeter

    (@wfpeter)

    Hi @ericr23, thanks for the detailed messages.

    When I’ve seen the “…headers already sent” message in the past, it’s been linked to another plugin loading WordPress core files out of order, which is a possibility here.

    The error lines you’ve shared looks like they could help if nothing else seems to point to a cause, but could you let me know whether you’ve written any custom code at all?

    Disabling your other plugins one-by-one, while keeping Wordfence enabled may also narrow it down. Another possibility is to turn off display_errors if it’s on. The warnings being output could be ones that wouldn’t normally be shown.

    Let me know how you get on!
    Peter.

    Thread Starter ericr23

    (@ericr23)

    Thanks. I will experiment.

    Thread Starter ericr23

    (@ericr23)

    It’s now been a day since I disabled Wordfence’s enhanced protection (optimized firewall). (I also deleted the empty user.ini file.) No more errors. It would seem to have been caused by displaying material from the blog (which is in a subdirectory) on the home page of the site (in which home directory’s error.log the errors had been logged).

    • This reply was modified 2 years, 2 months ago by ericr23.
    Thread Starter ericr23

    (@ericr23)

    Now it occurred just once a couple of hours ago, with the doctype call, which queries for the user agent of the request to return only “<html>” for MSIE. I don’t know why it threw up the warning only once, though (among thousands of requests). I’ll take that out and see what happens.

    I just realized that the warning was showing up only for one of the WordPress installations (there are 3): the most visited (by far), so more likely to get an MSIE request? I’ll also re-enable Wordfence’s enhanced protection on the other 2 and see what happens.

    Thread Starter ericr23

    (@ericr23)

    Still a couple of instances last night, and still only referring to the one WordPress installation. All 3 have the same plugins and very similar (custom) themes, exactly the same in the matter of those doctype and header (ie, banner) files. Since the warnings are only occasional, I’ll try to match requests with them.

    • This reply was modified 2 years, 2 months ago by ericr23.
    Thread Starter ericr23

    (@ericr23)

    Each instance of the set of 4 warnings appears to correspond to a request “POST /news/?wordfence_syncAttackData=1674058488.357 HTTP/1.1”. And each of those requests (with different numbers, of course) corresponds to a blocked user-agent on Wordfence’s Live Traffic feed.

    The conflict may be that I have tried to block those user-agents for the entire site (not just the WordPress subdirectories, which are protected by Wordfence) via Apache’s Mod_Rewrite (RewriteCond %{HTTP_USER_AGENT} … RewriteRule . – [R=403]), which doesn’t seem to work all that reliably (if at all).

    Thread Starter ericr23

    (@ericr23)

    I added “RewriteOptions InheritDownBefore” to the root htaccess (actually to an Apache config file) and the user-agent blocks now appear to be working apart from (before) Wordfence in the WordPress subdirectories (and no errors thrown up).

    • This reply was modified 2 years, 1 month ago by ericr23.
Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘headers already sent by … waf.php’ is closed to new replies.