Phil Erb

I didn’t update the version number – because nothing in the actual code changed, just the readme file. It’s been v1.0.1 since 2015 – and even that change was just cleaning up some blank lines from the file. If you look at the actual code for the plugin on your site, it probably hasn’t pulled the newest readme – WordFence is just comparing your version number against the WordPress plugin repo and noting that it’s currently maintained.

The plugin is so simple – it’s one actual line of code that just sets a flag in WordPress that was introduced in WordPress 3.5 when they removed a toggle for the XML-RPC setting from the interface. It’s done it’s job as simply as possible since 2012!

On all of the 6.4.2 sites where I have it installed, it’s working as expected.

What other plugins do you have installed? If anything is changing the xmlrpc_enabled filter, then that could be causing the results you’re seeing.

Not a problem. There are a couple of similarly named plugins.

Navigating to the xmlrpc.php file will still show that response. However, with the plugin active, XML-RPC will not accept requests.

Please check your site at https://xmlrpc.eritreo.it/ which will tell you if your site is accepting XML-RPC requests.

If it is, another plugin may be re-activating the XML-RPC functionality. All this plugin is doing is setting the WordPress “xmlrpc_enabled” filter to false. Another plugin could be setting it to true.

It may help, in that it’s going to limit the amount of processing that each XML-RPC call is going to take – for instance, with the plugin enabled, they’ll receive an from the XML-RPC processor. While generating this error takes a little bit of processing, it is less that what’s required to pull a page/post from the database.

However, I believe that’s only going to be a small step and may not even show any real effectiveness in making your site available throughout the DDOS attack.

I would recommend further measures, like using a plugin which will rate limit the requests coming from any on endpoint (I believe that Wordfence does this – though don’t take this as an endorsement, as I haven’t specifically tested the configuration). A CDN and/or web application firewall may also help.

If I recall correctly, Settings > Writing is where the toggle used to be. It was removed in version 3.5.

For reference, here is the original Trac ticket for removing the GUI option and enabling it by default: https://core.trac.wordpress.org/ticket/21509 (wow, that was over six years ago!).

I just ran the plugin through tests with 5.0.2 and pushed an update to the plugin repo to note that it’s supported.

I’m still around and available to support the plugin. I haven’t put it through testing on 5.0 yet, but I will in the next few days and push an update that indicates that it’s supported.

As you can see, it’s a super simple plugin (literally one line of actual code) that simply turns on the xmlrpc_enabled filter that was introduced in WordPress 3.5 – that version is when XML-RPC was enabled by default and, at the same time, the toggle to disable it was removed from the interface. So this plugin’s only purpose is a simple way to toggle that. If this plugin is activated, XML-RPC is off. If this plugin is deactivated, XML-RPC is on (unless something else is affecting the xmlrpc_enabled filter, of course).

https://plugins.trac.wordpress.org/browser/disable-xml-rpc/trunk