Ability to set Gutenberg compatibility?

[crazyjaco]

We are on an older version of Field Manager and are reviewing Gutenberg compatibility for our theme.

We are trying to mark several metaboxes as incompatible with Gutenberg so it will default back to the classic editor if those fields are present.

The setting for this is added to the add_meta_box() call according to this documentation: https://wordpress.org/gutenberg/handbook/extensibility/meta-box/ array( '__block_editor_compatible_meta_box' => false )

The add_meta_box() method in FieldManager doesn't seem to allow for an extra attribute such as this, however.

Am I missing the proper way to approach this? Is this added in a version later than 1.0.0? Will a Gutenberg compatible version of the plugin be released in the near future ahead of the merge with WordPress core in 5.0?

Thank you for your time and effort in maintaining this plugin.

[mboynes]

Hey @crazyjaco, Great point, we should definitely add a way to pass $callback_args to the Fieldmanager_Context_Post construct. Thanks for the suggestion!

Since you're using an older version, once we add it, that would either mean forking the version you're on and carrying that one patch over, or taking a slightly different route to fixing the problem. If you don't want to fork the version you're using, one option would be to unhook Fieldmanager_Context_Post::meta_box_render_callback() and then call add_meta_box() yourself. When you call Fieldmanager_Field::add_meta_box(), that returns the instance of Fieldmanager_Context_Post you would need to unhook it...

$field = new \Fieldmanager_TextField();
$context = $field->add_meta_box( ... );
remove_action( 'admin_init', [ $context, 'meta_box_render_callback' ] );
add_action( 'add_meta_boxes', function() {
    add_meta_box(
        'fm_meta_box_' . $field->name,
        $context->title,
        [ $context, 'render_meta_box' ],
        $context->post_types,
        $context->context,
        $context->priority,
        [ '__block_editor_compatible_meta_box' => false ]
    );
} );

Alternatively, you could write a custom context which extends Fieldmanager_Context_Post and simply overrides meta_box_render_callback(). Depending on how many meta boxes you want to declare as Gutenberg-incompatible, that might be a better approach regardless because it would likely be a bit DRYer. Hopefully this steers you in the right direction!

Will a Gutenberg compatible version of the plugin be released in the near future ahead of the merge with WordPress core in 5.0?

See #682 for discussion on that. We will certainly ensure the most compatibility we can between now and then, and if we find areas where we can't maintain compatibility, we'll document that and force the classic editor.

We are on an older version of Field Manager

Is there a reason you haven't upgraded? I don't believe we've released any significant breaking changes, so if there's something you encountered, we'd love to hear about it!

[crazyjaco]

Hey Matt,

Thank you for the guidance! We'll take a look at which approach is more feasible. Probably creating the new context. That seems much cleaner.

The reason we have not upgraded is that Field Manager is not in the WordPress Plugin Repo, so when updates are made, we don't get the little notification on the plugin page to notify us of the new release. We don't have any sort of automation setup to notify us of updates for plugins, nevermind this github repo. Something we probably need to reconsider.

Being on an out of date version was not a deliberate exercise. :\

Should I leave this ticket open to address passing in the $callback_args to the core plugin?

[mboynes]

Should I leave this ticket open to address passing in the $callback_args to the core plugin?

Yeah, we can keep it open to track. Thanks!

The reason we have not upgraded is that Field Manager is not in the WordPress Plugin Repo

Unfortunately it doesn't meet the requirements for the plugin repo because it doesn't do anything on its own. By itself, Fieldmanager does nothing; plugins, apparently, are required to be able to stand alone. On that note, we should probably give it its own update mechanism to check the releases in GitHub. I guess once we do that, it will technically meet the eligibility requirements for the plugins repo because then it would be able to independently do something 😆.

[crazyjaco]

Hah. Works for me. Feel free to reach out if you'd like a guinea pig on an older version. We'll upgrade but not right away.