WordPress.org

Make WordPress Core

Opened 6 months ago

Closed 7 days ago

Last modified 7 days ago

#49288 closed defect (bug) (fixed)

Metabox holders missing their border and "Drag boxes here" text

Reported by: xkon Owned by: audrasjb
Milestone: 5.5 Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-patch has-screenshots commit
Focuses: ui, accessibility, administration Cc:

Description

Splitting this up from #39074. While editing Posts/Pages the advanced-sortables was missing a visible border and it was of 0px height so kind of hard to even drag a postbox there even if you knew it existed.

This was unfortunately extended into all metabox holders within the Edit so even if the sidebar was emptied there was no indication then that a draggable placeholder exists there.

I've managed to track down changes regarding this back to ticket #26399 & changeset 36295.

After some investigation, I also realized that the Drag boxes here text was also hidden from the Dashboard and all other areas for me. This was due to the @media rules pointing to specific ranges of a max 1800px.

Attachments (31)

49288.diff (2.3 KB) - added by xkon 6 months ago.
edit_before.jpg (120.3 KB) - added by xkon 6 months ago.
edit_after.jpg (129.5 KB) - added by xkon 6 months ago.
dashboard_before_over_1800wide.jpg (100.1 KB) - added by xkon 6 months ago.
dashboard_after_over_1800wide.jpg (102.4 KB) - added by xkon 6 months ago.
49288.2.diff (3.0 KB) - added by xkon 6 months ago.
49288.2_preview.gif (3.1 MB) - added by xkon 6 months ago.
49288 current patch.png (117.1 KB) - added by afercia 8 weeks ago.
49288 empty side sortable.png (79.2 KB) - added by afercia 8 weeks ago.
49288 dragging into side sortable.png (27.8 KB) - added by afercia 8 weeks ago.
49288.3.diff (7.3 KB) - added by afercia 7 weeks ago.
dashboard.gif (269.8 KB) - added by afercia 7 weeks ago.
post.gif (524.1 KB) - added by afercia 7 weeks ago.
49288 placeholder height.png (38.8 KB) - added by afercia 7 weeks ago.
Sortable placeholder height issue in Chrome when zooming.
dashboard-1200.gif (3.3 MB) - added by audrasjb 5 weeks ago.
Dashboard looks good to me (viewport width 1200px)
Capture d’écran 2020-06-06 à 05.57.48.png (87.0 KB) - added by audrasjb 5 weeks ago.
Edit post viewport width 1200px - no drag boxes here message
d08afd063388dfe33a59e49999b11474.mp4 (2.9 MB) - added by audrasjb 5 weeks ago.
Attachement screen - works fine
49288 advanced sortables wp 3.2.gif (274.6 KB) - added by afercia 5 weeks ago.
WordPress 3.2: dragging a box to the "advanced" area
49288.4.diff (9.5 KB) - added by afercia 5 weeks ago.
49288 edge case.png (144.2 KB) - added by afercia 5 weeks ago.
49288.5.diff (11.4 KB) - added by afercia 12 days ago.
49288 toggling dashboard widgets.gif (791.7 KB) - added by afercia 12 days ago.
New behavior on the Dashboard.
49288.6.diff (11.4 KB) - added by afercia 12 days ago.
49288.7.diff (11.3 KB) - added by afercia 11 days ago.
empty-containers.png (53.2 KB) - added by azaozz 10 days ago.
The outline and "Drag here..." text probably shouldn't be visible when there's nothing to add there.
empty-containers-without-patch.png (118.2 KB) - added by azaozz 10 days ago.
Same as above without 49288.7.diff. There's no empty-container class on the drop area.
dragging postboxes.2.gif (219.9 KB) - added by afercia 10 days ago.
49288.8.diff (11.4 KB) - added by afercia 10 days ago.
49288 dashboard 4 sortbles.png (151.7 KB) - added by afercia 10 days ago.
Emulating a large screen with 4 sortable areas available (but no visual hint) and 1 visible box.
49288 logged in as contributor.png (195.3 KB) - added by afercia 7 days ago.
Screenshot from trunk before the patch: Dashboard: four available "boxes" for the Contributor role.
49288 wp 5.4 subscriper.png (386.1 KB) - added by afercia 7 days ago.
WordPress 5.4: subscriber role: 2 widgets and 4 areas (all visible)

