Extra padding below the admin bar

[akissz]

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...

[akissz]

5.5 with white gap

[akissz]

5.4.2

[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.

[Laxman Prajapati]

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.

[sabernhardt]

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.

[johnbillion]

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

[johnbillion]

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 );

[SergeyBiryukov]

Related: [47745] / #35155.

Previously:

• [26620] / #26312
• [20102], [21025] / #19196

See also: #28376.

[SergeyBiryukov]

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.

[SergeyBiryukov]

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.

[johnbillion]

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.

[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.

[SergeyBiryukov]

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.

[johnbillion]

LGTM

[SergeyBiryukov]

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.

[SergeyBiryukov]

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.

[dlh]

#50763 was marked as a duplicate.

[ocean90]

#51218 was marked as a duplicate.

[topher1kenobe]

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.