[wp-trac] [WordPress Trac] #16330: media_sideload_image() broken with URLs containing spaces

WordPress Trac wp-trac at lists.automattic.com
Mon Feb 28 14:11:45 UTC 2011

#16330: media_sideload_image() broken with URLs containing spaces
 Reporter:  Coolkevman    |       Owner:
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:
Component:  HTTP          |     Version:  3.1
 Severity:  normal        |  Resolution:
 Keywords:                |
Changes (by Coolkevman):

 * keywords:  reporter-feedback =>
 * status:  closed => reopened
 * resolution:  invalid =>


 Replying to [comment:5 hakre]:
 > As sivel wrote, URLs containing spaces are considered invalid. That's by
 the standards, so not a wordpress issue.

 Thanks for this clarification. From now on I'll assume URLs with spaces
 are invalid and should be expressed with percent encoding.

 > However as you wrote you might still have a related problem.
 > To further test, please replace the spaces inside the URL with %20
 (that's the proper way how to write a space inside a URL) and try to fetch
 that file.

 Yes, that's exactly what I've done as a second test in my original bug
 report. That's the part when I use these PHP statements:
   $img_url = str_replace(' ', '%20', html_entity_decode($img_url));
   $new_tag = media_sideload_image($img_url, $post_id);

 I just retried this test with the latest WordPress 3.1 (the final release,
 not the RCs) and it still have the same behaviour (look at my screenshots:
 http://twitpic.com/3s0ets and http://twitpic.com/3s0hup ).

 > If this does not work, you need to find out which error it is returning
 and you need to find out which transport you're using. To reduce noise,
 you can install a plugin like
 11499-curlforce.php] that will enforce the use of curl for debugging
 purposes, so the curl based transport will be always used.

 I just tried to use this plugin. It complained of missing Curl. So I just
 installed the {{{curl}}} and {{{php5-curl}}} package (I'm using kubuntu
 10.10) and restarted my Apache to have it work.

 Then I've redone my tests (the one replacing spaces by {{{%20}}}) and I
 still have the exact same error.

 Now I think the problem lies somewhere in remote downloading code of
 WordPress, when it first download the remote file to a temporary location
 before moving it to the {{{uploads}}} folder. That's just a guess, I still
 have to find hard evidences in the code...

Ticket URL: <http://core.trac.wordpress.org/ticket/16330#comment:7>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software

More information about the wp-trac mailing list