Change History (80)

@xkon
6 months ago

#1 @xkon
6 months ago

  • Keywords has-patch needs-testing added

49288.diff adjusts the CSS rules and alters the postbox.js to be able to read all metabox holders to add the empty class.

Instead of the default 250px height (as seen on Dashboard) the Edit empty holders will have a 50px height to avoid a big blank space at the bottom of the page (i.e. for advanced-sortables). It also enables the Drag boxes here message for resolutions above 1800px.

@xkon
6 months ago

@xkon
6 months ago

#2 @xkon
6 months ago

  • Keywords has-screenshots added

This ticket was mentioned in Slack in #accessibility by xkon. View the logs.


6 months ago

#4 @xkon
6 months ago

  • Summary changed from Adjust the CSS/JS of the empty metabox holders to Metabox holders missing their border and "Drag boxes here" text

This ticket was mentioned in Slack in #accessibility by xkon. View the logs.


6 months ago

#6 @audrasjb
6 months ago

  • Keywords needs-design-feedback added
  • Milestone changed from Awaiting Review to 5.4
  • Owner set to audrasjb
  • Status changed from new to reviewing

#7 @afercia
6 months ago

@xkon thanks for the patch!

Re: "Drag boxes here": since we're here, it would be nice to make the text have a sufficient color contrast. The current grey #ccc has a very low contrast of 1.42:1 see https://jdlsn.com/color/?type=hex&color=cccccc&color2=f1f1f1. We could use #606a73 which is already used in the Dashboard for some elements.

Re: the "advanced" area: Seems to me the "regression" is a bit more... ancient 🙂. WordPress 3.0 used to have these styles to set a min-height on the sortable areas:

.inner-sidebar #side-sortables {
	width: 280px;
	min-height: 300px;
}

#post-body #normal-sortables {
	min-height: 50px;
}

#post-body #advanced-sortables {
	min-height: 20px;
}

So in WordPress 3.0 it was actually possible to move a meta box to the "advanced" area. The UI wasn't that great: there was no visible indication of the advanced area but it worked.

The "normal" and "side" min-heights are still used today. Instead, the "advanced" min-height was removed in [18975] see the related ticket #18314. This change seems completely unrelated to the original ticket purpose and probably not intended. Since then, it is not possible to move meta boxes to the "advanced" area. /Cc @azaozz may know more.

Worth also considering jQuery UI Sortable has a start event. By using it, it would be possible to add a CSS class to the body e.g. is-dragging-metaboxes and style anything in the page. This could help to highlight the available areas in some way. Then, remove the CSS class on the stop event which is the already used in postbox.js.

I do realize the legacy Edit Post page has a low priority now that there's Gutenberg but this is a small, long-standing, regression that can be quickly fixed. The dashboard issue instead needs to be fixed anyways :)

@xkon
6 months ago

@xkon
6 months ago

#8 @xkon
6 months ago

Thanks for going even further back and pinpointing a commit @afercia!

I was aware of the start() stop() but I didn't have an idea on how to use them. The color correction to #606a73 gave me the idea though that instead of having them hidden/visible on drag we could also make them even more visible and a11y friendly since the border is still at #b4b9be which isn't a good difference with the background also.

The changes in the 49288.2.diff are re-introducing the older min-height:20px on advanced-sortables as well as adjusting the Drag boxes here to permanently use #606a73.

Also adds/removes the is-dragging-metaboxes class on drag/drop which also adjusts the border color to #606a73 as well. This way we tackle both a visual hint and also making it compatible to standards.

Side note: I did also play around with fully hiding the sortables while empty and show them on drag but this was resulting either on "flickering" of the screen if the height was also changed ( i.e. with a display:none or height: 20px) or you just ended up having a huge gap at the end of the page that didn't look nice :-). That's why I ended up just bumping the border color to have the best of both.

Preview 49288.2_preview.gif

#9 @karmatosed
5 months ago

  • Keywords needs-design-feedback removed

From a design perspective, this doesn't seem to change the interface much, unless I am mistaken. As result removing the keyword as looks like it is an improvement fix.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


5 months ago

#11 @afercia
5 months ago

This ticket was discussed during today's accessibility bug-scrub: the proposed patch appears to just need a final review.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


5 months ago

