File extensions "numbers" and "pages" in field.field.media.document.field_media_document.yml are missing from ExtensionMimeTypeGuesser

@annmarysruthy the array of file extensions should be in order by the numeric value.

We're going to need to add the other extensions too, but idk what they are supposed to be - maybe same as their od* equivalent, but add a "+xml" on the end because it's XML? Just a wild guess. If we can't find the mapping specified/documented somewhere, we could copy from some other package that maintains a mapping.

Looks like various packages have the suffix as "-flat-xml" rather than "+xml", so I'd go with that as my best guess

Thanks for reporting.

Noticed that the issue summary appears incomplete so tagged for that.

Also will need some kind of test case added to show the issue.

@smustgrave There is already test coverage of the extension to MIME type mapping, so I don't think additional test coverage is needed here.

If it already had tests though then why is the change needed? Shouldn't the tests of caught the bug?

@smustgrave What did you have in mind? You wouldn't want to add a test for each of the ~369 mappings. It's just a couple big flat arrays.

What did you have in mind? You wouldn't want to add a test for each of the ~369 mappings.

I agree that this doesn't seem like a typical thing that Drupal core would add test coverage for, namely, a test that verifies that all of the extensions defined in the standard installation profile's media types are present in the MimeTypeGuesser array. I think automated test coverage *would* be more appropriate for 🐛 Deprecated function: explode(): Passing null to parameter #2 ($string) of type string is deprecated in Drupal\file\Plugin\Field\FieldFormatter\FileMediaFormatterBase::mimeTypeApplies() (line 171 of Plugin/Field/FieldFormatter/FileMediaFormatterBase.php) Needs work , to demonstrate that when unknown file types are declared, they do not trigger a PHP warning, and/or are handled through appropriate form validation.

So, for this issue, I think it might be most appropriate to start by adding steps to reproduce, to show what "problem" there is when the MimeTypeGuesser does not include some of the file extensions defined in the standard installation profile's document media type configuration. Something like:

1. Install the "standard" installation profile
2. Enable the media_library module
3. Go to Structure > Media Types > Document > Edit > Manage display
4. [Describe resulting problem]

Added steps to reproduce to the issue summary.

I was thinking of this from the perspective of just missing data, like if a language was missing from the array of languages in LanguageManager.php, as Drupal maintains a mapping of known file extensions and MIME types, and file extensions can be configured manually. (Of course neither languages nor file extensions/MIME types are an exhaustive list, as they are only added when someone notices them missing..)

If we are re-mapping here are there others to be checked?

We could create a followup issue to do something like.. create a script to audit/compare drupal's mapping vs. the MIME type databases typically found in operating system distributions? There are actually at least two such databases: The /etc/mime.types file and the /usr/share/mime directory.

...and it looks like there is already a third-party tool pretty similar to what I mentioned - the fileeye-mimemap update utility retrieves MIME types from both Apache and freedesktop.org, merges them, and generates a map. This library could be incorporated as a runtime third-party dependency, or at least be leveraged to help maintain the existing mapping.