Error thrown when exif data could not be read for an image about media-command HOT 12 CLOSED

but thinking about it further, the fix is trivial so probably not worth your time doing it...

That's what I was secretly thinking but didn't want to sound like a jerk.

I'll take your offer to not spend any further time on this.

Appreciate your work on this! Thank you so much.

from media-command.

@rayrutjes Just wondering: you wouldn't perhaps have a broken image that we could use (without licensing issues) to build a regression test?

from media-command.

We might be able to produce the bug with images in here: https://github.com/ianare/exif-samples/tree/master/jpg

from media-command.

Note:
Test images can be uploaded to https://github.com/wp-cli/wp-cli.github.com/tree/master/behat-data

from media-command.

@schlessera TBH I wanted to give you the images, but i had a hard time isolating them :/ .
I needed to re-do the full import of thousands of images in a clean environment and I didn't know what to do with it anyway (but you just shared how above).

Not sure I'll have time this week to find the images that broke. I'll add it to my todolist though.

from media-command.

@rayrutjes Ok, thanks! As I posted above, we might have found broken example files already that are CC. So, hopefully, you don't need to bother going through everything again.

from media-command.

I could not reproduce this bug with the images from the repository of EXIF samples I posted above.

from media-command.

Okay reproduced the PHP warning by uploading a BMP with Imagick disabled and as the GD image editor can't handle it no sizes metadata is saved, and then regenerating with Imagick enabled.

Will do fix based on this though obviously it would be much better to have at least one of the original trigger images @rayrutjes if you get the time...

PR incoming...

from media-command.

I wanted to PR the image but the other repo seems read only :)
https://we.tl/BPNOcnRlgv

My logs report this one was causing the issue.

I've been unable to re-produce, probably because if you run it several time on a failing image the error occurs only the first time.
I hope this file is not a false positive.

Here is a bit more:

from media-command.

Thanks very much @rayrutjes. I'm guessing it is a false positive in that a different file is generating the sizes undefined message, as the polygon-or.jpg file does produce sizes metadata even though the EXIF is faulty. That plus the ordering (the EXIF message should occur after the sizes message on regenerate I think) and time gap.

This makes sense to me on looking at the "wp-admin/includes/image.php" code too. If you could work out which file after polygon-or.jpg might have no sizes metadata that would be cool, if not cool also...

from media-command.

Makes sense, in that case I will need to re-do the full import on a blank new instance.
Or maybe you have a trick to remove all existing metadata?

from media-command.

Or maybe you have a trick to remove all existing metadata?

Not in a good way, off the top of my head!

I will need to re-do the full import on a blank new instance

I'm happier now with the manufactured BMP method mentioned above as a reasonable test, but if that was possible and you would be able to identify the file and you have the time then that would be great...

Edit: but thinking about it further, the fix is trivial so probably not worth your time doing it...

from media-command.