Add image editing UI to the media modal

[koopersmith]

The media modal should contain a way to edit a given image size. This should include the capability to crop, resize, rotate, and flip (as all are currently possible).

The core of this UI should be capable to serve as both the crop step in a workflow like choosing a custom header, or in editing a given image size to include within a post.

This UI will benefit greatly from (and heavily relies upon) improvements on #21810, and should probably wait until work on that ticket is underway.

[markoheijnen]

#23564 was marked as a duplicate.

[toscho]

Especially the forced new window mentioned in #23564 is very annoying. At least this should be fixed in 3.6.

[markoheijnen]

This isn't going to be fixed in 3.6 since it is a feature. Also it does take a decent amount of time to get it working. So I would love to get it working for 3.7. And you can help out too if you want. It is easy to build a plugin around it.

[SergeyBiryukov]

#24467 was marked as a duplicate.

[SergeyBiryukov]

Related: #24573

[paaljoachim]

How are things going with this feature?

[paaljoachim]

Has anyone looked at integrating something like this into the edit media area?
​http://www.moxiemanager.com/

[markoheijnen]

I'm playing with it on ​https://github.com/markoheijnen/Improved-image-editor but I'm still looking into Backbone. Something as MoxieManager is cool but we need to have something simpel. I thing that most filters shouldn't be in core. But we do need to find a way that it can be easy added.

[tomauger]

Extending Image Editor - plugin

[tomauger]

Please see revised plugin and proof-of-concept plugin. The above files are problematic.

The above plugin (mu-plugin for now) demonstrates:
a) the difficulty in extending the current image editor (due to a few missing hooks)
b) how to refactor the current "editor group" UI boxes into a more modular format that can easily be leveraged by plugin developers.
c) how to modify the existing image-edit.js to include a simple eventing system that can be leveraged by plugin devs to, for instance, do something when the editor is invoked and ready.

I need to point out that this plugin demonstrates the length one has to go in order to be able to extend the current image editor. My intention is to submit a patch that introduces a few hooks and integrates the js changes into image-edit.js.

I will follow with a plugin that leverages this framework to show how to implement custom cropping of all the different image sizes individually.

[tomauger]

Proof-of-concept plugin demonstrating how to create individual crops for individual image sizes

[tomauger]

The proof-of-concept plugin above does the following:

1. Hooks into the proposed add_image_editor_groups hook, which is designed to function much like add_meta_boxes in edit-form-advanced.php.

2. Removes the thumbnail-settings Image Editor Group and replaces it with a new editor-target group using the proposed add_image_edit_group(), whose signature is modeled on add_meta_box().

3. The .js file leverages the proposed eventing system and registers event listeners for the new imageOpen and editorInit events so that we can run some jQuery on the UI controls within the Image Editor Group that we created.

[tomauger]

Revised plugin - no longer hooks off wp_enqueue_media

[tomauger]

Proof-of-concept demo - now runs correctly as a plugin

[tomauger]

The two revised files above can be installed as plugins and have been tested against trunk.

Needed to use another way to hook them in - opted for edit_form_after_title for lack of anything better.

I will be posting a patch shortly that eliminates nearly all of this mess and integrates the plugin concepts into the core files, with some appropriate hooks created to avoid having to duplicate large swatches of core code just to be able to extend the editor.

[tomauger]

Patch that enables extending the image editor groups. See notes below.

[tomauger]

Patch notes for trac-21811-extensible-image-editor.patch:

This patches the following core files:

• wp-admin/edit-form-advanced.php:
  • adds an action 'enqueue_image_editor_scripts' to allow plugin/theme devs a good spot to hook in their own image editor js/css.

• wp-admin/includes/image-edit.php:
  • adds add_image_edit_group() and remove_image_edit_group() to allow easy, add_meta_box-like modification of the ImgEditGroup boxes in the editor, grouped into tabs if needed / desired.
  • provides a corresponding action add_image_editor_groups for the proper place to hook into to add/remove image editor groups
  • provides an image_editor_groups filter for deeper modifications of editor groups if needed.
  • refactors all the HTML creation of the imgedit-groups used in wp_image_editor() to leverage the new way of creating these modular groups.
  • includes some tab/whitespace fixes to the HTML output of the TABLE structure, cause I'm anal that way.

