XML-RPC is one of the oldest, and possibly lesser used, components of WordPress. In fact, it has been around since day one, and will probably continue to stick around for many days to come.
In this article, we take a closer look at what XML-RPC is, and what it does, in reference to WordPress.
What Is XML-RPC?
XML-RPC is a not a WordPress-only innovation. In fact, it was a part of the original b2 software, from which WordPress was forked. However, earlier versions of WordPress had it turned off by default. Starting WordPress 3.5, functionality for XML-RPC has been turned on by default.
So, now that the history class is over, what does XML-RPC do?
In simple words, XML-RPC is what is used to standardize communications across different platforms. For instance, if WordPress needs to communicate with a different platform, say Blogger, or manage a website from a desktop client or a mobile app, XML-RPC can prove useful. With HTTP as the mechanism for transmission and XML as the mechanism for encoding, XML-RPC has often proved useful for helping external applications, services and clients in interacting with WordPress.
The class responsible for handling XML-RPC in WordPress can be found at wp-includes/class-wp-xmlrpc-server.php — this is where you will find functions for stuff like Blogger, Movable Type, as well as pingbacks. Rather than divulging the details here, I’d point you to a Tuts+ article, that has done the job of explaining the structure of the class really well.
However, that is not all. XML-RPC, at the end of the day, has been authenticating or communicating with different services via basic authentication. In today’s internet, with security loopholes rising everyday, sending data via basic authentication is probably not a good idea, and this is precisely why XML-RPC is falling out of favor. Using advanced authentication by means of tokens is a better choice.
Plus, XML-RPC has often served as a scapegoat for brute force attacks. Since XML-RPC requires a username and password when communicating, it is used for brute force attacks because you will pass through if you hit the right username and password combination, as reported by Sucuri.
On account of such security issues, many in the community have suggested turning XML-RPC off, especially if the concerned blog or website makes no use of it. There is a plugin to help you through that.
Alternatively, if you are more concerned about brute force attacks, protecting your login page via Login Lockdown or the Jetpack Protect module is a good idea.
With the new WP REST API infrastructure already included in WordPress, it won’t be long before XML-RPC finds itself falling even more out of favour. There are several key areas where the WP REST API does a better job than XML-RPC.
For example, by means of oAuth, the WordPress API relies on advanced authentication via tokens, as opposed to basic authentication via raw username and password of XML-RPC. This will also prove useful in ruling out a possible avenue for brute force attacks.
Most importantly, the WordPress API uses JSON, which has proven to be simpler and easier to use as compared to XML.
As a result, it’s possible that we might see XML-RPC fading into oblivion, as far as WordPress websites are concerned. Of course, backwards compatibility means it will still continue to be a part of WordPress in some form, but essentially, the new API will take over many of the tasks that have thus far been performed by XML-RPC.
For what it’s worth, XML-RPC has proven really useful for letting external services and clients interact with WordPress. Now, as the WordPress REST API becomes more of a reality, XML-RPC’s role will diminish. Of course, that is not gonna happen tomorrow, because the new WP API still lacks in some aspects and is yet to be fully integrated in WordPress core. But starting from here, XML-RPC will find less acceptance and will shrink in terms of usage.
Have you ever made use of XML-RPC in your projects? What was your experience? Share your views in the comments below!