Copy core 11.1.x ExtensionMimeTypeGuesser to s3fs

Created on 10 June 2025, about 2 months ago

Problem/Motivation

From ✨ Add support for Druapl 10.5/11.1 Active , core has refactored the extension mime type guesser.

We should copy the code into the module and run our own independent copy to avoid API breaks.

We can discuss converting to align to Core new layout in the 2.x branch.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

πŸ“Œ Task
Status

Active

Version

3.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States cmlara

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @cmlara
  • πŸ‡ΊπŸ‡ΈUnited States cmlara
  • Pipeline finished with Success
    about 2 months ago
    Total: 667s
    #519361
  • πŸ‡¨πŸ‡¦Canada b_sharpe

    Everything looks fine, confirmed I don't get the circular referencing as well. Small comment about calling out the change between core and override.

  • πŸ‡ΊπŸ‡ΈUnited States cmlara

    Added notes to the file comment referring to core and this issue.

    As a deeper summary:

    The history on s3fs having initialized its own copy of the MimeTypeExtensionGuesser can be traced back to #3259065: Circular reference detected for service "s3fsfileservice" with mime_type guesser β†’ . We were avoiding a circular reference after having added s3fsfileservice which decorates the core file_system service.

    Some (many?) MimeType guessers make use of the FileSystemInterface::basename() method. In the past this has been via a global container call \Drupal::service('file_system') in-line, however as part of proper service injection these calls are slowly being removed.

    The s3fsfileservice is somewhat unique with the fact it needs to know the mime type of a file as part of the Move/Copy operations to correctly set the headers from the S3 Bucket.

    FileSystemInterface::basename() is unfortunately just in a poor location for this scenario.

    To solve this our copy will use the native basename() function. FileSystem::basename() appears functionally identical to the PHP basename(). It would make no sense for a streamWrapper to be implemented in a manner where basename() does not follow the native format as such streamWrappers would be incompatible with normal PHP scripts. The entire purpose of streamWrappers is to provide program agnostic storage.

    Ideally as a followup we would encourage core to deprecate/remove FileSystemInterface::basename() to allow us to return to operating with the Core instance of mime type guessing services.

  • πŸ‡ΊπŸ‡ΈUnited States cmlara

    Digging a bit more into the core side history of this, there there is/was apparently a locales issues.

    https://bugs.php.net/bug.php?id=37738

    It does appear this issue is no longer present in modern PHP versions, although it does exist for the entire PHP7 line.
    https://3v4l.org/XcflK.

    Perhaps we will want to copy the

    FileSystem::basename()

    as PHP7.1 is listed for S3FS supported environments.

  • πŸ‡ΊπŸ‡ΈUnited States cmlara
  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024