Wrong Slug Saved for Some Attachments

[miqrogroove]

Currently, WordPress chooses image slugs from their filenames, or the meta title if available. (Some kind of EXIF thing that doesn't work most of the time?)

There's a huge problem with this. If that meta field is numeric, WordPress changes the permalink structure to

/blog/year/month/post-title/attachment/123456/

The blog author has no direct control over this, and it looks really bad when all of the other image permalinks have

/blog/year/month/post-title/filename/

WordPress needs to revert back to filename slugs when the meta title is numeric (garbage).

And don't let me blow your minds all at once here, but how about letting the blog author edit those slugs?

[hakre]

Regarding EXIF that does not work out of the time: #9417

Editing slugs might already be possible on the image details or within the media libraray. Have you checked that?

[hakre]

Test-Image

[hakre]

Tested this with the attached image which has a numery title only. Uploaded via the media library and left it un-associated to any post. Had not problems to open the image, was offerd with query strings on the view links instead of a nice permalink so I was not able to reproduce from the media library.

Then I added it to a post to better test. It got properly attached to the new post (verified via the Media Library's Attached to table column). I was able to switch from /?attachment_id=78 to proppery permalink linkage by publishing the post. Attachment then was referenced as /2010/01/numeric-attachment/attachment/11417/ which looks pretty valid to me (I do not actually see that this is wrong). To counter check I choosed an image with name and tested with it. I than ran over the problem (image taken from that #/11446 ticket, the one with the long name) that I was not able to change the attachments slug afterwards. Tried to by changing the title but no luck with that.

So in any case (not only numeric titles) the admin does not offer the user a possibility to change an attachments slug. this should be offered in the diverse editors (media library, post/page media thickbox). I'm unsure wether this is a bug (it does not break anything, URLs do actually work), an enhancement or even a feature request. But I think it should be taken care of this.

[hakre]

Related: #11446

[miqrogroove]

Attachment slug editing spinoff in #12233.

This ticket will focus on two bugs:

1. meta->numeric_garbage should never override "my-useful-filename.jpg"

2. Meta titles need more testing. It only seems to work on about half of the images I upload, suggesting there is another bug here.

[miqrogroove]

Fixes several major problems with EXIF, IPTC, and slug handling.

[miqrogroove]

Keep empty checks, add support for Windows property pages.

[miqrogroove]

Patch refreshed. Fixed a minor issue where I had stepped on the empty if($value) checking. 11417.2.patch prefers EXIF title, then IPTC v1.1 headline, then IPTC title, subject to availability. Without this patch, WordPress only tries to read the IPTC title and then gives up.

Numeric slugs fixed. This was actually being caused by an obsolete IPTC implementation where the filename was stored in the title field. This patch uses the IPTC v1.1 spec and only falls back on the IPTC title field as a last resort. Also, left some training wheels on the title assignment, just in case, WordPress will fall back on the filename slug instead of numeric garbage.

[miqrogroove]

note the IPTC headline and EXIF ImageDescription may be stored redundantly. It might look tidier to discard the latter if it is identical to the former.

[miqrogroove]

Check for more situations where caption was used instead of title.

[miqrogroove]

At this point, I've done everything I can do to break this patch. It needs to be committed so that we can get everyone who uploads during alpha/beta to report any undesirable results.

[nacin]

(In [13244]) Improved IPTC and EXIF handling. Drag a wider net and also try to avoid numeric attachment slugs where possible. Props miqrogroove. See #11417

[nacin]

(In [13249]) Use utf8_encode() consistently in wp_read_image_metadata(). Also add some whitespace. props miqrogroove, see #11417, see #12095

[dd32]

Closing as fixed, as there doesn't appear to be anything left here to do, and no issues have come up.

Please open a new ticket if you find a bug related to this.