atom_enclosure doesn't always get MIME type - inconsistency with rss_enclosure

[edent]

The function atom_enclosure() does not always select MIME types correctly. This bug is not present in rss_enclosure()

rss_enclosure gets the MIME type like this:

// Only get the first element, e.g. 'audio/mpeg' from 'audio/mpeg mpga mp2 mp3'.
$t    = preg_split( '/[ \t]/', trim( $enclosure[2] ) );
$type = $t[0];

The equivalent atom_enclosure is more complex, brittle, and subtly different:

for ( $i = 1; $i <= 2; $i++ ) {
  if ( isset( $enclosure[ $i ] ) ) {
    if ( is_numeric( $enclosure[ $i ] ) ) {
      $length = trim( $enclosure[ $i ] );
    } elseif ( in_array( $enclosure[ $i ], $mimes, true ) ) {
      $type = trim( $enclosure[ $i ] );
    }
  }
}

If I var_export the $enclosure variable in the atom_enclosure() function, this is what I see:

array (
  0 => 'https://video.twimg.com/ext_tw_video/1432767873504718850/pu/vid/720x960/sS9cLdGn93eUmvKC.mp4?tag=12',
  1 => '1546364',
  2 => 'video/mp4',
  3 => '',
)array (
  0 => 'https://shkspr.mobi/blog/wp-content/uploads/2025/03/Move-roomba-to-a-new-location.mp3^M',
  1 => '46188^M',
  2 => 'audio/mpeg^M',
  3 => '',
)

I do not know *why* some of my media has the DOS carriage return at the end!

This can be fixed by trimming the string before checking whether it is in the MIME type array:

…
    } elseif ( in_array( trim( $enclosure[ $i ] ), $mimes, true ) ) {
      $type = trim( $enclosure[ $i ] );
    }
…

Given that the type is trimmed anyway, this seems like a sensible precaution.

A longer-term solution might be to ensure that both rss_enclosure and atom_enclosure functions behave in the same way.

For more details, see ​https://wordpress.org/support/topic/missing-mime-type-using-atom_enclosure/

The atom_enclosure doesn't always pick up MIME types correctly. This PR ensures consistency with rss_enclosure.

Trac ticket: https://core.trac.wordpress.org/ticket/63292

[oglekler]

Hi @edent I cannot see this issue now in your atom feed. How can we reproduce it?

I assume we can use audio that is mentioned in the support ticket if this issue was with this audio.
But it is also possible that the audio file has some issue with the MIME type in the first place that it should not have.

Is it particular software from which these files are coming from?

[edent]

@oglekler I had manually patched feed.php to fix it. I have undone my fix so you can now see the issue in the atom feed.

Feel free to use the audio - I do not know if that is the cause of it.

Nevertheless, at the moment the in_array comparison is different to the value which is assigned to $type and I think that needs to be fixed.

[oglekler]

I still didn't see the issue, but I will check the atom feed elsewhere with audio files in it. Thank you for the quick reply.

[jorbin]

@edent Is this something that you saw for the first time on 6.8? Based on the timing of your report in the forums, I don't think so but wanted to check before I remove the version.

[edent]

@jorbin I only noticed it yesterday. I'm not sure when my blog updated to 6.8. Judging by the age of the feed.php file, it probably pre-dates it.

[edent]

Do let me know if this patch requires further work.