[wp-xmlrpc] Uploading images - XML-RPC limitations and AtomPub bugs

[Joseph Scott]

On Feb 15, 2009, at 7:09 AM, Timothy Armes wrote:

> Hi,
>
> I'm writing a Wordpress client that uploads images to a Wordpress blog
> using XML-RPC and/or AtomPub.  I'm having lots of problems relating to
> the transfer of metadata (Title, caption & description) and I'm hoping
> that someone can help me.
>
> First of all, it seems that it's impossible for me to upload this
> information using XML-RPC - can you confirm that this is the case or
> am I just being totally blind?


I presume you used the the metaWeblog.newMediaObject method or the  
wp.uploadFile (which really just a wrapper around  
metaWeblog.newMediaObject) method.  With those you really only get to  
provide a the title ("name") of the file being uploaded.  Extending  
those methods to support the caption and description fields would be a  
good thing.



> Since I came to a dead with that I've started to implement the AtomPub
> protocol.  There are a number of issues that I've come across:
>
> The 'edit' URL returned by Wordpress is incorrect.  POSTing the image
> will return something like this:
>
> <link rel="edit-media"
> href="http://www.myblog.com/blog/wp-app.php/attachment/file/491" />
> <link rel="edit" href="http://www. myblog.com/blog/wp-app.php/post/ 
> 491" />
>
> The edit media URL is correct, however if I do a GET of the edit URL,
> to retrieve the metadata, the result is empty.   After looking at the
> source I realised that it should have been returning this:
>
> <link rel="edit" href="http://www.
> myblog.com/blog/wp-app.php/attachment/491" />


Initially my thought was that you were exactly right on the edit URL,  
but after looking at the code, I'm not 100% sure.  In wp-app.php it  
routes requests with:

             '@/attachments/?(\d+)?$@' =>
                 array('GET' => 'get_attachment',
                         'POST' => 'create_attachment'),
             '@/attachment/file/(\d+)$@' =>
                 array('GET' => 'get_file',
                         'PUT' => 'put_file',
                         'DELETE' => 'delete_file'),
             '@/attachment/(\d+)$@' =>
                 array('GET' => 'get_attachment',
                         'PUT' => 'put_attachment',
                         'DELETE' => 'delete_attachment'),

I've haven't looked through the rest, but I believe the that / 
attachment/491 is the data about the file (title, caption,  
description) and that /attachment/file/491 is the actual file itself.   
That leaves us with edit URI using /post/491 though.  From what I've  
looked at so far using /post/491 appears to be a bug, and needs to be / 
attachment/491

.... sometime later ....

I've got a patch to fix it this so that both /wp-app.php/attachments  
and /wp-app.php/attachment/491 requests use /attachment/491 instead  
of /post/491.

https://core.trac.wordpress.org/ticket/9147

Did you write that ticket?


> With this URL the GET works, with the exception that the description
> isn't returned in the <content> node.

Since the <content> element is being used to provide details about the  
uploaded file (type="image/jpeg" in my tests) and providing a src  
attribute, which according to the Atom spec means that <content> must  
be empty:

"atom:content MAY have a "src" attribute, whose value MUST be an IRI  
reference [RFC3987]. If the "src" attribute is present, atom:content  
MUST be empty."

http://www.atompub.org/rfc4287.html#element.content

If I've read that wrong then let me know.  Is there another "standard"  
element that we could use to put the description in?  If not then I  
think this ends up in the area of a WordPress specific namespace'd  
element.


> Now, if I PUT the returned XML with a new <title> and description
> (<content>) it works quites well except for the fact that the HTML
> entities aren't decoded.  Is there a workaround for this?

Can you give a specific example that we can use to reproduce this?


> Finally I note that the GET correctly returns the image caption in the
> <summary> tag, however the PUT ignores it, so I can't update the
> summary.


Dealing with file management in WP is still pretty rough, so I'm going  
to have to look at this in more detail to see what's happening.  I've  
made a note of ticket http://core.trac.wordpress.org/ticket/9148 on  
this issue.

--
Joseph Scott
joseph at josephscott.org
http://josephscott.org/