Updated: Comment #20

Problem/Motivation

Following issue #1215730: Terminology update: don't say "Resolution" when we mean "Dimensions", we should change the name of the function file_validate_image_resolution into file_validate_image_dimensions and update documentation accordingly.

Note: the original issue described in this issue is now handled by #2110499: Unify the call and interfaces of image toolkit operations, only the function name change remains.

Remaining tasks

Reroll patch containing only the remaining parts.

User interface changes

Error messages will change.

API changes

Function name change.

Original report

The function file_validate_image_resolution in file file.inc can need some better error handling. Looking at the code (this issue is not created as a result of an actual error that occurred), I found that:

- Errors in image_scale are ignored: image_scale can be very resource intensive (multiple copies (of various sizes) in memory at the same time) and is thus error prone and should be checked, though I have to admit that this normally leads to a WSOD and error handling thus may seem futile :(.
- Errors in image_save are ignored: saving a file and chmod'ing it is error prone and should be checked.
- Error message 'The image is too large; the maximum dimensions are %dimensions pixels.' is misleading and should indicate something like "the image is too large and could not be resized to its maximum dimensions" (see also #1079116: Inaccurate text: Images must be smaller than !max pixels.).

Comments

dddave’s picture

Version: 7.0 » 7.x-dev
Category: bug » feature
Priority: Minor » Normal
fietserwin’s picture

Version: 7.x-dev » 8.x-dev

AFAIC, This issue does not need to be backported, so changed version without adding backport tag

claudiu.cristea’s picture

@fietserwin, can you provide a patch?

fietserwin’s picture

Status: Active » Needs review
StatusFileSize
new9.2 KB

OK, there we go.

Remarks:
- Will need a reroll after #2066219: Decouple image type from image extension gets in.
- Following #1215730: Terminology update: don't say "Resolution" when we mean "Dimensions", I changed the name of the method to file_validate_image_dimensions().
- Improved documentation: a.o. incorrect param type for File, may need a follow up for other occurrences in this file, or we add it to this patch. Type hinting the image factory is to get auto-completion and error-checking by e.g. PhphStorm.

claudiu.cristea’s picture

Status: Needs review » Needs work

@fietserwin, Thank you for the patch. I see the tests passed but I don't see how to manually test this.

  1. +++ b/core/modules/file/file.module
    @@ -419,32 +419,32 @@ function file_validate_is_image(File $file) {
    + * @param Drupal\file\Entity\File $file
    

    You should use the fully-qualified namespace of the class name. This mean also "\" prefix. Use the interface name instead of implementation. In this case it would be \Drupal\file\Entity\FileInterface.

  2. +++ b/core/modules/file/file.module
    @@ -419,32 +419,32 @@ function file_validate_is_image(File $file) {
    +function file_validate_image_dimensions(File $file, $maximum_dimensions = '', $minimum_dimensions = '') {
    

    Also FileInterface should be used for type hinting.

  3. +++ b/core/modules/file/file.module
    @@ -419,32 +419,32 @@ function file_validate_is_image(File $file) {
    +  /** @var $image_factory Drupal\Core\Image\ImageFactory */
    

    Remove this line.

  4. +++ b/core/modules/file/file.module
    @@ -453,12 +453,19 @@ function file_validate_image_resolution(File $file, $maximum_dimensions = 0, $mi
    +              $errors[] = t('The image is too large and saving a resized version failed.');
    

    Are we sure that saving failed because the image is too large? I'm not. What about "Saving the resized version of the image failed."?

  5. +++ b/core/modules/file/file.module
    @@ -453,12 +453,19 @@ function file_validate_image_resolution(File $file, $maximum_dimensions = 0, $mi
    +            $errors[] = t('The image is too large but resizing failed.');
    

    Same here. How do we know the reasons for resizing/scale failure? Wouldn't just be enough: "Failed to resize the image."?

fietserwin’s picture

Status: Needs work » Needs review
StatusFileSize
new3.67 KB
new10.62 KB

#5: Manually testing: hack scale and save to return FALSE and upload a large image?

#5.1, #5.2: Good catch, but the interface is located under \Drupal\file.

Question: should I change all these erroneous type info in other doc comments in this file as well?

#5.3: Is there an accepted way of specifying type information for services we request from Drupal;;service()? As the get method (is by its very nature) untyped, my (PhpStorm) IDE is full of warnings about unknown methods and I don't have auto-completion. This is a recipe for errors that can be easily caught by static type checking that modern IDE's are able to perform.

I think that adding this kind of documentation has added value for all developers that view or work on this code.

This point remains open for discussion/ideas.

#5.4, #5.5: I rephrased too "The image exceeds the maximum allowed dimensions and ...". The trigger for resizing (and saving that resized version) lie in the fact that the dimensions of the uploaded image exceed the maximum allowed dimensions. So, IMO, a plain "resizing failed" is too short. People are uploading not resizing.

Can a native English speaking person have a look at the messages as well?

The patch also contains (and the interdiff also shows) some white space/indentation corrections.

claudiu.cristea’s picture

Status: Needs review » Needs work

#5.1, #5.2: Good catch, but the interface is located under \Drupal\file.

Indeed, sorry! I would not change only if is in the proximity of touched lines (1-2 lines). That's because we want to keep the patch clean and readable.

  1. +++ b/core/modules/file/file.module
    @@ -5,6 +5,7 @@
    +use Drupal\file\FileInterface;
    

    There's no established rule for sorting the "use" statements but as a good practice a saw the next pattern:

    Drupal\Core\A...
    ...
    Drupal\Core\Z...
    Drupal\<a..._module>\A...
    ...
    Drupal\<z..._module>\Z...
    Drupal\Component\A...
    ...
    Drupal\Component\Z...
    Symfony\....
    

    So, wouldn't be nice if we move Drupal\file\FileInterface after File? (btw: What is reporting PhpStorm? Is Drupal\file\Entity\File still used in that file?)

  2. +++ b/core/modules/file/file.module
    @@ -419,49 +420,56 @@ function file_validate_is_image(File $file) {
    +  /** @var $image_factory \Drupal\Core\Image\ImageFactory */
    

    Just using \Drupal::service('image.factory') is OK. We are inside a procedural function and, anyway, we cannot inject that service. You did the right thing, but remove that comment -- there's no standard, no best practice to do that.

  3. +++ b/core/modules/file/file.module
    @@ -419,49 +420,56 @@ function file_validate_is_image(File $file) {
    +  // First check that the file is an image.
    

    I'm not an English native speaker but "Check first..." sounds better to me. But I have no idea what is the correct usage. Really!

Overall, looks good. Thank you!

fietserwin’s picture

StatusFileSize
new10.83 KB

#7.1 I reordered all the use statements. The Drupal\file\Entity\File is still used because many other functions are still type hinting File instead of FileInterface... That will have to wait. I will create a follow-up issue.

#7.2 Changed into a normal comment line. I will create another issue to see what other do or think.

#7.3: Just removed the word first.

fietserwin’s picture

Status: Needs work » Needs review
claudiu.cristea’s picture

Status: Needs review » Reviewed & tested by the community

RTBC. Thank you!

fietserwin’s picture

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs reroll

Patch no longer applies.

fietserwin’s picture

Status: Needs work » Needs review
fietserwin’s picture

Issue tags: -Needs reroll
StatusFileSize
new10.91 KB

Rerolled.

claudiu.cristea’s picture

Status: Needs review » Reviewed & tested by the community
linl’s picture

#14: 1079154-13.patch queued for re-testing.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 1079154-13.patch, failed testing.

claudiu.cristea’s picture

Issue tags: +Needs reroll

Needs reroll

fietserwin’s picture

Issue summary: View changes
Status: Needs work » Closed (duplicate)
Issue tags: -Needs reroll

Will be handled by #2110499: Unify the call and interfaces of image toolkit operations that also touches this code.

fietserwin’s picture

Title: Image uploading and scaling needs better error handling » Change 'resolution''into 'dimensions''
Issue summary: View changes
Status: Closed (duplicate) » Active

Hmmm, this patch also contained some improvements regarding the use of resolution versus dimensions, based on issue #1215730: Terminology update: don't say "Resolution" when we mean "Dimensions". So changing goal of this issue.

Remaining tasks:
- function file_validate_image_resolution
- docs of file_validate_is_image

mondrake’s picture

some improvements regarding the use of resolution versus dimensions

@fietserwin now a patch in #847098: Revise image field min/max settings help text form for clarity addresses this terminology issue - is this duplicated then?

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

smustgrave’s picture

Status: Postponed (maintainer needs more info) » Closed (outdated)

I think this can be closed out. If you see https://www.drupal.org/node/3363700

file_validate_image_resolution was deprecated for 'FileImageDimensions' => ['maxDimensions' => $max_dimensions]

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.