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.

#17 sounds like a great idea. Created 📌 Generate file extension mime type map with fileeye/mimemap update utility Active

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

False positive

So since we don't have test coverage already and seems #18 mentions adding a way to auto do this I'm assuming coverage will be added there.

That case I believe this change is fine, will go out on a limb and RTBC it.