#13 @afercia
5 months ago

  • Milestone changed from 5.4 to 5.5

This ticket was discussed during today's accessibility bug-scrub: With 5.4 Beta 3 approaching, agreed to move this ticket to the next release cycle.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 months ago

#15 @afercia
8 weeks ago

  • Keywords needs-refresh added; needs-testing removed

Testing 49288.2.diff, the "drop area" below the post content is a bit too big, see attached screenshot. There are some subtleties in the way the edit post columns work and the way the columns behavior changed over time that make touching this code not that easy. Given that the classic edit post screen is legacy, I'd tend to think we should focus on a solution that is as simple as possible. On it.

#16 @afercia
8 weeks ago

RIght now, when the right column (#side-sortables) is empty (or contains only hidden meta boxes) it gets a thick dashed border. See screenshot attached below.

Last edited 8 weeks ago by afercia (previous) (diff)

#17 @afercia
8 weeks ago

When dragging a meta box inside the right column, the meta box placeholder has a thinner border. This way, the two different border styles help distinguishing the drop area from the placeholder. See screenshot attached below.

I'd tend to think the best option would be using the same pattern for the two drop areas below the post (#normal-sortables and #advanced-sortables) with a way smaller height and only while dragging.

Version 0, edited 8 weeks ago by afercia (next)

@afercia
7 weeks ago

#18 @afercia
7 weeks ago

  • Keywords needs-refresh removed

49288.3.diff builds on the previous patch and seeks to introduce a few improvements.

To recap, the main purpose of this ticket is:

  • on the Dashboard: display the "Drag boxes here" text also on large screens
  • on the edit post pages: give the ability to move the post boxes to all the available areas, including the "advanced-sortables" one which isn't possible since [18975]

Some testing would be nice. Please test at various resolutions and with the 2 column or 1 column layout, where applicable:

  • dashboard
  • edit post/page pages
  • edit attachment page

Details, TL;DR

  • adds a is-dragging-metaboxes class to the body when dragging
  • simplifies the JS and adds the is-dragging-metaboxes CSS class to all the sortables in the Dashboard and in the various edit posts pages
  • displays the CSS generated content "Drag boxes here" only on the Dashboard
  • since this text is meant to appear only on the Dashboard, moves the related CSS to dashboard.css
  • makes sure the text is displayed also on large screens with a viewport larger than 1800 pixels
  • better scopes the CSS differentiating between the one for #dashboard-widgets and the one for #post-body
  • removes the CSS rulesets related to .inner-sidebar and .has-right-sidebar as they're no longer used since WordPress 3.4, see [20272] / #20015

Visual changes for the Dashboard:

  • when dragging, the "empty" drop areas get a darker border
  • note: the empty areas are the ones that are really empty or that contain only hidden boxes

Visual changes for the edit post pages:

  • when dragging, adds a visual indication of all the drop areas, making it possible to move post boxes also to the "advanced-sortables" area
  • to respect the original implementation intent, there's no change in the 1 column layout

Some relevant history related to columns and sortables:
[18975] / #18314 / [20272] / #20015

#19 @afercia
7 weeks ago

See below an animated GIF to illustrate the behavior on the Dashboard.

Question: would it be preferable to always show the drop areas borders while dragging? The fact that borders are only shown for empty containers is a bit odd to me.

@afercia
7 weeks ago

#20 @afercia
7 weeks ago

See below an animated GIF to illustrate the behavior on the Edit post screen.

@afercia
7 weeks ago

#21 @afercia
7 weeks ago

Aside: while working on this I noticed a pre-existing issue.

With Chrome, when zooming out or in, at some zoom levels the "sortable placeholder" (the rectangle with a thin dashed border) has no height. It just shows like a doubled dashed line. See screenshot below.

When the placeholder height isn't explicitly set via CSS, jQuery UI sortable is supposed to compute a height based on the dragged element. See https://github.com/jquery/jquery-ui/blob/1.11.4/ui/sortable.js#L816-L817
This is a good thing because the placeholder will adapt to the post box collapsed / expanded height.

However, seems this computation fails because Chrome returns a height value which is 0 with some decimals e.g. 0.02083400000000002 thus when the Sortable code checks for ! element.height(), it fails. I guess jQuery UI sortable should prevent browser roundings by using parseInt() on all those values. Thinking this should be reported upstream. Although WordPress is using a pretty old version of jQuery / jQuery UI, this issue doesn't seem fixed on latest master as well.

@afercia
7 weeks ago

Sortable placeholder height issue in Chrome when zooming.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


5 weeks ago

@audrasjb
5 weeks ago

Dashboard looks good to me (viewport width 1200px)

@audrasjb
5 weeks ago

Edit post viewport width 1200px - no drag boxes here message

#23 @audrasjb
5 weeks ago

@afercia

Question: would it be preferable to always show the drop areas borders while dragging? The fact that borders are only shown for empty containers is a bit odd to me.

Yes, it looks odd to me as well. I'm in favor of always showing the drop area borders when dragging.

Otherwise, the patch works fine on my side, great work :)

