Make WordPress Core

Opened 14 years ago

Last modified 5 years ago

#14493 accepted enhancement

do_enclose() can ping the same URL many times, can't filter URLs to ping

Reported by: mdawaffe's profile mdawaffe Owned by: nacin's profile nacin
Milestone: Priority: normal
Severity: normal Version: 3.0.1
Component: Feeds Keywords: needs-patch
Focuses: Cc:


If the same URL is included in a post several times, do_enclose() can check that URL for inclusion as a possible enclosure several times.

Additionally, there's no way to filter what URLs do_enclose() should ping for possible inclusion as enclosures.

Attached adds an array_unique() call to do_enclose().

Attached adds a do_action_ref_array( 'pre_enclose', array( &$post_links, &$pung ) ) hook to allow filtration of URLs to ping. (Matches the pre_ping hook.)

do_enclose() has several more problems this patch addresses.

  1. Correct non-functional DELETE FROM postmeta query (bad use of wpdb::prepare()).
  2. Use like_escape() in several LIKE queries.
  3. Add an apply_filters( 'enclosure_mime_types', array( 'video', 'audio' ) ) hook.
  4. Currently do_enclose() doesn't allow root URLs as enclosures (e.g., only URLs with a non-trivial path or query. Move that functionality to the new pre_enclose filter.
  5. Efficiency improvements in conditional logic.
  6. Clean up code by reducing control structure nesting depth.

Attachments (1)

14493.diff (6.6 KB) - added by mdawaffe 14 years ago.

Download all attachments as: .zip

Change History (10)

14 years ago

#1 @mdawaffe
14 years ago

Suggested test post content:

#2 @nacin
14 years ago

  • Milestone changed from Awaiting Review to 3.1

#3 @nacin
14 years ago

  • Keywords 3.2-early added
  • Milestone changed from 3.1 to Future Release
  • Type changed from defect (bug) to enhancement

Let's do this early 3.2. Probably too late for 3.1.

#4 @solarissmoke
13 years ago

Was going to open a new ticket but I think it can be addressed here:

do_enclose() does not check that the response to wp_get_http_headers() was good (i.e., HTTP 200) before trying to process it. That means that if you happen to have a link that is either broken or redirected (301), it doesn't realise this and still tries to parse the result, resulting in PHP notices (e.g., missing content-length header).

Two things:

(1) We should at least be checking for a 200 response

(2) Maybe we could be clever and follow 301 redirects. Seeing as there are so many shortlinks floating about everywhere, I think this would greatly increase the number of hits for do_enclose()

#5 @nacin
12 years ago

I just did a lot of similar cleanup in #20417.

#7 @nacin
12 years ago

  • Keywords 3.6-early added; 3.2-early removed
  • Owner set to nacin
  • Status changed from new to accepted

#9 @wonderboymusic
9 years ago

  • Keywords needs-patch added; has-patch 3.6-early removed

Half of this has improved greatly since this ticket was opened

Note: See TracTickets for help on using tickets.