Should WP Core "Custom Fields" UI be present by default?

[tomjn]

Issue Overview

Core provides a default custom fields metabox, but it has no equivalent in Gutenberg

Current Behavior

Plugin metaboxes get shown, but this one is missing, and the screen options tab to turn it on isn't in Gutenberg

Todos

• Tests
• Documentation

[BE-Webdesign]

Hi tomjn,

Thank you for bringing this up. This is something I probably overlooked while implementing the meta boxes. Since most of the core meta boxes have been replaced by JS counterparts, one of the goals was to filter out any core meta boxes.

This I believe is currently filtered out, if you want to re-enable it use the gutenberg_filter_meta_boxes filter.

Maybe it should be enabled by default though as it has not been replaced yet, nor will it probably be replaced on the JS side of things.

[tomjn]

+1, a lot of older sites with no active devs rely on this functionality, and without it they'll break

[nicolinuxfr]

I rely on it, since I'm using really simple text custom fields (for instance, to memorize the original title of a movie I'm reviewing).

This is probably the last item I need to use Gutenberg on a daily basis.

[lkraav]

I took a shot at add_filter filter_gutenberg_meta_boxes but it's much more involved than I expected. You would have to manually re-create the whole location, page, context array tree. Ideally the initial slug lists at the top of gutenberg_filter_meta_boxes() would be (also) filtered, so you could just disable/enable these via simple meta box slugs and avoid fiddling w/ complex arrays later.

Itmw, even when I commented out postcustom directly in Gutenberg source, it only made Custom Fields box appear on "Post" post type, but not on "Page", even though classic Screen Options has this metabox enabled for both. Not sure yet what this is all about.

Can we get some specialist help here @BE-Webdesign tyvm.

[BE-Webdesign]

Ideally the initial slug lists at the top of gutenberg_filter_meta_boxes() would be (also) filtered, so you could just disable/enable these via simple meta box slugs

Sounds like a good idea.

[jasmussen]

Here are mockups that put Custom Fields in the ellipsis menu:

Click that to access the custom fields interface. This could happen either in a modal interface:

... or in a screen take-over:

Thoughts?

[danielbachhuber]

How will these fields be editable through the REST API?

[danielbachhuber]

How will these fields be editable through the REST API?

To clarify, the REST API doesn't permit arbitrary modification of custom fields. Custom fields must be registered with register_meta before they're accessible through the REST API. See https://core.trac.wordpress.org/ticket/35658 for the long, sordid history.

If we want to keep arbitrary modification of custom fields, we'll need to save the data through the standard form submission process. This is an important detail to reflect in the design process.

[BE-Webdesign]

Right now, "core meta boxes" are being filtered out, I think the easiest potential solution is to not filter out the custom fields meta box, only if the post type supports custom fields.

[danielbachhuber]

My current thinking is that we should leave the Custom Fields disabled entirely by default, but then make it easy to re-enable with a WordPress.org plugin.

Because we don't have a Screen Options API (#5841) the Custom Fields metabox would always be visible if we restore it in Gutenberg.

[danielbachhuber]

I've documented this in the Gutenberg migration guide.

[omarreiss]

Because we don't have a Screen Options API (#5841) the Custom Fields metabox would always be visible if we restore it in Gutenberg.

The design by @jasmussen doesn't feature a metabox, so that's not really a concern. There's no need to break BC here. Instead I think we need to make those fields accessible in the REST API through a separate property.

Native custom fields are heavily relied on by Yoast SEO power users in metadata management. It would be a big regression for those users if this stuff is no longer core.

I've asked @felixarntz to look into making the fields accessible through the REST API.

[danielbachhuber]

@omarreiss Do you acknowledge and understand the following statement?

To clarify, the REST API doesn't permit arbitrary modification of custom fields. Custom fields must be registered with register_meta before they're accessible through the REST API. See https://core.trac.wordpress.org/ticket/35658 for the long, sordid history.

Any implementation would need to continue to use post.php, not the REST API.

[omarreiss]

@danielbachhuber I don’t understand why they must be. Can’t make that up from the thread either. Could you enlighten me?

[danielbachhuber]

@omarreiss Did you read WP-API/WP-API#1425 and WP-API/WP-API#2149 ?

[tomjn]

Keep in mind that for a lot of custom fields added this way, the only corresponding code is get_post_meta, no metabox, no registration. Some may not even be for code currently active yet still used for other purposes

In those cases I think the classic method of doing things and showing any that don't have _ would suffice for users with administrator level capabilities, as in these scenarios we can't know what the fields that need registering are by definition, or it'd be using a meta box

[danielbachhuber]

My preference is still:

