[wp-xmlrpc] Re: wp-xmlrpc Digest, Vol 21, Issue 6

[Joseph Scott]

I'm not sure this reply ever made it out to the list, so I'm resending  
it.

---------------------------------------------------------------------------------------------



Limited quotes to just portions that I'm updating status on

On Feb 17, 2009, at 5:24 AM, Tim Armes wrote:

>> That leaves us with edit URI using /post/491 though.
>
>> 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.
>
> Great.  I think.  I hope that we're both talking about the same thing
> - the XML returned by the Create Attachement function.


The patch on that ticket went into -trunk so it will part of 2.8 and
it's also in the 2.7 branch, so if we have 2.7.2 release it will be
part of that.


>>> 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?
>
> If you use Lightroom then you can use my new client:
>
> http://www.timothyarmes.com/lr2blog.php
>
> Configure Wordpress over Atom, stick something like "Tim's problem"
> into the description field for the photo upload, and then view the
> description in the uploaded photo in the media library.  It'll be
> "Tim&apos;s problem".


The problem here isn't that they aren't being decoded, it's that
WordPress is storing the encoded version (&apos; instead of ') in the
database.  This is a core WP problem, we'll probably have to take a
long hard look at re-arranging the default filter system to stop this
from happening.



>>> 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.
>
> That one's easy.  The put_attachment function doesn't extract the
> summary.  Not that I can update the title and descritiption.


When it's assembling the data for WP to update the database it's using
the content field value (which will always be empty since there's a
src attribute) instead of the summary field value.  I've added a patch
to ticket 9148 that fixes this.



> Finally, I've discovered a more serious problem.  It's not possible to
> PUT an updated image file.  Wordpress returns 200 to say that it's all
> worked, but in reality it hasn't.  I tracked it down to this code in
> the put_file function:
>
> 		$location = get_post_meta($entry['ID'], '_wp_attached_file', true);
> 		$filetype = wp_check_filetype($location);
>
> 		if(!isset($location) || 'attachment' != $entry['post_type'] ||
> empty($filetype['ext']))
> 			$this->internal_error(__('Error ocurred while accessing post
> metadata for file location.'));
>
> 		$fp = fopen("php://input", "rb");
> 		$localfp = fopen($location, "w+");
> log_app("tim", $location);
> 		while(!feof($fp)) {
> 			fwrite($localfp,fread($fp, 4096));
> 		}
> 		fclose($fp);
> 		fclose($localfp);
>
> When I PUT to ..../attachement/file/ID the code tries to locate the
> physical file and overwrite it.  The problem is that $location
> actually gets the path relative to the uploads folder, so it contains
> something like 2009/02/myfile.jpg
>
> This is then opened by fopen directly, but it needs prepending with
> the upload folder's path  (you can still see my debug line)

I've fixed this so that the full path is used and confirmed that the
file does then get properly overwritten (is that a word?).

http://core.trac.wordpress.org/ticket/9233

I'll ask about getting these updated in -trunk and the 2.7 branch as
well.

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