Then you ads additional image extensions they get stripped.
widget hardcodes supported extensions as 'png', 'gif', 'jpg', 'jpeg'

Will it be better to replace hardcoded values with something like this in FileBrowserWidget.php[439]:

from -- $supported_extensions = ['png', 'gif', 'jpg', 'jpeg'
to -- $supported_extensions = \Drupal::service('image.factory')->getSupportedExtensions();

Issue fork entity_browser-3582928

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

vikond created an issue. See original summary.

aayushpathak’s picture

aayushpathak commented

working..

aayushpathak opened merge request !119

aayushpathak’s picture

aayushpathak commented
Status: Active » Needs review

Injected the image factory service so that supported extensions are resolved dynamically from the active image toolkit, rather than being limited to a hardcoded list. This allows any image format supported by the toolkit to be accepted.

benstallings’s picture

benstallings commented
Status: Needs review » Reviewed & tested by the community

Claude Code says:

Assessment — Good change, with minor notes:

1. Correctness: The approach is sound. This mirrors how Drupal core's own ImageWidget handles extensions — delegating to the toolkit rather than maintaining a static list.
2. Service injection: Properly done via the create() method with a new $imageFactory property and docblock. Follows the existing pattern used for $mimeTypeGuesser.
3. Potential concern: ImageFactory::getSupportedExtensions() was added in Drupal 10.3. The module's .info.yml requires ^10.2 || ^11. If you want to support 10.2, this would need a version check or the minimum core version should be bumped. If 10.2 support has effectively been dropped, this is fine as-is.
4. Commit message style: Minor — the commit message has no space after Issue (Issue#3582928 vs Issue #3582928), inconsistent with the project's convention.
5. No test coverage for this change, but it's a straightforward service swap and would be hard to unit test without a toolkit mock.

Overall, this is a clean, well-scoped fix. The main decision point is whether the Drupal 10.2 compatibility matters.

benstallings’s picture

benstallings commented
Version: 8.x-2.15 » 8.x-2.x-dev

note that the failing tests are not related to this branch; those tests all fail on the release branch.