My current thinking is that we should leave the Custom Fields disabled entirely by default, but then make it easy to re-enable with a WordPress.org plugin.

[omarreiss]

Scanned through, still can’t see why we couldn’t do it. Maybe you could explain your point of view (and not make a fellow contributor feel stupid / ignorant with rethorical questions)?

[danielbachhuber]

Thanks for pushing me on this, @omarreiss. I took the opportunity to do a bit more research and share my findings.

First, I created a new post with ID 1 and set some test custom field values:

$ wp shell
wp> update_post_meta( 1, 'test_string', 'string' );
=> int(3)
wp> update_post_meta( 1, 'test_integer', 2 );
=> int(4)
wp> update_post_meta( 1, 'test_array', array( 'array' ) );
=> int(5)
wp> update_post_meta( 1, 'test_object', (object) array( 'array' ) );
=> int(6)
wp> update_post_meta( 1, '_test_hidden', 'hidden' );
=> int(7)

Of these test values, only two (test_string and test_integer) are editable through the custom fields meta box:

This logic is defined in the post_custom_meta_box() function (and _list_meta_row() under that):

• https://github.com/WordPress/WordPress/blob/cd4c960a6c17e683bcc76f1efaadcb272955bb83/wp-admin/includes/meta-boxes.php#L728
• https://github.com/WordPress/WordPress/blob/6b2e34f70335ad93928b78fb3a722db423d84fb4/wp-admin/includes/template.php#L596-L605

Strings, integers, and serialized strings are editable through the Classic Custom Fields meta box. Objects and arrays are not. Ryan McCue's post, "The (Complex) State of Meta in the WordPress REST API", is a great articulation of these nuances around meta handling. I'll defer further explanation there.

In order to make strings, integers, and serialized strings editable through the REST API, we'd need to do the following:

1. Expose the arbitrary custom fields in a GET request, but only where context=edit.
2. Handle updating arbitrary custom fields in a POST request.

To my knowledge, the REST API doesn't yet support these requirements, and interacting with custom fields over REST requires use of register_meta(). However, I haven't been following @kadamwhite, @felixarntz and others' recent work around meta handling, so this could now be possible.

Notably, when arbitrary custom fields are exposed in a GET request, neither the meta value nor the meta key can be publicly exposed unless explicitly defined as such (using register_rest_field() or similar). Including meta keys in a public response would be information disclosure.

At the end of the day, this is why I think it's more straightforward to use the existing Custom Fields Metabox when it's absolutely necessary, instead of trying to solve for REST API support and recreating the user interface.

Hope this helps clarify. Happy to take any follow-up questions you might have.

[felixarntz]

Notably, when arbitrary custom fields are exposed in a GET request, neither the meta value nor the meta key can be publicly exposed unless explicitly defined as such (using register_rest_field() or similar). Including meta keys in a public response would be information disclosure.

I completely agree with this. I'm thinking that we could expose those unregistered metadata in a separate property outside of meta (which is for the registered metadata). That property (for example called customFields) would not be included in the response by default, but instead it would need to be explicitly requested via _fields. Furthermore, requesting this would only work for authenticated users with sufficient permissions. I have yet to look at the details of how this could be implemented, but the above would be my first take.

To clarify, while metadata are essentially custom fields, only post types that support custom-fields support arbitrary metadata that the user can specify via the current UI. Metadata (as in registered metadata) itself does not require any post type support, it can be used for every post type. The UI in the above screenshot says it precisely: "Custom Fields" are "extra metadata". We definitely need to scope out more clearly how the two are distinct.

[omarreiss]

@danielbachhuber Thanks a lot for sharing your context. So, I've changed my mind... a bit. Here's what I'm thinking:

• I can see there are problems with the way custom fields are being handled in WordPress. There seems to be a total lack of abstraction and proper handling in comparison to registered metadata. Trying to solve that now could be premature optimization.
• This is mostly because with Gutenberg, custom fields need to prove themselves again as a useful concept. For legacy stuff, of course they've seen use. In a Gutenberg era, not so clear.
• To provide backwards compatibility, we still need that metabox, but having it always present is somewhat problematic. The designs by @jasmussen solve that though. The custom fields metabox could be rendered inside a modal in the same way we render other legacy metaboxes. Our only requirement would be for it to be present at all times, albeit in hidden markup, so that we can still reach its elements through our legacy integration using jQuery. But I think that is covered already in the way legacy metaboxes work.

[danielbachhuber]

