Opened 13 years ago
Closed 13 years ago
#19865 closed defect (bug) (fixed)
do_enclose() throws WP_DEBUG notices when $headers has no content_type
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.4 | Priority: | normal |
Severity: | normal | Version: | 3.3.1 |
Component: | Warnings/Notices | Keywords: | has-patch dev-feedback |
Focuses: | Cc: |
Description
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.
fix do_enclose throwing errors while checking for media to enclose