[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