Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show custom fields option only if post type supports it #16338

Closed
wants to merge 3 commits into from

Conversation

Soean
Copy link
Member

@Soean Soean commented Jun 27, 2019

Description

Fixes #16333
The custom field option should only be visible, if the post type supports this feature. The old solution doesn't work anymore, because enableCustomFields has now a default value false (added in #14082).
So this new solution checks the supports array of the post type for the value custom-fields.

How has this been tested?

Register a post type without custom field support, so the option should be hidden. If you add the custom fields support, the option should be visible.

function register_custom_post_types() {
	register_post_type('test', [
		'labels' => [
			'name' => __('test'),
		],
		'public' => true,
		'supports' => [
			'title',
			'editor',
			// 'custom-fields',
		],
		'show_in_rest' => true,
	]);
}
add_action('init', 'register_custom_post_types');

Screenshot

Bildschirmfoto 2019-06-27 um 21 48 31

@Soean Soean added the [Feature] Meta Boxes A draggable box shown on the post editing screen label Jun 27, 2019
@Soean Soean self-assigned this Jun 27, 2019

return {
// This setting should not live in the block editor's store.
areCustomFieldsRegistered: getEditorSettings().enableCustomFields !== undefined,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the purpose of the previous enableCustomFields setting?
I assume it's meant to be set in WordPress Core. is there code we need to remove from there?

Copy link
Member Author

@Soean Soean Jun 28, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

supportsCustomFields defines if the post type supports this feature. enableCustomFields is the setting if this meta-box is visible. Before enableCustomFields had the default value false we checked with !== undefined if the post type supports this feature. Now enableCustomFields can't be undefined anymore, so we need to check supportsCustomFields.

We still need enableCustomFields for checking if the meta-box should be visible. This logic is already merged into core.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, makes sense. Changes look good to me. I'll wait for @talldan or @noisysocks to confirm.

Copy link
Member

@noisysocks noisysocks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for looking into this!

Unfortunately we can't rely on checking if the CPT supports custom fields because plugins will disable custom fields by modifying the $wp_meta_boxes global during the do_meta_boxes action.

You can see this problem by following these steps:

  1. Check out this branch
  2. Install the Advanced Custom Fields plugin
  3. Create a new Field Group with a filed in it by going to Custom Fields > Add New
  4. Create a new post by going to Posts > Add New
  5. Select More tools & options > Options

Expected result: There should be no Custom Fields checkbox because ACF replaces the Core Custom Fields functionality.
Actual result: There's a Custom Fields checkbox which doesn't do anything.

This is why WordPress will check the $wp_meta_boxes global and unset the enableCustomFields editor setting (making it undefined) if custom fields were disabled by a plugin:

https://github.com/WordPress/wordpress-develop/blob/5fea17ba03c42d16a6517b164d3437bd53ac8ac9/src/wp-admin/edit-form-blocks.php#L366-L370

Are we able to stick with the undefined|true|false approach that existed before #14082? I think that the error is in having the default setting for enableCustomFields be false. The default should be undefined.

@kosso
Copy link

kosso commented Mar 5, 2020

Still having this issue on Version 5.3.2.

My custom post type supports array( 'title', 'editor', 'thumbnail', 'custom-fields' )

And I can see the Options checkbox to activate 'Custom Fields'.
But after clicking the provided button to view them in the panel, no change occurs after the page reloads.

Am I missing something?

Base automatically changed from master to trunk March 1, 2021 15:42
@paaljoachim
Copy link
Contributor

Hello everyone.

What is needed to move this PR forward?
Or perhaps a new PR is needed?

It would be great with an update @Soean
Thank you!

@ntsekouras Nik perhaps this is a PR you are able to move forward?

@ntsekouras
Copy link
Contributor

@ntsekouras Nik perhaps this is a PR you are able to move forward?

Hey Paal. I think some other person with previous work on custom fields could be more effective here. I'll keep this in my queue though.

@skorasaurus
Copy link
Member

skorasaurus commented Aug 31, 2021

I believe this can be closed because of the work done at #33931; the custom fields preference does not display, when i create a custom post type ,following the directions in #16333 in a new gutenberg build that includes #33931

@youknowriad youknowriad deleted the fix/meta-boxes-section-check branch August 31, 2021 18:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Meta Boxes A draggable box shown on the post editing screen
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Custom fields in custom post type not appearing
7 participants