Make WordPress Core

Opened 12 years ago

Closed 11 years ago

Last modified 11 months ago

#21391 closed task (blessed) (fixed)

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

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

Description

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).

Attachments (21)

21391.diff (1.6 KB) - added by martythornley 12 years ago.
attachment-show-ui.diff (3.9 KB) - added by nacin 12 years ago.
Some stuff I was playing with some time ago.
attachment_editing_scratch.diff (12.3 KB) - added by helenyhou 12 years ago.
The roughest of all rough patches, so the general direction can be seen. Specifically deals with (much) of the publish metabox.
21391.2.diff (22.3 KB) - added by helenyhou 12 years ago.
First real pass, with ocean90. Still needs work.
21391.3.diff (22.9 KB) - added by SergeyBiryukov 12 years ago.
21391.4.patch (22.0 KB) - added by ocean90 12 years ago.
21391.5.diff (30.4 KB) - added by ocean90 12 years ago.
21391.5.1.patch (29.2 KB) - added by ocean90 12 years ago.
21391.6.patch (28.6 KB) - added by ocean90 12 years ago.
21391.7.patch (29.5 KB) - added by ocean90 11 years ago.
plugin.php (1.3 KB) - added by ocean90 11 years ago.
21391.7.1.patch (30.0 KB) - added by ocean90 11 years ago.
s/image_editor/image-editor/g and s/get_attachments_taxonomies/get_taxonomies_for_attachments/
21391.8.diff (1.9 KB) - added by DrewAPicture 11 years ago.
Help tabs
21391.thumbnail-refresh.patch (2.0 KB) - added by ocean90 11 years ago.
Refresh the thumbnail
21391.4.diff (6.1 KB) - added by helenyhou 11 years ago.
21391.6.diff (5.9 KB) - added by helenyhou 11 years ago.
attachment_edit_submitbox.png (69.5 KB) - added by helenyhou 11 years ago.
21391.alt_text.diff (837 bytes) - added by helenyhou 11 years ago.
21391.7.diff (819 bytes) - added by helenyhou 11 years ago.
21391.8.patch (2.1 KB) - added by ocean90 11 years ago.
21391.8b.patch (2.1 KB) - added by ocean90 11 years ago.
Use $('#image-edit-context').length

Download all attachments as: .zip

Change History (106)

#1 @DrewAPicture
12 years ago

  • Cc xoodrew@… added

#2 @martythornley
12 years ago

  • Cc marty@… added

#3 @scribu
12 years ago

  • Cc scribu added

#4 @kirasong
12 years ago

  • Cc mike.schroder@… added

#5 @sabreuse
12 years ago

  • Cc sabreuse@… added

#6 @helenyhou
12 years ago

Swoon! :)

#7 @meliko
12 years ago

  • Cc melissachoyce@… added

@martythornley
12 years ago

#8 follow-up: @martythornley
12 years ago

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. :)

Last edited 12 years ago by martythornley (previous) (diff)

#9 @scribu
12 years ago

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

#10 in reply to: ↑ 8 @helenyhou
12 years ago

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.

#11 @mikeschinkel
12 years ago

  • Cc mikeschinkel@… added

#12 @kawauso
12 years ago

  • Cc kawauso added

#13 follow-up: @nacin
12 years ago

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

#14 @nacin
12 years ago

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

#15 @toscho
12 years ago

  • Cc info@… added

#16 in reply to: ↑ 13 @SergeyBiryukov
12 years ago

Replying to nacin:

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

Related: #19858

#17 @husobj
12 years ago

  • Cc ben@… added

+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!

#18 @simonwheatley
12 years ago

  • Cc simon@… added

#19 @bootsz
12 years ago

  • Cc bootsz added

#20 @WraithKenny
12 years ago

  • Cc Ken@… added

#21 @kieranmasterton
12 years ago

  • Cc kieranmasterton added

#22 @azizur
12 years ago

  • Cc azizur added

#23 @ChaseWiseman
12 years ago

  • Cc ChaseWiseman added

#24 @wycks
12 years ago

  • Cc bob.ellison@… added

@nacin
12 years ago

Some stuff I was playing with some time ago.

#25 @blobaugh
12 years ago

  • Cc blobaugh added

#26 @TomAuger
12 years ago

  • Cc tomaugerdotcom@… added

@helenyhou
12 years ago

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

@helenyhou
12 years ago

First real pass, with ocean90. Still needs work.

#27 follow-ups: @helenyhou
12 years ago

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. :)

#28 @scribu
12 years ago

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.

