WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 9 months ago

#29606 assigned defect (bug)

Reorder images via drag and drop is not working in WP 4

Reported by: gsarig Owned by: adamsilverstein
Milestone: Future Release Priority: normal
Severity: normal Version: 4.0
Component: Gallery Keywords: has-patch reporter-feedback close needs-testing
Focuses: ui Cc:

Description

When I create a gallery and then try to reorder the images via drag and drop, it does nothing. In WordPress 3.9 it was working, but not in WP 4.

I have tried this with Firefox in a fresh WP installation with no plugins, using both twenty-fourteen and _s theme.

Attachments (3)

Image 1.png (518.2 KB) - added by gsarig 3 years ago.
screenshot of the "edit gallery" screen
29606.patch (595 bytes) - added by iseulde 3 years ago.
29606.2.patch (1.2 KB) - added by azaozz 3 years ago.

Download all attachments as: .zip

Change History (65)

@gsarig
3 years ago

screenshot of the "edit gallery" screen

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


3 years ago

#2 @helen
3 years ago

  • Keywords reporter-feedback added
  • Milestone changed from Awaiting Review to 4.0.1

The upper one works for me, but sometimes doesn't make the space for the drop. It feels extremely finicky, much more so than previously. The lower one doesn't seem to work at all. Moving to 4.0.1 for investigation - have a feeling it has to do with how whitespace is created now. Possibly related: #29483.

gsarig - when you say it "does nothing", are you referring to dragging, dropping, or how it affects insertion/update?

#3 @sathishn
3 years ago

When the images are dragged horizontally(in the same line as the row) dropping is not working. Space is not created for the image to be dropped. If the image is moved a little below the actual position then the space is created for dropping.

#4 @gsarig
3 years ago

Helen - It creates the gallery all right and I can also remove an image, but I cannot reposition the images with drag and drop anymore.

At first I thought it was some plugin or some code in my custom themes, but I tried with several websites with no luck. Then I tested it in localhost, with a fresh WP4 install and same results. Finally, I thought that it might be some issue with Firefox and some addon and tested it with Chrome too - same results.

Forgot to mention that I use Windows 8.1.

edit: in my case no workarounds like those sathishn mentions seem to have any result.

Last edited 3 years ago by gsarig (previous) (diff)

#5 @markjaquith
3 years ago

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

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


3 years ago

#7 @ericlewis
3 years ago

I *think* this has to do with CSS somewhere nested inside the li.attachment, having played with devtools and deleting child nodes, and getting it working with just content inside li.attachment.

I'd guess something related to positioning/box model.

#8 @helen
3 years ago

Still suspect that the twitchy drag and drop may have to do with the usage of padding instead of margin now.

#9 @TheNightRider
3 years ago

Drag & drop gallery image reordering is also not working in Firefox 32.0.3 under MacOS X v10.6.8. Was working in WP 3.9.2. Tested with my normal Firefox plugin and extension set, then with all plugins and all extensions disabled. Works fine in Chrome 37.0.2062.124 (with my normal plugin and extension set).

Specific behavior: while editing a gallery, clicking on an image produces no "move" cursor and no movement by dragging is possible. Do see the rectangular blue highlight around the image. Tried clicking all around, but found no click zone to produce the "move" cursor. Repeatable. Fresh copy of WP 4.0. No plugins. Just in case, tested with several different themes, including Twenty Twelve, and no difference.

#10 @ericlewis
3 years ago

  • Keywords needs-patch added

This was introduced by r29376. Still can't tell what exactly did it. cc @azozz @avryl

#11 @iseulde
3 years ago

