Brute Force Login Protection + Update Manager

Mod Edit: Split from ClassicPress Update Manager

Okay, I give in. I can’t get this to work, no matter what I try.

I made the changes to the actual plugin, changed the namespace, added the require once, lines 28 & 72 and updated the version number.

But I have no idea what this “endpoint” thing is. When I test it, I just get [ ]

Originally I set the endpoint to where the current 2.0.1 plugin is installed, but that didn’t work.

So I created the folder cpbflp in both the wp-content folder and the root folder. I uploaded the updated plugin folders and files to both and the zip file to both.

Tried various settings in the editor and ended up just using the bare minimum settings. Saved it as Pending and gave it one site to test it with. But nothing happens, probably because the endpoint test fails.

What am I missing? It’s all right for you geeks, but I need a simpler explanation of what to do.

1 Like

Where did you try the endpoint?
From here?

When BFLP is unzipped in the plugin folder (even on another server) the folder is CP-Brute-Force-Login-Protection. The endpoind identifier must match pluginfolder/pluginfile.php so CP-Brute-Force-Login-Protection/cp-brute-force-login-protection.php

But it seems there is some other thing not going right.
Some warning in logs?


1 Like

Yes that’s where I checked the endpoint.

I created another one using the actual plugin location as you show, but still nothing.

This is the URL of the endpoint:

There is nothing in the error logs for cPanel, root or wp-admin

1 Like

Try to set (in the plugin) 'server' => '',
to see if the plugin (CPBFLP) side is working (you should get an update but don’t do it!).

1 Like

No, had no effect.

I published the endpoint and now I get the text in my browser for the endpoint. If I change it back to pending, it goes away again.

But my sites aren’t seeing any update available yet.

1 Like

Ok, to test with your sites when it’s pending you have to enter them in Testing Domains.
Can you send the endpoint link?

1 Like

Test site doesn’t see an update whether pending or published.

The endpoint is still the same as the blue link above.

1 Like

Ok, requires is referred to CP version.
Requires: 1.0.0

1 Like

Okay. Have changed that.

I’m just wondering how my sites know there is an update? They don’t have a version of the CPBFLP plugin with the extra update manager files (still on 2.0.1).

Do sites need those extra files in the plugin before they will contact

The forum is warning me I’m posting too much. It’s nearly midnight here, so I’ll call it quits for the day.

1 Like

No, they will not update…
v. 2.0.2 will get updates when 2.0.3 comes out!

You can try just changing from Version: 2.0.2 to Version: 99.0.2 to check that everything is working fine.


Got it. Thought that might be the case. Thanks.


First a couple of things…

@Aussie, sorry for the difficulty in getting the Update Manager working with your plugin … and @Simone, thanks for this valiant effort to help an end user out – this was all good advice.

Let me clarify that no files inside the plugin should be changed. The changes should be made only in the UpdateClient.class.php file that you copy into your own plugin. Any changes you make to the actual Update Manager plugin code would be wiped out when you updated the plugin.

This is likely an issue in that the plugin expects the plugin folder and primary PHP file to be named the same, ie, my-plugin/my-plugin.php, with lowercase letters. While I view this as a better practice in design, it’s not a hard rule. This has been resolved in RC2 which will be out in a day or two if no other issues are filed. I’d recommend waiting for that version before proceeding further with it as there will be a breaking change. I’ll be happy to help you get the Update Manager working if you still need an assist.

1 Like

@anon71687268 No need to apologise, I’m doing something I barely understand. But that’s how I’ve learned everything I know about computing and websites. A lot of “monkey-see-monkey-do” and sheer doggedness.

Simone did the initial fork of the CPBFLP plugin, so there was vested interest there. But, yes the help was greatly appreciated.

I have changed everything to lower case as you suggested and uploaded a version of the 2.0.2 plugin to a test site and set the version to 1.9.9 to see if an update shows up eventually (just came through).

I wasn’t changing anything in your plugin, I think the post you were referring to was a change made in the CPBFLP plugin installed on And yes, I am going to shut this machine down now.

1 Like

If it’s any consolation @Aussie I had exactly the same problem trying to get it work with Classic Commerce. We still had the folder name as classic-commerce but the main file was woocommerce.php. It didn’t work till I renamed the file the same as the folder.

1 Like


This is likely an issue in that the plugin expects the plugin folder and primary PHP file to be named the same, ie, my-plugin/my-plugin.php , with lowercase letters.

In my experience, it doesn’t matter how much information you put into the instructions on how to use something, there will always be someone who gets it wrong. Text is simply a poor medium for communication. That’s assuming anyone bothers to read all your instructions in the first place.




Good work! :+1:

1 Like

Way to stick it out and win the day!

Did it come down to the folder name having CaPs? If not, I’m curious to know if there’s something in particular that threw you off … something that could be made clearer?


@anon71687268 Yes I think it was that, as the update appeared soon after I changed it last night.

I think as ozfiddler said, it needs to be made clear that the folder and file names should be the same and in lower case.

For me the word Endpoint caused me the most trouble because I didn’t know if it was a coding term or just your choice. I also couldn’t grasp exactly what to put in there - the current location or a new folder for the updated plugin.

I didn’t understand that the site acting as the server needs to have the updated plugin already installed. I thought, because the docs said you could update the site acting as the server, that the updated plugin needed to be put in a folder of its own:

5. Can Update Manager update plugins on the same site where it is installed?

Maybe the hint:

Use the form folder-name/file-name.php to match that of your plugin.

Should read:

Use the format: folder-name/file-name.php from your plugin location in wp-content/plugins on this site. Both names must match and be in lowercase.


Rather than better-documenting this, I’ve opted to modify the code so that it doesn’t matter how you name your directory and file. While I view it as a best practice to name the folder and primary PHP file identically, it’s not the Update Manager’s job to enforce my preferences on how you design your own plugin. This is fixed in the next version. :wink:

I can’t take credit for the term “endpoint” … but, yeah, I suppose it’s more of a developer term. Given the nature of the plugin and what it’s doing, I’m not sure there’s a better term. I’ll add it to the FAQ.

The value that goes in there is whatever you used in your remote plugin’s design. If your plugin was built like my-sweet-plugin/my-sweet-plugin.php, that’s exaclty what you would put in the box. As previously mentioned, in the next version you will be able to “mismatch” the file and folder name rather than adhering to my preference.

This isn’t accurate. The site acting as the server only needs to have the Update Manager plugin installed. There is no need to have the to-be-updated plugin installed or hosted on the same site as the Update Manager plugin. That said, you absolutely can update a plugin that you’re using on the same site as the Update Manager plugin – when you push an update, your end users get the notification…and so do you… It’s a bit meta to wrap the mind around, I know… believe me, I know. :smiley: :smiley: :smiley:

That FAQ entry could be reworded, or, more likely, removed. It is intending to say that "you can also update plugins on the same server as the Update Manager plugin…you’re not limited to only updating offsite plugins.

This would imply that the plugin to-be-updated must live on the same server as the Update Manager plugin, which is not accurate… I think this change would lead to more confusion than presently exists.