_wp_get_default_posttype_form(): array

Builds the default form configuration for post types that don’t provide their own.

Description

It is a sensible default for post, page, and custom post types alike rather than being tailored per type. Post types that need a different shape can replace it entirely with a dedicated form through their own filter callback.

It is intentionally NOT gated by supports. The registered fields are the single source of truth for what applies: each field is registered for a post type based on its supports (and related flags such as theme_supports), and the editor drops any form field whose definition is absent or whose isVisible returns false.

Return

array The default form configuration.

Source

function _wp_get_default_posttype_form() {
	return array(
		'layout' => array( 'type' => 'panel' ),
		'fields' => array(
			array(
				'id'     => 'featured_media',
				'layout' => array(
					'type'          => 'regular',
					'labelPosition' => 'none',
				),
			),
			array(
				'id'     => 'post-content-info',
				'layout' => array(
					'type'          => 'regular',
					'labelPosition' => 'none',
				),
			),
			array(
				'id'     => 'excerpt',
				'layout' => array(
					'type'          => 'panel',
					'labelPosition' => 'top',
				),
			),
			array(
				'id'       => 'status',
				'label'    => __( 'Status' ),
				'children' => array(
					array(
						'id'     => 'status',
						'layout' => array(
							'type'          => 'regular',
							'labelPosition' => 'none',
						),
					),
					'scheduled_date',
					'password',
					'sticky',
				),
			),
			'date',
			'slug',
			'author',
			'template',
			array(
				'id'       => 'discussion',
				'label'    => __( 'Discussion' ),
				'children' => array(
					array(
						'id'     => 'comment_status',
						'layout' => array(
							'type'          => 'regular',
							'labelPosition' => 'none',
						),
					),
					'ping_status',
				),
			),
			'parent',
			'format',
			'revisions',
		),
	);
}

View all references View on Trac View on GitHub

Uses	Description
__()`wp-includes/l10n.php`	Retrieves the translation of $text.

Used by	Description
wp_get_entity_view_config()`wp-includes/view-config.php`	Returns the view configuration for the given entity.

Changelog

Version	Description
7.1.0	Introduced.

User Contributed Notes

Skip to note 2 content

Rodrigo Vieira Eufrasio da Silva 2 months ago

You must log in to vote on the helpfulness of this noteVote results for this note: 0You must log in to vote on the helpfulness of this note
This is the starting point, not the final form

The array returned here is unfiltered. What the editor actually receives is the return of wp_get_entity_view_config( 'postType', $name ) — this default after the get_entity_view_config_posttype_{$name} filter has run. Core hooks that filter for several of its own post types and replaces form outright, so this is only what a post type ends up with when nothing has patched it.

It is also reached only for the postType kind. Any other $kind starts from 'form' => array(), so a callback for a non-post-type entity builds the whole form itself.

To adjust the form for your own post type, patch it on the filter rather than calling this function and re-registering the result:
```
function wpdocs_book_form_fields( $data ) {
	return $data->merge(
		array(
			'form' => array(
				'fields' => array( 'wpdocs_isbn' ),
			),
		),
		1
	);
}
add_filter( 'get_entity_view_config_posttype_book', 'wpdocs_book_form_fields' );
```
The fields list merges by member identity, so a new id is appended while an id already present ('excerpt', 'status', …) is patched in place.

The id has to match a field registered for that post type — the editor drops any form entry whose field definition is missing. That is also the reason this default is not gated by supports: to keep a field out for your post type, leave the corresponding supports flag off at registration instead of editing the form.
Log in to add feedback

You must log in before being able to contribute a note or feedback.