WordPress.org

Make WordPress Core

Opened 7 months ago

Last modified 7 days ago

#50030 new defect (bug)

Post Attributes default template's value is empty

Reported by: sandesh055 Owned by:
Milestone: 5.7 Priority: normal
Severity: normal Version: 5.5
Component: Editor Keywords: has-patch reporter-feedback
Focuses: Cc:

Description

Default template value is empty in gutenberg.

File : wp-admin\edit-form-blocks.php
Line number : 162

Before the value was "default"

File : wp-admin\includes\meta-boxes.php
Line number : 988

Attachments (1)

edit-form-blocks.diff (844 bytes) - added by sandesh055 7 months ago.
Fix of the default template value bug

Download all attachments as: .zip

Change History (9)

@sandesh055
7 months ago

Fix of the default template value bug

#1 @sandesh055
7 months ago

  • Keywords has-patch added; needs-patch removed

This ticket was mentioned in PR #312 on WordPress/wordpress-develop by sandeshjangam.


6 months ago

Default template value is empty in gutenberg.
File : wp-admin\edit-form-blocks.php
Line number : 162

Before the value was "default"
File : wp-admin\includes\meta-boxes.php
Line number : 988

Trac ticket: https://core.trac.wordpress.org/ticket/50030

#3 @sandesh055
6 months ago

  • Keywords 2nd-opinion dev-feedback needs-testing added

#4 @noisysocks
10 days ago

  • Keywords 2nd-opinion removed

Hi @sandesh055. Not sure what you mean here. The code you linked to in your "before" example doesn't have an associative array at all.

Is there a bug that this fixes? How do I spot it?

#5 @sandesh055
9 days ago

@noisysocks Seems like the "Before" code is updated in the latest version

Now the line number is 1001. Check this below code,

File : wp-admin\includes\meta-boxes.php
Line number: 1001

Reference code -

<select name="page_template" id="page_template">
	
<option value="default"><?php echo esc_html( $default_title ); ?></option>

--- Gutenberg Editor ---

After the WordPress Gutenberg update, the value of the "Default template" is "empty" in "Post attributes"
Here is a screenshot - https://a.cl.ly/Jruql5AL

--- Classic Editor ---

If you enable the classic editor, then you will see the value of the "Default template" is "default" in "Post attributes"
Here is a screenshot - https://a.cl.ly/7KubJnyz

------ Solution -----

I have created a fix in the diff file.

File : wp-admin\edit-form-blocks.php
Line number: 162

Reference code -

$available_templates = ! empty( $available_templates ) ? array_merge(
	array(
		/** This filter is documented in wp-admin/includes/meta-boxes.php */
		'' => apply_filters( 'default_page_template_title', __( 'Default template' ), 'rest-api' ),
	),
	$available_templates
) : $available_templates;

You can see that the key of "Default template" is empty instead of "default"

I hope it clears the confusion.

#6 @noisysocks
8 days ago

  • Keywords dev-feedback removed
  • Milestone changed from Awaiting Review to 5.7

Thanks for clearing that up :)

#7 follow-up: @noisysocks
7 days ago

  • Keywords reporter-feedback added; needs-testing removed

I tested PR #312 locally and noticed that it introduces a "Updating failed. Invalid parameter(s): template" error when you change the template to Default template and save the post.

This is because the posts REST endpoint requires template to be '' or a valid template file. It does not allow 'default'.

@sandesh055: Does having the option's value set to "" cause a user-facing bug somewhere?

#8 in reply to: ↑ 7 @sandesh055
7 days ago

Ohh, Users are not facing a bug directly but conditions based on the "default" key causing an issue sometimes.

As a developer needs to keep both the condition old one and new i.e. compare with 'default' and 'empty' to maintain compatibility.

Replying to noisysocks:

I tested PR #312 locally and noticed that it introduces a "Updating failed. Invalid parameter(s): template" error when you change the template to Default template and save the post.

This is because the posts REST endpoint requires template to be '' or a valid template file. It does not allow 'default'.

@sandesh055: Does having the option's value set to "" cause a user-facing bug somewhere?

Note: See TracTickets for help on using tickets.