Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#22759 closed defect (bug) (fixed)

attachment_fields_to_edit should have flags for when to show the field

Reported by: helenyhou's profile helenyhou Owned by:
Milestone: 3.5 Priority: normal
Severity: normal Version: 3.5
Component: Media Keywords: has-patch commit
Focuses: Cc:


Previously, you could use IFRAME_REQUEST to determine whether or not to show a field in a given situation, as the old modal was in an iframe, whereas the inline attachment editing screen was not. The new modal is inline, and thus that detection no longer works.

It is possible to check the WP_Screen object for the post_type to achieve the same effect, but if for some reason somebody has turned on the modal for attachments, it won't quite work.

Attachments (8)

22759.diff (1.7 KB) - added by helenyhou 11 years ago.
22759.2.diff (2.2 KB) - added by nacin 11 years ago.
22759.throw-in-the-towel.diff (4.0 KB) - added by nacin 11 years ago.
22759.3.diff (7.6 KB) - added by nacin 11 years ago.
22759.4.diff (9.1 KB) - added by nacin 11 years ago.
22759.5.diff (10.8 KB) - added by nacin 11 years ago.
22759.6.diff (11.7 KB) - added by helenyhou 11 years ago.
22759.7.diff (1.1 KB) - added by nacin 11 years ago.

Download all attachments as: .zip

Change History (29)

11 years ago

#1 @helenyhou
11 years ago

22759.diff is a pass at defining some flags. These work with compat only, as in all the magic happens in get_compat_media_markup(), so effective only for new media.

Example code to check the magic:

add_action( 'init', 'hhs_init' );
function hhs_init() {
        register_taxonomy_for_object_type( 'category', 'attachment' );

add_filter( 'attachment_fields_to_edit', 'hhs_attachment_fields_to_edit', 10, 2 );
function hhs_attachment_fields_to_edit( $fields, $post ) {
        if ( isset( $fields['category'] ) )
                $fields['category']['show_in_modal'] = false;

        $fields['test-media-item'] = array(
                'label' => 'More Media Management',
                'input' => 'html',
                'html' => '<a href="#">Link One</a><br /><a href="#">Link Two</a>',
                'show_in_edit' => false,

        return $fields;

11 years ago

#2 @nacin
11 years ago

Updated to remove the taxonomies and description fields. Those were each added at different times. I figured the second time if we had to add a third argument, we'd probably do something like this.

#3 @nacin
11 years ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 3.5

#4 @helenyhou
11 years ago

22759.2.diff is lovely. And works. :)

#5 @nacin
11 years ago

  • Keywords commit added

#6 @eddiemoya
11 years ago

  • Cc eddie.moya+wptrac@… added

#7 @ryan
11 years ago

Does anything from [22929] need to come out?

11 years ago

11 years ago

#8 @nacin
11 years ago

#22760 was marked as a duplicate.

11 years ago

#9 @ryan
11 years ago

Added and updated attachment settings from the modal and from the attachment edit page. Looking good.

11 years ago

#11 @nacin
11 years ago

  • Resolution set to fixed
  • Status changed from new to closed

In [23083]:

Restore the Description field to the media UI in 3.5.

We tried in vain -- a noble but ultimately failed effort -- to reduce the number of fields for attachments from four (title, caption, alt, description) to one (caption for images, title otherwise). Alternative text needed to stay for accessibility reasons, of course.

Eventually title returned due to heavy plugin reliance. Description is too used by too many plugins (often times incorrectly -- the caption is more likely the proper field), hence its less-than-triumphant return today.

Version 3.5 has tried to streamline media in a number of ways. Removing fields may have been too much at once, as it forced not only a user interface change, but a paradigm change as well.

Finally, on upload we populate the description field with IPTC/EXIF captions, rather than the caption field. See #22768, this should be fixed. For now, Description stays.

This commit also restores 'Title' attribute editing to the main tab of the Edit Image dialog. The "Title" field no longer populates title attributes for <img> tags by design (for accessibility and other purposes, see #18984). So, here is a more obvious 'workaround' for the tooltip community.

Finally, this:

  • Cleans up the post.php attachment editor, including by showing a prettier form of the mime type.
  • Enables plugins to specifically hide attachment_fields_to_edit from either post.php (where you can create meta boxes) or the modal (which you may not want to clutter), for compatibility reasons.
  • Hides the 'Describe this file...' placeholder when a field is read-only in the modal.

props nacin, helenyhou.

fixes #22759.

11 years ago

#12 @nacin
11 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Anti-climactic re-opening. [23083] restored the "Caption" field for non-image attachments. 22759.7.diff does that for the modal too.

Keeping this as has-patch commit.

#13 @koopersmith
11 years ago

It works.

#14 @nacin
11 years ago

In 23087:

Restore captions for non-image attachments. see #22759.

#15 @nacin
11 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

#16 @pavelevap
11 years ago

Only small glitch on Gallery View page. There is "Describe this image" and on the right sidebar "Caption" field is edited. I would expect that "Description" field will be edited... I am not sure if I should reopen this ticket?

#17 @helenyhou
11 years ago

Not a glitch - intentional. Also, #22777

#18 @pavelevap
11 years ago

Yes, I saw this ticket. But "Describe this image" bellow image is suggesting to users that this is related to "Description" field on the right sidebar...

#19 @DrewAPicture
11 years ago

I think "Caption this image" is more fitting but that's just me. If we're populating the caption field, that is.

#20 @tar.gz
11 years ago

I understand there is some pain involved in bringing the Description field back ... And I'm sure some theme designers who tried the RC releases will now try to hide it :)

Is there a hook for that? If a theme designer wants to simplify the interface, and hide everything except the Caption -- with CSS -- the only available hook is the "data-setting=caption" attribute. Would it hurt to give a proper CSS class to each of those items (title, alt, caption, description)? Or is there a better method?

#21 @pavelevap
11 years ago

So, should I create new ticket for 3.5.1?

When "Describe this image" is used only in Gallery view, why there are other strings like "Describe this audio file"? They will be never visible?

Note: See TracTickets for help on using tickets.