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.
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?
@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.
@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 ClassicPress.club. And yes, I am going to shut this machine down now.
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.
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.
@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? Yes.
Maybe the hint:
Use the form folder-name/file-name.php to match that of your plugin.
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.
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.
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.