Decorate ImageWidget to fix the core bug

vaplas created an issue. See original summary.

In fact, the decorator prevents the '#default_value' of image field in multiple upload case. But this keeps the width / height of each of the images (yes, with multiple upload all very tricky). This can be verified if you put a breakpoint in ImageItem::preSave(). So there will be no extra costs for getting sizes. Woot!

Added two tests, for checking via BTB/JTB. But surely enough one, at your choice :) (if you like this idea, of course).

Deeper digging...

It turns out the image field widget is being processed twice:

1. First, for an empty image field (which is present for adding new files).
2. Second, for uploaded images.

When only one image is uploaded, it is not noticeable. But if we upload multiple images, then initially the empty field will take the data from the first image. And then will use them for all the other images by default.

For example, if we comment next line:

- $form = $this->rebuildForm($form_id, $form_state, $form);
+ //$form = $this->rebuildForm($form_id, $form_state, $form);

And than upload multiple images, we get next result:

All images were not proccesed, but the widget grabbed the first image instead of empty field widget.

Therefore, there is another suggestion, just ignore the standard image processing while uploading multiple images.

Thank you @fietserwin for good points!

It seems to me that #3 works more correctly, and I will push this variant to the core tracker until I am convinced.

However, after a series of the critical security fixes for core, #2 variant looks better for the contrib module. Because this variant completely preserves the behavior of the core.

You can ping me on this issue at any time. We can also provide the ability to disable this fix via settings.php + clear cache:
$settings['image_field_repair_disable_fix_2644468'] = TRUE;

I deleted the BTB test, because the JTB works better as a black-box test.

Furthermore, I think that adding the repair part to core will undoubtedly add another "year" before it gets committed, so I think we should strive for the core fix to get committed as is, thus without update hook and refer people to this module for repair, hopefully with an admin message presented by an update hook.

Nice idea! I will propose this to the core issue in the next few days.

About update project page, I suggest moving to the top of the "Usage" section (to users could immediately understand what to do):

Usage

After installing and enabling the module, it will fix the problem for next uploads of images.

To repair already damaged images, go to Admin -> Configuration -> Media -> Image Field Repair (admin/config/media/image_file_repair/dimensions) and press the "Start" button.

Note: If for some reason you want only repair images, and do not want to fix the bug (for example, you use a special patch or your own solution to fix the problem, or drupal version without this problem), you can disable fix. Just do add next line to /sites/default/settings.php:
$settings['image_field_repair_disable_fix_2644468'] = TRUE;

After having repaired your image fields you can uninstall and remove this module.

Yes, I thought about it, too. But to turn off decoration completely, we must intervene at the ServiceProvider::alert() stage. Unfortunately, at this stage the \Drupal::$container is not exists. So, inside of ImageFieldRepairServiceProvider we cannot use something like:

\Drupal::config('image_field_repair.settings')->get('disable_fix_2644468')

I looked at how other contrib modules solved this problem, and found solution only via Settings. Examples:

• https://cgit.drupalcode.org/s3fs/tree/src/S3fsServiceProvider.php?h=8.x-...
• https://cgit.drupalcode.org/s3fs_file_proxy_to_s3/tree/src/S3fsFileProxy...
• https://cgit.drupalcode.org/streamy/tree/src/StreamyServiceProvider.php#n27
• https://cgit.drupalcode.org/flysystem/tree/src/FlysystemServiceProvider....

Also many other modules use settings.php for their tweaks in other places. So looks like this is normal practice.

I tried to describe example of usage it in the end of #6:

add next line to /sites/default/settings.php:
$settings['image_field_repair_disable_fix_2644468'] = TRUE;

Maybe it's even more convenient than own yml file. Not all users are familiar with YML, but everything is editing settings.php (for set trusted_host_patterns, etc).

Of course, we can turn off the fix at a later stage, but still the decoration will remain. Or write custom method for read config. But in general, there should be quite specific reasons why the user will want to stop fixing, so its disable is a bit specific :)

I forgot to add that after settings.php change, we need to clear the cache too. (for run \Drupal::service('kernel')->invalidateContainer();)