• wp-admin/js/image-edit.js
  • added an addEventListener() method to the global imageEdit that allows other scripts to register against event listeners that are dispatched at specific points within the Image Editor workflow.
  • added the dispatchEvent() method that is used by imageEdit to dispatch those specific events.
  • added an events object that contains the event type constants used to identify a specific event.
  • sadly, the whole file is different because I changed the indent level of the first inner block.

I will follow this patch with a new plugin that demonstrates how to use these new features. Comments are welcome!

[tomauger]

Plugin to demonstrate how to use add_image_editor_group() and the new imageEdit.js events

[tomauger]

The plugin above requires that you do not use the minified image-edit.js if you're using my patch, since I haven't minified that script yet.

It demonstrates the following:

• using the add_image_editor_groups action as a best practice for hooking in and modifying the Image Editor groups
• using the enqueue_image_editor_scripts action as a best practice for hooking in js/css for your image editor plugin
• using remove_image_edit_group() and add_image_edit_group()
• leveraging the imageEdit INIT_EVENT and OPEN_EVENT to hook plugin js functionality into specific spots of the image editor workflow.

Currently, this plugin does not actually perform the crop since that requires another modification to wp_save_image() and I didn't want to dilute this patch, in case there was a better approach to the crop issue that I hadn't considered. I will be uploading that patch subsequently.

[tomauger]

Allows intermediate image sizes to be targeted for cropping in wp_save_image()

[tomauger]

The patch above to image-edit.php adds some code to wp_save_image() that frankly should have been in there in the first place, allowing the editor to target intermediate image sizes and pass that information along to WP_Image_Editor::multi_resize().

I'm not sure whether this is as comprehensive as what Koop was referring to when he wrote up this ticket, but it seems like a natural enhancement.

[wonderboymusic]

Any particular reason to not use Backbone here, especially for event handling?

[gcorne]

I agree with @wonderboymusic. While I think that making the image editor more flexible for plugin authors would be awesome, the goal of at least this ticket is to incorporate the image editor into the media modal, so I think it would be best if we refactored so that the image editor becomes a Backbone view that can easily be used in the modal.

In terms of functionality, I think we might want to think in terms of two basic modes:

1. An attachment editor mode where the user can edit any or all of the various intermediate sizes for an image. This mode is more or less what we have now.

2. A single image editor mode where the user is taken to a somewhat simplified UI where they are editing only one particular image size. I am thinking that this mode would make sense in for example the post editor when editing an image that has already been inserted. I am not exactly sure how it would work while still maintaining the integrity of the intermedia sizes, but I think it could be quite useful. Another situation where a single mode image editor would be useful is in header editor where it could be used inline and then in the customizer where it could be used as a state in the modal.

[gcorne]

After yesterday's discussion, I spent some time throwing together an initial implementation attachment:21811-modal-01.patch​ that incorporates the image editor functionality into the media modal. Even though this patch has some problems with it, I thought I would post it so that @tomauger and others could see what I am thinking.

The patch does the following:

1. Adds a new EditImage State and View
2. Adds the state to the existing ImageDetails and MediaFrame.Post workflows. (While writing this, I realized that I also should have added it to MediaFrame.Select.)

The whole thing sort of works, but it suggests to me that we should refactor the existing image editor code to make it more flexible. Figuring out what approach to use to add the necessary flexibility is the next step.

[tomauger]

@gcorne thanks for taking the time to put this together. I'm pretty new to Backbone, so this really helps. Does your patch have any dependencies on 21810? (Like , do I have to install a patch from #21810 first and then apply your patch)?

[gcorne]

Replying to tomauger:

@gcorne thanks for taking the time to put this together. I'm pretty new to Backbone, so this really helps. Does your patch have any dependencies on 21810? (Like , do I have to install a patch from #21810 first and then apply your patch)?

Glad that you found it useful. At this point, there aren't any dependencies on other patches.

[gcorne]

Added 21811-modal-02.patch​ which refreshes the patch and fixes a silly ReferenceError: event is not defined mistake.

[dnavarrojr]

I'd love to see the ability to set minimum image dimensions for uploads. And the possibility of extending the canvas to meet those dimensions... ie, minimum dimensions are 400x300 and a 200x225 image is uploaded, so it's placed in the middle of a white 400x300 canvas.

[paaljoachim]

What about max image size like this plugin?:
​http://wordpress.org/plugins/imsanity/

[tomauger]

Replying to dnavarrojr:

