Move attachment editing (media.php) to use standard post type UI

[nacin]

As noted in the #21390 parent ticket, the media.php attachment editing layout, which is essentially the contents of the Thickbox dialog, could use a lot of work.

We can get a lot of things "for free" if we move it to be a proper post type UI, including:

• Taxonomy UIs
• Slug editing
• Re-parenting (even if only exposed by a plugin)
• Proper editor for attachment page descriptions
• Proper field (the excerpt field) for a caption
• Additional fields (as determined by existing filters) can go in a meta box

Image editing (cropping, thumbnails, etc.) can be shown in a dialog that will come out of the media work (see parent ticket).

[helenyhou]

Swoon! :)

[martythornley]

I know this is early but I started messing with this a little and see a couple initial things...

It is easy enough to change the edit link to use the standard post types editor. But you get the standard editor, which doesn't do anything for an attachment. I see a couple ways to change that within advanced_edit_form.php but not sure what makes more sense...

1) Within the <?php if ( post_type_supports($post_type, 'editor') ) { ?> section, you could add something so that attachments use their own thing, or

2) You could add a new post_type_supports for attachment_editor? Then as you register the attachment post_type, you could say that it supports the media_editor?

Maybe there is another way but the idea of being able to register a post type and allow it to use a built in image editor sounds kind of awesome. :)

[scribu]

There should only be one attachment post type, so calling some function only for attachments should be good enough.

[helenyhou]

The description is the post content, actually, so supporting the editor might be fine.

We may indeed end up needing to do some things in advanced_edit_form.php, though, to make the editing flow more clear, especially as it relates to what was there previously. #19658 would be a good thing to have here, and then utilizing those hooks, rather than hard-coding a bunch of if ( 'attachment' === get_post_type() ) stuff.

Idea: Show the image somewhere prominently on the screen (below the title?), and then a button or some such to edit the image, which then shows the editing controls below the image already displayed.

[nacin]

Marked #9839 as a duplicate — enable/disable comments on attachments. Consider inheriting a parent's comments value.

[nacin]

Marked #13414 as a duplicate — showing taxonomies in the admin menu under Media.

[SergeyBiryukov]

Replying to nacin:

Marked #9839 as a duplicate — enable/disable comments on attachments. Consider inheriting a parent's comments value.

Related: #19858

[husobj]

+1 for getting proper taxonomy support for Media.
Will make it so much easier to create non post-dependent galleries - something that's been lacking for a while.

My ​Attachment Taxonomy Support plugin fudges it in the meantime but having this as part of core would be great!

[nacin]

Some stuff I was playing with some time ago.

[helenyhou]

The roughest of all rough patches, so the general direction can be seen. Specifically deals with (much) of the publish metabox.

[helenyhou]

First real pass, with ocean90. Still needs work.

[helenyhou]

Finally have a first pass: 21391.2.diff​, worked on with ocean90.

Does the following:

• Exposes the regular post edit screen for attachments, which comes with goodies like visual editor for the description, slug editing (works!), taxonomy metaboxes (works!), and any other metaboxes
• Adds the image thumbnail with in-place image editing, currently above the title (not beautiful, but works!)
• Adds a metabox for editing alt text, caption (really the excerpt), and displaying the file URL
• Introduces disable_for_post_type() and post_type_disables(). Currently utilized in the publish metabox
• Adds hooks to edit_form_advanced.php

Known issues:

• "Trash" in the publish metabox should really be "Delete Permanently" (or rather, based on the MEDIA_TRASH internal constant like it is elsewhere)
• Alt text shows but doesn't actually save
• The layout of the screen isn't awesome, at all. In particular, the placement of the image+details+editor at the top doesn't look great with the publish metabox still at the top of the side metaboxes. Also, it does feel a little clunky to have the title and description edited separately from the other pieces of data, when they were formerly indicated as being essentially equal in importance, and realistically the alt text and caption are perhaps more important.

Things to think about:

• What happens when you add new media via media-new.php? Upload and then punt over to editing it immediately? Something else?
• Do we want to expose attached status (parent post) on the screen somewhere? It is on the list table, so it's not lost.
• Should we leave the list table where it is (a special upload.php screen) or move to the /wp-admin/edit.php?post_type=attachment screen instead?

I'm sure there's more. :)

[scribu]

