Admin Menus Shouldn't Jump Around on Pageload

[filosofo]

Problem: When I open an admin page, I see the menu item I want and go to click it, and just at that moment the admin menu suddenly expands so that I click the wrong item.

Solution: Instead of expanding the menus by retrieving their saved state and adding open classes with JavaScript, we should retrieve the saved state from usermeta (it's already being saved there) and print the menus with appropriate classes, accordingly, so that there is no jump.

[strider72]

If we make the change you suggest, I believe there will be no way to close a menu if someone accesses Admin without JavaScript.

[filosofo]

Replying to strider72:

If we make the change you suggest, I believe there will be no way to close a menu if someone accesses Admin without JavaScript.

Well, currently if you access the admin without JavaScript there's no way to open a menu, except for the current children and ones preset as open, so there doesn't seem to be too much concern about allowing the non-JS folks flexibility with saved open/close states.

However, if that's something people want, we could just make the open/close arrows into links that accomplish state change for non-JS users. That might be a good idea anyways, since the current, non-JS menu has arrows that do nothing.

[nacin]

Related: #11957, changing how menu states are stored.

[nacin]

Should be looked at with #11957.

[t31os_]

I'm constantly clicking wrong menu items because of this problem, the suggestion is sound for me, i'd much prefer classes to be added to the elements on page load, so we avoid all this jumping around.

[nacin]

Marking for 3.2-early. I want to tackle this.

[garyc40]

there's a patch for that

[nacin]

Thanks for doing this!

You can probably kill wp_get_current_user() and the extra argument to get_user_option(), which defaults to the current user.

Actually, avoid get_user_option() all together, and leverage get_user_setting() and/or get_all_user_settings().

[garyc40]

use get_user_setting()

[garyc40]

There you go :)

[nacin]

10646.diff​ takes a different approach, to support no-JS situations. Also, the increment occurs in a different spot, as only top-level menus that have a submenu are actually counted. (Otherwise, the comments menu throws off the lower menus.)

[nacin]

Second patch changes the logic on wp-admin/menu-header.php:61 to ensure only menus with submenus are checked against the user settings. Otherwise for example the Comments menu will get wp-menu-open-if-js if Pages is open, despite it not doing anything.

[azaozz]

10646-3.patch is almost identical to 10646.2.diff except it uses only CSS to initially open/close the menus so it doesn't require any JS to run on DOM ready.

[nuxwin]

With the last patch (10646-3.patch) applied and under no-js mode, the Posts menu is always displayed (expanded). For me, it's bad behavior.

Edit

The Problem seem to be not linked to the patch since it's same behavior in current version.

Edit:

Ok; that seem to be another bug, but I don't know if I must create separate ticket for it... In no-js mode, the Posts submenu is always expanded because the menu has always the class open-if-no-js added to it. I doesn't known if it's the expected behavior or not. If yes, why ?

For me, under no-js mode, the open-if-no-js must be only added on the current menu (linked to the current loaded admin page).

To finish, I thinks that under no-js mode, all arrows that allow to expand the submenus in js mode must be hidden.

I'll provide a modified version of the current patch , which will include all these considerations.

Note: Sorry for the empty comments bellow. I've found the edit option too late.

[nuxwin]

Update on my previous comment: Problem seem to be not linked to the patch since it's same behavior in current version.

[nuxwin]

10646-4.patch is almost identical to 10646-3.patch. It include the following fixes:

• Under no-js mode, only the menu linked to the current loaded page is expanded ;
• Under no-js mode, all arrows are hidden.

The patch also includes the fix linked to the #17058 issue.

[azaozz]

Replying to nuxwin:

With the last patch (10646-3.patch) applied and under no-js mode, the Posts menu is always displayed (expanded). For me, it's bad behavior.

This is an UX decision. Since the Posts submenu is the most used one, it's always open when no-js.

To finish, I thinks that under no-js mode, all arrows that allow to expand the submenus in js mode must be hidden.

Agreed.

[nuxwin]

Replying to azaozz:

Replying to nuxwin:

With the last patch (10646-3.patch) applied and under no-js mode, the Posts menu is always displayed (expanded). For me, it's bad behavior.

This is an UX decision. Since the Posts submenu is the most used one, it's always open when no-js.

To finish, I thinks that under no-js mode, all arrows that allow to expand the submenus in js mode must be hidden.

Agreed.

Ok so, I'll update the patch according this UX decision. For me, it's a bad decision but it's only my personal opinion.

[nuxwin]

Some fixes added against the previous patch

[nuxwin]

Patch updated (UX decision - Posts menu must be expanded under no-js mode).

[azaozz]

(In [17623]) Don't refresh the admin menu after page load, apply the user-state from PHP, fix behaviour after folding the menu, props nacin, props nuxwin, fixes #10646, fixes #17058

[sbressler]

Excited to see this applied - this should significantly speed up the seeming load time of all admin pages!