@audrasjb
5 weeks ago

Attachement screen - works fine

#24 @afercia
5 weeks ago

Thx for testing @audrasjb, will refresh the patch to always show the borders while dragging.

Attaching one more animated GIF to illustrate how in very old versions of WordPress (3.2) it was possible to drag the boxes to the "advanced" area. Note that the placeholder area was grey on a white background. The border was the placeholder border, not a border set on the sortables area.

@afercia
5 weeks ago

WordPress 3.2: dragging a box to the "advanced" area

@afercia
5 weeks ago

#25 @afercia
5 weeks ago

49288.4.diff:

  • highlights all the drop areas while dragging
  • switches from border to outline, as it just works better with outline

Some testing would be nice, especially for edge cases.

For example, in the dashboard it is possible to move a box to the 3rd or 4th area when the page is zoomed out (or it's displayed on a large screen). Then when zooming to normal level or switching to another device with a different screen size, the layout may change and show "empty" drop areas between the other ones. See attached screenshot for an example. This is pre-existing behavior, there's just the need to check these edge cases still allow reordering the boxes.

#26 @afercia
3 weeks ago

Related: #47541. The "Drag boxes here" text isn't that appropriate in the (edge) case where there are no visible boxes in the Dashboard.

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


2 weeks ago

@afercia
12 days ago

#28 follow-ups: @afercia
12 days ago

  • Keywords commit added

49288.5.diff refreshes the patch and includes a fix for #47541.

Some testing and review would be nice :)

  • please double check the removed check for visible == 1 as I'm not sure I understand why it was there in the first place [edit] whether it's still used (it was introduced in [20272])
  • removes the postBoxL10n and uses more wp-i18n
  • provides an alternative text to Drag boxes here when all sortable areas are empty, fixing #47541

See attached animated GIF that illustrates the new behavior on the Dashboard. Notice the text changes when all sortable areas are empty.

Last edited 11 days ago by afercia (previous) (diff)

@afercia
12 days ago

New behavior on the Dashboard.

#29 in reply to: ↑ 28 @ocean90
12 days ago

Replying to afercia:

  • removes the postBoxL10n and uses more wp-i18n

Thanks for removing the variable. But please use $scripts->set_translations() for the script handle to properly register the translations instead of adding wp-i18n as a dependency.

#30 @afercia
12 days ago

  • Keywords commit removed

Thanks @ocean90 will have a look at it. Hm, I think I saw more cases where this should be done as well? Not 100% sure, but I've seen patches that just added wp-i18n.

@afercia
12 days ago

#31 @afercia
12 days ago

  • Keywords commit added

49288.6.diff adds set_translations()

@afercia
11 days ago

#32 @afercia
11 days ago

49288.7.diff omits to add the wp-i18n dependency to the postbox script, as it already uses set_translations().

#33 in reply to: ↑ 28 ; follow-up: @afercia
11 days ago

To me, the patch looks good to go for Beta. I'd greatly appreciate some input on the following point, please. /Cc @azaozz

  • please double check the removed check for visible == 1 as I'm not sure I understand why it was there in the first place [edit] whether it's still used (it was introduced in [20272])

#34 in reply to: ↑ 33 @azaozz
10 days ago

  • Keywords commit removed

Replying to afercia:

  • please double check the removed check for visible == 1 as I'm not sure I understand why it was there in the first place [edit] whether it's still used (it was introduced in [20272])