#29 in reply to: ↑ 27 @SergeyBiryukov
12 years ago

Replying to helenyhou:

  • Alt text shows but doesn't actually save

Fixed in 21391.3.diff.

#30 in reply to: ↑ 27 ; follow-up: @SergeyBiryukov
12 years ago

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).

#31 in reply to: ↑ 30 @helenyhou
12 years ago

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 :)

#32 @ocean90
12 years ago

  • Cc ocean90 added

@ocean90
12 years ago

@ocean90
12 years ago

@ocean90
12 years ago

@ocean90
12 years ago

#33 @ocean90
12 years ago

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()

#34 @ocean90
11 years ago

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'.

Last edited 11 years ago by ocean90 (previous) (diff)

@ocean90
11 years ago

@ocean90
11 years ago

#35 @ocean90
11 years ago

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
Last edited 11 years ago by ocean90 (previous) (diff)

@ocean90
11 years ago

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

#36 @nacin
11 years ago

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.

#37 @nacin
11 years ago

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.

#38 @nacin
11 years ago

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

#39 follow-up: @DrewAPicture
11 years ago

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

Last edited 11 years ago by DrewAPicture (previous) (diff)

@DrewAPicture
11 years ago

Help tabs

#40 @DrewAPicture
11 years ago

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

#41 @DrewAPicture
11 years ago

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.

#42 in reply to: ↑ 39 @ocean90
11 years ago

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

Last edited 11 years ago by ocean90 (previous) (diff)

#43 @ryan
11 years ago

In [21968]:

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

#44 @batmoo
11 years ago

  • Cc batmoo@… added

#45 @aesqe
11 years ago

  • Cc aesqe@… added

#46 @DrewAPicture
11 years ago

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

#47 @ryan
11 years ago

In [22093]:

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

#49 follow-up: @scribu
11 years ago

+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.

#50 @helenyhou
11 years ago

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

#51 in reply to: ↑ 49 @Bellfalasch
11 years ago

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
11 years ago

Refresh the thumbnail

#52 @ocean90
11 years ago

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

#53 @nacin
11 years ago

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.

#54 follow-up: @ryan
11 years ago

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

@helenyhou
11 years ago

#55 in reply to: ↑ 54 @helenyhou
11 years ago

  • Keywords has-patch added

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
11 years ago

#56 @helenyhou
11 years ago

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

http://core.trac.wordpress.org/raw-attachment/ticket/21391/attachment_edit_submitbox.png

#57 @ryan
11 years ago

I like it.

#58 @husobj
11 years ago

I like it too

#59 @ryan
11 years ago

In 22364:

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

Props helenyhou
see #21391

#60 follow-up: @ryan
11 years ago

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

#61 in reply to: ↑ 60 @ocean90
11 years ago

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.

#62 follow-up: @tar.gz
11 years ago

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)?

#63 in reply to: ↑ 62 ; follow-up: @DrewAPicture
11 years ago

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.

#64 in reply to: ↑ 63 ; follow-up: @tar.gz
11 years ago

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.

#65 in reply to: ↑ 64 @DrewAPicture
11 years ago

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.

Last edited 11 years ago by DrewAPicture (previous) (diff)

#66 follow-up: @helenyhou
11 years ago

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.

#67 in reply to: ↑ 66 @tar.gz
11 years ago

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...

#68 @helenyhou
11 years ago

Related, spun off to contain the dicussion: #22491

#69 @nacin
11 years ago

  • Owner set to helenyhou
  • Status changed from new to assigned

#70 @helenyhou
11 years ago

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.

#71 @nacin
11 years ago

In 22748:

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

#72 @nacin
11 years ago

In 22749:

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

#73 follow-up: @nacin
11 years ago

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
11 years ago

#74 @helenyhou
11 years ago

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

#75 @nacin
11 years ago

In 22757:

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

#76 @nacin
11 years ago

In 22777:

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

#77 @nacin
11 years ago

In 22783:

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

#78 in reply to: ↑ 73 @nacin
11 years ago

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.

#79 @nacin
11 years ago

  • Owner changed from helenyhou to ocean90

@ocean90
11 years ago

@ocean90
11 years ago

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

#80 @ocean90
11 years ago

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

#81 @koopersmith
11 years ago

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

In 22807:

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

#82 @bootsz
11 years ago

  • Cc bootsz removed

#83 @nacin
11 years ago

In 23081:

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

#84 @wonderboymusic
11 years ago

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

#85 @audrasjb
11 months ago

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.

Note: See TracTickets for help on using tickets.