SiteGround SuperCacher – Cannot modify header information php error

[Living Miracles]

I enabled SiteGround’s SuperCacher on my WordPress site yesterday; through SuperCacher I enabled static and dynamic chache, as well as “Memcache.” This morning I got the following PHP errors: Can you tell me what they mean and if there’s anything I need to do?

[14-Nov-2015 17:04:31 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /wp-content/plugins/bulletproof-security/400.php:61) in /wp-content/plugins/sg-cachepress/class-sg-cachepress.php on line 326
[14-Nov-2015 17:04:31 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /wp-content/plugins/bulletproof-security/400.php:61) in /wp-content/plugins/sg-cachepress/class-sg-cachepress.php on line 340

[AITpro Admin]

One of these 2 things is happening.

1.  Not Likely:  SuperCacher is caching the BPS 400.php template logging file and you would need to exclude the BPS 400.php file from being cached.
2.  Most Likely:  A 400 error is occuring due to a malformed request and/or coding mistake in SuperCacher and it has something to do with this SuperCacher file/code:   /wp-content/plugins/sg-cachepress/class-sg-cachepress.php on line 326 and line 340.  You would need to look at the SuperCacher class-sg-cachepress.php code to figure out the problem that is occurring.  If you would like for me to look at the SuperCacher class-sg-cachepress.php code then send the file to: info at ait-pro dot com.

Also the BPS Security Log logs 400 Bad Request errors (in most cases depending on how malformed the request is).  If you see a 400 error for this in your Security Log then post the error.

[AITpro Admin]

The code in SuperCacher file:   /wp-content/plugins/sg-cachepress/class-sg-cachepress.php on line 326 and line 340 is trying to set a header and a cookie for the 400.php file.  The BPS 400.php logging template uses:  session_cache_limiter(‘nocache’); and session_destroy(); which unsets cookies and kills cache control HTTP headers since the 400.php is only a logging template that should not have any cookies set for it or have a header set for it.  Look for a setting in SuperCacher to exclude files/file paths and exclude the path to the BPS 400.php logging template file here:  /wp-content/plugins/bulletproof-security/400.php

 

[Living Miracles]

There does appear to be an area to exclude files from being cached. I’ve placed the file path you provided in that area so it won’t get cached any longer.

Thanks so much for the help!

[AITpro Admin]

If there is not an option in SuperCacher to exclude the BPS 400.php file or if excluding the 400.php file does not work then you can modify BPS Error Logging htaccess code to not log 400 errors by doing these steps below:

1. Go to the B-Core > htaccess File Editor tab page > click on “Your Current Root htaccess File” tab > copy your BPS Pro Error Logging and Tracking htaccess code (Example shown below) to this BPS Root Custom Code text box:  CUSTOM CODE ERROR LOGGING AND TRACKING
2. Edit the Error Logging and Tracking code that you copied to BPS Custom Code and delete this line of code: ErrorDocument 400 /wp-content/plugins/bulletproof-security/400.php, which has been deleted in the example code below.
3. Click the Save Root Custom Code button.
4. Go to the BPS Security Modes page and click the Root Folder BulletProof Mode Activate button.

# BPS PRO ERROR LOGGING AND TRACKING
# Use BPS Custom Code to modify/edit/change this code and to save it permanently.
# BPS Pro has premade 403 Forbidden, 400 Bad Request, 410 Gone and 404 Not Found files that are used
# to track and log 403, 400, 410 and 404 errors that occur on your website. When a hacker attempts to
# hack your website the hackers IP address, Host name, Request Method, Referering link, the file name or
# requested resource, the user agent of the hacker and the query string used in the hack attempt are logged.
# All BPS Pro log files are htaccess protected so that only you can view them.
# The 400.php, 403.php, 404.php and 410.php files are located in /wp-content/plugins/bulletproof-security/
# The 400, 410 and 403 Error logging files are already set up and will automatically start logging errors
# after you install BPS Pro and have activated BulletProof Mode for your Root folder.
# If you would like to log 404 errors you will need to copy the logging code in the BPS Pro 404.php file
# to your Theme's 404.php template file. Simple instructions are included in the BPS Pro 404.php file.
# You can open the BPS Pro 404.php file using the WP Plugins Editor or by using the BPS Pro File Manager.
# NOTE: By default WordPress automatically looks in your Theme's folder for a 404.php Theme template file.

