WordPress.org

Make WordPress Core

Opened 21 months ago

Closed 17 months ago

Last modified 16 months ago

#21391 closed task (blessed) (fixed)

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

Reported by: nacin Owned by: 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 21 months ago.
attachment-show-ui.diff (3.9 KB) - added by nacin 20 months ago.
Some stuff I was playing with some time ago.
attachment_editing_scratch.diff (12.3 KB) - added by helenyhou 20 months 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 20 months ago.
First real pass, with ocean90. Still needs work.
21391.3.diff (22.9 KB) - added by SergeyBiryukov 20 months ago.
21391.4.patch (22.0 KB) - added by ocean90 19 months ago.
21391.5.diff (30.4 KB) - added by ocean90 19 months ago.
21391.5.1.patch (29.2 KB) - added by ocean90 19 months ago.
21391.6.patch (28.6 KB) - added by ocean90 19 months ago.
21391.7.patch (29.5 KB) - added by ocean90 19 months ago.
plugin.php (1.3 KB) - added by ocean90 19 months ago.
21391.7.1.patch (30.0 KB) - added by ocean90 19 months 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 19 months ago.
Help tabs
21391.thumbnail-refresh.patch (2.0 KB) - added by ocean90 19 months ago.
Refresh the thumbnail
21391.4.diff (6.1 KB) - added by helenyhou 18 months ago.
21391.6.diff (5.9 KB) - added by helenyhou 18 months ago.
attachment_edit_submitbox.png (69.5 KB) - added by helenyhou 18 months ago.
21391.alt_text.diff (837 bytes) - added by helenyhou 17 months ago.
21391.7.diff (819 bytes) - added by helenyhou 17 months ago.
21391.8.patch (2.1 KB) - added by ocean90 17 months ago.
21391.8b.patch (2.1 KB) - added by ocean90 17 months ago.
Use $('#image-edit-context').length

Download all attachments as: .zip

Change History (105)

comment:1 DrewAPicture21 months ago

  • Cc xoodrew@… added

comment:2 martythornley21 months ago

  • Cc marty@… added

comment:3 scribu21 months ago

  • Cc scribu added

comment:4 DH-Shredder21 months ago

  • Cc mike.schroder@… added

comment:5 sabreuse21 months ago

  • Cc sabreuse@… added

comment:6 helenyhou21 months ago

Swoon! :)

comment:7 meliko21 months ago

  • Cc melissachoyce@… added

martythornley21 months ago

comment:8 follow-up: martythornley21 months 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 21 months ago by martythornley (previous) (diff)

comment:9 scribu21 months ago

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

comment:10 in reply to: ↑ 8 helenyhou21 months 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.

comment:11 mikeschinkel21 months ago

  • Cc mikeschinkel@… added

comment:12 kawauso21 months ago

  • Cc kawauso added

comment:13 follow-up: nacin21 months ago

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

comment:14 nacin21 months ago

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

comment:15 toscho21 months ago

  • Cc info@… added

comment:16 in reply to: ↑ 13 SergeyBiryukov21 months ago

Replying to nacin:

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

Related: #19858

comment:17 husobj21 months 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!

comment:18 simonwheatley21 months ago

  • Cc simon@… added

comment:19 bootsz21 months ago

  • Cc bootsz added

comment:20 WraithKenny21 months ago

  • Cc Ken@… added

comment:21 kieranmasterton21 months ago

  • Cc kieranmasterton added

comment:22 azizur21 months ago

  • Cc azizur added

comment:23 ChaseWiseman21 months ago

  • Cc ChaseWiseman added

comment:24 wycks21 months ago

  • Cc bob.ellison@… added

nacin20 months ago

Some stuff I was playing with some time ago.

comment:25 blobaugh20 months ago

  • Cc blobaugh added

comment:26 TomAuger20 months ago

  • Cc tomaugerdotcom@… added

helenyhou20 months ago

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

helenyhou20 months ago

First real pass, with ocean90. Still needs work.

comment:27 follow-ups: helenyhou20 months 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. :)

comment:28 scribu20 months 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.

SergeyBiryukov20 months ago

