Remove XML-RPC specification

[discobot]

---

Read-only archive: Issues · ClassicPress/ClassicPress · GitHub

Author: Pieter Bos

Vote count: 91

Status: Research Plugin (GitHub)

Tags:

• request-remove-feature
• difficulty-moderate

---

Comments

I am not particularly keen on this one, unless there is a simple way to convert use of the XML-RPC spec to using the REST API. I think having a wide range of means of accessing CP will always be a good thing. I actually use XML-RPC on my localhost test sites (though never on a live site). I would prefer simply to have a simple on-off switch for XML-RPC, and for the default setting to be off.

~ posted by KTS915

That can also be an idea. As this one already has votes, I don’t want to edit it anymore (if even possible), maybe open a new one that gives that option?

~ posted by Pieter Bos

OK, good idea!

~ posted by KTS915

Let’s investigate which plugins this would break, especially widely used plugins. Jetpack is one.

~ posted by James Nylen

Jetpack is a topic for a different discussion I think

~ posted by Pieter Bos

I think it’s pretty closely related. Before we can make any decision to remove or disable a feature, we need to know roughly which plugins it will break, and decide whether we are OK with that.

~ posted by James Nylen

Yes, I agree about investigating which plugins it would break. What I mean about Jetpack, the mere fact that you need a wordpress.com account for it to work and it is constantly talking to wordpress.com, means that I would be inclined to vote the whole thing as restricted, meaning: has no business on ClassicPress. And of course I do realise that there are a bunch of people in love with that things, so that is why I said topic for a different discussion

~ posted by Pieter Bos

XML-RPC should be moved to a core plugin; if people need it they can enable it, if they don’t they can delete it. This improves the security profile of CP without breaking backwards-compatibility.

~ posted by invisnet

I like the idea of its being a core plugin.

~ posted by KTS915

I like the idea of moving less-used features out to plugins too.

However, we’d still want to handle other plugins that depend on those features. Still using Jetpack as an example: if someone requests to install Jetpack, we should prevent this unless the XML-RPC plugin is also installed (or auto-install it too).

This means we need to solve plugin dependencies before we can really start removing stuff, and calculate our own dependencies for at least the most popular plugins.

~ posted by James Nylen

@James Nylen: About plugin dependencies, see also Issues · ClassicPress/ClassicPress · GitHub

~ posted by Dora D.

I agree with that James

~ posted by Pieter Bos

What little my client’s use of Jetpack (stats and VaultPress) doesn’t require XML-RPC. I hard code XML-RPC off, as it is still the hacker’s fave way to brute force the login page. It needs to go!

~ posted by BlogAid

BlogAid: I think Jetpack is still using XML-RPC behind the scenes here.

~ posted by James Nylen

James, agreed, but the 2 things I mentioned work with it turned off otherwise.

~ posted by BlogAid

I’ve done research on this. Yes its problematic, and can cause security issues (big time) - but its also a core function of how WordPress works and integrates with other plugins. Think this one carefully.

~ posted by Avrom

Don’t know if this has been mentioned or not but XML-RPC is required to use the mobile apps for WordPress.

~ posted by Duncan McClean

Is there any reason why those mobile apps can’t use an API instead? Maybe deprecating this will light that fire.

~ posted by BlogAid

Maybe we can migrate all the xml-rpc as external plugin, so for who need compatibility can have it but for the majority of users is removed from the core.

~ posted by Daniele Scasciafratte

@Daniele, sounds like a good approach.

~ posted by Avrom

If nothing else, the ‘feature’ that allows attackers to try hundreds of username / password combinations in a xml-rpc single call has to go. There is zero legitimate use for this and it’s in active use against WP sites.

~ posted by Ian

Agree with pretty much everyone. I believe XML-RPC should be disabled by default (including in WP) since it is enabled on probably 96%+ of sites that do not need/use it (though as @KTS915 mentioned, it should be easily enabled in settings, maybe even a question in famous 5-minute: “Enable XML-RPC? Note: This is only required by some external apps, such as the mobile app. If you’re not sure, it is highly recommended that you leave it disabled.”). The idea of separating it into a plugin would be okay as well, but a default-off checkbox in settings might minimize difficulties that may be encountered with future back-porting (?).

As it is, enabling the ability to hammer xmlrpc by default is lame.

~ posted by Daniel Hendricks

XML-RPC should definitely be removed from Core. As @James hit upon, the API is almost entirely retained for Jetpack + WordPress.com access:

It’s Time for XML-RPC in WordPress to Hit the Road – WP Tavern

When I wrote this piece in 2015, Matt Mullenweg lashed out, but did not clearly explain why he disagreed. We can assume it’s because it would cause headaches primarily (only) for the Jetpack integration. And yes, I can confirm based on several years of managed hosting clients that disabling XML-RPC will break pretty much any Jetpack-infused services, like VaultPress, because those services check first that XML-RPC is enabled even if its not being used. In other words, it’s almost entirely an Automattic-exclusive API at this point.

The REST API is already here, and its the future. Even Automattic’s desktop client Calypso has already moved to that API instead of XML-RPC.

Besides Jetpack, I think the only other relevant software to mention here would be the Android and iOS apps for WordPress. But these have been poorly maintained for years, I wouldn’t be surprised if the REST API takes over soon…

~ posted by Jesse

There are other third-party integrations that still use XML-RPC, like MarsEdit 5 - Powerful web publishing from your Mac. for example.

~ posted by James Nylen

Thanks Jesse Nickles for alerting me about this thread, and thanks James Nylen for mentioning MarsEdit. It’s a really bad idea to remove XML-RPC support for your fork of WordPress unless you want to eliminate support for all 3rd party clients, such as MarsEdit, that rely on it to connect to WordPress/ClassicPress.

For years I have been anticipating an eventual shift to the REST API but as of yet no clients such as MarsEdit can switch to the REST API because the only supported authentication scheme is cookie-based (in-browser).

Notably the WordPress iOS and (I assume) Android apps still use the XML-RPC API because they are also not able to reliably authenticate with self-installe WordPress sites for the REST API.

If ClassicPress wants to retain support for 3rd party clients such as MarsEdit, and for the WordPress.org iPhone app, then it should not remove the XMLRPC API.

~ posted by Daniel Jalkut

Note we are not going to remove the XML-RPC API entirely, rather we are going to make it possible to disable this and other less-used features from within the UI.

Per discussion above and ClassicPress | Stable. Lightweight. Instantly Familiar., this will be achieved by moving things out into core plugins which can be disabled or even deleted if desired.

~ posted by James Nylen

[viktor]

No votes are needed on this petition. XML-RPC will eventually move to a core plugin. No timeline on this, but work is in progress. Additional discussion can be found here.

[viktor]

The progress on the core plugin will be tracked here:

Core Plugin: XML-RPC