To provide backwards compatibility, we still need that metabox, but having it always present is somewhat problematic. The designs by @jasmussen solve that though. The custom fields metabox could be rendered inside a modal in the same way we render other legacy metaboxes. Our only requirement would be for it to be present at all times, albeit in hidden markup, so that we can still reach its elements through our legacy integration using jQuery. But I think that is covered already in the way legacy metaboxes work.

💯 I love this idea. This seems like an excellent approach from a UX perspective.

[tomjn]

I would also note that Gutenberg is just UI, it wouldn't delete or erase things, and it's only active on an edit screen, the same way that if you create a custom field with a key starting with _ and save, it is hidden from the classic editor UI, but that doesn't mean it's been deleted, it's just not shown

[bkjproductions]

Whew! When will Custom Fields be available in Gutenberg beta? I don't see them now, which is why I worry.

[danielbachhuber]

When will Custom Fields be available in Gutenberg beta?

Unknown at this time. It's just one of many things that need to be worked on.

[earnjam]

@bkjproductions A few of us were actually just talking about the best way to implement it this afternoon. Hopefully we'll have a working example up soon that we can iterate on.

[danielbachhuber]

Custom Fields are returning indirectly through #10210. Once Screen Options are restored, the Custom Fields meta box can return.

[bkjproductions]

Wondering about the statement by @omarriess,
"This is mostly because with Gutenberg, custom fields need to prove themselves again as a useful concept. For legacy stuff, of course they've seen use. In a Gutenberg era, not so clear."

I don't see that they have anything to do with Gutenberg because they are used in many different ways-- not necessarily as displayable content-- or why they would need to prove themselves.

They're very useful semi-structured data, in that people are attaching all sorts of data to a Post, and can do so without having to register them ahead of time (easy for the novice to understand). Sometimes the data is content and sometimes the data is just data.

Examples:

I have a client who creates custom fields seemingly at the drop of a hat, and we are able to then take that field and display it in a certain area of the page, with very little coding effort. One example is that he creates a custom field called "link" and then populates it. So a Post may have four or five links. On the coding side, in PHP we loop through the custom fields and output the links in an unordered list. Now that he knows this is possible, it makes the layout of the page much more consistent, because he can put those links in an area separate from the regular "body" content, and as a bonus now we can generate a list of links from all Posts.

In another situation, a client chooses a color for the page, adding a custom field called "color" and puts in "red" or some other color. Then we take that custom field value and add it as a class to the BODY tag of the page. Our stylesheet then can affect the look of the page based on the body class.

At one site, there is a custom field called "notes" that may or may not be on all Posts. This can contain non-published information about the Post, and the ability to have it or not is very useful. If custom fields are buried in a panel in the Post Editor, then we lose the immediacy of seeing the note.

Another use is to simply count the number of views of a post, hooking into the "loop" and incrementing a value held in custom field "pageviews" -- which also allows the author to re-set this if needed.

I was actually wondering at the beginning of Gutenberg if you were going to turn every block into a custom field. Something like that would give you a lot of power, because then the blocks would be useful, granular, data that could be displayed or simply used as data. Of course then you'd probably need to expand the key-value nature of it to include sort and taxonomy, etc.

Anyway, glad to hear that they are returning. Please keep them visible rather than buried in a settings panel or dialog box.

[noisysocks]

Just a note that I'm working on this as part of #10210.

[nickcernis]

What is the status of Custom Fields for WordPress 5.0? I see the new options panel from #10210 in beta 1, but no clear way to enable a Custom Fields UI.

Workarounds such as https://wordpress.org/plugins/custom-fields-gutenberg/ don't currently work with 5.0 (they deactivate if the Gutenberg plugin is not active, probably because custom fields were promised for 5.0 so they're intended as temporary workarounds).

As a result it appears there's no way to edit custom fields in WP 5.0 at this time.

[noisysocks]

Custom Fields were a part of #10676 but had to be reverted due to a performance regression (see #10676 (comment)).

I'm currently exploring some different approaches, and will have an update soon. Stay tuned!

[bkjproductions]

Very anxious about this! If WP 5.0 ships without custom fields, does installing the Classic Editor plugin bring them back?

[chrisvanpatten]

@bkjproductions Classic Editor will show all metaboxes correctly, including Custom Fields.

I also think it's unlikely we'll ship 5.0 without having a solution for custom fields, but don't quote me on that!

[ghost]

So what's the deal? Still no custom fields in native support and we're now in 5.2.1....

This has been dropped off the radar too. What's going on?

[wpscholar]

@leecollings It is there. You have to click the three dots on the top right of the screen to bring up the global menu. Then, click on Options at the bottom of that menu. This will pull up a modal much like the old Screen Options panel. From there, you can check Custom Fields and it will show the meta box below the Gutenberg editor.