I'd love to see the ability to set minimum image dimensions for uploads. And the possibility of extending the canvas to meet those dimensions... ie, minimum dimensions are 400x300 and a 200x225 image is uploaded, so it's placed in the middle of a white 400x300 canvas.

I'm not sure that this is a good thing to enable globally - I mean, that behaviour may not always be the desired behaviour. My feeling is that this would be plugin territory, but others may have different opinions.

[tomauger]

Replying to paaljoachim:

What about max image size like this plugin?:
​http://wordpress.org/plugins/imsanity/

I like this idea a lot, but I don't feel that it's really in the scope of what this ticket is trying to accomplish. Perhaps you may wish to submit a new ticket for an enhancement, see if it gains any traction?

[tomauger]

Builds on gcorne's patch by passing in the view to imageEdit, so that we can properly close the editor and revert to the previous view.

[tomauger]

Added trac-21811-image-edit-view-01.patch which attempts to do the minimum to integrate image-edit.js into the EditImage view by passing the view itself to imageEdit.open() so we can set the previous state on the controller upon imageEdit.close().

What has me completely stumped is why setting the state to 'image-edit' in an ImageDetails View (ie: editing an embedded attachment in tinyMCE) works so well, but attempting to set the same state in the same way within an Attachment.Details view (for example, when choosing a Featured Image) fails silently.

[gcorne]

Replying to tomauger:

Added trac-21811-image-edit-view-01.patch which attempts to do the minimum to integrate image-edit.js into the EditImage view by passing the view itself to imageEdit.open() so we can set the previous state on the controller upon imageEdit.close().

What has me completely stumped is why setting the state to 'image-edit' in an ImageDetails View (ie: editing an embedded attachment in tinyMCE) works so well, but attempting to set the same state in the same way within an Attachment.Details view (for example, when choosing a Featured Image) fails silently.

In 21811-modal-03.patch​, I took your initial idea for passing a reference to the view, into imageEdit.open() and also attached _view to the object so that it could be accessed from close(). Then, I wired this up to the modal so that when clicking cancel, the user is taken to the previous state, which works pretty well. I also added crude support for the Featured Image workflow, which lives in media-editor.js and is coded a little differently. The image editing functionality was already working in the "Add Media" workflow.

While working on this, I discovered that the modals are not removed from the DOM when closed, which causes problems with the image editor because of how it uses id attributes. I will probably open a separate ticket to clean that up.

[kirasong]

21811-modal-03.patch plus enqueueing styles for imgAreaSelect.

[kirasong]

I played with this a bit. Seems like it's headed in a good direction!

An oddity that I haven't entirely tracked down yet:

If you try to crop an image by dragging on the image:

• The styles for the selection box don't show
• The selection box is created with the wrong left/top coordinates, which, with the styles enqueued, makes it ​show in the upper left rather than over the image.

I've attached a patch​ that includes the previous changes, plus enqueues the styles for imgAreaSelect, which should allow it to be easier to "See" what's going on. If I manage to track down where things are going wrong, I'll post an update.

[tomauger]

Replying to DH-Shredder:

If you try to crop an image by dragging on the image:

• The styles for the selection box don't show

I haven't noticed this, using your latest patch. Perhaps I'm missing something - but I'm seeing the "marching ants", the selection handles and the semi-opaque overlay. Was there something else?

• The selection box is created with the wrong left/top coordinates, which, with the styles enqueued, makes it ​show in the upper left rather than over the image.

So, I've tracked this down to imgareaselect.js, but I'm not sure what to do about it. At 1097/98 it traverses up the DOM from the crop wrapper element, and if it finds ANY ancestor element with position:fixed, then it sets position:fixed on all the visual elements it creates (the selection box and the opaque mask boxes). If we override this and set position:absolute on these elements, then everything works as it should.

The Media Modal itself is position:fixed, which is what's triggering the position:fixed on the other elements. I'm sure there's a good reason to set the modal to position:fixed, but I found that if I set it to position:absolute, everything still rendered as I expected. But then again, maybe it won't on another screen.

So, possible solutions:

