Admin Sidebar Text length Issue

[jagirbaheshwp]

Hello Team,

As this is really awesome as working with the community of wordpress CMS.

While creating custom post type my post type text is too large and i see text are not properly aligned in sidebar and it's look not good.

For Ref. Screen Shot Attach

[munyagu]

Padding added to the left side of the label.

[jagirbaheshwp]

Added Display flex

[harshbarach]

Aha @jagirbaheshwp , it's working like charm & glossy.

[Hareesh Pillai]

The submitted patch does not fix the bug in responsive width.

[naveenkharwar]

The submitted patch fixed the bug in responsive width too.
Tested in WordPress( 5.1-beta3-20190207.100728 ).

[Hareesh Pillai]

Patch refreshed

[Hareesh Pillai]

Screenshot of the page after applying the patch

[mukesh27]

Responsive design issue

[mukesh27]

Below css generate issue in responsive design but if we use height: auto then it will fixed issue in responsive design.

@media only screen and (max-width: 960px) {
	.auto-fold #adminmenu a.menu-top {
		height: 34px;
	}
}

[chetan200891]

For me adding below padding fixes issue.

#adminmenu div.wp-menu-name {
	padding: 8px 8px 8px 35px;
}

[dushanthi]

Run the patch and created some long custom post types texts, seems so work fine. One thing I noticed is that really long "words" are too close to the edge of the sidebar.

[worldweb]

Added display:flex, word-wrap: break-word and height: auto for responsive

[worldweb]

Tested in desktop and mobile. Working fine.

[audrasjb]

Works fine with 42201.5.diff

[audrasjb]

Changing owner of the ticket.

I tested the proposed patch and it works fine (see screenshot).

However I refreshed the patch since the previous one doesn't apply to WordPress Dev sourcecode.
42201.5.diff fix the implementation and refreshes the proposed patch against trunk.

Also @worldweb, youdon't need to copy patches to RTL CSS files since they are automatically generated during build process ;-)

Adding commit keyword.

[audrasjb]

Patch refresh and correct diff file

[whyisjake]

In 46332:

Administration: Ensure visual consistency with large titles in the sidebar.

Custom posts, and other menu titles that are long aren't wrapping correctly.

Props jagirbaheshwp, munyagu, harshbarach, hareesh-pillai, pratikkry, naveenkharwar, mukesh27, dushanthi, worldweb, audrasjb
Fixes #42201

[afercia]

Looks like this change introduced a small regression when the admin menu items display the "counters": the spacing is now clearly smaller and the counters are almost attached to the menu item text.

See in the screenshot below: left: before the change, right: after the change that added display: flex.

[afercia]

Also, with longer translations and counters with multiple digits, the new display: flexand word-break: break-word; properties make the counter break.

On the left: the previous CSS where, at least, the counter goes to a new line and doesn't break.
On the right: the new CSS.

[amolv]

Patch refresh and correct diff file

[amolv]

Admin Menus Before and After - 42201.6.patch

[iqbalbary]

Plugin Number Counter

[iqbalbary]

42201.6.patch fixes the plugin counter problem only, still need to add #adminmenu .awaiting-mod, #adminmenu .update-plugins for comment counter.

Also if we can add css to .wp-menu-name > span then it will cover other menu(theme & plugins) too which have counter option.

[amolv]

Replying to iqbalbary:

42201.6.patch fixes the plugin counter problem only, still need to add #adminmenu .awaiting-mod, #adminmenu .update-plugins for comment counter.

Also if we can add css to .wp-menu-name > span then it will cover other menu(theme & plugins) too which have counter option.

Thank you for testing, updating CSS.

[amolv]

Patch refresh and correct diff file.

[davidbaumwald]

Tested the most recent patch, and it works as intended. Marking this for commit.

[whyisjake]

In 46453:

Administration: Ensure visual consistency with large titles in the sidebar.

Custom posts, and other menu titles that are long aren't wrapping correctly.

Props jagirbaheshwp, munyagu, harshbarach, hareesh-pillai, pratikkry, naveenkharwar, mukesh27, dushanthi, worldweb, audrasjb, afercia, amolv, iqbalbary, davidbaumwald.
Fixes #42201

[afercia]

Sorry to reopen but [46453] doesn't seem to fully address the unnecessary visual changes introduced with the previous commit.

1
On WordPress 5.2 when the counters have only 1 digit, they're a 18 by 18 pixels circle. This is not a coincidence: it's intentional and the CSS should make sure it's a perfect circle. Instead, now the counters aren't a perfect circle: they have a slightly oval shape and the number is not perfectly centered. Screenshot:

