WordPress.org

Make WordPress Core

Opened 4 months ago

Closed 4 hours ago

Last modified 2 hours ago

#53813 closed defect (bug) (fixed)

Do not provide initial_edits for properties that are not supported by the current post type.

Reported by: youknowriad Owned by: audrasjb
Milestone: 5.9 Priority: normal
Severity: normal Version: 5.8
Component: Editor Keywords: good-first-bug has-patch commit
Focuses: Cc:

Description

I noticed that edit-form-blocks.php (block editor initialization) always provides "title", "content" and "excerpt" initial edits in the initializeEditor call even though these properties might not be supported by the current post type being edited.

This creates a subtle bug in the post editor where as soon as you open a "new post", the editor considers the content "dirty", meaning changes are applied and you can't "leave" the editor without having the "unsaved changes" notice.

I think we should consider updating the $initial_edits variable declaration to only add the properties that are supported by the current CPT.

Attachments (3)

53813.diff​ (1.1 KB) - added by h71 6 weeks ago.
53813.2.diff​ (1.1 KB) - added by h71 6 weeks ago.
Empty line removed.
a36db167e65d579d6d25f42a79a09567.mp4​ (2.4 MB) - added by audrasjb 7 hours ago.
Reproducing the issue by removing "excerpt" support in a custom post type

Change History (15)

This ticket was mentioned in ​Slack in #core by amustaque97. ​View the logs.
2 months ago

This ticket was mentioned in ​PR #1743 on ​WordPress/wordpress-develop by ​hectorfarahani.
6 weeks ago

  • Keywords has-patch added

Trac ticket: https://core.trac.wordpress.org/attachment/ticket/53813

@h71
6 weeks ago

@h71
6 weeks ago

Empty line removed.

#3 @h71
6 weeks ago

My first patch! I had to wait for Github checks. The new diff is attached after passing all checks.

This ticket was mentioned in ​Slack in #core-editor by h71. ​View the logs.
5 weeks ago

#5 @audrasjb
7 hours ago

  • Owner set to audrasjb
  • Status changed from new to reviewing

Self-assigning for review.

@audrasjb
7 hours ago

Reproducing the issue by removing "excerpt" support in a custom post type

#6 @audrasjb
6 hours ago

I can confirm the proposed patch fixes the issue.

Marking for commit.

#7 @audrasjb
6 hours ago

  • Keywords commit added

#9 @audrasjb
6 hours ago

Tests are passing well.

#10 @audrasjb
4 hours ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 52230:

Editor: Do not provide initial_edits for properties that are not supported by the current post type.

Previously, the block editor initialization always provided "title", "content" and "excerpt" initial edits in the initializeEditor call even though these properties might not be supported by the current post type being edited. This leads to a bug in the post editor where as soon as one would open a "new post", the editor considers the content "dirty", meaning changes are applied and it is not possible to leave the editor without encountering an "unsaved changes" notice.

This change updates the $initial_edits variable declaration to only provide the properties that are supported by the current post type.

Props youknowriad, h71.
Fixes #53813.

#11 @prbot
2 hours ago

​audrasjb commented on ​PR #1927:

Fixed in 52230

#12 @prbot
2 hours ago

​audrasjb commented on ​PR #1743:

Fixed in 52230

Note: See TracTickets for help on using tickets.