CP2.0 - cannot drag and drop boxes on dashboard

Support Version 2.x
1

Just noticed today when I tried to rearrange dashboard items on a website that’s on CP2.0, cannot drag the boxes to a new position. Checked on another site on CP2.0, and same thing. I do not know if this was also an issue with the 2.0 RC.

UPDATE: OK, check that: SOMETIMES I can drag a box, but sometimes not. When it does drag, it feels glitchy.

FURTHER UPDATE: Same issue wuth boxes on edit screens of pages and posts. It’s still possible to move boxes one space at a time using the up and down arrows in the upper right corner of the boxes.

2

Hover over the title of the item before you click (so you get that 4 way arrow thing), then you should be able to move them as before.

2 Likes
3

OK, that works; much smaller target area. On other sites I can get the arrows anywhere on the title block.

4

Was it intentional to make the ui-sortable-handle smaller?

5

Not particularly, but it’s necessary to avoid a JavaScript conflict. There are further changes to come there in v2.1 which might help.

6

@raygulick Could you test out the following CSS and see if it reverts the dragging area to its previous size without pushing things onto two lines?

In ~/wp-admin/css/common.css on line 2047, change the properties of .postbox-container summary > div to read:

	display: inline-flex;
	justify-content: space-between;
	width: 95%;

Then, on about line 2103, change

.js .widget .widget-top,
.js .postbox .hndle

to read:

	cursor: move;
	flex: 1;

If this does the job, I’ll submit a PR.

7

Actually, to fix both the dashboard and post widgets, the first one should be as follows:

.postbox-container summary > div {
	display: inline-flex;
	justify-content: space-between;
}

#dashboard-widgets-wrap .postbox-container summary > div {
	width: 95%;
}

#poststuff .postbox-container summary > div {
	width: 92%;
}
9

I added all; don’t see a change in widgets either on dashboard or edit screens.

10

Not sure I’m able to force a reload of the CSS; not showing up on inspector.

11

If I add in the inspector, it works, but only if I add the following:

.metabox-holder .postbox > h3, 
.metabox-holder .stuffbox > h3, 
.metabox-holder h2.hndle,
.metabox-holder h3.hndle { width:100%; }

I’m confused about why ~/wp-admin/css/common.css isn’t reloading with the added styles.

12

There is also a ~/wp-admin/css/common.min.css. Is it loading that instead?

13

Ah, yes, you need to have define('SCRIPT_DEBUG', true); in your wp-config.php file in order to load the unminified version.

14

Well that’s weird, when I add that to wp-config.php I get an error
Warning: Constant SCRIPT_DEBUG already defined in ~wp-config.php on line 82

which is where I added it.

15

That is weird!

16

Did you add it after if ( !defined('ABSPATH') ) instead of before?

17

82 is the last line

18

You need to add that bit of code above the line that says:

/* That's all, stop editing! Happy blogging. */
19

Current setup, still showing error:

/** Absolute path to the WordPress directory. */
if ( ! defined( 'ABSPATH' ) )
	define( 'ABSPATH', dirname( __FILE__ ) . '/' );
/** Sets up WordPress vars and included files. */
require_once ABSPATH . 'wp-settings.php';

define('SCRIPT_DEBUG', true);

/* That's all, stop editing! Happy blogging. */
20

That’s not the default order of items in that file. It should end with:

/* That's all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

Which means that it should now end like this:

define( 'SCRIPT_DEBUG', true );

/* That's all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');
21

OK, I misinterpreted what you said. No more error.

Also, drag and drop are good.

1 Like