WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 3 years ago

Last modified 3 years ago

#21811 closed task (blessed) (fixed)

Add image editing UI to the media modal

Reported by: koopersmith Owned by:
Milestone: 3.9 Priority: normal
Severity: normal Version: 3.5
Component: Media Keywords: dev-feedback has-patch reporter-feedback
Focuses: Cc:

Description

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.

Attachments (20)

ExtensibleImageEditor.zip (11.5 KB) - added by tomauger 4 years ago.
Extending Image Editor - plugin
ZG_Enhanced_Image_Editor.zip (6.3 KB) - added by tomauger 4 years ago.
Proof-of-concept plugin demonstrating how to create individual crops for individual image sizes
ExtensibleImageEditor_plugin.zip (11.6 KB) - added by tomauger 4 years ago.
Revised plugin - no longer hooks off wp_enqueue_media
EnhancedImageEditorDemo_plugin.zip (4.2 KB) - added by tomauger 4 years ago.
Proof-of-concept demo - now runs correctly as a plugin
trac-21811-extensible-image-editor.patch (58.5 KB) - added by tomauger 4 years ago.
Patch that enables extending the image editor groups. See notes below.
21811-enhanced-editor-demo.zip (4.4 KB) - added by tomauger 4 years ago.
Plugin to demonstrate how to use add_image_editor_group() and the new imageEdit.js events
trac-21811-image-edit-intermediate-crop-sizes.patch (25.6 KB) - added by tomauger 4 years ago.
Allows intermediate image sizes to be targeted for cropping in wp_save_image()
21811-modal-01.patch (7.4 KB) - added by gcorne 4 years ago.
21811-modal-02.patch (7.4 KB) - added by gcorne 4 years ago.
trac-21811-image-edit-view-01.patch (8.7 KB) - added by tomauger 4 years ago.
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.
21811-modal-03.patch (10.6 KB) - added by gcorne 4 years ago.
21811-modal-04.patch (10.8 KB) - added by mikeschroder 3 years ago.
21811-modal-03.patch plus enqueueing styles for imgAreaSelect.
21811-modal-05.patch (11.4 KB) - added by tomauger 3 years ago.
Addresses the position:fixed bug
21811-modal-05-refresh.patch (11.3 KB) - added by mikeschroder 3 years ago.
Refreshed.
21811-modal-06.patch (17.3 KB) - added by gcorne 3 years ago.
21811-07.patch (17.7 KB) - added by gcorne 3 years ago.
21811-08.patch (19.2 KB) - added by gcorne 3 years ago.
21811-09-27473-load-scripts.patch (3.0 KB) - added by tomauger 3 years ago.
Moved image-edit script out of is_admin() section. Also moved media and set-post-thumbnail
21811-10.patch (3.2 KB) - added by gcorne 3 years ago.
21811-11.patch (485 bytes) - added by gcorne 3 years ago.

Download all attachments as: .zip

Change History (98)

#1 @ocean90
5 years ago

  • Cc ocean90 added

#2 @JerrySarcastic
5 years ago

  • Cc fittingsites@… added

#3 @sabreuse
5 years ago

  • Cc sabreuse added

#4 @lessbloat
5 years ago

  • Cc dave@… added

#5 @nacin
5 years ago

  • Milestone changed from 3.5 to Future Release
  • Type changed from task (blessed) to feature request

#6 @markoheijnen
4 years ago

#23564 was marked as a duplicate.

#7 @toscho
4 years ago

  • Cc info@… added

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

#8 @markoheijnen
4 years ago

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.

#9 @SergeyBiryukov
4 years ago

#24467 was marked as a duplicate.

#11 @adamsilverstein
4 years ago

  • Cc adamsilverstein@… added

#12 @paaljoachim
4 years ago

How are things going with this feature?

#13 @paaljoachim
4 years ago

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

#14 @markoheijnen
4 years ago

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.

#15 @buffler
4 years ago

  • Cc jeremy.buller@… added

#16 @dnaber-de
4 years ago

  • Cc kontakt@… added

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


4 years ago

@tomauger
4 years ago

Extending Image Editor - plugin

#18 @tomauger
4 years ago

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.

Last edited 4 years ago by tomauger (previous) (diff)

@tomauger
4 years ago

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

#19 @tomauger
4 years ago

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.
  1. 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().
  1. 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
4 years ago

Revised plugin - no longer hooks off wp_enqueue_media

@tomauger
4 years ago

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

#20 @tomauger
4 years ago

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.

This ticket was mentioned in IRC in #wordpress-dev by TomAuger. View the logs.