• set .media-modal to position:absolute instead of fixed
• ? hack imgareaselect.js and remove the part that sets position:fixed.
• ?! modify image-edit.js initCrop to look for the imgareaselect UI elements and force them to position:absolute (onInit is a closure and doesn't have access to the imgareaselect scope, sadly)
• modify the way offsets are calculated to allow position:fixed to work.

I'd prefer the first option, if it IS an option, because it seems cleaner, but there's probably a good reason why the modal is position:fixed. The last option, calculating the way the image and container offsets are calculated seems interesting, but possibly, um, impossible without surgery on imgareaselect.js.

So, I'm uploading a patch that taps into initCrop and forces position:absolute on the crop UI elements. It appears to work everywhere I've tested the editor, but not sure this is the preferred approach.

[tomauger]

Addresses the position:fixed bug

[kirasong]

Replying to tomauger:

Replying to DH-Shredder:

If you try to crop an image by dragging on the image:

• The styles for the selection box don't show

I haven't noticed this, using your latest patch. Perhaps I'm missing something - but I'm seeing the "marching ants", the selection handles and the semi-opaque overlay. Was there something else?

No, that was it. That's what adding the styles (in the patch I attached) fixed.

So, I've tracked this down to imgareaselect.js, but I'm not sure what to do about it. At 1097/98 it traverses up the DOM from the crop wrapper element, and if it finds ANY ancestor element with position:fixed, then it sets position:fixed on all the visual elements it creates (the selection box and the opaque mask boxes). If we override this and set position:absolute on these elements, then everything works as it should.
--snip--
I'd prefer the first option, if it IS an option, because it seems cleaner, but there's probably a good reason why the modal is position:fixed. The last option, calculating the way the image and container offsets are calculated seems interesting, but possibly, um, impossible without surgery on imgareaselect.js.

So, I'm uploading a patch that taps into initCrop and forces position:absolute on the crop UI elements. It appears to work everywhere I've tested the editor, but not sure this is the preferred approach.

Nice find! Agreed, if we can avoid modifying imgareaselect.js, that'd also be the biggest thing for me. I don't think I understand all of the possible pitfalls of moving to absolute positioning with the modal, so I'll leave that call for someone that knows the drawbacks better.

I'll toss a few tests at the patch, in any case, and see if there's anything else that seems amiss.

[tomauger]

Replying to DH-Shredder:

I'll toss a few tests at the patch, in any case, and see if there's anything else that seems amiss.

The biggest issue I see right now with the modal implementation is what happens when you exit the modal, especially after switching to the Editor state. When the modal is reinvoked, it appears that the instance is just revived (in the Editor state) rather than reinstantiated. I think this is problematic, not just from a UX perspective, but there seems to be an issue where you get a blank (ie: empty) modal sometimes as a result.

I'll sniff around, but my understanding of our implementation of Views is spotty at best, so that issue may be above my head.

[kirasong]

Refreshed.

[kirasong]

Thanks for the refresh and update!

Did a quick test; two things noticed so far:

No Update of Image in dialog after editing via MCE:

• Insert an Image
• Click on image MCE to edit
• Click "Edit"
• Modify the image
• Save
• Notice image hasn't changed in dialog

Insert Media button doesn't insert while editing:

• Click on "Add Media"
• Select An Image
• Click "Edit Image
• Change Image
• Click "Insert Image"
• Notice image has not been inserted

[gcorne]

Replying to DH-Shredder:

No Update of Image in dialog after editing via MCE:

Thanks for giving it a spin. There is still more things to do, but I thought I would post an updated patch 21811-07.patch​ that takes care of the above issue.

[gcorne]

21811-08.patch​ starts with a refresh and fixes up the following:

• Fix the width of the right column
• Refresh the attachment model when either scaling or restoring the original image
• Modify the modal toolbar to include a back button that takes the user to the previous state.

One known issue is that when selecting an image from the Featured Image mode by click "Set Featured Image" and then saving the edit, the selection is lost.

There are also is some awkwardness UX-wise when editing an image that has been inserted into a post at a thumbnail size, but I think that is really a problem with the preview in the Image Details modal not being based on the selected image size.

[helen]

In 27445:

At long last, a first pass at bringing the image editor into the media modal. props gcorne, DH-Shredder, tomauger. see #21811.

[iseulde]

Why not have one button row instead of two? I think that's confusing. Maybe just have two buttons "Cancel" and "Save" at the bottom? Both of those take you back, so the "Back" button is not really necessary.

[ungestaltbar]

The latest patch (21811-08.patch) broke wp_enqueue_media on the frontend, because the new dependency 'image-edit' for 'media-views' is only registered if is_admin() equals true.

Moving ->add('image-edit') out of the admin condition at least makes things load and setup properly again.

[tomauger]

@ungestaltbar thanks for the report. I'll look into it tonight if someone doesn't get to it sooner.

[helen]

Replying to avryl:

Why not have one button row instead of two? I think that's confusing. Maybe just have two buttons "Cancel" and "Save" at the bottom? Both of those take you back, so the "Back" button is not really necessary.

Seems reasonable to me to put the save button down there instead of back. I wonder if it should be more like gallery creation and also change the sidebar and put the back link there instead.

[gcorne]

Replying to helen:

Replying to avryl:

Why not have one button row instead of two? I think that's confusing. Maybe just have two buttons "Cancel" and "Save" at the bottom? Both of those take you back, so the "Back" button is not really necessary.

Seems reasonable to me to put the save button down there instead of back. I wonder if it should be more like gallery creation and also change the sidebar and put the back link there instead.

I had a version that had "Save" and "Cancel" buttons in the media modal toolbar area, but unfortunately that didn't work well for the scale and restore original functions, which have their own submit buttons that manipulate the image. Maybe we need to rethinking the UX of the image editor in general?

[tomauger]

Replying to gcorne:

Maybe we need to rethinking the UX of the image editor in general?

Yes, I'm feeling that UX/UI of the image editor should go into a new ticket as well. I'd rather see this ticket stay focused on mopping up any bugs with the backbone / modal integration.

[tomauger]

Moved image-edit script out of is_admin() section. Also moved media and set-post-thumbnail

[tomauger]

In 21811-09-27473-load-scripts.patch, moved 'image-edit' script registration out of the is_admin() section, so it would be available to the front end, since it's a dependency of media-views, which is already available in the front end.

For good measure, also moved 'media' and 'set-post-thumbnail', since they will be needed by front end editors as well.

Tested in twenty-fourteen with ​WP Front End Editor plugin and some really snappy pictures of Lotus Elises.

[iseulde]

#27372 was marked as a duplicate.

[iseulde]

"Add Media Button of wp_editor() is no more working on front-end since r27445" (#27372) by imath:

Hi,

First, i'd like to congratulate you for the great features introduced in the Media Editor in 3.9 next release.

I've noticed #21811 makes it possible to edit image directly in the Media Editor, which is great :)
Unfortunately, there seems to be an annoying side effect when the wp_editor() is used on front-end or if a plugin uses wp_enqueue_media() on front-end which is my case...
Clicking on the "Add Media" button no more opens the Media Editor since [27445].

I've seen @tomauger in his comment suggested a patch to fix it. It brings back the Media Editor but clicking on the "Edit image" link of the Media details side box loads the Image Edit view without the toolbar. So it's not usable. The problem seems to be that this part needs a css file that is included in the wp-admin one.
I guess it's one good reason to have the is_admin() check before enqueueing image-edit.

On my local dev, i've built an alternative patch which seems to solve the side effect. So i thought you might be interested by it. I hope i didn't do wrong by creating a new ticket instead of carrying on the discussion in the original ticket. If i did, i apologise.

27372.diff​

[iseulde]

Ideally these scripts should also be moved to wp-includes/js and css that applies to the media modal to wp-includes/css/media-views.css.

[iseulde]

So what shall it be for the front-end? Add the dependencies or remove the image editing part? I've temporarily added the dependencies to the front-end editor plugin to prevent breakage.
And, btw, media and set-post-thumbnail are not used by the modal or the front-end. media is for the Media Library in wp-admin/upload.php.

[tomauger]

Replying to avryl:

So what shall it be for the front-end? Add the dependencies or remove the image editing part?

It was suggested by nacin that the modal be removed entirely from the front-end for now (keeping ImageEdit as it was in 3.8) until the modal implementation settled down. This should solve any dependency issues for front-end editor for the time being.

[gcorne]

21811-10.patch​ only enqueues the image editor script if the request is an is_admin() request. The behavior of "Edit Image" switches back to the 3.8 behavior everywhere except the Image Details view, which just doesn't include the button.

[nacin]

In 27625:

Only enqueue the image editor in the media modal in the admin.

props gcorne.
see #21811.

[gcorne]

21811-11.patch​ fixes an issue where the model data was not being refreshed after restoring the original image or rescaling the image.

[azaozz]

In 27644:

Editing image file: properly refresh the view after restoring the original image or rescaling the image. Props gcorne, see #21811

[helen]

Looking good. New tickets for any new issues, please. And so happy to have that jank smoothed out.

[nacin]

In 27712:

Don't allow the image editor thumbnail to be dragged. see #21811.