When composing a post, the Gutenberg blocks overlap the meta boxes at the bottom of the post. I cannot enter content into those blocks so I cannot complete my post using the new editor.
All meta boxes from Advanced Custom Fields Pro are shown and the other is Yoast SEO Premium.
I presume because there is no document template option that ACF conditionals are not working so it shows all those meta boxes, but that's a separate issue.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Clear separation of the content editor and the document meta boxes.
Screenshots
You can see the overlapping Title block and the eBooks and Yoast SEO meta boxes from this screenshot.
Desktop (please complete the following information):
Additional context
WordPress 4.9.8
Advanced Custom Fields PRO 5.7.7
Yoast SEO Premium 8.3
I can confirm this issue. Insert a long content into the classic block and the meta boxes will overlap this block.
Can anyone of you test with master, I'm not being able to reproduce this issue, it might have been fixed.
It persists.
Tested with a pure WordPress 4.9.8 installation and Gutenberg 4.2.0
For test purposes I installed a plugin as described in #11482
Result:
It could be a windows issue? Can you test with this zip https://builds.danielbachhuber.com/gutenberg-nightly.zip
With the nightly build it is working 👍
Thanks for the test, that's great news. I'm going to close this, this will be released in the 4.3 version.
I installed Gutenberg 4.3.0-alpha-1ac70e1 on my 4.9.8 site and the problem persists.
@DeveloperWil Interesting, I'm reopening so we can investigate more, but it's not going to be an easy fix if we can't reproduce reliably.
@DeveloperWil could you deactivate Advanced Custom Fields PRO and
Yoast SEO Premium? Then install the plugin as described in #11482 for test purposes?
I had also tested (like you) with windows 10 64bit and Chrome, WP 4.9.8 etc and Gutenberg 4.3.0-alpha-1ac70e1 (but nothing else installed) and the bug has been fixed.
Firefox
Ubuntu 14.04
WP 5.0-beta3-43878
Gutenberg nightly build https://builds.danielbachhuber.com/gutenberg-nightly.zip
registered a lot of metaboxes.
My issue from #11482 does not really persist.
@gziolo modified the milestones: 4.3, WordPress 5.0 5 days ago
This is not fixed in Gutenberg 4.3.0 and it is not fixed in WP 5.0-beta3-43891.
I'm not sure if this is related, but if it is, you can replicate this by enabling the Sharing Buttons in the Jetpack plugin. As you can see in the screenshot, the sharing buttons meta box overlaps the Gutenberg blocks. This could however be a bug in Jetpack (and the All in One SEO plugin, which has the same issue, as you can see in the image)
If this is a bug in those two plugins, please let me know and I'll log issues with each project.
I am crossreferencing this issue from TwentyNineteen https://github.com/WordPress/twentynineteen/issues/599 as this issue also seems to address metaboxes and the editor field (while from a slightly different angle)
The same bug exists with Genesis Framework 2.7.1 (Gutenberg ready) and Gutenberg 4.4.0
I've found a way to reproduce, however only on 4.4, not in master. So it's worth trying to figure out when/how it was fixed.
Result of the above steps in 4.4:
Result of the above steps in master:
☝️ Note that the coral color is one i added in the debugger, to the editor-writing-flow__click-redirect
element, which initially appeared to be the one misbehaving.
I have tested this in Chrome and Firefox on Windows and Mac.
When I initially investigated, it looked like it was bad flexing of the editor-writing-flow
and the .editor-writing-flow__click-redirect
. However as noted, I can't reproduce this issue in master, despite the code appearing unchanged. Let's try and figure out what changed here recently.
Would appreciate if someone could test this issue in master and see if the issue persists there.
I'm not sure if this is related, but if it is, you can replicate this by enabling the Sharing Buttons in the Jetpack plugin. As you can see in the screenshot, the sharing buttons meta box overlaps the Gutenberg blocks. This could however be a bug in Jetpack (and the All in One SEO plugin, which has the same issue, as you can see in the image)
If this is a bug in those two plugins, please let me know and I'll log issues with each project.
As it turns out my 'bug' was related to the Divi theme and not the Jetpack or All in One SEO plugins.
Activating Twenty Seventeen and running the master branch of the plugin, everything works fine.
Thanks for the followups and testing.
While I see that this bug is closed, I too have this issue with the Meta Blocks floating over the WP editor blocks. I tried disabling my current theme (Theme.co Pro) as well as Yoast. This was on a dev site with minimal plugins. I will try deactivating all plugins to see if I can identify a conflict. I'm using 5.0-RC1.
Updated: Found the conflicting Plugin - Shortcake (Shortcake UI) - https://wordpress.org/plugins/shortcode-ui/
After disabling that, all looks good.
I am still getting this issue with 4.9.8 and Gutenberg 4.5.1
I also get 3 lots of the following error in the console in Chrome:
wp-seo-premium-metabox-830.min.js?ver=8.3:109 Uncaught TypeError: (0 , i.getI18n) is not a function
at t (wp-seo-premium-metabox-830.min.js?ver=8.3:109)
at Object.
at e (commons-premium-830.min.js?ver=8.3:1)
at window.yoastPremiumWebpackJsonp (commons-premium-830.min.js?ver=8.3:1)
at wp-seo-premium-metabox-830.min.js?ver=8.3:1
I have reproduced this with a small testcase.
Step 1: Have a metabox on the page. Can be custom fields (More Menu > Options > Custom Fields)
Step 2: Put the following in functions.php:
add_action('init', iAmError);
Step 3: Reload and behold the error.
The issue appears to be that a plugin throws a PHP error, but this error often isn't visible in the admin, because the actual error message is either hidden because it's just a warning and those are hidden by default on most hosts, or because it's covered by the adminbar.
Additionally this is compounded by the editor _seemingly working fine_, when in fact it's partially in an error state.
To further elaborate, this error is probably still present on an editor page without metaboxes enabled. But the error just is not apparent because there are no metaboxes to show the erroring state.
Can we handle these errors better?
This is an issue for us as well. We found the results below while our custom theme and a bunch of plugins are activated (including YoastSEO):
Functions correctly with meta boxes appearing at the bottom of the page blocks when using:
Meta boxes overlap the page blocks when using:
@SJNBham So far the only way I have been able to reproduce this, is by having a plugin that throws an error in WordPress 5.0.
Can I kindly ask you to try and deactivate your plugins and see if that works? If it does, please reactivate them one by one so we can figure out which one is causing the error, that will help me reproduce and debug this.
Another way to reproduce this without causing an error under WP 5.0-RC1-43945:
add_action( 'enqueue_block_editor_assets', function() { echo '<style></style>'; } );
That produces no console or PHP error, but content overlays meta boxes.
@jasmussen If I disabled all plugins except Gutenberg, activate the Twenty8teen theme, use a default page template, and select to show custom fields, the overlap issue is presented.
I switched to one of our most basic sites that's only had two plugins activated on it (Google Analytics Dashboard for WP and Gutenberg). It uses the Dynamic Seventeen theme and the meta boxes align correctly at the bottom of the content blocks. I switched to the Twenty8teen theme just to make sure I was comparing apples to apples and the meta boxes continued to behave correctly.
We're running WordPress 4.9.8 and Gutenberg 4.5.1
Update: The site we were seeing this issue on was a staging site of our production site. We discovered there are errors being presented on our staging site (we're hosting with WPEngine and testing PHP 7.2 upgrade). I believe WPEngine is aware of the error and working on it.
"Parameter 1 to wp_default_scripts() expected to be a reference...."
When I activated Gutenberg on our production site, the meta boxes appear to be aligning at the bottom as desired.
So maybe this is related to how errors are being handled as stated earlier?
For those of you experiencing this issue, can you please try the following debugging steps and get back to me?
javascript:window.alert('You are in ' + (document.compatMode==='CSS1Compat'?'Standards':'Quirks') + ' mode.')
Please report back what message you are getting.
@jasmussen I see “You are in Quirks mode” when using the add_action( 'enqueue_block_editor_assets', function() { echo '<style></style>'; } );
snippet in a theme's functions.php file from above.
(It's because <style></style>
is emitted before <!DOCTYPE html>
, forcing quirks mode.)
So regular invalid HTML could trigger this too as well as errors emitted by PHP.
Thank you for verifying, @nickcernis, yes indeed. It seems that the flex rules that size the main editing canvas behave differently when in quirks mode compared to standards mode. I'm looking at some options.
@jasmussen - I activated that plugin I mentioned before (that was causing the issue) and put the code you suggested into the console. I see the "You are in Quirks mode" on that instance with the plugin active.
When I deactivate that plugin and reload the post page, I get the "You are in Standards mode". Hope that helps.
@HighTechDad That does help a lot, yes. I have some ideas for how to mitigate this, but weighing the options. If I'm right, then it means there's a small issue with the Shortcake UI plugin that's causing the issue, and ideally it's fixed there. But I'll get back when I have something to share.
@jasmussen - I don't really use that Shortcake UI plugin. I just happened to have it on my dev site where I'm testing WP 5.0. I'm sure there will be/are many plugins that haven't been updated in a while that may cause the issue to manifest. I just know that with that particular plugin, it's easy to test and reproduce. (Just worried when 5.0 rolls out, there will be many other plugins that will have "small issues" and cause frustration.)
Thanks for keeping this thread alive, even though this particular issue is marked as "Closed." Perhaps it's time to re-open...
I reached out to the support team for Yoast SEO and they saw this ticket was closed so said it was a WordPress issue that will be addressed with a newer version of WordPress eventually. I'm mentioning this because other vendors may give the same response if they see this ticket closed. Also the fact that it's very likely other plugins will have an error in them that will trigger the compatibility mode. So finding a solution to gracefully fall back when compatibility mode is active would be great. Thanks for your work on this!
Yep discussion is never closed. I'm still trying to figure out where and how the issue appears, and depending on the details, the issue will either be reopened or a new one created based on the learnings here. Thanks for your patience.
You are in Quirks mode for me too
So I just came across this in 5.0 RC1. Standards mode, no PHP errors, no JS errors.
Turns out my issue was that my theme had this in an editor-styles.css
file:
body {
height: 100%;
}
which got rendered as inline css to the editor screen as:
.editor-styles-wrapper {
height: 100%;
}
So looks like bad editor styles are another possible culprit for this issue.
Good catch, @earnjam. I would suggest that is a separate issue, though (and feel free to open one with steps to reproduce). This is related to the fact that the editing canvas is not in an iframe, and if you are not mindful you can write editor styles that affect the surrounding UI, such as this:
* {
border: 13px solid mediumaquamarine;
}
The editor styles can definitely use some improvements as far as scoping goes, and it would be nice to start to collect the issues we mean to address, I think a few have been noted here and there. But in this case, WordPress themes have to explicitly opt in to using editor styles, so hopefully this is the sort of thing that will be caught in development of said style. Perhaps the solution to this particular issue is to note it in a "best practices" section under the theme support docs?
Okay, I created a pull request as a proof of concept that mitigates this, but given it's an error not with Gutenberg, I don't think it should be merged. But hopefully it can inspire some better ideas as to how to help the user or developer of the plugin that's putting Gutenberg in quirks mode fix the issue. Please share your thoughts and observations on the PR: https://github.com/WordPress/gutenberg/pull/12455
@jasmussen Yeah, I just wanted to note another cause of the issue described in the original post.
The only concern I would have about the opt-in part is that this particular theme opted in for editor styles in the old editor. It hasn’t been updated in a while and thus hasn’t been updated to support the new block editor.
So there is no way to know how many existing themes may have editor styles that work fine in the classic editor but will cause issues like this in the block editor.
I’m not sure there is a solution to that problem except maybe some defensive CSS for known rules that can cause problems.
Nevermind it was updated November 20. Maybe they just made a mistake in testing. I’ll investigate further.
I believe that is one of the reasons why Gutenberg requires theme developers to explicitly opt in to support the new editor styles: https://wordpress.org/gutenberg/handbook/designers-developers/developers/themes/theme-support/#editor-styles — to my knowledge, old editor styles shouldn't load unless a theme author says they are good to load. And if they do, in many cases the styles should translate 1:1 — but the opt in should suggest a testing step there.
Here's my newest attempt at mitigating and causing developer awareness of the plugin conflicts that might cause this: https://github.com/WordPress/gutenberg/pull/12575 — please share your thoughts.
I had this issue and it was caused by Form Maker Plugin thanks for the info on "Quirks Mode" it would have taken forever for me to figure this out! I created a Post on this issue on my WordPress site. I am currently using WP version 5.0.2 on Debian 9 with php 7.2.13
I was having this issue with Yoast SEO and Postmattic. My browser was in Quirks mode becuase of the WP Rainbow Hilite plugin. Disabled for now and now the problem is gone.
I can tell you that the problem of blocks overlapping (actually disappearing under) meta boxes on pages using Gutenberg still exists, and prevents us from making changes or additions to the page.
Some people seem to think it's been fixed, but it's not.
I am using:
Google Chrome browser.
WordPress 5.1
Theme: Nirvana Version: 1.5.1.1
Yoast SEO metabox is the first one that shows the problem; there are others.
And, no it's not a Windows thing; I'm experiencing this on an iMac.
Note that when I switch to Firefox, it doesn't show the same problem -- at least on one page I tried.
If you need anything more to help track this down, let me know...
Thanks for the report.
If you need anything more to help track this down, let me know...
Can you open the JavaScript console and see if there are any messages there? In Chrome, mac it's ⌘⌥J, in Firefox it's ⌘⌥K, in Safari you first have to enable it, instructions here: https://support.airtable.com/hc/en-us/articles/232313848-How-to-open-the-developer-console
Depending on whether or not there's a message in the console, the next steps depend on that. Thanks.
Here's a screen capture that resulted when I said "Edit Page" on my chosen
page (attached).
Note that I cleared the console before doing the edit page.
https://user-images.githubusercontent.com/1204802/54151216-a0ea1c80-443a-11e9-8ea7-9f34965840c7.png
I hope it helps!
Bryan
I hope you got the screen capture!
Thank you Bryan, yes, the screenshot got through. I edited your comment to link to it so it's easier to see.
And indeed, it was helpful. In the screenshot there's a warning that says the browser is in "Quirks Mode". This mode is what's causing the metaboxes to overlap, and it is almost certainly caused by a plugin that is adding content to the page in a non-standard way and needs an update. It _can_ be the WordPress theme, but that is less likely.
If you are able, can you try to deactivate plugins, one at a time, then reloading the editor to see if it starts working as it should? Not necessary to deactivate all at once, just one at a time then reload the editor each time. When you find the one plugin that when deactivated makes the editor work, then let me know here. I can then reach out to the developer and offer advice and help on how to update that plugin to work with the editor. Thanks!
I can't do this on our live website, but I'll see if I can do something to
reproduce the issue on another, development, website. Stay tuned...
FWIW, I did the same Javascript console capture on Firefox, which doesn't
seem to experience the behavior, using edit page on the same page as before.
Here's the result (attached). Perhaps comparing it with the Chrome capture
might shed some light?
I tried to reproduce this on several other websites, even installing Yoast SEO if it wasn't already installed. Unfortunately, I was unable to reproduce the behavior on those sites, which means deactivating plugins wouldn't do much good.
Did the second console capture come through?
I did not see the attachment. If you respond to these messages via email, I don't think attachments sow up. I think you have to go here to Github via the browser in order to add images.
I suspect that Firefox will show the same error message, but perhaps the browser rendering engine has a better way of handling what's referred to as "quirks mode". The best solution is still to find the problematic plugin and ask the developer to submit a fix for that. But I suppose if Firefox is working well for you at the moment, then that can serve as a workaround. I totally understand why you can't test this in production.
An alternate way we can debug: can you send me a complete list of the plugins you use on your website? Then I can test them one by one, see if I can reproduce it.
I've been having the same problem as well. Installing the Disable Gutenberg plugin fixes the issue and the "Quirks Mode" message disappears, but that's not a good long term solution.
I've tried going through and disabling plugins on my local version of Wordpress. I've verified that 26 of my plugins don't cause the issue, but turning on any of these 5 causes the issue to come back:
Social Warfare - Pro
Table of Contents Plus
TablePress Extension: Responsive Tables
WP Hide Post
WP Tab Widget Pro
Thank you for the report, Joe! I will try those plugins and see if I can narrow down the issue, and return with more info here.
Thanks! Interestingly I didn't install any of those Plugins today when the error started (don't think I updated them either although I could be wrong).
I've been making a few changes to my site with Elementor pro which is what i first thought would be causing the issue, but deactivating that doesn't change anything.
The explanation for why the issue appears is a little technical, but the gist of it is this:
What causes a webpage to become invalid? In this case it's likely that a plugin outputs some extensions into the editor markup that causes it to break. If it works as intended in the classic editor, this is likely because browsers _guess correctly_ as to the rendering due to any number of differences in the markup. Since it has appeared to work correctly, the bug in these plugins has likely gone unnoticed so far.
The fix to the plugins causing these issues is relatively trivial: just output the extensions in a place that doesn't break the markup validity. So once we know which plugins cause this, it should be easy to reach out with suggested fixes.
If Firefox guesses correctly, then that would be a suggested workaround until the plugins can update themselves. Thanks for your patience.
Joen --
I just added the screen capture to my message on Github. I hope it helps.
Bryan
FWIW, I took a look at the list of plugins that Joe-Clements126 listed:
Social Warfare - Pro
Table of Contents Plus
TablePress Extension: Responsive Tables
WP Hide Post
WP Tab Widget Pro
I use none of these plugins on my website.
Sure. Here's the system information that Elementor provides -- it's a
convenient source of what you're looking for, although I'm not using
Elementor on this site terribly much. When I move this site to a new one,
that will change.
See attached...
== Active Plugins ==
Add From Server
Version: 3.3.3
Author: Dion Hulse
Akismet Anti-Spam
Version: 4.1.1
Author: Automattic
Antispam Bee
Version: 2.9.1
Author: pluginkollektiv
Auto Update Plugins
Version: 0.1.4
Author: Geenyous Limited
Better Font Awesome
Version: 1.7.1
Author: Mickey Kay
Black Studio TinyMCE Widget
Version: 2.6.8
Author: Black Studio
Broken Link Checker
Version: 1.11.5
Author: Janis Elsts, Vladimir Prelovac
Classic Editor
Version: 1.4
Author: WordPress Contributors
Contact Form 7
Version: 5.1.1
Author: Takayuki Miyoshi
Contact Form 7 Style
Version: 3.1.8
Author: Johnny, dorumarginean, mlehelsz, MirceaR
Cryout Serious Theme Settings
Version: 0.5.9
Author: Cryout Creations
Custom Menu Wizard
Version: 3.3.1
Author: Roger Barrett
Easy Google Fonts
Version: 1.4.4
Author: Titanium Themes
Elementor
Version: 2.5.5
Author: Elementor.com
Google Analytics Dashboard for WP (GADWP)
Version: 5.3.7
Author: ExactMetrics
Howdy Tweaks
Version: 2.3
Author: Kailey Lampert
Jetpack by WordPress.com
Version: 7.1.1
Author: Automattic
Members
Version: 2.1.0
Author: Justin Tadlock
My Custom Functions
Version: 4.35
Author: Space X-Chimp
myStickymenu
Version: 2.0.6
Author: m.r.d.a
Nav Menu Roles
Version: 1.9.3
Author: Kathy Darling
Page Links To
Version: 3.0.1
Author: Mark Jaquith
Popup Builder
Version: 3.1.7.1
Author: Sygnoos
Profile Builder - Email Confirmation Field
Version: 1.0.4
Author: Cozmoslabs, Adrian Spiac
Profile Builder - Numbers and Phone Validation
Version: 1.0.1
Author: Cozmoslabs, Cristian Antohe
Profile Builder Pro
Version: 2.9.7
Author: Cozmoslabs
Search Exclude
Version: 1.2.2
Author: Roman Pronskiy
ShareThis Share Buttons
Version: 1.1.8
Author: ShareThis
Simple History
Version: 2.29.2
Author: Pär Thernström
SSL Insecure Content Fixer
Version: 2.7.2
Author: WebAware
Tela Albums: Google Photo Albums for Wordpress
Version: 1.5.2.8
Author: Isaac Brown
Timeline Express
Version: 1.8.0
Author: Code Parrots
TinyMCE Advanced
Version: 5.1.0
Author: Andrew Ozz
Title Remover
Version: 1.2
Author: WPGurus
Visual Form Builder
Version: 2.9.9
Author: Matthew Muro
WP-VR-view - Photo Sphere and 360 video
Version: 1.6
Author: Tumanov Alexander
WP Mail SMTP
Version: 1.4.1
Author: WPForms
WP Media Category Management
Version: 1.9.3
Author: DeBAAT <[email protected]>
WP UI - Tabs, accordions and more.
Version: 0.8.8
Author: Kavin
Yoast SEO
Version: 10.0
Author: Team Yoast
I was having this same issue too, so I compared our list of plugins and deactivated Popup Builder. That fixed the issue for me.
So, I tried deactivating Popup Builder on my site, and the bad behavior
went away, at least on a page where it was present before.
I think we have found a culprit (perhaps one among many...)
Thank you, Elizabeth!
Thank you everyone, for the feedback! This is sure to be helpful to others searching. For now I will double-test popup builder and reach out to the developer of Popup Builder with advice and suggestions for a fix. Hopefully we can get this fixed up soon! Much appreciate all the feedback.
FWIW, I replaced Popup Builder with Popup Maker (which I was going to do, eventually, anyway).
It does not appear to have the same negative effects as Popup Builder.
I tried today, and I could not reproduce the issue with popup builder. That doesn't mean there is no issue, perhaps it means that you have to use popup builder in a particular way, or in a particular server environment. For example if it outputs an error message in the source code, that would cause it too.
I have reached out to the developer, they seem to be very active and responsive in their forums. It feels like they might be able to address this quickly, as their last update was a week ago. Thanks for the reports!
Thanks for looking into this. I had a developer working on my site today and he was sure this was Elementor causing the issue.
This is what he came back with, which I have passed on to them.
"Inside of elementor/includes/utils.php within the Elementor plugin there is a function which is injecting script tags into what should be normal JSON responses.
The below function is causing the trouble since you can't just randomly send ' . PHP_EOL;}
It would be great if you could update your plugin to determine if the request/response is JSON before fiddling with this output"
I've just received feedback from the developer of Popup Builder that they expect a fix to land in the next version. I've not been able to verify this, but it's cool to see such a fast response 👏
Hi guys, thank you for all your sharing. Regarding issues with Popup Builder, the problem that breaks the visual editor is that new button they added to editor. This is the fix (remove that button)...
Go to the following file on your site: your_wordpress_folder/wp-content/plugins/popup-builder/com/classes/Actions.php
Remove the 26 line: add_action('mce_external_plugins', array($this, 'editorButton'));....
This should solve the problem.
I use WP 5.1.1 and it solved the problem for me in all my sites.
Just wanted to report that the overlapping issue is also caused by Ninja Forms 3.4.4., beta4, and WP 5.1.1.
@alkah3st I am unable to replicate this issues with just the Ninja Forms plugin version 3.4.4 and the 2019 WordPress theme activated on WP 5.1.1 It appears that the issue that you are seeing is being caused by the ACF 5.8.0 Beta4 plugin.
Hmm, when I leave everything deactivated except ACF Beta 4 and Yoast, I don't get overlapping. The instant I turn on Ninja Forms, the overlapping starts happening. I can create a staging instance to demonstrate this if you like.
Update: Looks like, Ninja Forms outputs this error:
| SELECT title
, created_at
, form_title
, default_label_pos
, show_title
, clear_complete
, hide_complete
, logged_in
, seq_num
| FROM wp_k5n_nf3_forms
| WHERE id
= 2
When there's no title assigned to a form (something that's allowable in Ninja Forms). So this error gets dumped at the top of the doc, before the HTML declaration, causing the editor to enter Quirks Mode.
Not sure if this is of any help...but when I have a PHP warning while WP_DEBUG is active the overlap issue occurs. When I resolve the PHP warning the overlap goes away.
@alkah3st I am unable to replicate this issues with just the Ninja Forms plugin version 3.4.4 and the 2019 WordPress theme activated on WP 5.1.1 It appears that the issue that you are seeing is being caused by the ACF 5.8.0 Beta4 plugin.
I have the ACF Beta4 on all sites I am currently developing and I have no overlap issues on those sites.
To be clear, this is just a warning to anyone using Ninja Forms, as the issue comes from Ninja Forms injecting its error before the HTML declaration, which causes the document to go into Quirks Mode (as it does for other people with similar issues with different plugins in this thread).
Thanks all, for the great bug reports here. All of your information is valuable in us figuring out how we can mitigate and harden this in the future.
@ellatrix I see some reports that the TinyMCE external plugins feature may be causing some PHP errors — this would also cause the overlapping to occur since it puts the browser in quirks mode. Do you know if there's anything we can do to prevent this from happening? Anything from not loading external plugins in Gutenberg, to outputting the PHP error in a different place? Thanks Ella.
There are multiple issues opened with this same problem and there seem to be multiple sources. I ran into it as well, for me the issue was not silent php errors. The issue was that my theme css had a rule setting the body element's height to 100%. The way Gutenberg handles editor styles is by transforming your theme's css:
In the classic editor, the editor stylesheet is loaded directly into the iframe of the WYSIWYG editor, with no changes. Gutenberg, however, doesn’t use iframes. To make sure your styles are applied only to the content of the editor, we automatically transform your editor styles by selectively rewriting or adjusting certain CSS selectors. This also allows Gutenberg to leverage your editor style in block variation previews.
The result in my case is that body { height: 100% }
becomes .editor-styles-wrapper { height: 100% }
. This is the css rule that caused the plugin metaboxes to overlap the editor. Removing height: 100%
from the body element fixed the issue for me.
The result in my case is that body { height: 100% } becomes .editor-styles-wrapper { height: 100% }. This is the css rule that caused the plugin metaboxes to overlap the editor. Removing height: 100% from the body element fixed the issue for me.
Thank you for sharing that, @bitwitch! @youknowriad this feels like something we should mitigate. Do you think we should either remove that height when rewriting, or create a separate rule in the new "normalization" stylesheet that overrides the height to always be auto, perhaps with an !important and an inline comment?
May I ask why there's a body { height: 100% }
in the editor styles?
The main reasons for the fact that the editor styles are opt-in in Gutenberg is the fact that the old editor styles are not usable directly. Theme authors should check whether their styles are "compatible" and then enable them.
I'm not sure we should introduce hacks like this.
May I ask why there's a body { height: 100% } in the editor styles?
The primary reason to do this is usually to create websites that use the full height of the browser window for elements. For example if you have an "above the fold" splash element on your homepage, one that's always 100% tall. Or if you need to bottom align something on a page that doesn't scroll.
Admittedly this is very much a front-end thing, and not something you would normally put in the editor style. In that vein, I buy your argument indeed. My thought in perhaps opening a separate ticket is to take yet another small baby step towards a future where the editor style doesn't have to be different from the frontend style. Though perhaps this particular one is a task to revisit at a later time.
May I ask why there's a body { height: 100% } in the editor styles?
The reason for such a rule in my case is because we do not use a separate stylesheet for the editor. We minify the entire site's css into a single file, including all the css for custom blocks. The body height: 100 rule is for elsewhere on the site. My intention in posting was to help out others who may have the same source of problem as me, not necissarily to recommend introducing a workaround on gutenberg's end.
I don't have much to add other than to say I have had the same issue (Yoast SEO blocking text on the page editor) to the point of making it barely usable.
@PhotoCoog usually this is a plug-in issue.
Can you open the JavaScript console and see if there are any messages there? In Chrome, mac it's ⌘⌥J, in Firefox it's ⌘⌥K, in Safari you first have to enable it, instructions here: https://support.airtable.com/hc/en-us/articles/232313848-How-to-open-the-developer-console
Depending on whether or not there's a message in the console, the next steps depend on that. Thanks.
It has the following which actually mentions the issue! Any way to fix it?
JQMIGRATE: Migrate is installed, version 1.4.1
edit-post.min.js?ver=3.1.11:12 Your browser is using Quirks Mode.
This can cause rendering issues such as blocks overlaying meta boxes in the editor. Quirks Mode can be triggered by PHP errors or HTML code appearing before the opening . Try checking the raw page source or your site's PHP error log and resolving errors there, removing any HTML before the doctype, or disabling plugins.
@PhotoCoog Thanks for looking!
This means there there is a plugin or a theme on your website that needs an update. One way to test is disable plugins one by one and figure out which one makes the editor render correctly, but I realize this is tricky to do on a production site. As an alternative, feel free to send me a list of the plugins you're using, and I can test them one by one for you, and see which one causes the issue. Once we find the culprit, I can reach out to the developer to suggest a fix.
Fix this issue from style for the dashboard.
Add this hook in your theme, functions.php
// Add style for dashboard, overlap meta boxes on posts(editor)
add_action('admin_head', 'custom_metabox_style');
function custom_metabox_style()
{
echo '';
}
@rendergraf Can you open the JavaScript console and let me know if you see a warning there? In Chrome, mac it's ⌘⌥J, in Firefox it's ⌘⌥K, in Safari you first have to enable it, instructions here: https://support.airtable.com/hc/en-us/articles/232313848-How-to-open-the-developer-console
I've tried that overflow trick in the past, and there are unfortunate side effects to it. Additionally, if you _do_ see a warning in the JS console, it means there _is_ a conflict with a plugin, and the real fix is to fix that plugin.
@jasmussen in the console does not show any error related to admin_head.
everything works correctly
Interesting! Thank you for getting back to me with that.
If you open the web inspector, is the first thing in the document the doctype? I.e. ? Or is there anything before that?
No, in my case is:
Please, if you need more information about hook admin_head, can you see documentation oficial:
https://developer.wordpress.org/reference/hooks/admin_head/
I hope it helps you
In my case the problem was in a CSS code echoed on admin_menu hook, changed the hook to 'admin_bar_menu' and everything seems to be okay
Fix this issue from style for the dashboard.
Add this hook in your theme, functions.php
// Add style for dashboard, overlap meta boxes on posts(editor)
add_action('admin_head', 'custom_metabox_style');function custom_metabox_style()
{
echo '';
}
that works
but why it is not fixed in WP itself still.
I run in this problem yesterday, after i upgraded to Google Chrome Version 77.0.3865.75 on my mac. I disabled all Browser Plugins, the Problem still exists.
The editing is working normal on Google Chrome 76. I upgraded Chrome to Version 77 on this machine and the problem also appears.
I also tested with Chrome Canary Version 79.0.3912.0 (Offizieller Build) canary (64-Bit) without problems.
And i tested with firefox. Also no problems.
I run in this problem yesterday, after i upgraded to Google Chrome Version 77.0.3865.75 on my mac. I disabled all Browser Plugins, the Problem still exists.
The editing is working normal on Google Chrome 76. I upgraded Chrome to Version 77 on this machine and the problem also appears.
I also tested with Chrome Canary Version 79.0.3912.0 (Offizieller Build) canary (64-Bit) without problems.
And i tested with firefox. Also no problems.
Upper solution doesn't help me, i try edit this hook and its works for me.
// Add style for dashboard, overlap meta boxes on posts(editor)
add_action('admin_head', 'custom_metabox_style');function custom_metabox_style()
{
echo '';
}
I'm seeing this same problem across several sites that updated to 5.2.3. ACF, Yoast and RevSlider settings cover the post content and if collapsed will stay in the middle of content when you scroll. Tried to isolate by turning off plugins and using one at a time and behavior is the same.
I confirm.
Plugins: Yoast, ACF
Firefox 69.0
Chrome 77.0.3865.75
This piece of code fixes a bit Chrome behaviour
add_action('admin_head', 'custom_metabox_style');
function custom_metabox_style()
{
echo '<style>
.block-editor-writing-flow {
height: auto;}
</style>';
}
metaboxes are at bottom now but some lags persist
add_action('admin_head', 'custom_metabox_style');
function custom_metabox_style() {
echo '<style>.block-editor-writing-flow { height: auto; }</style>';
}
Works for me.
Win10, Google Chrome
Can confirm this issue exists in Chrome 77.0.3865.75 on MacOS.
The above solutions regarding adding height: auto;
to .block-editor-writing-flow
or overflow: auto;
to .editor-writing-flow
did not work for me. The solution for me was adding:
add_action( 'admin_head', 'fix_overlapping_blocks' );
function fix_overlapping_blocks() {
?>
<style>
.edit-post-layout__content .edit-post-visual-editor {
flex-basis: auto; // override the default flex-basis: 100%;
}
</style>
<?php
}
@TylerB24890
i can confirm your css solution.
Same solution worked for me.
Best
Patrick
Happening on 4 sites in 5.2.3 for us. TylerB's fix worked for me, though you should remove the // comment since that's not a valid CSS comment.
You can also run this in the console as a temporary fix:
document.querySelector('.edit-post-layout__content .edit-post-visual-editor').style.flexBasis = 'auto'
.block-editor-writing-flow {
height: auto;}
Worked for me!
document.querySelector('.edit-post-layout__content .edit-post-visual-editor').style.flexBasis = 'auto'
this works as a temporary solution, but why is it not added to the core by default?
You can also use:
#editor .edit-post-layout__content {
display:block;
}
With this the editor will show its content always, and not shrink down when your mouse enters a meta-box.
Here is what fixed it for me, which is combinition of both solutions.
add_action( 'admin_head', 'fix_overlapping_blocks' );
function fix_overlapping_blocks() { // fix the admin edit post with metabox
?>
<style>
#editor .edit-post-layout__content {
display: block;
}
#editor .edit-post-layout__content .edit-post-visual-editor {
flex-basis: auto; /* override the default flex-basis: 100%;*/
clear: both;
}
</style>
<?php
}
Fix with this:
/* sort out floating metaboxes issue */
in file 'post_edit_styles.css'
.block-editor-page .edit-post-visual-editor.editor-styles-wrapper {
min-height: unset;
}
Enqueue only on admin:
function function_name( $hook){
$screen = get_current_screen();
if ( ! is_admin() && $screen->id !== 'edit-post' ) {
return;
}
$datetimeversion = date('YmdHis');
wp_enqueue_style( 'post_edit_styles', plugin_dir_url( __FILE__ ) . 'css/post-edit-page.css', array(), $datetimeversion, 'all' );
}
Most helpful comment
Can confirm this issue exists in Chrome 77.0.3865.75 on MacOS.
The above solutions regarding adding
height: auto;
to.block-editor-writing-flow
oroverflow: auto;
to.editor-writing-flow
did not work for me. The solution for me was adding: