Contrib.social

Allow image fields to use any extensions the current image toolkit supports (instead of hard-coding jpg, png and gif only)

Open on Drupal.org →
Created on 4 January 2011, over 13 years ago
Updated 28 March 2024, 2 months ago

Updated after #86.

Problem/Motivation

Changing the allowed file extensions on an image field doesn't update in the edit form. Other changes to the field are reflected though.

Steps to reproduce -
1. Create an Image Field
2. Set the allowed file extensions to also include svg, etc.
3. Or modify the allowed file extensions after creating the field to include svg, etc.

The current patch tries to solve the fact that the list as defined by a site builder is reduced based on a hard-coded list instead of the list of extensions supported by the actual toolkit.

Proposed resolution

It should also check when defining an image field, not only when showing an image widget (and allow site builders to shoot themselves in the foot).

  • When defining a new image field, the default value for 'Allowed file extensions' should be the list of supported extensions.
  • When saving field settings, the entered list should be validated against the list of supported extensions.
  • If there are no unsupported extensions: save as is
  • If there are unsupported extensions, we have the following options (TBD):
    • Warn but accept the reduced set.
    • Fail with a form validation error.
  • If an existing image field is edited: no changes, ie take the currently saved list as value.
  • If an existing image field is saved: same validation as above.
  • If an image widget is displayed we have 2 options that should align with the options above:
    1. Take the list as is. Do not make any changes to the list at this point.
    2. Take the list and intersect with the actual list of supported extensions.

  • If an image with an unsupported but allowed extension is uploaded:
    • Fail (aligns with the fail option above).
    • Fail if dimensions are specified (never logical).
    • Fail if dimensions are specified and getimagesize() (does not require a toolkit) indicates that the dimensions fall outside the allowed dimensions. If getimagesize() fails to produce dimensions: TBD.

I am in favor of the warning option, not the hard fail as most error handling on the image widget side will still be necessary for when toolkit configuration has changed (more specifically the list of supported extensions).

If we go for the warning, the warning should indicate which extensions are unsupported and what the consequences are:

  • Image styles will not be applied to unsupported extensions.
  • Resizing due to min/max resolution will not be possible and thus image uploads might fail.
  • [future request] Auto rotating on upload will not be possible, so an upload might fail. To determine if we actually need to rotate, we would not necessarily need an image toolkit, just the EXIF PHP extension.

Remaining tasks

Decide on a path forward, quickly. So we can get rolling on a direction again. This issue has stalled out at comment #86, which bodes poorly for adopting any solution.

User interface changes

API changes

Data model changes

Original Summary

Changing the allowed file extensions on an image field doesn't update in the edit form. Other changes to the field are reflected though.

Steps to reproduce -
1. Create an Image Field
2. Set the allowed file extensions
3. Modify the allowed file extensions after creating the field.

🐛 Bug report
Status

Fixed

Version

8.7 ⚰️

Component
Image module  →

Last updated 5 days ago

Created by

🇿🇦South Africa guybedford

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

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024