2
The spacing between the text and the counters is still clearly different and doesn't help readability. Not to mention it's not great visually.

3
With longer menu items or longer translations the counter ends up in the middle of the page: this is undesirable. On WordPress 5.2 wasn't perfect as well but at least it went to a new line leaving just the text to overflow into the page.

Screenshot for 2 and 3:

4
#adminmenu .wp-menu-name > span is now a flex item thus these properties applied on it:

display: inline-block;
vertical-align: top;

don't make much sense. Alignment should be controlled with the properties that pertain to flexbox.

See also the attached animated GIF that better highlights the visual changes.

[afercia]

WordPress trunk 5.3 vs. WordPress 5.2.3

[amolv]

Patch refresh and correct diff file.

[amolv]

Latest patch fixes longer Menus and submenus text, rounded circle to counts till 9 number and it's 18px, spacing between menu text and count.

[amolv]

Patch refresh and correct diff file.

[afercia]

One more thing to address that happens also on trunk before applying 42201.9.patch​:

When the menu is collapsed, the counters are not styled properly. See screenshot below. Actually, there is another counter within .wp-submenu-head that is shown only when the menu is collapsed.

[afercia]

Collapsed menu counters not styled

[amolv]

Latest patch diff file, counter fix on menu collapsed

[amolv]

When menus is collapsed .wp-submenu-head fix added in recent patch.

[SergeyBiryukov]

The updates count under Dashboard is no longer styled properly after [46453], see 42201.updates-count.PNG​.

42201.10.patch​ appears to resolve the issue.

[sabernhardt]

Notification circles after patch 42201.10 in Chrome (Windows 10)

[sabernhardt]

The notification circle style is restored with 42201.10 in Chrome, Edge, Internet Explorer and Firefox (Windows 10).

[sabernhardt]

Notification counters in folded menu after patch 42201.10 (Chrome, Windows 10)

[johnbillion]

Thanks for the testing @sabernhardt .

Safari 12, Chrome 77, and Firefox 69 all look good on macOS, as does latest Chrome on Android.

Those nested selectors aren't optimal but I can't immediately see a better way to do it, so +1 from me to get this in.

[johnbillion]

In 46555:

Administration: Fix the appearance of update bubbles in submenus and when the admin menu is collapsed.

Props afercia, amolv, sabernhardt

Fixes #42201, #48294

[johnjamesjacoby]

r46555 broke the use of :after on #adminmenu .wp-submenu a.

Specifically, changing from display: block; to display: flex;.

I help build or maintain several plugins that add styling to a pseudo element after some specific anchors. This styling is applied specifically based on user feedback for plugins with large add-on ecosystems that add many sub-menus to a single top-level menu item.

/* Secondary Separators */
#adminmenu ul > li:not(:last-child) a[href^="admin.php?page=sugar-calendar"]::after,
#adminmenu ul > li:not(:last-child) a[href^="post-new.php?post_type=sc_event"]::after
{
	display: block;
	border-bottom: 1px solid rgba(255,255,255,0.2);
	height: 14px;
	margin: 0 -13px;
	content: '';
}

With these anchors now displaying as flexible instead of blocks, the :after pseudo elements flex after them, even when display: block; is applied to them.

[johnjamesjacoby]

Some research from: ​https://www.w3.org/TR/css-flexbox-1/#flex-items

Each in-flow child of a flex container becomes a flex item, and each contiguous sequence of child text runs is wrapped in an anonymous block container flex item. However, if the entire sequence of child text runs contains only white space (i.e. characters that can be affected by the white-space property) it is instead not rendered (just as if its text nodes were display:none).

If I am reading this correctly, anything now "inside" that now-flexed anchor is forced to be a flex element.

Using display: block !important; even gets ignored in all browsers, confirming (to me) that child pseudo elements of a flexed element are forced to flex, meaning there is no alternative CSS to get this styling working again (a more strict hack could override the core anchor styling, but whack-a-mole priority juggling isn't a solution IMO.)

A flex item establishes an independent formatting context for its contents. However, flex items themselves are flex-level boxes, not block-level boxes: they participate in their container’s flex formatting context, not in a block formatting context.

[zodiac1978]

UI glitch for every color schema besides the default

[zodiac1978]

I get a wrong styling in every color scheme besides the default one (looking at 5.3-RC1-46560).

Reason from colors.min.css (in this example):

#adminmenu .awaiting-mod, #adminmenu .update-plugins {
    color: #fff;
    background: #e1a948;
}