My 2c:

What happens when you add new media via media-new.php? Upload and then punt over to editing it immediately? Something else?

Wait for the media revamp a bit.

Do we want to expose attached status (parent post) on the screen somewhere? It is on the list table, so it's not lost.

It will be even less relevant in 3.5 than it is now, so I'm thinking that's fine.

Should we leave the list table where it is (a special upload.php screen) or move to the /wp-admin/edit.php?post_type=attachment screen instead?

Would be nice, but I'm not sure if it's wise to attempt in 3.5.

[SergeyBiryukov]

Replying to helenyhou:

• Alt text shows but doesn't actually save

Fixed in 21391.3.diff​.

[SergeyBiryukov]

Replying to helenyhou:

• Do we want to expose attached status (parent post) on the screen somewhere? It is on the list table, so it's not lost.

Perhaps in a meta box similar to "Page Attributes". This would allow reparenting (#6820).

[helenyhou]

Replying to SergeyBiryukov:

Replying to helenyhou:

• Do we want to expose attached status (parent post) on the screen somewhere? It is on the list table, so it's not lost.

Perhaps in a meta box similar to "Page Attributes". This would allow reparenting (#6820).

I think I'm inclined to agree with scribu - we're de-emphasizing the attachment relationship with media management changes, so perhaps it is more of a plugin thing to do. At least they can, now :)

[ocean90]

​https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2012-09-19&sort=asc#m459225

---

21391.6.patch​:

• Adds support for custom taxonomies
• Adds a custom publish metabox for attachments
• Removes the disable_for_post_typeAPI in favour of the custom metabox
• Adds support for MEDIA_TRASH

Todo:

• Support for get_attachment_taxonomies()

[ocean90]

21391.7.patch​ adds support for type specific taxonomies. See plugin.php​ for an example.

Currently the counts on the term lists doesn't work. Couldn't find the right place to fix it. Probably a query which only queries for publish posts. Solved through 'update_count_callback' => '_update_generic_term_count'.

[ocean90]

Some thoughts:

• Maybe we should find a better name for get_attachments_taxonomies() - nacin proposed get_taxonomies_for_attachments() Done in 7.1
• Support for attachment_fields_to_edit and attachment_fields_to_save filters
• Time to add a show_in_menu arg toregister_taxonomy? See #20930
• Help tab

[ocean90]

s/image_editor/image-editor/g and s/get_attachments_taxonomies/get_taxonomies_for_attachments/

[nacin]

In [21948]:

Use the regular post type UI for editing single media items (attachments).

• Attachments now go through post.php, edit_post(), the like, and have show_ui set to true.
• Taxonomies attached to the media library now appear in the admin menu (if show_ui).
• Editing, cropping, uploading, etc. is still very rough, but mostly functional.

API-wise:

• New function: get_taxonomies_for_attachments(). Like get_taxonomies(), for taxonomies specifically registered against attachments.
• Brings taxonomy support from the posts list table to the media list table. Expect them to converge soon.
• wp_insert_attachment() now handles taxonomies like wp_insert_post(). Also expect them to converge soon.
• New edit_form_after_title hook.

props helenyhou, ocean90. see #21391.

[nacin]

Some things on the to-do:

• We need proper messages in post.php, for those that apply, to replace my array_fill().

• Some of the get_post_status() checks make sense. But, if you upload an attachment to a draft post, that attachment page is publicly accessible. Don't really want to get into whether it *should* be publicly accessible, but since it is, "View Attachment Page" should be visible.

• On the same vein, I had to make a change from the patches in [21948] from name=publish on the submit button to name=save so everything worked. We need a full post status audit — what happens when an attachment is status X, Y, Z, what happens when its parent is X, Y, Z. Are messages right? Cap checks right? Save buttons proper? etc.

• Dissolve media.php. Figure out what we need out of there (including help), and otherwise, kill it.

• media-new.php shows the old form. (Keep in mind it allows for multiple uploads at once.) What should this workflow be? I don't know yet.

• Fully test cropping. Fully test taxonomies and edit-tags.php integration (figure out if we should force _update_generic_term_count).

• The "Add New" button needs an upload_files check. This is probably time for a create_posts meta cap. I've moved #16714 to 3.5.

[nacin]

We also need to block post_status, post_password, stickiness, post_date from being changed.

[DrewAPicture]

Tracked a problem with image scaling on the edit screen back to imageEdit.scaleChanged() in image-edit.js. Not present in 3.4.2 so gotta be trunk. Anyway, changing the width or height has the expected effect of changing the adjacent value per the correct ratio, but there's some weirdness of the values incrementing down when you tab between them. Short screencast: ​http://screencast.com/t/tPiq9KlYVzzj

[DrewAPicture]

Help tabs

[DrewAPicture]

21391.8.diff​ adds the Help Tabs. Could probably be refreshed, though I changed 'five fields' to 'four fields' in the first sentence.

[DrewAPicture]

Some observations after [21948]:

• Not sure there are other relevant messages besides those supplied by the inline image editor. I'm completely ignorant of whether there's a feasible way to combine them together as currently the inline editor messages display inline below the permalink editor.

• Inline editor works mostly as expected. Besides the scaling issue mentioned in comment:39, there's weird ux with cropping where saving the cropped image supplies the 'Image saved' message but the original image is still displayed. Manually refreshing shows the cropped image was indeed saved.

• Custom taxonomy term counts on attachments appear to indicate precisely half the actual count, e.g. 6 associated attachments, displays as 3. 1 attached displays as 0 and so on.

[ocean90]

Replying to DrewAPicture:

Tracked a problem with image scaling on the edit screen back to imageEdit.scaleChanged() in image-edit.js. Not present in 3.4.2 so gotta be trunk.

I can reproduce this in 3.4.2 on Chrome too. Please open a separate ticket.

Replying to DrewAPicture:

• Custom taxonomy term counts on attachments appear to indicate precisely half the actual count, e.g. 6 associated attachments, displays as 3. 1 attached displays as 0 and so on.

Which update_count_callback did you use? _update_generic_term_count should work, since the default one has some special status checks, see ​_update_post_term_count

[ryan]

In [21968]:

Add help to the attachment editor. Props DrewAPicture. see #21391

[DrewAPicture]

Related: #22047 - Do action 'save_post' for attachments in 'wp_insert_attachment()'

[ryan]

In [22093]:

Respect ssl for the image src link in edit_form_image_editor(). see #21391

[ocean90]

Some feedback from the the forums:
​http://wordpress.org/support/topic/suggestions-for-the-media-library-edit-screen-in-admin

[scribu]

+1 on moving the non editable data to the right.

+1 on moving the image URL closer to the image.

+1 on moving alt text and caption higher; attachment page content should be a separate, hidable metabox.

[helenyhou]

How would we feel about putting the non-editable data in the Save metabox? Uploaded date is similarly non-editable.

[Bellfalasch]

Replying to scribu:

+1 on moving the non editable data to the right.
+1 on moving the image URL closer to the image.
+1 on moving alt text and caption higher; attachment page content should be a separate, hidable metabox.

+1 on your addition of "Separate hideable metabox" for the last suggestion.

Replying to helenyhou:

How would we feel about putting the non-editable data in the Save metabox? Uploaded date is similarly non-editable.

Sounds good to me - fewer boxes =)

