I’ve been fighting with WordPress 2.7’s xmlrpc.php file for a few days now, and I’ve made 2 modifications that may be useful to you.
If you’re writing new posts via metaWeblog.newPost and the angle brackets from your HTML formatting are being stripped out (as described in this official WordPress bug report) and you’d rather not rebuild PHP on your server (who does?), open up xmlrpc.php and replace:
$post_content = apply_filters( 'content_save_pre', $content_struct['description'] );
with
$post_content = apply_filters( 'content_save_pre', $content_struct['description'] );
$post_content = str_replace('lt;', '< ', $post_content);
$post_content = str_replace('gt;', '>', $post_content);
This should replace the stripped angle brackets with actual, functioning angle brackets.
Secondly, if you’re having trouble uploading files via metaWeblog.newMediaObject, try this fix (big thanks to Keith Garner). In xmlrpc.php replace:
$bits = $data['bits'];
with
$bits = $data['bits'];
$bits = base64_decode($bits);
WordPress has given me quite a roller coaster ride these past couple years. While 2.7 is a huge improvement over the last couple releases, if I wasn’t so committed, I’d be looking for something much leaner.
Update 30 Dec 2008
Big thanks to Daniel Jalkut for commenting that the reason I needed $bits = base64_decode($bits); was probably due to my bits not being properly encoded. Correct he was. So, rather than a bug in WordPress, this is a bug in Applescript (what isn’t) and in Ruby’s XMLRPC/client for failing the Principle of Least Surprise (if the spec says the tag is <base64>, the tag should be <base64> not <string>).
To get the <base64> tags in Ruby, you need to encode with XMLRPC::Base64.new(the_file) not simply Base64.encode(the_file)
The brackets problem is particularly icky since it’s a libxml2 bug. Perhaps if we can reliably detect known bad versions we could attempt to work around the behavior. This require a fair bit of testing to make sure it didn’t break other areas.
Interesting that the metaWeblog.newMediaObject item has been filled as a ticket already. Seems like that should have been caught already.
There’s an email list for those interested in XML-RPC/AtomPUB work in WordPress: http://lists.automattic.com/mailman/listinfo/wp-xmlrpc
Hi Garrick. Your post was brought to my attention by Joseph Scott on the WordPress team, who posted about your proposed base64 patch on the WordPress XMLRPC mailing list.
I suspect that the base64 encoding is not happening automatically in your upload, because you are not enclosing the uploaded bits in a tag.
If you upload the bits like this:
<name>bits</name>
<value><base64>[your base64 bits here]</base64></value>
Then I suspect it will work with existing WordPress releases, no patch required.
Daniel
Daniel, thanks for the comment. I’ve done testing multiple ways – and while MarsEdit did successfully upload. Applescript (with and without an explicit tag didn’t, nor did ruby’s XMLRPC/client, without the patch.
I think there must be some bug in the methods you are trying that fail. You could examine the network traffic to see what the XML cargo looks like in each scenario. If you have an AppleScript example, I’d be happy to try running it and examine the traffic to see what is happening.
Daniel
Was going to follow up on this, but Daniel beat me to it 🙂
On Mac I often use HTTPScoop (http://www.tuffcode.com/) to sniff the network traffic to see what’s actually being sent.
Thanks for the XMLRPC::Base64.new(the_file) tip. Was stuck on the exact same problem.