WordPress.org

Make WordPress Core

Opened 8 months ago

Closed 8 months ago

Last modified 2 months ago

#51073 closed defect (bug) (fixed)

Extra padding below the admin bar

Reported by: akissz Owned by: SergeyBiryukov
Milestone: 5.5.1 Priority: normal
Severity: normal Version: 5.5
Component: Administration Keywords: has-patch commit
Focuses: Cc:

Description

hopefully someone else noticed the obvious css bug in 5.5 after updating. i do not see anyone else writing about it so i will write about it. when you update to 5.5 there is a huge white gap below the admin menu on top between the side menu. it only shows up in single site mode. in multisite mode is it not visible. i can't believe 5.5 was released with this obvious css bug...

Attachments (3)

Screen Shot 2020-08-19 at 9.15.23 PM.png (11.3 KB) - added by akissz 8 months ago.
5.5 with white gap
Screen Shot 2020-08-19 at 9.14.42 PM.png (17.3 KB) - added by akissz 8 months ago.
5.4.2
51073.diff (867 bytes) - added by SergeyBiryukov 8 months ago.

Download all attachments as: .zip

Change History (25)

@akissz
8 months ago

5.5 with white gap

#1 follow-up: @tw2113
8 months ago

Curious if this is a conflict coming from the theme or possibly a plugin you have installed, as I haven't seen any issue like this with any WP 5.5 install I have.

#2 in reply to: ↑ 1 @Laxman Prajapati
8 months ago

Yes, I think theme or plugin CSS are conflicted over here.

Replying to tw2113:

Curious if this is a conflict coming from the theme or possibly a plugin you have installed, as I haven't seen any issue like this with any WP 5.5 install I have.

#3 @sabernhardt
8 months ago

  • Focuses css added
  • Keywords reporter-feedback added; needs-design removed

Hi @akissz and thanks for the report!

I also think it might be a plugin causing the problem. My single-site testing environment does not show the gap in Windows 10 browsers (Chrome, Firefox, Edge, IE11).

If you still have the empty space with all plugins deactivated and using a default (Twenty-something) theme, please let us know your browser and operating system.

#4 @johnbillion
8 months ago

  • Keywords needs-testing added; reporter-feedback removed
  • Milestone changed from Awaiting Review to Future Release

This means that a PHP error has occurred on your site. WordPress 5.5 adds extra padding at the top of the admin screen in order for the error message to be visible; previously it would have been hidden.

If the error message itself isn't appearing then this might be something that the change in 5.5 isn't accounting for. I'm also seeing this blank space on a couple of sites but I haven't investigated yet.

@akissz for now, please try:

  • Checking your PHP error logs for error messages
  • Deactivating your plugins one by one to see if you can find the culprit

#5 @johnbillion
8 months ago

  • Focuses css removed
  • Milestone changed from Future Release to 5.5.1

This seems to be reproducible by redeclaring a constant in your wp-config.php file, before bootstrapping WordPress. For example:

define( 'FOO', true );
define( 'FOO', true );

#6 @SergeyBiryukov
8 months ago

This means that a PHP error has occurred on your site. WordPress 5.5 adds extra padding at the top of the admin screen in order for the error message to be visible; previously it would have been hidden.

Related: [47745] / #35155.

Previously:

See also: #28376.

Last edited 8 months ago by SergeyBiryukov (previous) (diff)

#7 @SergeyBiryukov
8 months ago

  • Summary changed from obvious css bug in 5.5 to Extra padding below the admin bar

#8 @SergeyBiryukov
8 months ago

Just noting that I was able to reproduce the issue as described in comment:4.

The .php-error class gets added to the page, but the error itself is not displayed.

This ticket was mentioned in Slack in #forums by joyously. View the logs.


8 months ago

#10 @SergeyBiryukov
8 months ago

  • Keywords has-patch added; needs-testing removed

In 51073.diff, only add the class if:

  • The error is not a notice, as notices are not displayed with the error_reporting level set in wp-load.php.
  • AND the error is not in wp-config.php, as it's the only user-editable file loaded before wp_debug_mode() runs.

This still can result in the extra padding on some environments, e.g. if wp-config.php sets error_reporting to not display warnings and there is a warning later in the file, but the chances of that are reduced significantly.

In a future release, we could try something like:

  • Saving the value of error_reporting() before it's affected by wp_debug_mode().
  • Using that to only print the class if we determine that the error was displayed according to that setting.

But that seems more complicated, and I think 51073.diff would be good enough for 5.5.1.

#11 @SergeyBiryukov
8 months ago

  • Owner set to SergeyBiryukov
  • Status changed from new to accepted

#12 @johnbillion
8 months ago

I think rather than looking at E_NOTICE specifically, we can checking the error code against the error_reporting() bitmask. That should take into account any type of error that doesn't get displayed.

#13 follow-up: @johnbillion
8 months ago

Well huh, that doesn't work because WP_DEBUG does indeed affect the error reporting level in between the error occurring in wp-config.php and the point where php-error gets added to the body class.

#14 in reply to: ↑ 13 @SergeyBiryukov
8 months ago

Replying to johnbillion:

Well huh, that doesn't work because WP_DEBUG does indeed affect the error reporting level in between the error occurring in wp-config.php and the point where php-error gets added to the body class.

Yeah, I tried to go that route, but found that the value is affected by WP_DEBUG once wp_debug_mode() runs.

This ticket was mentioned in Slack in #core by david.baumwald. View the logs.


8 months ago

#16 @SergeyBiryukov
8 months ago

  • Keywords commit added

#18 @SergeyBiryukov
8 months ago

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

In 48850:

Administration: Don't print the .php-error class in the admin header for PHP notices in wp-config.php.

Any notices in that file happen before WP_DEBUG takes effect, and should not be displayed with the error_reporting level previously set in wp-load.php.

Adding the class when there is no notice displayed results in extra padding under the admin bar, which should be avoided.

Follow-up to [20102], [21025], [26620], [47745].

Props akissz, tw2113, laxman-prajapati, sabernhardt, johnbillion, SergeyBiryukov.
Fixes #51073.

#19 @SergeyBiryukov
8 months ago

In 48851:

Administration: Don't print the .php-error class in the admin header for PHP notices in wp-config.php.

Any notices in that file happen before WP_DEBUG takes effect, and should not be displayed with the error_reporting level previously set in wp-load.php.

Adding the class when there is no notice displayed results in extra padding under the admin bar, which should be avoided.

Follow-up to [20102], [21025], [26620], [47745].

Props akissz, tw2113, laxman-prajapati, sabernhardt, johnbillion, SergeyBiryukov.
Merges [48850] to the 5.5 branch.
Fixes #51073.

#20 @dlh
8 months ago

#50763 was marked as a duplicate.

#21 @ocean90
7 months ago

#51218 was marked as a duplicate.

#22 @topher1kenobe
2 months ago

Leaving this here as a data point. I got the space and @johnbillion pointed me here, and I read his comment that setting a constant more than once can cause it.

WP-CLI has been whinging at me that WP_CACHE was already set.

I have a wp-config file that has a directive to use wp-config-local if it exists (it does). However, WP Rocket stuck the WP_CACHE constant right in the very top of wp-config, before the code calling for the local file. I'm going to register a bug report with them to test to see if it's already set before just injecting like that.

I'm on 5.6.1, 5.4.4 didn't have the issue.

Last edited 2 months ago by topher1kenobe (previous) (diff)
Note: See TracTickets for help on using tickets.