Hmm, can't remember (it was 8 years ago!). Seems it had something to do with hiding the outlines for empty drop areas on the Dashboard when there is only one "box" available for dragging. Then it doesn't make sense to show other areas as there's nothing to move there.

49288.7.diff seems to work well on the Dashboard, but doesn't work on the old Edit Post screen (need Classic Editor to test). When there are no boxes under the editor, or when all of them are (visibly) hidden, you cannot drag a box from the side to under the editor.

Seem caused by

#normal-sortables.empty-container, #post-body #advanced-sortables.empty-container {
    height: auto;
    ...

For Sortables the drop area has to have width and height before you start to drag, or there's nowhere to drop. Removing the above CSS seem to fix it.

Last edited 10 days ago by azaozz (previous) (diff)

@azaozz
10 days ago

The outline and "Drag here..." text probably shouldn't be visible when there's nothing to add there.

@azaozz
10 days ago

Same as above without 49288.7.diff. There's no empty-container class on the drop area.

#35 @afercia
10 days ago

Thanks @azaozz ! Will try to check all your points:

First:

doesn't work on the old Edit Post screen (need Classic Editor to test). When there are no boxes under the editor, or when all of them are (visibly) hidden, you cannot drag a box from the side to under the editor.

Seems to work for me. See attached animated GIF. I do know the sortables drop areas need a height to work correctly. That is why a min-height is added while dragging. However, I do see that when "hovering" a drop area, the "placeholder" appears only when you move a bit around the drop area. This is clearly visible also in the GIF. The placeholder should appear immediately and probably a height needs to be set earlier.

On the other hand, there's the need to reset the height inherited from common.css otherwise there will be a huge blank space below the editor.

I experimented a bit and looks like the sortables need any initial height to work better: even a 1 pixel initial height seems to improve things. Then, when dragging, min-height: 60px; makes the drop areas height bigger. Of course, we can adjust these numbers if necessary. Patch incoming.

@afercia
10 days ago

#36 @afercia
10 days ago

49288.8.diff adds a 1 pixel initial height to the sortables drop areas in the Edit Post screen. In my testing, this makes things work better, as the placeholder appears immediately when dragging over.

#37 @afercia
10 days ago

Second point:

The outline and "Drag here..." text probably shouldn't be visible when there's nothing to add there.

I think this is related to the visible == 1 bit :) Glad to know we traced it back to its original purpose. I have no strong opinion on this. We can restore it and not show the dashed outline + text when there's only 1 visible box.

On the other hand, with so many large screens in use today we should take into consideration many desktop users will likely see 4 sortables areas on the Dashboard.

Theoretically, users could end up in a situation like the one in the screenshot attached below. I'd tend to think in that scenario, it would be best to show the outline + text. But again I have no strong opinion, I'd defer the decision to you.

@afercia
10 days ago

Emulating a large screen with 4 sortable areas available (but no visual hint) and 1 visible box.

#38 @joedolson
9 days ago

I think that the outlines should be visible even when there's only one movable box visible. It would help make it more clear that there's a reason for a box to floating in the middle of neutral territory, and also help people to understand what spaces are available.

Also, as long as it is possible to drag a box into another position, it should be possible to identify the locations of those position.

#39 follow-up: @afercia
8 days ago

  • Keywords commit added

@joedolson thanks. @azaozz 49288.8.diff looks good to me. I'd like to commit, pending your final review and final input on the visibility thing. When you have a chance :)

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


7 days ago

#41 in reply to: ↑ 39 ; follow-up: @azaozz
7 days ago

Replying to afercia:

Right, 49288.8.diff fixes the problems on the old Edit Post screen. Also fixes start-location placeholders when starting to drag. Looks good here.

I think that the outlines should be visible even when there's only one movable box visible.

@joedolson Thinking this will be a "UX regression". Moving boxes is not the main purpose on the Dashboard, it is a settings option. Perhaps all placeholders can be visible when opening the Screen Options, even when nothing to drag there, but having drop areas that are always empty and cannot be used and cannot be hidden is not a good UI :)

For example "contributor" level users can only see one box on the Dashboard. Why would they need to be constantly asked to drag it to another place? Ideally the empty drop areas will match the number of available/visible boxes (had a plan to add this long time ago, never got to it...).

+1 to commit now, lets look into refining it during beta.

Last edited 7 days ago by azaozz (previous) (diff)

