Opened 20 months ago
Last modified 9 months ago
#18730 new defect (bug)
media_sideload_image() doesn't handle dynamic image url's well
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Awaiting Review |
| Component: | Warnings/Notices | Version: | 2.9 |
| Severity: | normal | Keywords: | has-patch |
| Cc: | JustinSainton, kpayne@…, chris@… |
Description
Example URL: http://www.tumblr.com/photo/1280/10464566223/1/tumblr_lrum2xzkpC1r3z8e3
As a result, the preg_match() for the file extension fails and issues a notice (no file extension in that url, although the redirection location does have).
The handling of a download failure also seems hairy, upon failure, it still attempts further importing before loading - I haven't looked into that too far.
Attachments (1)
Change History (4)
comment:1
JustinSainton — 20 months ago
- Cc JustinSainton added
comment:3
c3mdigital — 9 months ago
- Cc chris@… added
I'm having this issue with some of my users in my media-tools plugin which imports and attaches external images. I'm going to work on refreshing the patch for 3.5.
Note: See
TracTickets for help on using
tickets.

Probably not relevant for your use case, and I'm sure you're very well aware of the filter, but I was able to get around a similar bug by modifying the wp_check_filetype_and_ext filter as such -
add_filter( 'wp_check_filetype_and_ext', 'gd_pdf_bypass' ); function gd_pdf_bypass( $filearray ) { $filearray['type'] = 'image/jpeg'; $filearray['ext'] = 1; return $filearray; }Granted, still doesn't attach properly (not necessary in my use case), but I'm able to get it to return the proper <img> tag and upload to the server with the override.