4 years ago

@tomauger
4 years ago

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

#22 @tomauger
4 years ago

  • Keywords has-patch added

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

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

#23 @tomauger
4 years ago

  • Keywords dev-feedback added

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

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

#24 @tomauger
4 years ago

  • Keywords needs-testing added

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.

#25 @wonderboymusic
4 years ago

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

#26 @gcorne
4 years ago

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

This ticket was mentioned in IRC in #wordpress-ui by helen. View the logs.


4 years ago

#28 @gcorne
4 years ago

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.

#29 @gcorne
4 years ago

  • Milestone changed from Future Release to 3.9

This ticket was mentioned in IRC in #wordpress-dev by gcorne. View the logs.


4 years ago

#31 follow-up: @tomauger
4 years ago

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

#32 in reply to: ↑ 31 @gcorne
4 years ago

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.

This ticket was mentioned in IRC in #wordpress-dev by TomAuger. View the logs.


4 years ago

#34 @gcorne
4 years ago

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

This ticket was mentioned in IRC in #wordpress-ui by TomAuger. View the logs.


4 years ago

#36 follow-up: @dnavarrojr
4 years ago

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.

#37 follow-up: @paaljoachim
4 years ago

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

#38 in reply to: ↑ 36 @tomauger
4 years ago

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.

#39 in reply to: ↑ 37 @tomauger
4 years ago

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

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.

#40 follow-up: @tomauger
4 years ago

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.

#41 @tomauger
4 years ago

  • Keywords needs-testing removed

This ticket was mentioned in IRC in #wordpress-dev by TomAuger. View the logs.


4 years ago

#43 in reply to: ↑ 40 @gcorne
4 years ago

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.

@mikeschroder
3 years ago

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

#44 follow-up: @mikeschroder
3 years ago

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.

This ticket was mentioned in IRC in #wordpress-dev by TomAuger. View the logs.


3 years ago

#46 in reply to: ↑ 44 ; follow-up: @tomauger
3 years ago

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

Addresses the position:fixed bug

#47 in reply to: ↑ 46 ; follow-up: @mikeschroder
3 years ago

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.

#48 in reply to: ↑ 47 @tomauger
3 years ago

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.

@mikeschroder
3 years ago

Refreshed.

This ticket was mentioned in IRC in #wordpress-dev by DH-Shredder. View the logs.


3 years ago

#50 follow-up: @mikeschroder
3 years ago

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

@gcorne
3 years ago

#51 in reply to: ↑ 50 @gcorne
3 years ago

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.

#52 @nacin
3 years ago

  • Type changed from feature request to task (blessed)

This ticket was mentioned in IRC in #wordpress-dev by gcorne. View the logs.


3 years ago

#54 @ericlewis
3 years ago

  • Keywords needs-refresh added

@gcorne
3 years ago

#55 @gcorne
3 years ago

  • Keywords needs-refresh removed

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.

This ticket was mentioned in IRC in #wordpress-dev by gcorne. View the logs.


3 years ago

#57 @helen
3 years ago

In 27445:

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

#58 follow-up: @iseulde
3 years ago

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.

#59 @ungestaltbar
3 years ago

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.

#60 @tomauger
3 years ago

  • Keywords has-patch removed

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

#61 in reply to: ↑ 58 ; follow-up: @helen
3 years ago

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.

#62 in reply to: ↑ 61 ; follow-up: @gcorne
3 years ago

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?

#63 in reply to: ↑ 62 @tomauger
3 years ago

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

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

#64 @tomauger
3 years ago

  • Keywords has-patch reporter-feedback added

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.

#65 @iseulde
3 years ago

#27372 was marked as a duplicate.

#66 @iseulde
3 years ago

"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

#67 @iseulde
3 years ago

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.

This ticket was mentioned in IRC in #wordpress-dev by TomAuger. View the logs.


3 years ago

#69 follow-up: @iseulde
3 years ago

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.

#70 in reply to: ↑ 69 @tomauger
3 years ago

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

#71 @gcorne
3 years ago

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.

This ticket was mentioned in IRC in #wordpress-dev by gcorne. View the logs.


3 years ago

#73 @nacin
3 years ago

In 27625:

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

props gcorne.
see #21811.

@gcorne
3 years ago

#74 @gcorne
3 years ago

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

#75 @azaozz
3 years ago

In 27644:

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

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


3 years ago

#77 @helen
3 years ago

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

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

#78 @nacin
3 years ago

In 27712:

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

Note: See TracTickets for help on using tickets.