Opened 6 years ago
Last modified 7 months ago
#41155 reopened defect (bug)
WordPress 4.8 Admin Sidebar Sub Menu Navigation Issue
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | Themes | Keywords: | good-first-bug has-patch has-screenshots |
Focuses: | ui, css, administration | Cc: |
Description (last modified by )
Hello Team
As this is really awesome as working with the community of wordpress CMS.
While reviewing themes of WordPress Me and my colleague @amolebonde face issue about accessing sub-menu navigation when we are theme detail page WordPress Admin > Appearance > Themes > Theme Details.
Once we are on Theme Detail page then in case if the user wants to access any Sub Menu Navigation it not shows well, which goes behind the popup theme detail page.
Wordpress Version 4.8
Browser Check: SAFARI 10.1.1, Google Chrome 58.0
Attachments (12)
Change History (38)
#1
@
6 years ago
- Component changed from General to Administration
- Focuses accessibility administration removed
- Keywords needs-patch good-first-bug added
- Severity changed from normal to trivial
- Version 4.8 deleted
@
6 years ago
@adamsilverstein if increased #adminmenuwrap
selectors z-index 9990 to 10001 we can solve this issue.
@
6 years ago
Hi, @adamsilverstein, Updated theme.css for appearing admin sidebar submenu. Also, Decreased the width of theme overlay for a perfect view of the submenu.
#3
@
6 years ago
- Keywords has-patch added; needs-patch removed
Hi, @adamsilverstein
For standard view desktop (1920x1080) Reduced the theme overlay width. I saw that the media is working for (min-width: 1680px).
This change is made in regard to standard desktop view.
This ticket was mentioned in Slack in #core by staceybl. View the logs.
6 years ago
#8
in reply to:
↑ 6
@
6 years ago
Thank you for the patch! I tested it (on 4.8.1) and it is working perfectly.
Also big thanks to @codexdemon for pointing out the issue!
Replying to chintanmachhi207:
#41155.3 added to fixed this issue.
#9
@
5 years ago
- Description modified (diff)
- Owner set to mp518
- Status changed from new to assigned
Assigning to mark the good-first-bug
as "claimed".
#10
@
4 years ago
- Keywords has-screenshots added
- Resolution set to worksforme
- Status changed from assigned to closed
#11
follow-up:
↓ 12
@
4 years ago
- Resolution worksforme deleted
- Status changed from closed to reopened
@worldweb Why did you close this ticket? There was no fix committed here.
#12
in reply to:
↑ 11
@
4 years ago
Seems to be done by mistake. Thank you.
Replying to swissspidy:
@worldweb Why did you close this ticket? There was no fix committed here.
This ticket was mentioned in Slack in #core by worldweb. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by worldweb. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by worldweb. View the logs.
4 years ago
This ticket was mentioned in Slack in #forums by worldweb. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-themes by worldweb. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-editor by worldweb. View the logs.
4 years ago
#19
@
4 years ago
- Component changed from Administration to Themes
- Focuses administration added
- Severity changed from trivial to normal
#26
@
7 months ago
Hi, this is my first contribution to WordPress, sorry if I made some mistakes.
Instead, to change the value of the z-index in those classes, I tried a different implementation: I removed the z-index properties because I didn’t see any value in having them.
As you can see, I attached two videos with the current behavior and the fixed behavior.
The css that causes this in theme.css has an inline comment indicating it was added to keep the overlay over 'WP Pointers':
z-index: 10000; /* Over WP Pointers. */
This was added in r33068, and at the time the issue with the submenus going under the overlay was noted and an attempt to resolve was made in r33111.
These z-index conflicts are very difficult to resolve, maybe we should go back to @obenland's original suggestion to not show pointers when the modal is open?