Yes, r29376 somehow broke the drag and drop for the smaller thumbnails on the bottom. But the main thumbnails are droppable, and it seems to be just as difficult as before to do so (even thought they're much larger).

I'll try to figure out what's wrong with the bottom ones. I actually never noticed you could rearrange the images there.

#12 @iseulde
3 years ago

Looks like the problem is related to horizontal dragging. Even for the bigger thumbnails, if you move the thumbnail horizontally without moving a pixel up or down, the other thumbnails don't make space.

#13 @iseulde
3 years ago

  • Keywords reporter-feedback removed

So what we could do is setting a margin around the smaller thumbnails, instead of the padding around .thumbnail further down the list item. For the bottom ones it does not matter anyway, since the width is fixed to 40/48px. However, that doesn't fix it for the bigger thumbnails. The thumbnails are contained in the ul element so you can't move the ones on the first row up if the thumbnails have no margin. The margin from pre-4.0 was removed so that we could use percentages for the width of them. So another thing we could do is using the parent of ul for containment. Let me make two patches. Other ideas are welcome. :)

#14 @iseulde
3 years ago

This really looks like a bug in jQuery UI though.

@iseulde
3 years ago

@azaozz
3 years ago

#15 @azaozz
3 years ago

  • Keywords has-patch 2nd-opinion added; needs-patch removed

In addition to 29606.patch removing the containment makes it easier/possible to arrange both the big and the small (bottom row) thumbnails, 29606.2.patch.

However not sure why the bottom row thumbnails are draggable in the first place. Usually only the first 7-8 are visible (11-12 on bigger screens) so pre-arranging a gallery while selecting more than a few images doesn't work anyway. Furthermore arranging the big thumbnails on the next step works better.

Thinking we should remove UI Sortable from the bottom row of thumbnails (not in a dot release though).

Last edited 3 years ago by azaozz (previous) (diff)

#16 @iseulde
3 years ago

Yeah the bottom should be horizontally scrollable. But I also think we should disable the sorting.

#17 @azaozz
3 years ago

  • Keywords fixed-major commit added; 2nd-opinion removed

In [29876]

Media modal: fix reordering of the thumbnails while creating or editing a gallery, props avryl, fixes #29606 for trunk.

#18 @bduclos
3 years ago

Testing on a Touch Screen PC / Chrome, the patch doesn't solve the issue.

#19 @jorbin
3 years ago

https://www.youtube.com/watch?v=8Wgb7px9t7E&feature=youtu.be

I tested backporting this fix to the 4.0 branch and it doesn't fix the issue. Above video was made with chrome 38.

#20 @nacin
3 years ago

  • Keywords needs-patch added; fixed-major has-patch commit removed

#21 @earnjam
3 years ago

After a bunch of testing, this looks like a jQuery UI Sortable bug specific to the last element in a row using % widths and it only occurs at specific containing element widths. It's miscalculating the location and thinking the item is actually on the next row...probably due to some type of rounding up.

I found lots of things that appeared to fix it, but ultimately each was specific to individual container sizes/column sizes.

Did a JSFiddle to eliminate all the other CSS from the admin and still could easily replicate: http://jsfiddle.net/Ln9pzgra/

#22 @nacin
3 years ago

  • Milestone changed from 4.0.1 to 4.1

#23 @helen
3 years ago

What do we need to do here?

#24 @earnjam
3 years ago

Other than patch jQuery UI Sortable, I'm not sure what can be done. It's miscalculating the location of floated elements with % width by rounding up the computed width, which forces the item onto the next row.

I suppose there could be some javascript hack to force it to be correct, but that doesn't seem like a good solution.

#25 @azaozz
3 years ago

  • Milestone changed from 4.1 to Future Release

Seems best is to wait for upstream fix.

#26 @afercia
3 years ago

is this happening just in Chrome? Sorry I can't reproduce but I had some fights with similar issues in the past. If the culprit is really the difference between the CSS computed width in Chrome and the width value that jQuery UI actually uses (didn't look into that) maybe there's something easy to try.
Chrome does sub-pixel roundings, testing on my machine the relevant values are:

.attachments (6 attachments per row)
computed width: 1104px;

.attachment
width: 16.66%;
padding: 8px;
box-sizing: border-box;
Chrome computed width: 183.921875px;
(just for reference, in Firefox is : 183.917px)

.attachment-preview
.thumbnail
Chrome computed width: 167.921875px;
(Firefox: 167.917px)

