Updated libxml2-fix Plugin for WordPress

I made a small update to the libxml2-fix WordPress plugin this morning. There are few more odd combinations of PHP + libxml2 that have problems, so this change applies the work around as long as the libxml2 version is below 2.7.3. That saves on having to list all of the individual versions that may have this issue. This improvement was submitted by Danilo Ercoli.

I’m bummed that there are still so many hosts running known to be broken combinations of PHP + libxml2. In the meantime we may as well make it easier for people to work around the issue.

WordPress Plugin Update: LibXML2 Fix

A small update to the LibXML2 Fix WordPress plugin is now available, version 0.2.3.

The only change was the addition of 2.6.27 to the list of libxml versions that the plugin looks for. I’ve had a few reports that this version also has problems with stripping brackets.

For those that haven’t been following this problem here’s the short version of the story. Some combinations of libxml and PHP don’t play nice with each other, the result being that brackets get stripped out of XML content. This is a particular problem for XML-RPC requests in WordPress. This plugin injects a small hack into the XML-RPC data before it gets processed in an attempt to preserve the brackets.

WordPress 2.9 – XML-RPC and AtomPub Changes

Just in time for Christmas WordPress 2.9 is out. Here’s what has changed in the XML-RPC and AtomPub APIs since 2.8.6:


  • Expose user registration option via wp.getOptions/wp.setOptions ( ticket #10454 )
  • Fix bug in wp.getComment that reported spam comments with a status of hold ( ticket #10510 )
  • Adjust how the XML-RPC server is activated so that the functions can be reused in other areas ( ticket #10513 )
  • Fix bug in setting optional number of pages arguments for wp.getPages ( ticket #10659 )
  • Reduced memory usage when processing requests ( ticket #10698 )


  • Fix a conflict with plugins that redefine wp_set_current_user() ( ticket #10938 )

If you are using the WordPress XML-RPC/AtomPub APIs in your software or service, or are just interested in this part of WordPress, please join the WordPress XML-RPC email list. Code changes and patches can be submitted via tickets at http://core.trac.wordpress.org/.

XML-RPC Types: Dates vs. Strings

The XML-RPC spec outlines 6 types: integer, boolean, string, double, date/time and base64. If you count struct and array as types then we go up to 8 types. The XML-RPC page on Wikipedia has examples of the XML tags for these data types.

One mistake that I’ve seen commonly made (and I’ve done it myself) is to confuse dates and strings. It’s easy to do, most databases for instance treat date input essentially as a string. So it might seem natural that a date would be encoded in XML-RPC as:


and expect the XML-RPC server to just know that it should be converting that value to a date/time. XML-RPC libraries massage the encoded values based on the XML tag though, so this gets treated as a string. The correct mark up for a date/time value would be:


An XML-RPC library will then put this into a correct date context for that specific programming language.

If you find that a date field in your XML-RPC request isn’t being processed correctly take a look at the raw XML, you may actually be passing it as a string. When a problem comes up spending a minute to verify the XML tag can save you a bigger headache later on.

WordPress 2.8.1 – XML-RPC and AtomPub Changes

The 2.8.1 release of WordPress is now available. This is mostly a bug fix release so there are only a few small changes in the area of XML-RPC and no changes in AtomPub:

  • metaWeblog.getPost now returns the correct value for the date_created_gmt field for draft posts ( ticket #10244 )
  • RSD API endpoint URLs now use HTTPS if FORCE_SSL_ADMIN or FORCE_SSL_LOGIN is defined and true ( ticket #10330 )

WordPress 2.8 – XML-RPC and AtomPub Changes

Here’s what has changed in WordPress XML-RPC and AtomPub APIs from 2.7.1 to the new WordPress 2.8 release:


  • Fixed wp.getUsersBlogs and blogger.getUsersBlogs to return the correct value for the ‘xmlrpc’ field when WordPress is installed in separate directory ( ticket #9516 )
  • Authentication is filterable now, allowing for alternative authentication methods like OAuth ( ticket #8941 and #8938 )
  • Provide sticky status of posts via ‘sticky’ field in metaWeblog.newPost / metaWeblog.editPost / metaWeblog.getPost ( ticket #8777 )
  • Don’t duplicate post enclosures ( ticket #7773 )


  • Always use filterable authentication, allowing for alternative authentication methods like OAuth ( ticket #9320 and #8938 )
  • Update image captions (summary) correctly ( ticket #9148 )
  • Hooks for extending AtomPub ( ticket #8827 )
  • Fix file upload updates and image processing when uploading an image ( ticket #9233 )
  • Provide the correct edit URL for images ( ticket #9147 )

A big thank you to everyone who submitted tickets and patches. With 2.8 out the door now is the time to bring up new features for WordPress 2.9. If you’ve got a patch for a new feature, even better! Go submit a ticket at http://core.trac.wordpress.org/.

If you are using the WordPress XML-RPC/AtomPub APIs in your software or service, or are just interested in this part of WordPress, please join the WordPress XML-RPC email list.

LibXML2 Fix – Version 0.2

I’ve updated my LibXML2 Fix WordPress plugin so that the work around is enabled even if you have libxml2 2.7.3 installed but have a PHP version that is less that 5.2.9. This should fix servers who decided to update libxml2 without updating PHP.

Further details and history are at my LibXML2 Fix plugin page.

Update: Rein caught a typo in version 0.2, so make sure that you get version 0.2.2.

WordPress Theme Authors, Don’t Forget The wp_head() Function

When creating a WordPress theme don’t forget to include a wp_head(); call in the HTML HEAD section of your theme. It’s very simple to do, just include:


Before the closing HEAD tag (</head>) in your HTML.

Why make such a fuss over a single function call? Because it does a fair bit of work behind the scenes and without it some WordPress features will not work properly. Take a look at the wp_head section of the wp-includes/default-filters.php file in WordPress, you’ll see a number of events that are tied to the wp_head action.

One area where this is a particular problem is for offline blog clients that make use of the XML-RPC and AtomPub APIs in WordPress. The “Really Simple Discoverability” (RSD) link that WordPress inserts instructs these clients on where to find the RSD URL, which contains information on how the clients can send XML-RPC and AtomPub requests. We’ve seen a number of times now where an error reported by a WordPress iPhone App user is caused because there is no RSD link in their WordPress blog. Looking a little deeper reveals that there was no RSD link because the theme they were using didn’t include a call to wp_head().

If you are writing a WordPress theme here is your reminder, make sure that the wp_head() function is being called at the end of your HEAD section.

Slow Loading RSD URLs In WordPress

A common mechanism for XML-RPC clients to find out information about your WordPress blog is to look for the Really Simple Discovery (RSD) URL. The RSD contains information about the available APIs that WordPress supports. A typical discovery process would look something like this:

  1. Request your blog URL, http://example.com/ and look for the RSD link element
  2. Request the RSD URL and parse the provided info
  3. Determine which API information to use
  4. Communicate with your blog via the determined API

On rare occasions I’ve seen reports where the RSD URL (which looks like http://example.com/xmlrpc.php?rsd in WordPress) will take a very long time to load (3 minutes or more) even though the rest of the site responds very quickly. This can cause problems for XML-RPC clients (like the WordPress iPhone app) if they timeout trying to get the RSD data. The reports of this problem were few and far between, without much of a common thread. Until today.

Ticket 9380 showed up earlier today, reported by foks. Foks noticed that the SSL check being done when the RSD URL was requested didn’t have a timeout set, so if the conditions were just right it will wait for the system level timeout before failing. That explained why the RSD request would take so long in some cases. If you’ve run into this problem you can use the trivial one line patch or grab a copy of the wp-includes/functions.php file from the WordPress 2.7.x branch at http://core.trac.wordpress.org/browser/branches/2.7/wp-includes/functions.php?rev=10831&format=txt and try it out.

This fix has been applied to both the 2.7.x branch (meaning it will be part of a 2.7.2 release if there is one) and -trunk (meaning it will be part of the upcoming 2.8 release).