• Resolved OllieJones

    (@olliejones)


    I’m working on a plugin to read metadata from media

    In wp-admin/includes/image.php, in the function wp_read_image_metadata, there’s a metadata array initialized like this:

    $meta = array(
    			'aperture' => 0,
    			'credit' => '',
    			'camera' => '',
    			'caption' => '',
    			'created_timestamp' => 0,
    			'copyright' => '',
    			'focal_length' => 0,
    			'iso' => 0,
    			'shutter_speed' => 0,
    			'title' => '' );

    It seems that the only element of this array that actually gets used by WP core is the ‘title’ element (in media.php in function media_handle_upload.). Is that correct?

    For some reason the created_timestamp is stored in this array as a UNIX-style 32-bit integer. Is there any reason for that? Will I break core if I change that to a time string?

    If the file doesn’t contain photo-specific metadata (aperture, shutter, iso) would my plugin break stuff in core if it removed these items? Would it break stuff in core if I add new items?

    I’m considering using a similar array of metadata (the same array, actually, populated by chain of filters) for various kinds of media attachments other than images. (MP3 files, PDFs, etc). Adobe has been pushing an XMP standard, the publishers have IPTC, and there’s EXIF and ID3 metadata as well. So there are lots of sources of useful data.

    Is there any core-architecture reason this kind of thing will not work? Thanks.

Viewing 2 replies - 1 through 2 (of 2 total)
  • Moderator bcworkz

    (@bcworkz)

    I wouldn’t change the timestamp to a string, otherwise it’s no longer a valid timestamp, just on principle. Plenty of functions to translate timestamps to something human readable. If you just intend to store the same integer as a string representation of that integer, that may be OK, the usual typing mechanisms should be able to work with that. Or add something like a UTC_string field if you really need a string without doing any conversion.

    The nature of meta data is it can be expanded and contracted based on what’s available, so I don’t think there would be an issue with doing so. WP seems pretty good at initializing defaults for any data it needs to use if it does not exist already. However, I don’t know for sure if there will be problems, it’s just my gut feeling there won’t.

    Thread Starter OllieJones

    (@olliejones)

    OK. Thanks for the gut check.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘media file metadata: what drives the choices in wp_read_image_metadata?’ is closed to new replies.