And the following works just in Chrome: setting display: table on .attachment

.attachment
the computed width becomes: 183px;

.attachment-preview
.thumbnail
the computed width becomes: 167px;

which hopefully will help jQuery UI.

That's because Chrome will use the table sizing algorithms (no more roundings).

#27 @mrjarbenne
3 years ago

I'm seeing this on Mobile Safari (iOS) still in 4.2.1. It seems to be solved on desktop (on Firefox and Chrome on OSX at least).

#28 @gsarig
3 years ago

Is there any chance that it has something to do with the device's screen resolution? In my case, it doesn't work on my Surface Pro 2 which has 208 ppi density but it puzzled me when I saw that it worked fine on a client's old laptop. I also tested it on a 2009 Macbook pro and it works fine with both Firefox and Safari.

On the contrary, on my Surface Pro 2 it won't work no matter the browser. Also, Chrome console says

"Consider using 'dppx' units, as in CSS 'dpi' means dots-per-CSS-inch, not dots-per-physical-inch, so does not correspond to the actual 'dpi' of a screen. In media query expression: print, (-webkit-min-device-pixel-ratio: 1.25), (min-resolution: 120dpi)"

Last edited 3 years ago by gsarig (previous) (diff)

#29 @TheNightRider
3 years ago

It was never an issue for Chrome on my system, but it's still broken for Firefox 38.0.1 under WP 4.2.2. I'm still on Mac OS X 10.6.8.

I also tried on Mobile Safari under iOS 8.3, and no rearrangement is possible, but did it ever work on touch devices?

Last edited 3 years ago by TheNightRider (previous) (diff)

#30 @zerodegreeburn
3 years ago

I think this is a HiDPi/retina issue at least on Windows 8.1. I've tested on my Acer Aspire S7-392 laptop, which is Windows 8.1 with a HiDPi screen. The drag and drop reordering of thubnails inside the gallery does not work in the latest versions of Chrome, Firefox, Opera or Vivaldi. It does work in IE11, but not via touch only with a mouse pointer.

