WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#19129 closed defect (bug) (fixed)

Unexpected behavior of the Categories meta box

Reported by: linuxologos Owned by: azaozz
Milestone: 3.3 Priority: high
Severity: normal Version: 3.3
Component: Administration Keywords: has-patch
Focuses: Cc:

Description

The "All Categories" tab in "Categories" meta box on Add New Post screen does not float in the right place (by some pixels to the top), if single-column screen layout is chosen.

Tested against latest trunk, IE/Firefox/Chrome Windows, Firefox Linux.

It's new in 3.3, probably caused by #18198 or #18314.

See also screenshot.

Attachments (6)

all-categories-float.jpg (12.4 KB) - added by linuxologos 10 years ago.
19129.patch (195.3 KB) - added by linuxologos 10 years ago.
19129.2.patch (387 bytes) - added by duck_ 10 years ago.
collapsed-tabs.png (3.5 KB) - added by linuxologos 10 years ago.
19129.3.patch (515 bytes) - added by linuxologos 10 years ago.
19129.4.patch (419 bytes) - added by linuxologos 10 years ago.

Download all attachments as: .zip

Change History (24)

#1 @SergeyBiryukov
10 years ago

  • Milestone changed from Awaiting Review to 3.3

#2 @linuxologos
10 years ago

  • Severity changed from trivial to normal

Actually, it's more complicated...

Go to Add New Post screen. The default choice is two-columns screen layout.

In WP 3.3 the Categories meta box has only one tab (All Categories). In 3.2.1 there is a Most Used tab, too. I don't know if this change is by design.

Now in WP 3.3, drag & drop the Categories meta box from the right to the left (wider) column. The Most Used tab suddenly appears and both tabs are in the right place (and the original bug described here is invalidated!).

#3 follow-up: @linuxologos
10 years ago

  • Summary changed from "All Categories" tab in "Categories" meta box floating to Unexpected behavior of the Categories meta box

After a dipper look, some more evidence:

Both in WP 3.2.1 and 3.3 the "Most Used" tab in Categories meta box gets the hide-if-no-js class. Difference is, in WP 3.3 it matches against

#side-sortables .category-tabs li.hide-if-no-js {
    display: none;
}

and it's hidden. Of course, it shouldn't. (Same browser window.)

If you drag & drop (in WP 3.3) the Categories meta box from the right to the left (wider) column, the Most Used tab appears, because the parent div has now the #normal-sortables id and the earlier match doesn't apply.

Also in WP 3.3, meta boxes which are in the right column before the screen layout switch (from two- to one-column) retain the #side-sortables parent div, which is correct, but it causes the floating problem initially described (another CSS problem?).

If Category meta box is already in the left column before the screen layout switch, nothing changes, as expected.

@linuxologos
10 years ago

#4 @linuxologos
10 years ago

The above mentioned CSS rule doesn't seem to exist in WP 3.2.1 at all. If it was inserted in WP 3.3 at some point and it isn't useful anymore, the patch removes it and reveals the "Most Used" tab.

#5 follow-up: @duck_
10 years ago

The rule exists to hide the Most Used tab when Javascript is disabled, but it's not written correctly. See [18668], #16810 and #18656.

Attached 19129.2.patch to correctly display none when the body element has the .no-js class. Also does not restrict this to #side-sortables.

@duck_
10 years ago

#6 in reply to: ↑ 5 @duck_
10 years ago

Replying to duck_:

Also does not restrict this to #side-sortables.

Actually it does need to specify #side-sortables otherwise the display: inline rule still has more specificity. Re-uploaded.

#7 @duck_
10 years ago

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

In [19179]:

Only hide "Most Used" category tab when the body has .no-js class. See #16810, fixes #19129.

#8 in reply to: ↑ 3 ; follow-up: @linuxologos
10 years ago

  • Keywords has-patch added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Replying to linuxologos:

Also in WP 3.3, meta boxes which are in the right column before the screen layout switch (from two- to one-column) retain the #side-sortables parent div, which is correct, but it causes the floating problem initially described (another CSS problem?).

If Category meta box is already in the left column before the screen layout switch, nothing changes, as expected.

This doesn't exist in WP 3.2.1, because all meta boxes get the #normal-sortables parent div, when switching to single-column layout.

See new screenshot and patch, which tries to cure this.

#9 @linuxologos
10 years ago

19129.4.patch touches only #side-sortables .category-tabs li, which clearly affects the Add New Post screen.

#side-sortables .add-menu-item-tabs li (Appearance > Menus screen) and .wp-tab-bar li do not seem to appear on this screen and I don't know if they should be affected, as of 19129.3.patch.

#10 in reply to: ↑ 8 @duck_
10 years ago

Replying to linuxologos:

Sorry didn't notice that part. I think that in 3.2 the switch to 1 column moved the boxes out of #side-sortables. This isn't done in 3.3 to help with responsive admin, so as the screen expands the boxes in 1 column can move out into the side automatically.

#11 @linuxologos
10 years ago

Everything is fine, except for the fact that even after moving the meta box to the left (wider) column, the below rule

#side-sortables .category-tabs li {
	display: inline;
}

is still in action, causing the tabs, which are now vertically aligned, to collapse upon each other.

That was really the original ticket about. 19129.4.patch offers a solution to this, if it's good to go.

The JS stuff came in later, but was solved first. :)

#12 follow-up: @duck_
10 years ago

  • Owner changed from duck_ to azaozz
  • Status changed from reopened to assigned

Re-assigning to azaozz as this is a responsive follow up issue.

#13 @ryan
10 years ago

  • Priority changed from normal to high

#14 in reply to: ↑ 12 ; follow-up: @azaozz
10 years ago

Replying to duck_:

Re-assigning to azaozz as this is a responsive follow up issue.

Was this fixed in another patch? Don't see it happening as of r.19215.

#15 in reply to: ↑ 14 ; follow-up: @duck_
10 years ago

Replying to azaozz:

Was this fixed in another patch? Don't see it happening as of r.19215.

I can still reproduce. Make sure that the categories meta box is in the right column, so it's output in #side-sortables, before switching to the one column layout. If it's already part of the main column it will not be targeted by the #side-sortables rule to change display to inline.

postbox.dev.js does

$('#normal-sortables').before( $('#side-sortables') );

in 3.2 it would append the children of #side-sortables with class .postbox.

#16 @azaozz
10 years ago

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

In [19219]:

Fix inline/block switching for the Categories postbox tabs, props linuxologos, fixes #19129

#17 in reply to: ↑ 15 @azaozz
10 years ago

Replying to duck_:

Yes, changed that to move the containers instead of individual postboxes. Has the advantage of keeping the postboxes in place when switching back.

#18 @WraithKenny
10 years ago

semi-related #17959

Note: See TracTickets for help on using tickets.