Opened 95 minutes ago
#64466 new defect (bug)
Admin layout broken: #wpcontent height constraint prevents container from extending to full content height
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Awaiting Review | Priority: | normal |
| Severity: | normal | Version: | 6.9 |
| Component: | Administration | Keywords: | |
| Focuses: | ui, css | Cc: |
Description
The WordPress admin layout has a CSS architecture flaw that prevents #wpwrap and #wpcontent containers from extending to their full content height. This causes layout issues on admin pages with long content, such as WooCommerce orders pages with thousands of entries. I've seen this issue in WooCommerce and possibly WordPress in general on many occasions over recent years.
Steps to Reproduce:
- Navigate to any WordPress admin page with content exceeding viewport height (e.g., WooCommerce > Orders on a site with 1000+ orders)
- Inspect the
#wpwrapelement in browser DevTools - Observe that
#wpwraponly extends to the height of the left sidebar (~1840px) rather than the full content height (~5000px+) - The page footer and background styles do not extend to the bottom of the actual content
Expected Behavior:
The #wpwrap container should extend to contain all its child content, regardless of how tall that content is. The layout should work correctly whether content is 500px or 50,000px tall.
Actual Behavior:
#wpwrap and #wpcontent are constrained in height, causing the layout to break. The containers only extend to approximately the sidebar height rather than the full content height.
Root Cause:
In wp-admin/css/common.min.css (version 6.9), the following CSS creates a circular height dependency:
`css
#wpwrap {
min-height: 100%;
}
#wpcontent {
height: 100%;
}
`
The problem:
#wpcontenthasheight: 100%, which means "be 100% of parent's height"- Parent
#wpwraphasmin-height: 100%, which is calculated relative to<body> <body>doesn't have an explicit height, so percentage-based heights create a constraint loop- Neither element can expand beyond the calculated constraint, even though child content (
#wpbody) is much taller
Technical Analysis:
With default WordPress CSS:
#wpwrapoffsetHeight: ~1840px (constrained)#wpcontentoffsetHeight: ~1194px (constrained)#wpcontentscrollHeight: ~5102px (actual content height)#wpbodyoffsetHeight: ~5042px (actual content)
The height: 100% on #wpcontent prevents it from growing with its content, creating a hard ceiling that shouldn't exist.
Proposed Solution:
Change the CSS in wp-admin/css/common.css from:
`css
#wpwrap {
min-height: 100%;
}
#wpcontent {
height: 100%;
}
`
To:
`css
html {
height: 100%;
}
body {
min-height: 100vh;
height: auto;
}
#wpwrap {
min-height: 100vh;
height: auto;
}
#wpcontent {
min-height: 100vh;
height: auto;
}
`
This approach:
- Ensures minimum viewport height for short pages
- Allows containers to grow with content for tall pages
- Uses modern
vhunits instead of percentage-based heights - Breaks the circular dependency
Workaround:
Site administrators can add this CSS to their admin theme or via a plugin:
`css
html {
height: 100%;
}
body {
min-height: 100vh;
height: auto !important;
}
#wpwrap {
min-height: 100vh !important;
height: auto !important;
}
#wpcontent {
min-height: 100vh !important;
height: auto !important;
}
`
Impact:
This affects any WordPress admin page with content exceeding viewport height. It's particularly noticeable on:
- WooCommerce orders/products pages with many items
- Sites with large media libraries
- User lists on sites with many users
- Any admin page with extensive tabular data
Browser Testing:
Issue confirmed in:
- Chrome 131
- Likely affects all modern browsers due to CSS architecture issue
Additional Notes:
This is a longstanding issue in WordPress core CSS architecture. Similar height-based layout issues have been reported in other tickets (#43244, #52623), but this specific #wpcontent height constraint has not been addressed.
Shows the issue described