SiteGround SuperCacher – Cannot modify header information php error

[Living Miracles]

Interesting. Seems like it could have something to do with SuperCacher.  I flushed all the cache and disabled SuperCacher, and the last modified time in the database (on PHP Error Log page) reset itself automatically when I refreshed the page…  Looks like I’ll have to keep an eye on this. Any thoughts?

[AITpro Admin]

2 thoughts:  Maybe SuperCacher is caching your wp-admin backend Dashboard area.  Maybe SuperCacher is literally caching the BPS php error log file here: /wp-content/bps-backup/logs/bps_php_error.log.  You would need to ask SiteGround if either of these things are done by SuperCacher.  I tried testing the SG CachePress WordPress plugin, but it did not work on any of my hosting accounts.  It is obviously designed specifically for SiteGround and they have a disclaimer that states that.

[Living Miracles]

Thank you so much! I contacted SiteGround. Here is what they said:

Our Super Cacher plugin does not cache your WordPress Dashboard and it should not cache any of its dynamically generated content.

[AITpro Admin]

“it should not cache any of its dynamically generated content”.  Hmm can’t make heads or tails of this part of their answer statement.  See if you can get them to clarify what that means.  Unless what it means is it is a second part of the answer to the first question about caching the WP backend and they did not answer the second question about caching the BPS php error log file.

[AITpro Admin]

A 3rd thought: I found this information about Memcached on their site so maybe the reason you cannot update the timestamp is that it is stored in memory, which would mean that when you click the Reset button either nothing would happen or the value would not be current and would be the value stored in memory.

Memcached reduces the amount of database queries by storing your data and objects in memory, which helps to speed up database calls and page rendering.

[Living Miracles]

Thank you for all the thoughts.

I had the same thought about the “it should not cache any of its dynamically generated content” part of SiteGround’s answer so I asked for some clarification, about what that means in regards to the BPS Pro php error log file and they answered, “It is highly unlikely that that the SuperCacher tool would cache the file in question.”

Right now I have no new PHP errors in my PHP Error Log so I can’t do any more testing at this point. I will keep all of your thoughts in awareness though for future PHP errors. I have everything set up on my site as I did before (i.e. SuperCacher is fully enabled, and the 400 error line of code is removed from the CUSTOM CODE ERROR LOGGING AND TRACKING. If another PHP error comes up, I will first disable the Memcache in SiteGround’s SuperCacher and see if that makes any difference. I am also in communication with SiteGround and they’re happy to do some troubleshooting should the problem return.

[AITpro Admin]

A 4th thought:  It is possible that the reason the php error log timestamp was not being successfully reset was due to corrupt cache in your Browser application on your computer.  If the same problem happens again try clearing/deleting your Browser cache.

[AITpro Admin]

These things below were changed/corrected in BPS Pro 11.5 so what that means is that the original “Cannot modify header information – headers already sent” php error should no longer occur anymore.  You can delete the custom code that you created and do the rest of the Custom Code steps (save and activate Root BulletProof Mode) since these changes in BPS Pro 11.5 should prevent that php error from occurring again.

http://www.ait-pro.com/aitpro-blog/5221/bulletproof-security-pro/whats-new-in-bulletproof-security-pro-11-5/

• Correction|BugFix: ob_end_flush(); added to 403.php logging template.
• Correction|BugFix: ob_start(); and ob_end_flush(); added to the 400.php and 410.php logging templates.
• Change: Security Logging check for On|Off. Only checks if 403 Logging is On or Off and no longer checks if other ErrorDocument directives are On|Off.

If the original php error happens again then do 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 add a # sign infront of this line of code: #ErrorDocument 400 /wp-content/plugins/bulletproof-security/400.php.
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 400 Bad Request, 403 Forbidden, 404 Not Found, 405 Method Not Allowed and
# 410 Gone template logging files that are used to track and log 400, 403, 404, 405 and 410 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, 405.php and 410.php files are located in /wp-content/plugins/bulletproof-security/
# The 400, 403, 405 and 410 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 400 /wp-content/plugins/bulletproof-security/400.php
ErrorDocument 401 default
ErrorDocument 403 /wp-content/plugins/bulletproof-security/403.php
ErrorDocument 404 /404.php
ErrorDocument 405 /wp-content/plugins/bulletproof-security/405.php
ErrorDocument 410 /wp-content/plugins/bulletproof-security/410.php

[Author]

Posts