Gutenberg: ACF Metaboxes are always visible
Describe the bug
All field groups created with the Advanced Custom Fields plugin are shown as empty visible metaboxes when editing a post irrelevant of those field group's location rules.
Image above shows all field groups as empty metaboxes when editing the Hello World post.
Understanding the bug
The reason for this is due to Gutenberg removing/modifying the visibility of metaboxes during initialization. Please see example code below to replicate the issue.
Here is a little background on the problem and why this is an important one to fix before 5.0 is released...
ACF registers all field groups as metaboxes and then uses JS to hide/show them based on their location rules. This allows for dynamic updating of metaboxes when post attributes (such as category, post_format, post_parent) are being edited. This approach has allowed ACF to honor the custom metabox order and position settings set when dragging around metaboxes.
With Gutenberg activated (or WordPress 5.0 RC2), all metaboxes are shown as visible. I believe that some JS code within Gutenberg is setting the visibility of metaboxes without checking if the metabox is already hidden by custom JS.
Why this needs to be fixed
There are lots of reasons why this needs to be fixed, but I will try to win you over with just a few:
- User experience. Any user with ACF installed will run into this issue within the first few minutes of activating Gutenberg / updating to 5.0. This presents a negative user experience to those who have customized websites. Users will wonder "what else is broken"?
- Adoption. This issue unfortunately reflects badly on Gutenberg. The problem is only visible when Gutenberg is active and will ultimately lead to unhappy developers / users who have ACF installed.
To Reproduce
Here is some example code and some attachments to demonstrate the problem:
<?php
// Register a metabox.
add_action('add_meta_boxes', 'test_add_meta_boxes', 10, 2);
function test_add_meta_boxes( $post_type, $post ) {
add_meta_box( 'test-metabox', 'Test Metabox', 'test_render_meta_box', $post_type, 'normal', 'high' );
}
// Render metabox HTML.
function test_render_meta_box() {
?>
<script type="text/javascript">
(function($) {
$('#test-metabox').hide();
$('#test-metabox .inside').html('This should be hidden.');
})(jQuery);
</script>
<?php
}
?>
Expected behavior
Metaboxes hidden via custom JS should remain hidden.
Additional context
- Issue present in all versions of Gutenberg or WP 5.0
elliotcondon
All 24 comments
This happens because MetaBoxVisibility sets style.display to '' when it mounts:
One easy fix would be to update this to only update the DOM if we need to _hide_ the meta box:
componentDidMount() {
if ( ! this.props.isVisible ) {
this.updateDOM();
}
}
However the user would still be able to show the meta box again by opening _Options_ and toggling off/on the checkbox for that meta box.
@elliotcondon: Are you able to unregister the meta box using remove_meta_box() instead of hiding it with CSS? This way the meta box will be removed from both the editor and from the _Options_ modal.
noisysocks
on 4 Dec 2018
@noisysocks Thanks for the reply and info.
I'm happy to look into an alternative solution for dynamically updating metaboxes, however, it will not be possible to roll out an update to all users before Thursday's WP5.0 release.
Is it possible to "mount" the metaboxes without removing their "display" style?
This would allow Gutenberg to inherit the metabox HTML as expected.
elliotcondon
on 4 Dec 2018
Is it possible to "mount" the metaboxes without removing their "display" style?
Yes this is essentially what the change I proposed above would do. It only mitigates the bug, though, since Gutenberg needs to set style.display to '' or 'none' so that the user is able to enable and disable meta boxes via the _Options_ modal.
noisysocks
on 4 Dec 2018
That makes sense. Is this easy enough to push into the 5.0 release?
elliotcondon
on 4 Dec 2018
I'm sorry to say that it is too late in the release cycle for this to be fixed for 5.0 and that this isn't a blocking issue. I've added it to the 5.0.1 milestone which is targeted for two weeks after 5.0 is released on December 6.
As a workaround, you could look into hiding the element using an approach that doesn't modify style.display, e.g.
- $('#test-metabox').hide();
+ $('#test-metabox').addClass( 'hidden' );
Do you not realise how many millions of sites are using ACF and ACF Pro that this is going to affect? Not fixing this before the 5.0 release is ridiculous and incredibly disheartening that you're just willing to release code that breaks such a popular plugin. I bet if this issue affected Jetpack or some other Automattic plugin, it'd be fixed in minutes and magically added into the 5.0 release.
*This is Just for ACF alone
maddisondesigns
on 5 Dec 2018
I manage over 200 site owners who leverage ACF and another 31using ACF Pro. This release cycle has been among the most disappointing I've encountered. Shameful to punt this issue for two weeks, or more.
logicalphase
on 5 Dec 2018
I bet if this issue affected Jetpack or some other Automattic plugin, it'd be fixed in minutes and magically added into the 5.0 release.
Amen
webdados
on 5 Dec 2018
I assume enabling the classic editor fixes this issue? Unsure how much Gutenberg code is still included with it on
rochow
on 5 Dec 2018
@elliotcondon Is this a regression, or has it been functioning this way all along?
earnjam
on 5 Dec 2018
It’s likely that this is a regression introduced a month ago by https://github.com/WordPress/gutenberg/pull/11084.
Please let’s stay on topic. This isn’t the place to be discussing the 5.0 release process which is what it is.
noisysocks
on 5 Dec 2018
What does "super hacky approach" in https://github.com/WordPress/gutenberg/pull/11084 mean?
Wouldn't it be better to use a "non hacky approach", as WordPress 5.0 "is ready" now? Or isn't it?
bupotalovo
on 5 Dec 2018
@noisysocks have you successfully tested your pull request against ACF upfront before the merge like @youknowriad recommended?
rpkoller
on 5 Dec 2018
Apologies, I got my wires crossed there. This regression was introduced in 4.1 six weeks ago by https://github.com/WordPress/gutenberg/pull/10676.
noisysocks
on 5 Dec 2018
Hi all. We are starting to see a lot of support tickets regarding this issue. Please keep this GitHub ticket updated with your plans to address the problem.
elliotcondon
on 7 Dec 2018
12628 fixes the issue and will be shipped as part of WordPress 5.0.1 in ~2 weeks.
Hiding the meta box using $( '#test-metabox' ).addClass( 'hidden' ) or wp.data.dispatch( 'core/edit-post' ).removeEditorPanel( 'meta-box-test-metabox' ) remains the preferred workaround.
Going forward, we recommend that removeEditorPanel() or remove_meta_box() is used for cases like these.
noisysocks
on 7 Dec 2018
It sounds like we will need to release an update to fix this from our end.
It is a shame that such a little fix couldn't have been added to WP 5.0 prior to the release.
This directly effects every ACF user updating to 5.0.
elliotcondon
on 7 Dec 2018
It sounds like we will need to release an update to fix this from our end.
It is a shame that such a little fix couldn't have been added to WP 5.0 prior to the release.
This directly effects every ACF user updating to 5.0.
WordPress really screwed the pooch with Gutenberg. They say they listen to their users, but apparently not. Nobody wants this monstrosity.
Thanks so much to @elliotcondon for fixing WPs screw-up.
gmsdesignworks
on 7 Dec 2018
Yes, it's regrettable that this bug wasn't discovered and fixed in time for the 5.0 code freeze.
_Please_ let's stay on topic. GitHub is our workplace. It's important that we keep the conversation here friendly and on topic so that existing contributors are able to do their best work and new contributors are made welcome to the project.
noisysocks
on 7 Dec 2018
@noisysocks ... my apologies. I'm going to try to bite my tongue. But you should know that what you've done has negatively impacted millions of WP users only to put it on the developer of that plugin to fix your mistake. It should be WP that puts out the fix and not ACF.
gmsdesignworks
on 7 Dec 2018
Yes, it's regrettable that this bug wasn't discovered and fixed in time for the 5.0 code freeze.
Maybe if this release wasn't so rushed then it would've been found. Maybe if Gutenberg didn't constantly break backwards compatibility, it wouldn't have needed to be found in the first place.
The number of times that Elliot has had ACF working fine only for it to be broken weeks later by Gutenberg, is ridiculous! The fact that this was released, knowing that it was going to break millions of sites, is equally ridiculous.
maddisondesigns
on 7 Dec 2018
As @noisysocks mentioned, this repository is where we work: just as you wouldn't wander into someone's office and bad mouth them or their work, doing it here is equally unacceptable.
I understand that it's frustrating to run into a bug, particularly if it affects sites that you manage in production. However, that's no excuse to vent your frustration in a bug report, which exists specifically for the purpose of fixing that bug.
12628 will be in WordPress 5.0.1, which will be released in ~2 weeks. If you'd like to help ensure that it's fixed completely, I would encourage you to test that PR and see if it fixes the issue for you, particularly for more complex ACF configurations.
In the mean time, I've hidden the off topic comments in this thread. Please keep further discussion on topic.
pento
on 7 Dec 2018
Still, have this issue after updating 5.0
Any luck?
murshed
on 7 Dec 2018
@pento ... Just like Automattic to censor user feedback. If you don't like the comments, do a better job putting your stuff together. I think it's hilarious that you're going to wait 2 weeks to fix a major bug like this. There's no way I would wait that long. Heck, I wouldn't have put this kind of garbage out in the first place.
gmsdesignworks
on 7 Dec 2018
Related issues
spocke
·
3Comments
moorscode
·
3Comments
davidsword
·
3Comments
mhenrylucero
·
3Comments
maddisondesigns
·
3Comments
Most helpful comment
Do you not realise how many millions of sites are using ACF and ACF Pro that this is going to affect? Not fixing this before the 5.0 release is ridiculous and incredibly disheartening that you're just willing to release code that breaks such a popular plugin. I bet if this issue affected Jetpack or some other Automattic plugin, it'd be fixed in minutes and magically added into the 5.0 release.
*This is Just for ACF alone