WordPress.org

Make WordPress Core

Opened 4 weeks ago

Closed 4 weeks ago

Last modified 2 weeks 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 4 weeks ago.
5.5 with white gap
Screen Shot 2020-08-19 at 9.14.42 PM.png (17.3 KB) - added by akissz 4 weeks ago.
5.4.2
51073.diff (867 bytes) - added by SergeyBiryukov 4 weeks ago.

Download all attachments as: .zip

Change History (24)

@akissz
4 weeks ago

5.5 with white gap

#1 follow-up: @tw2113
4 weeks 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
4 weeks 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
4 weeks 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
4 weeks 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
4 weeks 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
4 weeks 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 4 weeks ago by SergeyBiryukov (previous) (diff)

#7 @SergeyBiryukov
4 weeks ago

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

#8 @SergeyBiryukov
4 weeks 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.


4 weeks ago

#10 @SergeyBiryukov
4 weeks 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.

@SergeyBiryukov
4 weeks ago

#11 @SergeyBiryukov
4 weeks ago

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

#12 @johnbillion
4 weeks 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
4 weeks 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
4 weeks 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.


4 weeks ago

#16 @SergeyBiryukov
4 weeks ago

  • Keywords commit added

#18 @SergeyBiryukov
4 weeks 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
4 weeks 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
4 weeks ago

#50763 was marked as a duplicate.

#21 @ocean90
2 weeks ago

#51218 was marked as a duplicate.

Note: See TracTickets for help on using tickets.