[wp-trac] [WordPress Trac] #19629: return option for media_sideload_image

[WordPress Trac]

#19629: return option for media_sideload_image
-------------------------+------------------
 Reporter:  slbmeh       |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  3.5
Component:  Media        |     Version:  3.3
 Severity:  minor        |  Resolution:
 Keywords:  has-patch    |
-------------------------+------------------

Comment (by nacin):

 Some explanation of the existing stack:
  * wp_handle_upload() is the underlying function that handles an upload of
 any file in WordPress, writing it to disk, etc.
  * wp_handle_sideload() is the equivalent underlying function.
  * media_handle_upload() takes $_POST/$_FILES and passes it to
 wp_upload_image().
  * media_handle_sideload() is the equivalent function, taking a $_FILES
 array and passing it to wp_sideload_image().

 Then, there is media_sideload_image(), which is more or less a glorified
 wrapper for media_handle_sideload():
  * It accepts a URL, which then goes to download_url(), builds a $_FILES-
 like array of local files, then passes it along.
  * Only works on images.
  * Returns an <img> tag.

 Now, media_handle_upload()'s first argument is $file_id, which is the key
 to the corresponding file in $_FILES. But media_handle_sideload() takes
 the full array. This is because it isn't actually using $_FILES, instead
 just taking an argument that looks like it.

 Since media_handle_sideload() takes an array currently, we can actually
 get away with allowing a URL to be passed instead. The benefits here are
 many fold:
  * We don't need to introduce a new function, which would cause imbalance
 to the current stack.
  * media_handle_sideload() ends up taking a saner argument of a URL to
 sideload.
  * The existing function already works on any kind of file, not just
 images.
  * The existing function already returns an ID.

 We're not prevented, of course, from adding new highest-level functions
 like wp_upload_media() (or wp_upload_file()) and wp_sideload_media() in
 the future.

 Doing this will probably mean a deprecation of media_sideload_image() in
 favor of media_handle_sideload(). Its single usage in Press This could
 become a call to media_handle_sideload() followed by a call to
 wp_get_attachment_url(), as it does now.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/19629#comment:13>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software