Mark Maunder

Wordfence 5.0.2 has been released as a hotfix.

This includes a fix for the warning you’re seeing above. Please upgrade and let me know if it resolves the issue.

Regards,

Mark.

Hi,

I’ve tested Falcon and basic caching with the following set of UTF8 characters:

¥ · £ · € · $ · ¢ · ₡ · ₢ · ₣ · ₤ · ₥ · ₦ · ₧ · ₨ · ₩ · ₪ · ₫ · ₭ · ₮ · ₯ · ₹

It appears to work perfectly.

Can you give me more information about which characters are being corrupted and what you’re seeing when they are corrupted. Also let me know if you’re running a Windows or Linux server. Not your workstation, but the actual web server, is it Windows running IIS or Linux running Apache.

Thanks.

Hi,

We’ll have a fix out shortly for this. This was also caused by us changing the order of access logging which caused the is_404() warning which many have reported. The is_404() fix will also fix this issue. The fix will be released within the next couple of hours.

Regards,

Mark.

We made a strategic decision to go this route because we see performance and security as closely linked. We also discovered a way to provide better performance for WordPress sites than the existing caching plugins available.

As our user needs become apparent we will be adding more documentation. Keep in mind that understanding mod_rewrite rules is above the average consumer. However if you’re interested, I’d encourage you to simply read your .htaccess once falcon is enabled and it’s fairly clear what we’re doing there. If you have any questions I’m happy to answer them here.

Regards,

Mark.

Thanks for the report. We’ll investigate the charset problem.

Please let me know what your server error log says when you see the internal server error.

Thanks.

Yes it sounds like WP_DEBUG is defined elsewhere and what you’re doing is overriding it with your own define() statement. But the order of execution is difficult to predict – perhaps your override gets called first or perhaps the existing statement gets called. So I would recommend asking your hosting provider if they’ve set WP_DEBUG and ask them to change that if it’s a production site.

Gotta get back to fixing this issue, so won’t be replying for a little while.

Regards,

Mark.

Not sure why my last message was not posted by the board. Trying again after I waited 5 mins. Sorry if a duplicate appears:

Firstly, thanks very much Otto for weighing in here.

For the folks that are complaining about this issue, you have the following setting in your wp-config.php file which should not be used in production sites:

define(‘WP_DEBUG’, true);

That is the only way that this error can possibly be generated and made visible to your customers.

I strongly recommend you disable debugging if you’re running a production website.

I’d appreciate it if some of the folks here can confirm that this setting IS in fact enabled in wp-config.php and also give me some insight as to why you would do this. Not looking to hen-peck our users, but I’d like to gain a deeper understanding of how you choose to configure your sites.

We changed the order in which the logging code is run as a performance enhancement in the newest version and it looks like is_404() is being called too early. So we’re working on a fix which will be released shortly.

Regards,

Mark.