Front Page
Does anyone still use the xml-rpc protocol for their WordPress site? A question I was curious to find the answer; which unknowingly led me down a rabbit hole. Just what is XML-RPC in the first place. I had recently heard about this piece of technology after reading an article about disabling it for fear of attack methods to gain access to my personal website. It seems that all WordPress websites have this enabled by default and that unless I was using some type of remote publishing software to manage/publish articles on my website, there was no need to have this thing enabled. So what exactly is XML-RPC? XML-RPC goes back to the early days of the internet of 1998. Created by Dave Winer in collaboration with Microsoft, it became one of the earliest methods of an API via HTTP. This was valuable back then because programming languages ( such as Java which had Java RMI) had libraries which incorporated XML, leading one piece of software be able to communicate with another via a user readable markup language. Personally interesting to me, the successor of said protocol became SOAP. I can remember in the early 2000’s of this thing from Microsoft called SOAP, or Simple Object Access Protocol, which was a more advanced XML format. Turns out XML-RPC was a precursor. Companies were incorporating XML into just about anything, from RSS feeds to iTunes music libraries used it. XMl-RPC stands for XML Remote Procedure Protocol; fancy words for sending/receiving data in an XML format over HTTP . XML or Extensible Markup Language is the schema for passing variables between the two. There is no built-in authentication, this is done via the HTTP process (if added). Now a days, XML has mostly been replaced by JSON, or JavaScript Object Notation. Matter of fact, since around 20101, the true XML-RPC protocol itself has mostly been replaced by XML transferred directly over HTTP, bypassing the RPC part entirely. You don’t even need the PHP module (php-xmlrpc) enabled to make the WordPress client/server work today. The XML can be parsed directly from PHP. It seems WordPress was keen to add this functionality into the WordPress core as it would allow uses creating articles on desktop software to be able to publish directly to ones own site. Remember, back in the day, running an word processor/web editor entirely in a web browser was a herculean task. Fast forward a few years to the birth of WordPress in 2003, a forked version of b2/cafelog, WordPress always had an xml-rpc client/server built into its core. At least as far back as version 2.6, you could theoretically enable the server for remote publishing as to receive posts to be published. Around version 3.5, released in 2010, some seven years after the launch of WordPress, XML-RPC was enabled by default into the WordPress core. One would have to visit the Settings page to uncheck the Remote Publishing option to disable it. The Documentation for WordPress’ XML-RPC API has always been somewhat sparse and has changed over the course of WordPress’ decades of development. Many of the links on the documentation page are dead or no longer functioning, so I needed to use the Wayback Machine from Archive.org to fill in the blanks. Originally the API used five client callbacks for publishing; Blogger (now defunct by Google), MetaWeblog (another creation from Dave Winer), MovableType (now a closed sourced, proprietary software), the WordPress.com API, and a separate PingBack API. The fact that all but Automattic’s WordPress is still around today tells you where this article is going… And speaking of the separate Pingback API, this ended up being the beginning of the downfall of using XML-RPC. If you’re not familiar with what the pingback feature is, it is a method for “pinging” other blogs that are mentioned in a post. For example if you linked to a domain in your article, say example.com, and you hit published; If you had pingbacks enabled and the other site in question was running a blog platform that also accepts pingbacks, it would send an XML-RPC pingback call to the example.com site that it was linked in your article. Sounds great right, you’re able to let the owner of said site that you have mentioned something valuable in your article, giving them credit. Except, part of the pingback API was to verify that the domain in question is indeed linked in said article. This would cause the example.com site to pingback to the original site that sent the first pingback to verify that indeed the article in question has linked example.com in its post. Problem is, it was easy to send false verification methods to make unwillingly WordPress sites to ping random website to verify a link that never existed. Due this thousands of times to random WordPress sites, all wanting to verify that the site example.com has linked my random site, would cause a ddos attack on example.com This was somewhat of a known vulnerability going back to 20122, but didn’t make headlines until a few years later when in 2014, Akamai3, noticed an uptick in ddos attacks. Some speculation of the timing of the attack coincides to the release of WordPress, version 3.5, which just so happens to be the very version remote publishing (XML-RPC) was enabled by default. So the attack vector went from a few sites testing out the feature to almost all WordPress sites running version 3.5. At this point, over 20% of the web was being powered by WordPress. Soon after, code snippets showed up online on how to disable or prevent access for using remote publishing (XML-RPC) on WordPress. Even plugins to disable the xml-rpc.php file. Some plugins disabled the entire protocol, while others only disabled the pingback feature. But it seems that the concept of using pingbacks was an idea that never went any farther. And so, only the WordPress API still has a pingback function allowing you to publish from WordPress.com to your own hosted WordPress.org version. The rest have either been acquired or defunct. Fast forward to today, where WordPress dominates more than 40% of the internet. Things have changed quite a bit since the early days of the internet. The WP API was launched, using JSON as the language between client and server. The built in editor, Gutenberg, does more than any offline publishing tool ever did. The web browser has consumed practically all native software running on desktop machines. That is to say, if you are even using such a device and not some Chromebook labeled notebook. I decided to take a look at the landing page for XML-RPC on WordPress. There is a lot to unpack here about the current state of XML-RPC in the WordPress core. The first problem that reached out to me was visiting the very first link on the page, xmlrpc.com, leads you to a 404. So I had to visit the trusty Archive.org service, the Wayback Machine to pull up an archive of what the site should look like on this protocol. Ok, I thought to myself, although the main site focusing on this protocol is no longer valid, perhaps the rest of the data might still be valid today. I had… no such luck. As I had already explained above about the five services listed as being add to the XML-RPC client code in core are also defunct, those pages were too, also defunct. Well at least I can look at the code in core to see the libraries that were added. Blogger’s API5 might have been gone since the early 2000’s, but the code is still there. There is also a link on the WordPress page about weblog clients that support XML-RPC for remote publishing. However to my dismay, most of these too were also defunct. Even the link for creating your own client6 was now gone. Again, back to the Wayback machine to see what, if any, pages remained of the site offering code and examples on building your own client. Side Note Interestingly enough, the domain in question now redirects to another domain, which I’m pretty sure is being used for SEO link juice. Probably get a nice boost from WordPress linking back to you. The truth of the matter by and large, this whole part of WordPress seems like something of a bygone era. Links that seem to go nowhere, code repositories that are missing, API libraries that are no longer updated. The creators of said API libraries are also defunct, good luck finding information on some of them. The whole thing seems like its something that has been left in place and forgotten about. Turns out, I don’t think I’m too far off with this conclusion. One of the main reasons XML-RPC is still in the core, seems to be due to plugins. Most importantly enough, Automattic’s own Jetpack plugin7, which still uses XML-RPC. It would seem only a handful of big time plugins like Jetpack, Uncanny Automator, and some mobile publishing software for android/iOS still use it. With the ever expanding and updating of WordPress’ WP API, which will be updated in version 6.8, it should come as no surprise that sooner rather than later, we’ll be saying our last good byes to XML-RPC.
The Current State of XML-RPC at WordPress
What is XML-RPC?
Incorporating into WordPress
The Now
Footnotes