[afercia]

Personally, at this point of the release cycle (WordPress 5.3 is now in Release Candidate) I'd lean towards a complete revert of all the changes from this ticket.

This is not to blame anyone :) The intent was good but the WordPress admin menu is tricky, made of various "layers" of functionalities, HTML, and CSS that stratified across the years. It's a very good example of a place where changing even a very small detail can break many things.

Overall, this change doesn't seem ready for 5.3 and it can be explored better in the next release cycle.

[SergeyBiryukov]

Replying to afercia:

Personally, at this point of the release cycle (WordPress 5.3 is now in Release Candidate) I'd lean towards a complete revert of all the changes from this ticket.

I tend to agree. Given that we're still discovering regressions after two follow-up commits, seems like we should consider reverting [46332], [46453], and [46555] for now, and trying again in a future release to allow for more testing.

[amolv]

Patch refresh to support admin menu counter/bubble in different color schemes

[johnbillion]

Agreed on the revert. Let's get this back into 5.4 as soon as we branch so it can be tested as-is and iterated upon.

[johnbillion]

Reverting given agreement from three committers.

[johnbillion]

In 46561:

Administration: Revert changes to the admin menu styles for long line lengths.

This reverts [46555], [46453], and [46332].

See #42201

[davidbaumwald]

Edited wrong ticket and falsely reassigned. Reassigning this to @johnbillion.

Since this ticket doesn't have any momentum, it's being moved to Future Release. If any committer feels this can be moved up or can be owned during a specific cycle, feel free to update the milestone accordingly.

[amolv]

Patch Refresh, without using flex long titles/menus displayed nicely.

[amolv]

Patch Refresh.

[audrasjb]

Last patch works fine

[audrasjb]

I tested the last proposed patch and it looks good to go on my side. Marking this for commit.

[johnbillion]

Agreed, I tested this last night and it looks like a good approach. I think we can commit it so it gets a good amount of testing across browsers.

[helen]

I've uploaded a screenshot of the effects in the narrow viewport/mobile menu view, it's not great now but it seems even worse after. I'd like for that to be addressed before committing a patch here.

[amolv]

Patch Refresh.

[amolv]

@helen thank you for test, patch refreshed to fix issue on narrow viewport.

[audrasjb]

Looks good to me, thank you @amolv 👍

[SergeyBiryukov]

Could we have a screenshot of 42201.13.patch​ on a narrow viewport?

[audrasjb]

New patch to address a small responsive issue

[audrasjb]

42201.14.diff on narrow screen

[audrasjb]

While I was taking screenshot of the last patch, I noticed a small remaining CSS issue. 42201.14.diff fixes this issue. See screenshot of the new patch above.

[mukesh27]

42201.14.diff​ working fine in WP 5.6-alpha-48958 version.

[garrett-eclipse]

With the use of word-break: break-word; has this been tested on IE11? To my understanding it doesn't support that css;
​https://caniuse.com/mdn-css_properties_word-break_break-word
*I would but am on a mac.

[mukesh27]

I have tested 42201.14.diff​ in IE11 and word-break: break-word; is not working in IE11.

Replying to garrett-eclipse:

With the use of word-break: break-word; has this been tested on IE11? To my understanding it doesn't support that css;
​https://caniuse.com/mdn-css_properties_word-break_break-word
*I would but am on a mac.

[mukesh27]

IE11 issue

[amolv]

Patch refresh and IE fix

[garrett-eclipse]

Latest patch should be retested across browsers but looks good.

[audrasjb]

The refreshed patch looks good to go on my side.
It's basically the same than mine, but it adds cross browsers support.

[metalandcoffee]

I tested 42201.15.patch on the latest version of Chrome, Firefox and Safari. It looks good to go. Attaching screenshot. Still needs to be verified on IE11 since I'm a mac user :)

[metalandcoffee]

Latest Patch Testing

[helen]

#44938 was marked as a duplicate.

[helen]

In 49149:

Admin Menu: Better wrapping for long menu item names.

Props munyagu, jagirbaheshwp, harshbarach, pratikkry, hareesh-pillai, naveenkharwar, mukesh27, chetan200891, dushanthi, worldweb, audrasjb, afercia, amolv, iqbalbary, davidbaumwald, sabernhardt, johnjamesjacoby, garrett-eclipse, garrett-eclipse.
Fixes #42201.