comment:29 in reply to: ↑ 27 SergeyBiryukov20 months ago

Replying to helenyhou:

  • Alt text shows but doesn't actually save

Fixed in 21391.3.diff.

comment:30 in reply to: ↑ 27 ; follow-up: SergeyBiryukov20 months 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).

comment:31 in reply to: ↑ 30 helenyhou20 months 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 :)

comment:32 ocean9020 months ago

  • Cc ocean90 added

ocean9019 months ago

ocean9019 months ago

ocean9019 months ago

ocean9019 months ago

comment:33 ocean9019 months 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()

comment:34 ocean9019 months 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 19 months ago by ocean90 (previous) (diff)

ocean9019 months ago

ocean9019 months ago

comment:35 ocean9019 months 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 19 months ago by ocean90 (previous) (diff)

ocean9019 months ago

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

comment:36 nacin19 months 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.

comment:37 nacin19 months 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.

comment:38 nacin19 months ago

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

comment:39 follow-up: DrewAPicture19 months 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 19 months ago by DrewAPicture (previous) (diff)

DrewAPicture19 months ago

Help tabs

comment:40 DrewAPicture19 months ago

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

comment:41 DrewAPicture19 months 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.

comment:42 in reply to: ↑ 39 ocean9019 months 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 19 months ago by ocean90 (previous) (diff)

comment:43 ryan19 months ago

In [21968]:

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

comment:44 batmoo19 months ago

  • Cc batmoo@… added

comment:45 aesqe19 months ago

  • Cc aesqe@… added

comment:46 DrewAPicture19 months ago

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

comment:47 ryan19 months ago

In [22093]:

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

comment:49 follow-up: scribu19 months 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.

comment:50 helenyhou19 months ago

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

comment:51 in reply to: ↑ 49 Bellfalasch19 months 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 =)

ocean9019 months ago

Refresh the thumbnail

comment:52 ocean9019 months ago

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

comment:53 nacin19 months 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.

comment:54 follow-up: ryan18 months ago

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

helenyhou18 months ago

comment:55 in reply to: ↑ 54 helenyhou18 months 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.

helenyhou18 months ago

comment:56 helenyhou18 months 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

comment:57 ryan18 months ago

I like it.

comment:58 husobj18 months ago

I like it too

comment:59 ryan18 months ago

In 22364:

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

Props helenyhou
see #21391

comment:60 follow-up: ryan17 months ago

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

comment:61 in reply to: ↑ 60 ocean9017 months 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.

comment:62 follow-up: tar.gz17 months 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)?

comment:63 in reply to: ↑ 62 ; follow-up: DrewAPicture17 months 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.

comment:64 in reply to: ↑ 63 ; follow-up: tar.gz17 months 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.

comment:65 in reply to: ↑ 64 DrewAPicture17 months 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 versionz, 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 it 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.

Version 0, edited 17 months ago by DrewAPicture (next)

comment:66 follow-up: helenyhou17 months 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.

comment:67 in reply to: ↑ 66 tar.gz17 months 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...

comment:68 helenyhou17 months ago

Related, spun off to contain the dicussion: #22491

comment:69 nacin17 months ago

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

comment:70 helenyhou17 months 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.

helenyhou17 months ago

comment:71 nacin17 months ago

In 22748:

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

comment:72 nacin17 months ago

In 22749:

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

comment:73 follow-up: nacin17 months 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.

helenyhou17 months ago

comment:74 helenyhou17 months ago

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

comment:75 nacin17 months ago

In 22757:

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

comment:76 nacin17 months ago

In 22777:

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

comment:77 nacin17 months ago

In 22783:

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

comment:78 in reply to: ↑ 73 nacin17 months 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.

comment:79 nacin17 months ago

  • Owner changed from helenyhou to ocean90

ocean9017 months ago

ocean9017 months ago

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

comment:80 ocean9017 months ago

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

comment:81 koopersmith17 months 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.

comment:82 bootsz17 months ago

  • Cc bootsz removed

comment:83 nacin17 months ago

In 23081:

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

comment:84 wonderboymusic16 months ago

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

Note: See TracTickets for help on using tickets.