Make WordPress Core

Opened 6 months ago

Last modified 4 weeks ago

#58082 accepted defect (bug)

Import metadata description from Darktable into media caption in WordPress

Reported by: fotodrachen's profile fotodrachen Owned by: joedolson's profile joedolson
Milestone: 6.4 Priority: normal
Severity: normal Version: 6.2
Component: Media Keywords: has-patch needs-testing
Focuses: Cc:

Description (last modified by sabernhardt)

WordPress 6.2 in interaction with Darktable 4.2.1

It should be possible to set Metadata in the Photo-Editor "Darktable" that can be used as "caption" (and "title") in WordPress without typing it once again.

In Darktable there are 3 metadata-fields in the internal database: title, description, notices.
While exporting from Darktable to JPEG the metadata can be written into the JPG-file. There are 3 groups of metadata: EXIF, IPTC and Xmp.

Darktable writes EXIF and Xmp.
WordPress reads EXIF and IPTC.
So only EXIF can be used.

Darktable writes only the "description" into the EXIF-group, the fields "title" and "notices" only in Xmp.
So only the Darktable-field "description" can be used for WordPress-caption and title.

If the description has "ASCII only" characters, Darktable exports the description to "EXIF ImageDescription field".
If the description contains some special characters (like in german ä ö ü), then Darktable writes the Description to "EXIF UserComment field".
So "EXIF ImageDescription field" OR "EXIF UserComment field" is filled, but never both.

The "EXIF UserComment field" is not imported to the WordPress-caption when "EXIF ImageDescription field" is empty (wrong if-structure?).

So at least only descriptions with "ASCII only"-characters are imported from darktable, texts with special national characters are lost.

Please enable the import of the "EXIF UserComment field".

Source-code is: function wp_read_image_metadata() in /wp-admin/includes/image.php.
Inserting this 7 lines of code at line 877 solved the problem for me:

// }
} elseif ( empty( $meta['caption'] ) && ! empty( $exif['COMPUTED']['UserComment'] ) ) {
        $meta['caption'] = trim( $exif['COMPUTED']['UserComment'] );
        $description_length = strlen( $exif['COMPUTED']['UserComment'] );
        if ( empty( $meta['title'] ) && $description_length < 80 ) {
                $meta['title'] = trim( $exif['COMPUTED']['UserComment'] );

Documentation in German:

On long term it could be useful also to import metadata from the Xmp-group, for example to get different description and title.

Attachments (1)

58082.diff (793 bytes) - added by mikinc860 3 months ago.
Uploaded the diff based on provided code.

Download all attachments as: .zip

Change History (18)

#1 @sabernhardt
6 months ago

  • Component changed from Administration to Media
  • Description modified (diff)
  • Summary changed from Import metadata description from darktable into media caption in wordpress to Import metadata description from Darktable into media caption in WordPress

This ticket was mentioned in Slack in #core-media by antpb. View the logs.

6 months ago

#3 @antpb
6 months ago

  • Milestone changed from Awaiting Review to 6.3

Hello @fotodrachen ! We reviewed this ticket in the recent Core Media meeting and think there is some improvement that could be made Core side to make this a better experience. Standards suggest UserComment as the intended substitute for ImageDescription when multibyte characters are needed. One way forward might be to append the UserComment if defined to ImageDescription.

And for future reference, here's the exif standard:

This ticket was mentioned in Slack in #core-media by joedolson. View the logs.

5 months ago

#5 @joedolson
5 months ago

  • Owner set to joedolson
  • Status changed from new to accepted

#6 @joedolson
5 months ago

Our proposal is:

If identical, use ImageDescription; if one field is empty, use the one that's populated, if both populated, append in order ImageDescription + UserComment; add filter so plugins can adjust this behavior.

This ticket was mentioned in Slack in #core-media by antpb. View the logs.

3 months ago

3 months ago

Uploaded the diff based on provided code.

#8 @mikinc860
3 months ago

  • Keywords has-patch added

#9 @oglekler
3 months ago

  • Keywords needs-testing added

#10 @azaozz
3 months ago

  • Milestone changed from 6.3 to 6.4
  • Type changed from defect (bug) to enhancement

This ticket type is set as "bug" but it sounds more like an enhancement? Also seems it may be too late to add it to 6.3, RC is in few days.

Setting as enhancement and to the 6.4 milestone. Feel free to move it back to 6.3 if somebody is ready to test and fix this now.

#11 follow-up: @joedolson
3 months ago

  • Type changed from enhancement to defect (bug)

I think this should remain a bug; WordPress fails to read the appropriate description data out of the image meta in some circumstances, failing to follow the EXIF spec regarding multibyte characters when reading this data.

#12 in reply to: ↑ 11 @azaozz
3 months ago

Replying to joedolson:

Sure. In this case it seems that the EXIF "UserComment" should have a higher priority than the old, non-standard "Comment". I.e. the patch needs a small update.

#13 @fotodrachen
3 months ago

It's a bug and it's a small update.

The code for import the EXIF "UserComment" is already there. But it is wrapped in a wrong IF-structure (bug!).
A filled "UserComment" is only imported, when "ImageDescription" is also non-empty. This never happens for pics from DarkTable.
"ImageDescription" is filled for only-ascii text from the description-metadata in DarkTable, "UserComment" is filled for NOT-only-ascii text.
So "ImageDescription" OR "UserComment" is filled in the EXIF-data in a picture, but never both.
"UserComment" should be imported even if "ImageDescription" is empty, it's the alternative.

I added this case at the end of the if-else-structure. May be there is a smarter solution modifying a if-condition.

This ticket was mentioned in Slack in #core-media by joedolson. View the logs.

2 months ago

#15 @joedolson
2 months ago

  • Keywords early added

This ticket was mentioned in Slack in #core-media by joedolson. View the logs.

2 months ago

#17 @hellofromTonya
6 weeks ago

  • Keywords early removed

I've removed the early keyword. Why?

The handbook explains the keyword as:

This keyword should only be applied by committers. The keyword signals that the ticket is a priority, and should be handled early in the next release cycle.

early means the commits need to happen during the early part of the Alpha cycle; else, the ticket gets bumped.

Though it would be great to prepare the work for commit as early as possible, commits for this ticket should not be constrained to only happen during the early Alpha phase. Rather, defect commits can happen up to 6.4 RC 1.

To aid in 6.4 tracking and scrubs, I've removed the early keyword.

Note: See TracTickets for help on using tickets.