Mark Maunder
Forum Replies Created
-
Guys I’m a bit confused by what’s going on here.
On our side, we simply use standard PHP output buffering including ob_start() and ob_get_contents() to just grab the PHP output and generate our cache files. That is how all other PHP based caching plugins work.
So we’re just grabbing whatever the application is giving us for a particular page and storing in in a file which is associated with the URL that was accessed.
Can you give me a few theories about why InfiniteWP is triggering this weird behaviour? Or where the conflict might be? Is InfiniteWP sending the HTTP response or page content using some non-standard mechanism? Or is it using output buffering itself which conflicts with our buffering? Or is InfiniteWP doing caching too?
I’ve confirmed that this is the only report we’ve seen of this issue.
Thanks.
Hi Scott,
Strange. Can you post your .htaccess file here and exclude any sensitive info. Looks like your gzip files are being served up raw rather than the browser interpreting them as compressed content. That points to a web server config issue. I don’t think we’ve had any other reports from this but I’ll let Tim weigh in.
Any other web server config info you think might help would be useful.
Thanks.
Mark.
http://support.wordfence.com/ is where you want to open a priority support ticket as a paid customer. One of our team will be happy to help.
Regards,
Mark.
Hi,
I’m Mark Maunder, the founder. We have Tim, Brian and Matt all working hard in the forums to provide an excellent level of support. In addition, we provide a paid support system at support.wordfence.com for premium customers just like you.
I’d strongly recommend you use support.wordfence.com and if you’d like you can also post a regular post in the forums.
Posting a reply to a forum ‘sticky’ is not going to get you faster support. In addition, ‘WTF” and ‘make it fast’ also doesn’t help – our team works pretty hard for our customers and they tend to make-it-fast by default.
We also are unable to look up your username without some additional info which I wouldn’t want you to post here. So please open a ticket asap at support.wordfence.com and we’ll either process an immediate refund if that’s what you want or work the issue.
Regards,
Mark Maunder
Wordfence Founder/CEO.No it definitely has not. As far as I’m aware yours is the only report. This error was caused by a very specific problem. We have just added support for IPv6 to Wordfence and some older versions of PHP didn’t provide that function when we launched the code. So within a few hours we released a fix to deal with that specific issue. It hasn’t appeared since. So I’m reasonably sure this is a caching issue for you.
Thanks,
Mark.
The third is probably not a plugin that is in the WordPress.org official plugin repository. We only detect changes in plugins in the official repository.
Regards,
Mark.
Hi Tony,
Disabling cookies in your browser will pretty much give you that same effect for any modern web application out there. You can’t login because the app can’t store session info like: the fact that you’re logged in.
No it’s not a bug. Also Wordfence cookies have nothing to do with WordPress cookies – even if you disable our cookies, WordPress will still send cookies unless you find a way to disable that too.
Mark.
Hi Daniela,
This is happening in the core WordPress code, not in our plugin. If your’e seeing this on the ‘scan’ page of Wordfence in one of the yellow status windows, it may be that we’re just reporting an error that WordPress is generating.
I’d work with your site designer, developer or hosting company to try to find the cause. It might just be that they have the WP_DEBUG constant enabled and it’s reporting benign warnings.
Wordfence has been known to display errors in other parts of WordPress in those two yellow windows on the scan page. I did examine the code reported in the error and confirmed this is deep in the WordPress core code.
Mark.
Hi Jay,
We made this design choice because most WordPress sites with permalinks are structured in a way where anything that doesn’t end in a slash should probably not be cached e.g. .php scripts.
I’m going to file a bug to consider providing an option to cache pages that don’t end in a slash.
Regards,
Mark.
I’ve taken a brief look at the code you pasted and I don’t see why we wouldn’t log this. It’s just submitting a form to the normal WordPress login mechanism. Are you sure you’re signing into the correct site?
Does Wordfence block you if you fail enough login attempts? You can test this using Tor or a proxy so that you don’t block your own IP address.
Mark.
Strange that you’re seeing this with every request. It’s from the routine that runs at plugin upgrade. Is it possible that your DB is read-only?
You can probably solve this by doing a factory default reset on Wordfence: http://docs.wordfence.com/en/I%27d_like_to_reinstall_Wordfence_completely._How_do_I_do_that%3F
Bear in mind that you’ll be deleting all your wordfence options.
We’re investigating this further on our end.
Regards,
Mark.
Hi Nicklas,
Sorry about the delay – Brian contacted me immediately and it’s me that dropped the ball on this.
So the issue here is that you’ve enabled server side caching and your PHP application doesn’t see the request that is served from the cache. So Wordfence live traffic doesn’t have the opportunity to log the request which is why you’re missing requests.
I’m afraid there’s no way around this other than to use a javascript logging app like google analytics which will log even with your cache enabled. The down-side to using Google Analytics is that you won’t see requests from bots and hackers like Googlebot or malicious requests.
Point taken re better documenting Nginx. We’ll see if we can make that happen.
Regards,
Mark.
That’s great, thanks for letting us know.
Regards,
Mark.
Hi,
Looks like you are running a version of PHP older than 5.3. We released a compatibility hot-fix right after today’s release to fix this issue. The fix went out a few minutes after our initial release, but it looks like you might have caught the older version that is incompatible with your older version of PHP.
So please remove the Wordfence files and then install Wordfence 6.0.5 which should work fine.
If you still have the same issue, please paste here what appears on line 509 in wordfenceClass.php and we’ll diagnose the issue.
Thanks.
Mark.
Hi Frederik,
Can you post a screenshot of your live traffic page? Or tell us if you’re seeing normal looking IP addresses on that page? I have a theory that what has happened is your hosting provider changed the way your server or environment works and Wordfence is getting internal IP’s. The effect of this would be that those IP’s are automatically whitelisted by Wordfence and so they will never be blocked even if they break a rule.
Regards,
Mark.