Support from Acquia helps fund testing for Drupal Acquia logo

Comments

stoickthevast’s picture

Issue summary: View changes
mgifford’s picture

I just noticed that too. It's both redundant & confusing. How can you get both a success message that an image was resized and a failure message that an image size was too large?

This was in 8.0.x as well.

dpi’s picture

Title: Uploading user picture or image: Display the correct validation message » Do not attempt to resize image if uploaded file exceeds maximum upload size
Version: 8.0.0-beta1 » 8.3.x-dev
Component: user.module » file.module

I can confirm this is still an issue. Rewording issue title.

File size for image fields is handled by file_validate_size. File rescale is handled by file_validate_image_resolution. Moving to file module.

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

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now 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.

scott_euser’s picture

I couldn't see a great way to approach this as the `file_validate_image_resolution` function is effectively trying to do two things on it's own:

  1. validate and potentially throw an error
  2. inform the user of successful resize(s)

In the attached patch I modify the `file_validate` function to be able to handle either the default return values (ie, just an array of errors) or mixed return values of both messages and errors. It feels a bit dirty, perhaps someone else has a better suggestion.

Essentially the issue is `file_validate_image_resolution` is unaware of the results of other validations, yet we want the messages to only be shown if the other validations pass which is why I am passing the messages back to postpone sending of them until all validations are called.

Status: Needs review » Needs work
scott_euser’s picture

Updated test for `file_validate_image_resolution` to match new return format.

D-XPERT’s picture

Assigned: Unassigned » D-XPERT
scott_euser’s picture

D-XPERT’s picture

Status: Needs review » Reviewed & tested by the community

I have tested the patch in #7 with 8.4.x-dev, php 5.5 and mysql 5.5. The patch worked fine as per the proposed solution.
i.e. "Do not display the The image was resized to fit within the maximum allowed dimensions of 85x85 pixels. if the validation fails."
I also tried by uploading the image file of size less than 30KB with the success message of resized.

Note - This is the first time I reviewed a patch. Any feedback from community members are most welcome.

D-XPERT’s picture

Assigned: D-XPERT » Unassigned
Issue tags: +GlobalSprint_Tricity_Drupalist
scott_euser’s picture

Thanks for the review!

tstoeckler’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/core/modules/file/file.module
@@ -286,15 +286,41 @@ function file_move(FileInterface $source, $destination = NULL, $replace = FILE_E
-      $errors = array_merge($errors, call_user_func_array($function, $args));
+      $result = call_user_func_array($function, $args);

@@ -468,7 +494,13 @@ function file_validate_image_resolution(FileInterface $file, $maximum_dimensions
-  return $errors;
+  // Return both errors and messages. We only want to have these messages
+  // sent if none of the validators return errors (their may be other
+  // validators attached to this element).
+  return [
+    'errors' => $errors,
+    'messages' => $messages,
+  ];

I think this could be considered an API change, so I think we should introduce a BC-layer that checks if the return value of the validator contains a 'errors' key and if not adjusts the format accordingly.

scott_euser’s picture

Is this bit not what you mean?

--- a/core/modules/file/file.module
+++ b/core/modules/file/file.module
@@ -286,15 +286,41 @@ function file_move(FileInterface $source, $destination = NULL, $replace = FILE_E
 function file_validate(FileInterface $file, $validators = array()) {
   // Call the validation functions specified by this function's caller.
   $errors = array();
+  $messages = array();
   foreach ($validators as $function => $args) {
     if (function_exists($function)) {
       array_unshift($args, $file);
-      $errors = array_merge($errors, call_user_func_array($function, $args));
+      $result = call_user_func_array($function, $args);
+
+      // Allow a mixed result of messages and errors so validators can
+      // provide messages to be shown only if there are no errors.
+      if (array_intersect(['errors', 'messages'], array_keys($result))) {
+        if (array_key_exists('errors', $result)) {
+          $errors = array_merge($errors, $result['errors']);
+        }
+        if (array_key_exists('messages', $result)) {
+          $messages = array_merge($messages, $result['messages']);
+        }
+      }
+      else {
+
+        // Fallback to the standard file validation return value.
+        $errors = array_merge($errors, $result);
+      }
     }
   }

It accepts both results (flat array or multi-dimensional array) so anyone adding a validator (including other image / file validators in core) continue to work fine without change.

scott_euser’s picture

Status: Needs work » Needs review
dpi’s picture

The format of the return value is different, therefore it is an API change and not permitted.

scott_euser’s picture

Status: Needs review » Needs work

Fair enough, I will try to rethink it. To me, the heart of the issue is that that validation function is trying to do two things at once.

scott_euser’s picture

Simply removing the resize save on validation (but still testing that it is re-sizeable) solves the issue.

Validation: Attempt to resize image but don't save.
Submit: Resize image and save.
Consequence of this change: Resize attempt happens twice, once in validation, once after submit.

The file_validate_image_resolution() describes it's own goal as "Verifies that image dimensions are within the specified maximum and minimum" and as it is a validator function, it should only do just that: validate. This removes the side effect.

scott_euser’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work
scott_euser’s picture

Will wait for comments on the above before updating the tests to match the change.

scott_euser’s picture

As the validation seems to need to actually generate the image (ie, do more than just validate), here is a different approach to ensure it validates only when there are no errors so no image generation occurs if there are any errors.

scott_euser’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 22: do_not_attempt_to-2353933-22.patch, failed testing.

scott_euser’s picture

Status: Needs work » Needs review
FileSize
1.73 KB
1.23 KB

Status: Needs review » Needs work

The last submitted patch, 25: do_not_attempt_to-2353933-25.patch, failed testing.

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

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now 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.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now 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.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now 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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). 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.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

AswathyAjish’s picture

I am also facing the same issue.

My drupal version is 8.9.16.

artemboiko’s picture

The same on 9.2.7

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

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.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.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now 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.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now 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: 10.1.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, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.