[wp-trac] [WordPress Trac] #19865: do_enclose() throws WP_DEBUG notices when $headers has no content_type

[WordPress Trac]

#19865: do_enclose() throws WP_DEBUG notices when $headers has no content_type
------------------------------+------------------------------------
 Reporter:  jeremyclarke      |      Owner:  jeremyclarke
     Type:  defect (bug)      |     Status:  new
 Priority:  normal            |  Milestone:  Awaiting Review
Component:  Warnings/Notices  |    Version:  3.3.1
 Severity:  normal            |   Keywords:  has-patch dev-feedback
------------------------------+------------------------------------
 This only happens in the background so you'll have to enable debug.log
 (WP_DEBUG_LOG) as well as WP_DEBUG to see the output, but
 {{{do_enclose()}}} chokes on the results of {{{wp_get_http_headers(
 $url)}}} because it assumes there will be a 'content-length' in the
 results.

   [20-Jan-2012 18:56:10] PHP Notice:  Undefined index:  content-length in
 /path-to-site/wp-svn/wp-includes/functions.php on line 524

 I noticed it when saving a post that had a lot of links in it. Not all of
 them caused the error, but enough that it flooded debug.log. I suspect the
 effect is harmless because they weren't video or audio links. This just
 got overlooked 'cause it's so deep in the background.

 Th lack of checking with isset() also applies to 'content-type' so the
 patch addresses that as well. I'm pretty sure this will safely fix the
 problem because the foreach section only does anything if 'content-type'
 is 'audio' or 'video' and all the urls that were bugged for me were pages.

 I tested this by inserting an mp3 URL and it was added as an 'enclosure'
 meta with the length and type.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/19865>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software