[ocean90]

Refresh the thumbnail

[ocean90]

21391.thumbnail-refresh.patch​ refreshes the image after editing.

[nacin]

As mentioned in #16714, we actually did not need a create_posts cap. media.php happens to be accessible without upload_files, but it's a fluke — the Media Library (including the list table at upload.php) is entirely disabled for users who cannot upload files.

[ryan]

I see +1s but no patches. :-)

[helenyhou]

Replying to ryan:

I see +1s but no patches. :-)

Ask and you shall receive! 21391.4.diff​

I feel like the output for the attachment metadata metabox could be handled better, like an array of labels and corresponding content. Open to ideas.

[helenyhou]

Another take: 21391.6.diff​ puts the non-editable metadata into the submit/publish box. Screenshot:

[ryan]

I like it.

[husobj]

I like it too

[ryan]

In 22364:

Attachment editor improvements. Put the non-editable metadata into the submit/publish box.

Props helenyhou
see #21391

[ryan]

Do we still need 21391.thumbnail-refresh.patch?

[ocean90]

Replying to ryan:

Do we still need 21391.thumbnail-refresh.patch?

Yes.

Maybe there is another way as the if ( false !== strpos( wp_get_referer(), 'post.php' ) ) { check.

[tar.gz]

Some comments regarding the new layout:

(1) - The image preview is now using the "Large size", which defaults at 1024 px width. On a typical 1440x900 laptop screen, this forces the user to scroll in order to reach the text fields.

If we assume that in many cases, the user comes here to edit the fields rather than for viewing the image in large size, then this layout is not the most practical.

Here is how it looks with a large image:

​http://ms-studio.net/wp-content/uploads/2012/11/media-page-3.5.png

And here is a mockup of a more compact layout, that I find much more usable:

​http://ms-studio.net/wp-content/uploads/2012/11/media-page-3.5-alt.png

• I think the image preview doesn't need to be bigger, since we aren't editing the image here.
• I find it more coherent to have the Title field close to the other text fields.

(2) - An other minor issue: the file URL field is now much narrower than previously. I think that it should allow for line breaks, in order to have the full URL visible. And a nice touch would be if by clicking on that string, the whole URL would get auto-selected.

(3) - Finally, a question regarding the naming of "Caption" and "Description" (now "Attachment Page Content"): is there any official method for overriding those labels, such as we can override the labels for Posts and Pages (with change_post_object_label() / change_post_menu_label() in functions.php)?

[DrewAPicture]

Replying to tar.gz:

And here is a mockup of a more compact layout, that I find much more usable:
​http://ms-studio.net/wp-content/uploads/2012/11/media-page-3.5-alt.png

• I think the image preview doesn't need to be bigger, since we aren't editing the image here.

I like the idea of pushing the image over to the right column, it reminds me of how the new modal is laid out. On the other hand, we are sometimes editing the image here. That's why there's an 'Edit Image' button. As it stands with the media in the left column, the inline image editor has enough space to breathe. How would you handle the editor if the media were previewed in the right column?

• I find it more coherent to have the Title field close to the other text fields.

I agree, but for consistency sake, see above.

(2) - An other minor issue: the file URL field is now much narrower than previously. I think that it should allow for line breaks, in order to have the full URL visible. And a nice touch would be if by clicking on that string, the whole URL would get auto-selected.

This would be great. Do you have a patch?

(3) - Finally, a question regarding the naming of "Caption" and "Description" (now "Attachment Page Content"): is there any official method for overriding those labels, such as we can override the labels for Posts and Pages (with change_post_object_label() / change_post_menu_label() in functions.php)?

I think currently all we've got are gettext and/or translation.

[tar.gz]

Replying to DrewAPicture:

How would you handle the editor if the media were previewed in the right column?

Ah, right, the editor. Will it stay exactly the same as in 3.4? In WP 3.4, while the preview is thumbnail (150x150), the size of the image in the editor is 400 px wide. That feels intuitive enough.

But won't it feel strange if the preview is 1024px wide, and when you open the editor, the image shrinks to 400px width?

So a good compromise is maybe to use the same size (400x300, rougly), both for the preview and for the editor. That would look pretty much like the screenshot posted above by helenyhou.

(2) file URL field (...) line breaks (...) auto-selected.

This would be great. Do you have a patch?

Not yet, but I gave it a try with Firebug. Apparently, it's impossible to force a line break with CSS on an <input> element - word-break and word-wrap rules are ignored. Auto-selection on click is very easy, we just need to add onclick="this.focus();this.select()" to the markup.

On the other hand, if we would use some other container element, such as <p>, the URL would break normally, and would be fully visible, but it would need additional styling. Also then the above Javascript won't work, it would require some tweaking. Not sure which solution is more appropriate, but the second needs more work.

[DrewAPicture]

Replying to tar.gz:

But won't it feel strange if the preview is 1024px wide, and when you open the editor, the image shrinks to 400px width?

If the editor gets moved into a modal in a future version, the right-column suggestion would be a lot more feasible. I think what we have now is a good improvement on 3.4 and I'm guessing it's pretty well locked-in for 3.5.

Apparently, it's impossible to force a line break with CSS on an <input> element - word-break and word-wrap rules are ignored. Auto-selection on click is very easy, we just need to add onclick="this.focus();this.select()" to the markup.

We don't need to mess with trying to break the line -- you can't change the value anyway. I was thinking the auto-select/copy would be a nice-to-have, but that may be a broader future decision because I see applications for it in several places in the Dashboard.

[helenyhou]

To me, the screen looks funny and uneven with the image at an arbitrary small size aligned left, but maybe it makes sense to leave it the same size as it is when being edited, and allow the size to be filtered. The size defined is 900x600, not the large size. I don't see why the image editor would get moved into a modal, though, so that is probably not a scenario to chase.

I'm not convinced having a URL potentially (probably) break over multiple lines is a good idea or really any better than the input that doesn't show it all at once. It's already sort of a power user feature, isn't it? I would also say that any JS for selecting everything would need to not be done with onclick, and as noted by DrewAPicture, probably has further applications across the admin. Might not be for this cycle.

[tar.gz]

Replying to helenyhou:

To me, the screen looks funny and uneven with the image at an arbitrary small size aligned left, but maybe it makes sense to leave it the same size as it is when being edited, and allow the size to be filtered.

It wouldn't be an arbitrary small size: it would be exactly the same size as when you click "Edit image". But it's true, the amount of white space will make the screen uneven.

The size defined is 900x600, not the large size.

That's correct. I was thinking 1024px because I was looking at the actual image pixel size. The CSS shrinks it to 900x600.

What I find problematic is that, upon arriving on the page, I don't get a global overview of "what's on that page". The arguably most important editable fields (caption, alt text, content) are pushed down "below the fold". As a user with an average laptop screen, I have to scroll in order to see what's there.

On the other hand, if I came here in order to crop the image, I will feel frustrated by the comparatively small size of the edit preview.

I'm not convinced having a URL potentially (probably) break over multiple lines is a good idea (...). It's already sort of a power user feature, isn't it?

Again, I see it as a matter of "information design principles". The "informational" part of that URL is the last piece. If I can see only the beginning (the root of the domain), it conveys no information at all. From a usability perspective, it's easier to select a string if I can see all of it. But I agree this might be too small a feature to waste time on it...

[helenyhou]

Related, spun off to contain the dicussion: #22491

[helenyhou]

So, we need 21391.thumbnail-refresh.patch​ to deal with the fact that the image size is different here, yes?

The only other thing that I see as a definitive to-do on this screen to round this out is to not show the alternative text input for non-images. 21391.alt_text.diff​ for that. From there, I think we should be making new tickets.

[nacin]

In 22748:

Non-images don't have alternative text. props helenyhou. see #21391.

[nacin]

In 22749:

Properly refresh the thumbnail on post.php after an image edit. props ocean90. see #21391.

[nacin]

I think [22749] is implying that an XHR request passes a referer. We should replace it with a $_REQUEST['context'] parameter and call it a day.

[helenyhou]

I am an idiot and put the endif in the wrong place in [22748]. 21391.7.diff​ to fix, please.

[nacin]

In 22757:

Properly nest the if tag. props helenyhou. see #21391.

[nacin]

In 22777:

Redirect post-new.php?post_type=attachment to media-new.php. see #22491, #22083, #21391.

[nacin]

In 22783:

Support attachment_fields_to_save and attachment_fields_to_edit for attachments going through post.php. see #22186. see #21391.

[nacin]

Replying to nacin:

• I think [22749] is implying that an XHR request passes a referer. We should replace it with a $_REQUEST['context'] parameter and call it a day.

This is the only thing left here, as far as I know.

[ocean90]

Use $('#image-edit-context').length

[ocean90]

$type_html isn't needed here. It's some cruft from get_media_item().

[koopersmith]

In 22807:

Media: Replace the thumbnail on post.php using a request variable instead of the referer. props ocean90. fixes #21391.

[nacin]

In 23081:

Media list table: Fix the categories column, hidden thanks to a typo. props eddiemoya, fixes #22764. see #21240, #21391.

[wonderboymusic]

'admin_action_editattachment' is gone in 3.5. 'edit_attachment' works just fine, but that wasn't broadcasted here.

[audrasjb]

In 55647:

Media: Deprecate wp-admin/media.php.

The wp-admin/media.php file was introduced in [7262], then removed from the Media workflow in [21948].
This changeset finally deprecates it as it is not used anymore.

Follow-up to [7262], [21948].

Props kebbet, costdev, SergeyBiryukov, jrf, antpb, audrasjb.
Fixes #57612.
See #6181, #21391, #57608.