Carbon-fields: Post Meta Fields not visible while using Gutenberg

[SteveRyan-ASU]

Version

• Carbon Fields: 2.2.0
• WordPress: 4.9.8
• Gutenberg: 4.5.1 (latest, plugin)

Behavior

Post meta Carbon Field containers were visible under the normal Gutenberg block editor space. With an upgrade of Gutenberg to the latest version, the post meta boxes are now no longer displayed.

Container definition

Container that can be used to replicate the issue can be found in the documentation. (Works with any post meta container, defined to display on either native or custom post types.)

Container::make( 'post_meta', 'Custom Data' )
    ->where( 'post_type', '=', 'page' )
    ->add_fields( array(
        Field::make( 'map', 'crb_location' )
            ->set_position( 37.423156, -122.084917, 14 ),
        Field::make( 'sidebar', 'crb_custom_sidebar' ),
        Field::make( 'image', 'crb_photo' ),
    ));

Comments

The post meta boxes actually DO render on the screen using the latest version of Gutenberg. But they are accidentally hidden with a CSS rule which apparently no longer applies in the latest (stable) version of the plugin.

The CSS in question here can be found on lines 5-6 within _containers.theme-options.css

#poststuff .carbon-box,
#poststuff .spinner.disabled { display: none; }

[SteveRyan-ASU]

I mostly created this issue to document a relatively simple fix for themes using Carbon Fields while the 3.0 version (with full Gutenberg support) is finalized.

Changing the display:none; to display:block; above fixes the problem enough to render Carbon Fields usable with the current beta versions of Gutenberg plugin.

Untested with the latest WP 5.0 RC. (Working on it.)

[SteveRyan-ASU]

Adding this to your theme's functions.php should address the problem on any post type which is currently using both Carbon Fields and Gutenberg. (Note: This loads the rule across the whole admin, which is overkill but also dead simple.)

// Address visibility problem with Carbon Fields and the latest (beta) version of Gutenberg.
function make_carbonfields_great_again() {
    echo '<style>
    .edit-post-layout__metaboxes #poststuff .carbon-box,
    .edit-post-layout__metaboxes #poststuff .spinner.disabled {
        display: block;
    }
    </style>';
}
add_action('admin_head', 'make_carbonfields_great_again');

[dameer]

Sorry for my ignorance, but wouldn't it be better to just enqueue (admin_enqueue_scripts) the above as a separate CSS file?

[SteveRyan-ASU]

Yes, it probably would be, and using that hook also allows you to target the correct page in the admin on which to load the CSS - post.php

That would end up looking something like the function below.

```
function make_carbonfields_great_again($hook) {

if( $hook != 'post.php' ) 
    return;

    wp_enqueue_style( 'carbonfields-gutenberg-fix', get_template_directory_uri() . '/carbonfix.css' );

}
add_action('admin_enqueue_scripts', 'make_carbonfields_great_again');

[dameer]

Good patch. So far so good :)

[ghost]

FYI thid doesn't work for containers that are positioned below title but above the editor ->set_context( 'carbon_fields_after_title' )

I looked at page source and in inspector, the fields and code that's 'after_title' isn't even on the page. Probably need to simply not set container context to 'after title'.

There is also the Classic Editor plugin that enables switching posts individually to blocks or use classic 4.x style editor.

[jorostoyanov]

Hey guys!

We have been working lately on Carbon Fields v3 with support for Gutenberg and I am excited to share that Release Candidate is now available.

You can install it via Composer:

composer require htmlburger/carbon-fields:v3.0.0-rc.2

You can read more about it here: https://carbonfields.net/2018/12/13/introducing-carbon-fields-v3/

[daniftinca]

Is it possible to Upgrade from carbon fields 2.2 to 3.0 without losing data? @jorostoyanov