Attempt to detect the correct post enclosure mime type

[josephscott]

When looking for audio/video enclosures to add to new posts WP relies on the hosting server (for the media file) to provide a useful/correct mime type. Some servers will provide generic types (like binary/octet-stream) instead of a more specific type. A common case is Amazon S3, which defaults to binary/octet-stream. Not having a specific mime type (like audio/mpeg instead of binary/octet-stream) will cause WP to miss what would other wise be a valid feed enclosure item.

WP already has a list of common file extensions and their associated mime type in the get_allowed_mime_types() function. We can compensate some what for these non-specific mime types by comparing the file extension with the list from get_allowed_mime_types().

I've put together a simple patch that adds a look up loop to do_enclose(), if we find a mime type match based on the file extension it uses that instead of the type provided by the hosting server.

[azaozz]

Nice idea, get_allowed_mime_types() returns an array that is prepared for use in a (case-insensitive) regex but in the patch it's used in a nested loop instead. With such short strings I don't think there will be any performance differences but may be good to keep the case-insensitive functionality.

[josephscott]

That works for me. I tested the 11668.patch with my test case from Amazon S3 and the enclosure showed up correctly in the RSS feed.

[azaozz]

(In [12580]) Attempt to detect the correct post enclosure mime type, props josephscott, fixes #11668