#42 @afercia
7 days ago

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

In 48340:

Accessibility: Administration: Improve the sortable postboxes areas on the Dashboard and Classic Editor pages.

  • makes the postboxes areas in the Dashboard visible also on large screens
  • uses a more meaningful text when all postboxes areas are empty instead of "Drag boxes here"
  • restores the ability to drag boxes to the "advanced" area in the Classic Editor page
  • makes the postboxes areas in the Classic Editor page visible while dragging so that users have a clue what the available areas are
  • improves the color contrast of the postboxes areas while dragging
  • uses wp.i18n for translatable strings in wp-admin/js/postbox.js

Props xkon, karmatosed, audrasjb, ocean90, joedolson, afercia, azaozz.
See #20491.
Fixes #49288, #47541.

#43 in reply to: ↑ 41 @afercia
7 days ago

Thanks @azaozz !

Replying to azaozz:

For example "contributor" level users can only see one box on the Dashboard. Why would they need to be constantly asked to drag it to another place? Ideally the empty drop areas will match the number of available/visible boxes (had a plan to add this long time ago, never got to it...).

Yep, that would be something interesting to explore in future iterations.

Worth noting Editors and Contributors can see 4 post boxes on the Dashboard, see attached screenshot. I think you meant the Subscriber role which traditionally had only one visible postbox. In the last releases though, subscribers can see also "WordPress Events and News".

@afercia
7 days ago

Screenshot from trunk before the patch: Dashboard: four available "boxes" for the Contributor role.

#44 follow-up: @azaozz
7 days ago

Uh, right, subscriber level users :)

Yeah, the problem is that before this patch "metabox holders" were not visible when there was only one visible box on the Dashboard. Now there will be up to three, telling the user to drag the box when they clearly don't need to do that.

Still thinking this is a bad UI/UX that was better before the patch, and possibly there will be some unhappy/confused users.

#45 @joedolson
7 days ago

Subscriber level users can see *two* boxes, I believe; Events & News and Activity.

What I think is that any droppable area should be exposed - if there is an area available, it should be visible. But I'd be totally in favor of removing droppable areas if there aren't enough boxes available to fill them.

#46 in reply to: ↑ 44 ; follow-up: @afercia
7 days ago

Replying to azaozz:

Still thinking this is a bad UI/UX that was better before the patch, and possibly there will be some unhappy/confused users.

I do agree the behavior on the Dashboard can be improved :) I'm not sure I understand in which way this change is a "regression" as you said above. Currently, on stable 5.4, subscribers can see up to two dashboard widgets and four dashed areas. Of course, this depends on the viewport width that on 5.4 needs to be not greater than 1800 pixels to see all the 4 areas. The dashed area "disappeared" above 1800 pixels, which is a bug fixed by this change.

See screenshot.

@afercia
7 days ago

WordPress 5.4: subscriber role: 2 widgets and 4 areas (all visible)

#47 in reply to: ↑ 46 @azaozz
7 days ago

Replying to afercia:

Replying to azaozz:

Still thinking this is a bad UI/UX that was better before the patch, and possibly there will be some unhappy/confused users.

I do agree the behavior on the Dashboard can be improved :) I'm not sure I understand in which way this change is a "regression" as you said above.

It's not so much of a "code" regression, but when there is only one box visible, now there will be up to three "drop areas" asking the users to "Drag boxes here". See

https://core.trac.wordpress.org/raw-attachment/ticket/49288/empty-containers-without-patch.png

The users can select to have only one box visible on the Dashboard, also plugins can disable some of the default boxes. That's why I'm expecting there may be some confusion :)

In any case, can look into polishing this during beta.

Last edited 7 days ago by azaozz (previous) (diff)

#48 @afercia
7 days ago

Yeah, that's the visible == 1 bit :) However, even if the dashed areas were not visible on 5.4 with only one enabled widget, the areas were still fully functional and users were able to drag boxes there. A better way to improve this would be not playing with the visibility of the "dashed outlines" but actually disabling the areas. Which is a bit more complicated :)

#49 @azaozz
7 days ago

Hmm, think Sortables has a reject/return callback on drop, can probably look into using that based on the number of visible boxes. Or can just reinitialize Sortables when boxes are shown or hidden from Screen Options.

Note: See TracTickets for help on using tickets.