wp_read_image_metadata() doesn't handle Exif array values

[dd32]

Some images appear to have multiple values for some headers, which causes wp_read_image_metadata() to return 'Array' for some fields.

A real-life example are these images:

• ​https://wordpress.org/photos/photo/3056444e62/
• ​https://wordpress.org/photos/photo/7716444e53/
• ​https://wordpress.org/photos/photo/5376444e57/

Looking at the return value from exif_read_data() for one of these, you'll see arrays below. However wp_read_image_metadata() includes lines like (string) $exif['FocalLength'];. It looks like iPhone 13 mini might be common between the above examples

[...]
  'SectionsFound' =>
  string(19) "ANY_TAG, IFD0, EXIF"
  'COMPUTED' =>
  array(6) {
[...]
    'ApertureFNumber' =>
    string(5) "f/1.6"
  }
[...]
  'Make' =>
  string(5) "Apple"
  'Model' =>
  string(48) "iPhone 13 mini back dual wide camera 5.1mm f/1.6"
  'Exif_IFD_Pointer' =>
  int(106)
  'ApertureValue' =>
  array(2) {
    [0] =>
    string(9) "1356/1000"
    [1] =>
    string(9) "8803/1000"
  }
[...]
  'FocalLength' =>
  array(2) {
    [0] =>
    string(9) "5100/1000"
    [1] =>
    string(10) "10884/1000"
  }
  'ShutterSpeedValue' =>
  array(2) {
    [0] =>
    string(10) "10884/1000"
    [1] =>
    string(19) "1124129791/84149760"
  }

As a result on the above Photo pages you'll see something like this:

Focal Length: Arraymm
Shutter Speed: 1/0

This could be related to the image processing application being used, or the sections found in the image. I'd be tempted to just select the first array key in those cases.

[joedolson]

This could definitely be better. My first thought is that this relates to the multi-camera arrays on the phone, since I see it's citing an iphone 13 with dual cameras. I'm inclined to implode the array and store it as comma separated values, although for these numerics, we should assume that there could be plugins using this data numerically. Might require a bit of research to decide whether it's better to change the data type from a numeric string to a stringy string or omit some of the image data.

[dd32]

Replying to joedolson:

I'm inclined to implode the array and store it as comma separated values

That approach seems sane to me, although I question if it could just be stored as a literal array too.. but for compatibility, probably best to store it as a single stringy value.

although for these numerics, we should assume that there could be plugins using this data numerically

That appears to be the case for the Photo Directory at least, although it looks like it's anticipating an array key anyway and imploding those:
​https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/photo-directory/inc/photo.php?marks=903#L841

[mukesh27]

This ticket was discussed during the bug scrub.

No progress since last few week, Moving to 6.4

Additional props: @OGlekler

[marybaum]

Speaking for the September 12 bug-scrubbers, I wonder if we could see a patch with the CSV values in a string and test that. That would at least be movement, and if it doesn't break anything, it could land in 6.4!

[antpb]

With RC1 very close @joedolson mentioned being more comfortable moving this to future so we can close the other tasks assigned for 6.4

[audrasjb]

As per today's bug scrub, we decided to move this ticket to Future Release to give it more time to get a patch.

This PR change handles array values returned from the exif_read_data() function which is mainly used at wp_read_image_metadata(). It converts array values to comma separated values.