Stop logging errors when a file does not exist

To be honest I do not think this is appropriate, it'd just hide a problem occurring upstream.

I am not familiar with migrate, but if we end up here most likely it's because an Image object is opened, with a background Imagemagick toolkit, on a non-existing image file. But in that case (either GD or Imagemagick, anyway), the Image object will be invalidated. So either migrate is trying to read image metadata, and is therefore failing to migrate some information, or is doing nothing with the metadata, so it's doing an unnecessary operation. For both cases I think the case of 'migrating a file that does not exist' should be handled upstream in migrate code.

Getting this error is easily reproducible through the use of the https://www.drupal.org/project/stage_file_proxy module at least, especially if you configured it to not download the original images, but instead only the derivates. Then it will happen for every image on every page load if you have image styles that rely on metadata.

No idea if this patch is the appropriate way to fix this, but it's an easy fix for me at least.

@TwiiK correct. This is happening when stage_file_proxy is enabled with an option to not download the original images. I created a D.O. issue for this some time ago (https://www.drupal.org/project/imagemagick/issues/3254511), but honestly I don't know what would be the best approach to handle this.

Updated the patch for the new release.

@alayham the issue's number (id) in your patch is incorrect its 3030820 not 3030830

It looks as if nowadays we are dealing with two separate warnings while using imagemagick.

One being
Error getting supported keys for @metadata
this was addressed by patch 8

another
Error getting imagemagick_identify metadata

Attached is a patch addressing both of them.

Still -something for the maintainer to sort out

I created a new branch & MR with a different approach: instead of not catching the exception anymore, we just shouldn't throw it in the first place. The execution doesn't have to stop when the file is not found: e.g. \Drupal\Core\Image\Image::$fileSize can handle being assigned a NULL value by the filesize() function. Drupal\Core\Image\ImageInterface::getFileSize() indicates the same thing in its return value documentation: The size of the file in bytes, or NULL if the image is invalid..

The ImageMagick module can also handle Drupal\file_mdm\FileMetadataInterface::getMetadata() returning NULL:

if (!$file_md->getMetadata(static::FILE_METADATA_PLUGIN_ID)) {
  // No data, return.
  return FALSE;
}

If we really want to log it, an error log would be a better choice than an exception, but I would make that logging optional through a setting in the module. For me personally, and apparently a lot of other people, these kind of errors are not really relevant.

Seems like 1.x is not supported anymore, changing the base branch to 2.x.

I added a new setting to control the log level with which this error will be logged, together with the ability to not log the error at all. I'll add an update hook to set this value to the error log level for backwards compatibility reasons, but what should the default log level for new installations be? I'll set that to error as well for now.

If you're testing this in combination with the ImageMagick module, make sure to include the patch from #3330803: Fix subclassing and stop overriding constructors.

Thanks for working on this!

TIL how to avoid extending constructors!

I like the idea of a UI setting for the missing file error logging. However I think the implementation should be a bit different, see details in inline comments in the MR.

We also would need tests here.

Since the change to Drupal\file_mdm_exif\Plugin\FileMetadata\Exif is no longer necessary, I created a separate issue for that: #3331098: Fix subclassing and stop overriding constructors.

Processed your feedback, resulting in a much simpler solution. Thanks! I'm going to pass for the tests for now since I'm not very experienced in that area.

Moving to the 3.0.x branch.