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
OK, good idea!
~ posted by KTS915
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
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
I agree with that James
~ posted by Pieter Bos
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
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
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
September 16, 2021, 6:06pm
3
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 .
4 Likes
The progress on the core plugin will be tracked here:
opened 04:17AM - 06 Jul 22 UTC
type: feature request
help wanted
status: needs pr
flag: major change
scope: core plugins
Move XML-RPC to core plugin ([orginal petition](https://forums.classicpress.net/… t/remove-xml-rpc-specification/2798/4)).