A maximum size can be set in pixels for an image field in every content type, so that the original image can be resized to a maximum size, saving space in case the true original file won't be needed.

In that case, it would be useful to be able to apply an Original image-style so that additional image_effects can be set, such as auto-rotate or even ImageMagick arguments to allow a better optimization of the original file-size, which can reduce file-system usage.

Issue fork drupal-2831529

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:

Comments

juliencarnot created an issue. See original summary.

mondrake’s picture

mondrake’s picture

Title: Instead of just resizing original image, create an original image style to apply image_effects on (optimization, rotation) » Instead of just resizing original image, select an image style to apply on the image being uploaded
Status: Active » Needs review
StatusFileSize
new6.99 KB

Just a proof of concept patch.

The concept is:
a) Add to the image field settings an additional setting to optionally specify an image style to be applied to the image file being uploaded. This image style could have any sort of effects - exif autorotation, metadata stripping, text overlay, etc etc. This could solve at the root #2664632: Bugs with images that include image orientation from image EXIF data: you may want to have an EXIF autorotate effect in the style you select => the uploaded file will be autorotated 'at the origin' so you can avoid having to enter the same effect in all the styles used for image styling in formatters/widgets. Quite powerful as it opens a pandora box of possibilities.
b) Apply the selected image style to the uploaded image before it is saved to final storage. Since the file upload temporarily stores the image file in the temp directory to execute validation against it, and moves it to final storage only after validations passed, I thought to introduce an additional validation function that would try to apply the image style to the temp file and produce a derivative. If that passes, derivative is moved back to the temp filename and finally stored to final destination.

This overlaps to some extent with the 'maximum resolution' settings - these could be replaced with an image style with a 'scale' effect. But this would break BC, so I just thought to run the image style validation before the maximum resolution validation.

Of course this misses tests, upgrade path, configuration dependency, etc etc but just wanted to share to see if it makes sense.

Feedback appreciated :)

EDIT: just a remark - if we take this path, uploaded images will be styled with the effects/settings defined at the moment of the upload: there's no way to recover the original image to apply a different set of effects/settings if the image style is changed afterwards.

Status: Needs review » Needs work

The last submitted patch, 3: 2831529-3.patch, failed testing.

mondrake’s picture

Status: Needs work » Needs review
StatusFileSize
new1.11 KB
new8.11 KB

Just trying to fix failure of existing tests.

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.

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.

it-cru’s picture

StatusFileSize
new7.22 KB

Re-factor #5 patch to work again with current 8.3.x branch.

it-cru’s picture

StatusFileSize
new7.21 KB

Add patch which works with 8.4.x and 8.5.x branches.

Status: Needs review » Needs work

The last submitted patch, 9: 2831529-9.patch, failed testing. View results

it-cru’s picture

My #8 patch works fine for 8.3.x when you use uploading of image field. But when you use something like dropzoneJS this do NOT work.

In our projects I removed the patch again and add an hook_file_validate() with validate code of this patch with a static in code configured 'upload' image style.

/**
 * Implements hook_file_validate().
 */
function custommodule_file_validate(FileInterface $file) {
  $errors = [];

  // Apply 'upload' image style on temporary image files.
  if ($file->isTemporary() && in_array($file->getMimeType(), ['image/gif', 'image/jpeg', 'image/png'])) {
    $image_style_name = 'upload';
    $image_style = ImageStyle::load($image_style_name);
    if ($image_style === NULL) {
      $errors[] = t("The image style %image_style to be applied on the uploaded image does not exist.", ['%image_style' => $image_style_name]);
    }
    else {
      $derived_uri = $file->getFileUri() . '.derived';
      if (!$image_style->createDerivative($file->getFileUri(), $derived_uri)) {
        $errors[] = t('The uploaded image could not be processed with style %image_style. The image file may be invalid.', ['%image_style' => $image_style_name]);
      }
      else {
        if (file_unmanaged_move($derived_uri, $file->getFileUri(), FILE_EXISTS_REPLACE) === FALSE) {
          $errors[] = t('An error occurred while saving the uploaded image file.');
        }
      }
    }
  }

  return $errors;
}

Perhaps a other solution for this have to be found, when better media handling is in core.

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.

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.

kazah’s picture

Hello, @IT-Cru!

How to use your patch only for specific content type?

For example I have two content types review, and page.

I would like to optimize images while uploading files only for review.

How to achieve this?

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.

vasike’s picture

This could achieved with the "proposal" from https://www.drupal.org/project/drupal/issues/3509597

Added as related issue.

tolstoydotcom’s picture

In my current case there are dozens of sites with dozens of in-house contributors who upload very large images. All those very large originals creates storage issues. Contributors are informed that they have to keep local copies of those images, so overwriting them on upload isn't an issue.

The imageapi_optimize module doesn't work on upload, but image_style_on_upload (as its name suggests) does and a basic test indicates that it will work.

That said, IMNSHO it'd be a good idea to generalize things as much as possible. Running some sort of pipeline when an image is uploaded or about to be displayed would be great, especially if it has if/else capability. E.g., if the image is landscape, put a watermark in one corner but if it's portrait put it in the other corner. If it's larger than 1000px, change the hue a bit. Etc. I haven't looked into if ECA has that already.

What would work best is something extensible that could be augmented by ECA or custom code.

meeni_dhobale made their first commit to this issue’s fork.

mayurgajar made their first commit to this issue’s fork.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.