[wp-trac] [WordPress Trac] #22743: Add a link to the image editor in the media modal

WordPress Trac noreply at wordpress.org
Tue Dec 4 22:26:17 UTC 2012


#22743: Add a link to the image editor in the media modal
-------------------+--------------------------
 Reporter:  nacin  |       Type:  defect (bug)
   Status:  new    |   Priority:  normal
Milestone:  3.5    |  Component:  Media
  Version:  trunk  |   Severity:  normal
 Keywords:         |
-------------------+--------------------------
 I'm a bit concerned about the potential backlash we might get for removing
 "Edit Image" from the media dialog from 3.4 to 3.5. The WordPress.com
 forums are providing brutal feedback for it. We don't really know how many
 installs have GD on them to the point where they would miss it — could be
 10%, 50%, or 90% for all I know. None of those numbers are good, though.

 I think we should probably set an early 3.6 goal (after a few weeks of
 rest) of bringing image editing to the modal. Obviously, that got punted
 from 3.5 scope early on (if it was ever truly a part of scope beyond a
 "nice if we get to it").

 In the meantime though, we should implement a stopgap. Here's a plan of
 action:
  * Add an "Edit" link next to "Delete Permanently", with target=_blank. If
 they can edit the attachment, of course.
  * Add a query running on a timeout to see if any attachments have been
 modified since X.
  * Re-load those attachments, which should refresh any changes.

 It's not perfect. It's subject to the general "race" condition of doing a
 last-modified on a timeout. (We could speed up that timeout after an
 "Edit" click, but still.) It is also subject to a deeper race condition
 where we do this:

 {{{
 $id = wp_insert_attachment($attachment, $file, $post_id);
 if ( !is_wp_error($id) ) {
         wp_update_attachment_metadata( $id,
 wp_generate_attachment_metadata( $id, $file ) );
 }
 }}}

 Aside from the fact that IIRC, wp_insert_attachment() can't actually
 return WP_Error, there is a pretty bad race condition wherein we update
 the attachment itself (and thus post_modified), and then generate and
 update the attachment metadata, which includes an image editing
 multi_resize() call, so it is fairly slow. And, since
 wp_update_attachment_metadata() only touches metadata, post_modified is
 not updated a second time after. (We could hack in a second update simply
 to bump the modified date, though.)

 That said, it's fairly easy to do. I'm attaching an admin-ajax endpoint,
 along with some sample code from Koop that will automatically refresh the
 attachments (that's the .more() call):

 {{{
 modified = wp.query( args_that_set_modified );
 setInterval( function() {
   modified.more();
 }, 30000 );
 }}}

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/22743>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list