I use a scaling option of 144% with the laptop. I tested it out with no scaling applied (Control Panel -> Display -> 100% (smallest) and it made no difference.

#31 @earnjam
3 years ago

I'm able to re-create the issue on both retina and non-retina displays in all browsers, however the problem is dependent on the window size and typically when you see it, if you resize the window larger or smaller, the issue goes away. The container sizes where the issue occurs varies between browser and screen type. This explains why some people see it and others do not.

As I noted above (https://core.trac.wordpress.org/ticket/29606#comment:21), the problem can be seen when just using some very basic % width floated elements and jQuery UI Sortable.

Sortable appears to round the calculated % widths when generating the placeholder and the dragged item because it needs a specific pixel width for the absolute positioning. Sometimes it gets rounded too large for the space available, so the browser then calculates the floated item as being on the next row.

I think the solution is that Sortable probably needs more precise rounding, or perhaps to simply always round down, when calculating the current width of a floated element with a percentage width.

#32 @ManuelRazzari
3 years ago

This also happens in WP 4.2.2 with the "Uploaded to this post" option.
The drag simply does not start, as if the LI wasn't draggable at all.

This is Firefox 38 on Win 2k3.

Chrome 43 on Win works fine. Firefox in Ubuntu works fine too.

#33 @opticsugarmedia
2 years ago

Any idea when this will be fixed? Running WP 4.3 and Chrome 45.0.2454.85 m (64-bit) on Windows 8.1.

#34 @AJD
2 years ago

I'm having this problem in WP 4.3 ; Fire Fox 40.0.3. Drag and drop media files in a gallery does not work at any screen size.
However, it does work in Chrome Version 47.0.2507.0 canary (64-bit.

Last edited 2 years ago by AJD (previous) (diff)

#35 @kirashi
2 years ago

  • Keywords ui-feedback dev-feedback added

Can confirm drag and drop re-ordering is not working on Wordpress 4.3.1 using Chrome Canary Version 48.0.2561.0 canary (64-bit)

#36 @ericlewis
2 years ago

  • Owner ericandrewlewis deleted

#37 follow-up: @DarcPress
19 months ago

Can confirm still error on WordPress 4.5.2 using Chrome Version 51.0.2704.84 m (64-bit)

#38 in reply to: ↑ 37 @elusiveunit
19 months ago

Replying to DarcPress:

Can confirm still error on WordPress 4.5.2 using Chrome Version 51.0.2704.84 m (64-bit)

+1. A client currently has this problem on Chrome 51, Windows 10. Me and two coworkers have tried reproducing on a number of browsers without success (OSX: FF, Chrome, Safari. Windows 10: Chrome, IE11, Edge). Client doesn't have the problem on Edge.

#39 @andru.bonus
19 months ago

Can't drag'n'drop images in gallery too.
Problem in Chrome 51.0.2704.106 m / WP 4.5.3 / Windows 10 (64)

While in Firefox 38.4.0 it works fine on the same system.

#40 follow-ups: @afercia
19 months ago

Just a thought, since it seems this can't be consistently reproduced, maybe it depends on the screen size/resolution and browser's rounding. Would be interesting to know if all the people who can reproduce this issue have screens with the same resolution.

#41 in reply to: ↑ 40 @andru.bonus
19 months ago

1920*1080

Replying to afercia:

Just a thought, since it seems this can't be consistently reproduced, maybe it depends on the screen size/resolution and browser's rounding. Would be interesting to know if all the people who can reproduce this issue have screens with the same resolution.

#42 @ManuelRazzari
19 months ago

I've tested a bunch of different resolutions, and it doesn't seem to be related.

I haven't been able to further debug this but, just in case it rings any bells, the UL for the thumbs has a class ui-sortable that changes to ui-sortable-disabled when you change the #media-attachment-filters dropdown. (Screenshot https://i.imgur.com/QfpxIOV.png)

In Firefox, this ui-sortable class isn't being set at all. Actually - the UL is left unchanged when you change from "images" to "uploaded to this post".

#43 @afercia
19 months ago

Hm, the #media-attachment-filters select is available in the "Create Gallery" view where, as far as I can tell, the attachments are not intended to be draggable.

https://cldup.com/SXovM71ZWt.jpg

By the way, as soon as I choose to see only the attachments "uploaded to this post" or the "unattached" ones, the CSS class ui-sortable-disabled gets removed and the attachments become draggable. To me, this doesn't seem to be the intended behaviour. I don't see why "uploaded to this post" or "unattached" attachments should be draggable so this is probably a bug.

As far as I can tell the only place where attachments should be draggable is in the "Edit Gallery" view that appears after clicking on the "Create a new gallery" button, see screenshot below:

https://cldup.com/728u1xQjBQ.jpg

This is probably a bit confusing so, are we all speaking about the same view? :) Does anyone is unable to drag attachments in the "Edit Gallery" view?

#44 follow-up: @ManuelRazzari
19 months ago

I don't see why "uploaded to this post" or "unattached" attachments should be draggable so this is probably a bug.

It's not too useful in "Create gallery", but it's not a bug.

The critical thing is that #media-attachment-filters is also available in the main "Insert Media" view.

Here's where sorting items is super useful - for example to generate a list or gallery of a post's attachments automatically, based on their sort order. (That is, you use this view as an attachment order admin, rather than to actually insert media to the post.)

As far as I can tell the only place where attachments should be draggable is in the "Edit Gallery" view that appears after clicking on the "Create a new gallery" button

FWIW, it doesn't work in this view either.

#45 in reply to: ↑ 44 ; follow-up: @afercia
19 months ago

Replying to ManuelRazzari:

I don't see why "uploaded to this post" or "unattached" attachments should be draggable so this is probably a bug.

It's not too useful in "Create gallery", but it's not a bug.

It is indeed, since when you use the "all images" filter the attachments are not draggable.

As far as I can tell the only place where attachments should be draggable is in the "Edit Gallery" view that appears after clicking on the "Create a new gallery" button

FWIW, it doesn't work in this view either.

It works for me, and for many others. This is one of the main points of this ticket: can't be reproduced consistently.

#46 in reply to: ↑ 40 ; follow-up: @earnjam
19 months ago

Replying to afercia:

Just a thought, since it seems this can't be consistently reproduced, maybe it depends on the screen size/resolution and browser's rounding. Would be interesting to know if all the people who can reproduce this issue have screens with the same resolution.

I've been able to reproduce at various viewport sizes on multiple monitors of varying pixel density in Chrome, Safari and Firefox. It's a general issue with the way jQuery UI uses a fixed width for the placeholder. I think it needs to be fixed upstream as it just needs to be smarter about calculating the size.

See https://bugs.jqueryui.com/ticket/11517

#47 in reply to: ↑ 45 @ManuelRazzari
19 months ago

Replying to afercia:

I don't see why "uploaded to this post" or "unattached" attachments should be draggable so this is probably a bug.

It's not too useful in "Create gallery", but it's not a bug.

It is indeed, since when you use the "all images" filter the attachments are not draggable.

I can see it's debatable whether in the "create gallery" context this is a bug or a feature.
We can list the pros and cons, but it's not important. It's even a separate ticket.

As far as I can tell the only place where attachments should be draggable is in the "Edit Gallery" view that appears after clicking on the "Create a new gallery" button

This is wrong. This bug is also a serious issue in the main "Insert Media" view. In that view, attachments should be draggable for "Uploaded to this post" files.

To give you some context as to why this isn't a bigger deal for a lot of people: there is no affordance in the UI about this items being draggable! No move cursor, no help text, etc.

This is even more of an issue for people that already know about the feature, in particular those coming from older WP where there was a visible drag cursor and an order field.

http://i.imgur.com/fDbJgLr.png

Either way, the "Uploaded to this post" filter in the media modal is the only UI provided by WP for users to alter the menu_order of attachments within a post. So it has to work.

It works for me, and for many others. This is one of the main points of this ticket: can't be reproduced consistently.

It can be reproduced consistently, just not by everyone ;)
It would be great if one of us who can repro can debug this a bit.
I'm under a deadline right now, but will give it a try as soon as I can.

Last edited 19 months ago by ManuelRazzari (previous) (diff)

#48 in reply to: ↑ 46 @ManuelRazzari
19 months ago

Replying to earnjam and everyone, just to clarify RE:

It's a general issue with the way jQuery UI uses a fixed width for the placeholder. [...]
See https://bugs.jqueryui.com/ticket/11517

Yes, that is a bug in jQuery UI, and I can repro both in WP and in the JSFiddle demo in the ticket you've linked to. But that bug is about clunky drag and drop behavior.

Somehow this ticket got sidetracked. If you go back to the original report by @gsarig, this ticket is about drag and drop not working at all.

Like I said the ui-draggable hook simply isn't there.

#49 @snowboardmommy
19 months ago

I would like to +1 that under WP 4.5.x + multisite this still appears to be an issue on iPads and probably iPhones too. A customer just reported it to me and I had to tell her that, if she only has access on her iPad, she has to remove all the photos from the gallery and then, one by one, individually add them back in in the order she wants them in (which was really not a lot of fun giving that as a "solution").

Drag and drop to reorder media files in Galleries (Edit Gallery screen) is not working on the iPad, which of course, most of my clients use to manage their websites anymore.

I don't know what other issues have gotten mixed up in this bug report, but it does appear that on the Edit Gallery screen, drag and drop to reorder media files is still not fixed for Safari / iOS. Thanks

#50 @programmin
18 months ago

Like @bduclos and @andru.bonus I can also confirm rearranging a gallery seems to not work at all on a Win10 touch-screen laptop with Chrome. Firefox/Edge ok.

I tried in two different themes. Does the touch-screen case need a new ticket created for it?

#51 @madis
17 months ago

Confirming: cannot reorder gallery items under Win 10, Chrome 53.0.2785.89 m using WordPress 4.6. Disabled all the plugins and tried with different monitors as well - still the same.

Rearranging works with Internet Explorer 11.

Last edited 17 months ago by madis (previous) (diff)

#52 @bhoudek
16 months ago

I can confirm this is an issue with Google Chrome. No issues in Firefox.

#53 @karmatosed
16 months ago

  • Keywords ui-feedback removed

As this is a bug, not sure it needs ui-feedback, so for now removing.

#54 @adamsilverstein
16 months ago

  • Keywords has-patch reporter-feedback needs-testing added; needs-patch removed
  • Owner set to adamsilverstein

Related: #31652

@gsarig @madis @programmin @snowboardmommy @earnjam @andru.bonus - I believe I tracked down the issue here to a general flaw in the way we enqueue "Touch Punch" - the jQuery library we use to make jQuery UI draggable/sortable work on touch devices. Our logic was flawed and was only enqueueing the script correctly on certain devices and definitely not on browsers like chrome on desktop windows with touch screen.

Can you please test the final patch on that ticket - https://core.trac.wordpress.org/attachment/ticket/31652/31652.2.diff and let me know if it resolves the sortable functionality on your devices? Also can you please mention the physical device your are testing on and specifically whether it is a touch screen device as this seems to be the root of the issue.

Thanks!

#55 follow-ups: @adamsilverstein
15 months ago

  • Keywords close added; dev-feedback removed

@gsarig Pretty sure this issue is fixed with the commits on #31652, can you please re-test?

#56 in reply to: ↑ 55 @gsarig
15 months ago

Replying to adamsilverstein:

@gsarig Pretty sure this issue is fixed with the commits on #31652, can you please re-test?

On my device (Surface Pro 2) it works fine with WordPress 4.6.1

#57 in reply to: ↑ 55 ; follow-up: @DarcPress
15 months ago

Replying to adamsilverstein:

@gsarig Pretty sure this issue is fixed with the commits on #31652, can you please re-test?

On Lenovo Yoga 2 Pro (Touch device) and I still can't move the image. The specs are WP 4.6.1, PHP 5.6, and Chrome 54.0.2840.71 m (64-bit).

The problem is there with both mouse and touch.

#58 in reply to: ↑ 57 ; follow-up: @gsarig
15 months ago

Replying to DarcPress:

Replying to adamsilverstein:

@gsarig Pretty sure this issue is fixed with the commits on #31652, can you please re-test?

On Lenovo Yoga 2 Pro (Touch device) and I still can't move the image. The specs are WP 4.6.1, PHP 5.6, and Chrome 54.0.2840.71 m (64-bit).

The problem is there with both mouse and touch.

Indeed, Chrome doesn't work for me too (neither mouse nor touch). Earlier I only tested it with Firefox, which worked fine.

#59 in reply to: ↑ 58 @DarcPress
15 months ago

Replying to gsarig:

Indeed, Chrome doesn't work for me too (neither mouse nor touch). Earlier I only tested it with Firefox, which worked fine.

Yes, other browser has always been working on Firefox (and IE, I think).

It seems the problem is indeed jQuery UI behavior in touch screen. Some other JS library like Fancybox also has weird behavior on touch screen.

#60 follow-ups: @adamsilverstein
9 months ago

@gsarig or @DarcPress is this issue resolved for you in the latest version of WordPress?

#61 in reply to: ↑ 60 @gsarig
9 months ago

Replying to adamsilverstein:

@gsarig or @DarcPress is this issue resolved for you in the latest version of WordPress?

Hi,

Now it works fine on my Surface Pro 2 with Chrome too.

#62 in reply to: ↑ 60 @DarcPress
9 months ago

Replying to adamsilverstein:

@gsarig or @DarcPress is this issue resolved for you in the latest version of WordPress?

Yep, finally working on Windows 10.1 on normal Chrome. Thanks for the update!

Note: See TracTickets for help on using tickets.