Michael

I am very sure that it was not a configuration issue. I took a screenshot of all notification settings before I disabled the plugin. I never created a notification with all users as recipients.

But you are right, I should have posted this in the support forum first.

This is what the plugin did and the review is therefore justified. Even if I could help you to debug your plugin, I would never use it again. We have thousands of users who all received several wrong notifications. The corresponding notification was set to deliver the emails to admins only. If you offer a notification plugin, you have to be 100% sure that it does not send emails to the wrong people, I admit it was my mistake to use a plugin for such sensitive task in the first place. I am now writing the corresponding code myself.

I found a way to test if a doc has beed tagged with a certain Doc Tag:

if(in_array($yourTag,wp_get_post_terms(get_the_ID(),'bp_docs_tag',array("fields" => "names"))))

Did you verify that pages are served from the cache? This article explains how you can verify if WTC is working: https://www.webnots.com/how-to-check-w3-total-cache-is-working-on-your-wordpress-site/

Note that is usually not enough to just install and configure WTC. You usually need to do a few things on the server.

It would be a miracle if Stopbadbots works with WTC. Like most caching plugins WTC modifies .htaccess and redirects the web server to load pages directly from the cache. This means that WordPress plugins are no longer involved in page delivery once the page is in the cache. This is the very point of caching because PHP it the main reason for slow page delivery. This means that Stopbadbots no longer “sees” page requests that are in the cache and can therefore not block such requests.

What you need to do is to work with Javascript or add all your bots to .htaccess and block access there. The latter would make sense anyway because this way the bots consume less server resources.

• This reply was modified 6 years, 5 months ago by Michael. Reason: changed link

Did you verify that the page was delivered from the WTC cache? You can configure WTC in test mode. You can then see on the delivered page that it comes from cache.

I tested it many times. Whenever I disable WTC, StopBadBots works fine. I then enable W3TC and load a certain page and StopBadBots still blocks the bot. wget will then store an empty index.html. But I when I load exactly the same page a second time, wget will download the page.

Memory Checkup says I have 256MB and 8MB are used.

StopBadBots only works when a certain page is accessed the first time because the page is then not yet in the cache. If you access the page a second time with a bot (I tried wget), StopBadBots no longer recognizes the bot.

You also have to make sure that you configured W3 Total Cache properly, that is that you enabled all caches (pages, objects, MySQL etc.) You also have to check if the delivered page really comes from the cache. There are plenty of ways to mess up a WTC configuration.

This doesn’t really make any sense. I am working in IT for 35 years and as an IT journalist and consultant I have tested countless firewalls and security solutions. I never saw a tool that restricts access without informing admins about the restriction and giving them the ability to remove the restriction. This is a serious flaw in Wordfence. There is really no room for discussion here.

I skimmed through your code and I don’t think that the plugin currently prevents the sending of duplicates. Actually, we had a case where some subscribers received 10 copies which resulted in a wave of complaints and many of our subscribers unsubscribed.

I think you can replicate the problem by creating a cron job with several hundred email addresses and then just launch the cron URL twice. Note that this is just one case where your plugin will send an email multiple times to the same address. This only demonstrates that your plugin is unable to prevent duplicates. We also observed that the problem usually occurs when the server is under stress.

I hacked now into your plugin to prevent this from happening again. Whenever an email is sent I create a text file with the email subject as filename. I then add the email address to this file. Before an email with a certain subject is stent I first check if the address is in this file and if it is, I exit the function. This appears to work so far.

Of course, this is just a quick-and-dirty solution. I hope you can fix this serious bug in your plugin.

Bill, I am afraid you still don’t understand. This is not a troubleshooting case. Your plugin is incompatible with W3 Total Cache which is one of the most popular plugins for big sites. Actually, I think StopBadBots currently does not work with most caching plugin because most of them redirect traffic via .htaccess and StopBadBots code will then not executed anymore.

This means that exactly those sites that would be interested in paying for the premium version, can’t use StopBadBots.

My guess is that you have to work with JavaScript because this code is also executed if the HTML page comes from a cache.

sminozz, thanks for the reply. I think you misunderstood my post. W3 Total Cache is not a bot. It is a very popular caching plugin that runs on many big sites. W3 Total Cache makes your plugin useless because even if StopBadBots is enabled ALL bots can access the site. The reason is that W3 Total Cache loads pages from its cache and StopBadBots has no chance to intervene anymore.

Maybe your support page does not work. How about just replying here?

It seems the problem occurs if you work with cron and the set the Email Count parameter to a high number (>1000). If the server load is then high, some recipients will receive the same email multiple times.

Malay, thanks for fixing this! It works again.

I contacted you but didn’t hear back from you. Anyone interested in fixing this serious bug?

The plugin bug still exists. It appears to happen less frequently, but this can have other reasons. It might be an incompatibility with the popular W3 Total Cache plugin. But this is only a wild guess.

Note that we use countless other plugins that store their options in a similar way and All in One SEO Pack is the only one that constantly resets its settings.

I think you need to completely rewrite the procedure that tests whether the plugin is loaded the fist the time.

Michael, thanks. I just updated. It will take a little until I know if the problem is fixed.