ErrorDocument 401 default
ErrorDocument 403 /wp-content/plugins/bulletproof-security/403.php
ErrorDocument 404 /404.php
ErrorDocument 410 /wp-content/plugins/bulletproof-security/410.php

[Living Miracles]

Thank you. It seems that the PHP errors are still occurring even though I added /wp-content/plugins/bulletproof-security/400.php to be excluded in SG CachePress (the WordPress plugin for SuperCacher).

I just added the above code with the commented out line for 400 errors into the  CUSTOM CODE ERROR LOGGING AND TRACKING box, and then got the following error:

Plugin Firewall AutoPilot Mode Alert
Security Logging MUST be turned On in order for AutoPilot Mode to work. Either turn On Security Logging or turn Off AutoPilot Mode to make this Alert go away.

So I’ve taken the custom code out again. Do you have any idea why I would be getting that error? I’d like to not receive the 400 PHP errors but I’d also like AutoPilot Mode to be on and functioning.

[AITpro Admin]

Yep, thought that they would continue to happen since whatever is actually causing the 400 error is the root source problem that you would need to fix.  Unfortunately, the php error only shows what is occurring “after the fact” for whatever is causing the 400 error.

Oops I gave you the wrong custom code modification to use.  😉  I will correct the code modification above in my previous reply.  This line of code needs to be deleted and not commented out:  ErrorDocument 400 /wp-content/plugins/bulletproof-security/400.php

[Living Miracles]

Thank you. I’ve ammended the code as you said and no errors this time!

Can you tell me if there potentially is anything unhelpful about having removed that line of code? Would I, in certain cases, want to see 400 PHP errors in the log?

[AITpro Admin]

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1

400 Bad Request
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

A 400 error means that a bad request was made usually due to a coding mistake in something or on a rare occaison a hacker script that is used to attack your website has a coding mistake in it.  Those types of issues cause 400 errors on your server.  They are not important to log since whatever made the request is broken.  In other words, nothing bad can happen if something that is broken is not working. 😉  And once again the php error does not tell you what is broken and causing the 400 error and only shows an error after the fact.

[Living Miracles]

Thank you! Does that mean I should get in touch with SiteGround regarding this error and see if there is something they need to fix? Or does it look like it’s just a slight incompatibility between SuperCacher/SG CachePress and BPS Pro?

[AITpro Admin]

X is causing the 400 error and SuperCacher may or may not be directly involved in causing the 400 error for X.  So the orginal 400 error occurs and then since SuperCacher is trying to set a header and a cookie for the BPS Pro 400 logging template, which should not be happening, then you could say that that is a coding mistake with this SuperCacher file/code: /wp-content/plugins/sg-cachepress/class-sg-cachepress.php on line 326 and line 340.  So there is a chain reaction event going on – the orginal 400 error and then another issue with what SuperCacher is doing.  So the only important thing to look at would be the original 400 error since the other issue with what SuperCacher is doing is just a nuisance issue that is not important whatsoever.  Maybe the server logs have more clues about where the original 400 error is occurring?  Also if a hacker is attacking your website right now and the hacker’s script has a coding mistake in it then that will cause 400 errors since the request is bad.  So it may be that the 400 errors are coming from something external and not your website (plugins, theme, etc).

And to be exactly specific the problem with the code in this SuperCacher file: /wp-content/plugins/sg-cachepress/class-sg-cachepress.php on line 326 and line 340 is that the header is set even if you exclude/blacklist a URL and a cookie is set no matter what – there is no on/off or exclude conditional code.

		if ( ! $this->options_handler->is_enabled( 'enable_cache' ) || $this->is_url_blacklisted()) {
			header( 'X-Cache-Enabled: False' );
			return;
		}

		header( 'X-Cache-Enabled: True' );
		
		// Check if WP LOGGED_IN_COOKIE is set, validate it and define $userIsLoggedIn
		if ( isset( $_COOKIE[LOGGED_IN_COOKIE] ) ) {
			$userIsLoggedIn = wp_validate_auth_cookie( $_COOKIE[LOGGED_IN_COOKIE], 'logged_in' );
		} else {
		$userIsLoggedIn = false;
		}
		
		// Logged In Users
		if ( $userIsLoggedIn || ( ! empty( $_POST['wp-submit'] ) && 'Log In' === $_POST['wp-submit'] ) ) {
			// Enable the cache bypass for logged users by setting a cache bypass cookie
 			setcookie( 'wpSGCacheBypass', 1, time() + 100 * MINUTE_IN_SECONDS, '/' );
		} elseif ( ! $userIsLoggedIn || 'logout' === $_GET['action'] ) {
			setcookie( 'wpSGCacheBypass', 0, time() - HOUR_IN_SECONDS, '/' );
		}
	}

[Living Miracles]

Thank you for the extra explanation!

After implementing the CUSTOM CODE ERROR LOGGING AND TRACKING earlier without the “ErrorDocument 400 /wp-content/plugins/bulletproof-security/400.php” line I got the following PHP Warnings, and also noticed that I am unable to “Reset Modified Time in DB” now. I can click the button, and the page seems to reload, but the time doesn’t get reset. Any idea why I’d be having issues at the moment?

[14-Nov-2015 23:23:12 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /wp-content/plugins/bulletproof-security/400.php:61) in /wp-content/plugins/sg-cachepress/class-sg-cachepress.php on line 322
[14-Nov-2015 23:23:15 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /wp-content/plugins/bulletproof-security/400.php:61) in /wp-content/plugins/sg-cachepress/class-sg-cachepress.php on line 322
[14-Nov-2015 23:23:16 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /wp-content/plugins/bulletproof-security/400.php:61) in /wp-content/plugins/sg-cachepress/class-sg-cachepress.php on line 322
[14-Nov-2015 23:23:19 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /wp-content/plugins/bulletproof-security/400.php:61) in /wp-content/plugins/sg-cachepress/class-sg-cachepress.php on line 322

I also checked the error log on our server and found one line regarding this particular WordPress site and BPS Pro: Not sure what to make of it as I’m pretty sure that that’s a SiteGround IP address.

[Sat Nov 14 18:06:41 2015] [error] [client 109.199.127.51] client denied by server configuration: /wp-content/plugins/bulletproof-security/admin/mod-test/mod_access_compat-od-nc-denied.png

[AITpro Admin]

Did you do all of the Custom Code steps?  Is the new custom code actually in your root htaccess file or just saved in Custom Code?  I have no idea what would cause this:  “I am unable to “Reset Modified Time in DB”.  It would not be related to any of the Custom Code changes you made and would be some sort of other problem.  You can disregard the:  mod_access_compat-od-nc-denied.png file error since that is normal and is an intentional error check (is supposed to happen) created by/for the Apache Modules testing code.

Other possibility for this:  “I am unable to “Reset Modified Time in DB”.  When you say “but the time doesn’t get reset” do you mean that the Last Modified Time in DB does not match the Last Modified Time in File timestamp?  When you reset the timestamp you are synchronizing the file and DB timestamps and not resetting the time to “now”.

[Living Miracles]

Hi, no actually, it seems like clicking the “Reset Last Modified Time in DB” on the PHP Error Log doesn’t actually do anything, and the following notice doesn’t go away:

A PHP Error has been logged in your PHP Error Log
Click Here To go to the P-Security PHP Error Log page.
To remove/clear this Alert click on the Reset Last Modified Time in DB button.

And I continue to see this as well, even though I see a little green notice that says “Settings Saved” (a refresh doesn’t make a difference):

PHP Error Log Last Modified Time:
Last Modified Time in DB: November 14 2015 14:41:13
Last Modified Time in File: November 13 2015 16:23:19

Yes, I did go through all the steps to save the custom code and activate Root Folder BulletProof Mode, and FYI, I have not seen any new PHP errors or warnings since I posted the ones earlier.

[AITpro Admin]

Yep, totally different problem unrelated to the other problem.  Or maybe it is a series of problems all caused by SuperCacher.  What happens when you flush/delete all SuperCacher cache and turn off SuperCacher?  Do all of the problems go away?  Does everything start working correctly again?

What are these paths?  PHP Error Log Location Set To: and Error Log Path Seen by Server:  Are they the same or different?

[Author]

Posts