Make WordPress Core

Opened 7 years ago

Closed 7 years ago

#39715 closed defect (bug) (fixed)

Customize: Keep alive auto-drafts created for page/post stubs, and delete when changeset is garbage-collected

Reported by: westonruter's profile westonruter Owned by: westonruter's profile westonruter
Milestone: 4.8 Priority: normal
Severity: normal Version: 4.7
Component: Customize Keywords: has-patch has-unit-tests commit
Focuses: Cc:


By default the customizer will store the customized state in a customize_changeset post that gets an auto-draft status so that it will be garbage-collected after a week. Whenever the changeset is updated, the post_date should be updated to the current datetime so that it will be kept-alive for another week (see #39713). However, when new page/post stubs are created via nav menus (#34923) or via starter content (#38114) these are also inserted with the auto-draft status. Whenever the changeset is updated and its post_date is bumped, the post_date for each of the auto-draft nav_menus_created_posts also needs to be correspondingly bumped. Currently such page/post stubs can be deleted out from under the changeset prematurely.

Additionally, if customize_changeset is transitioned to a stable draft status so that it will not be garbage-collected, any auto-draft nav_menus_created_posts should have the post_date bumped to be very far in the future so that they will always be ignored by wp_delete_auto_drafts().

Lastly, when a customize_changeset post is deleted without having been published, all auto-draft nav_menus_created_posts should be deleted as well.

Attachments (1)

proof-of-concept.php (3.2 KB) - added by westonruter 7 years ago.
Proof of concept (plugin)

Download all attachments as: .zip

Change History (18)

7 years ago

Proof of concept (plugin)

#1 @westonruter
7 years ago

  • Keywords needs-patch added

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.

7 years ago

#3 @westonruter
7 years ago

  • Milestone changed from 4.7.3 to 4.7.4

#4 @swissspidy
7 years ago

  • Owner set to westonruter
  • Status changed from new to assigned

This ticket was mentioned in Slack in #core by swissspidy. View the logs.

7 years ago

#6 @westonruter
7 years ago

The proof of concept was implemented in Customize Posts:

The patch in the PR can be adapted for core.

#7 @westonruter
7 years ago

  • Owner westonruter deleted

I would appreciate help on patch.

#8 @utkarshpatel
7 years ago

@westonruter should patch also consider duplication of changeset?

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.

7 years ago

#10 @swissspidy
7 years ago

  • Milestone changed from 4.7.4 to 4.7.5

#11 @westonruter
7 years ago

Let's include the logic in the patch, and we can evaluate whether to keep it or put in another later commit.

This is the code in question:

#12 @westonruter
7 years ago

@utkarshpatel thinking about this some more. So the problem is to make sure that the reference count for a given auto-draft page/post stub in a given changeset is 1. If a changeset has been duplicated, then the reference count would be greater than 1 and the auto-draft stubs should not be garbage-collected until the reference count reduces to 1 again.

Essentially we'd have to query the post_content for all changesets (other than the one being deleted), parse out the nav_menus_created_posts from each one, merge the post IDs into a list. Then, for delete each post in nav_menus_created_posts for if it does not exist in the set of all nav_menus_created_posts gathered from all other changesets. Right?

Since currently changeset duplication is only in plugin territory (Customize Snapshots), perhaps accounting for deletion of a page/post stubs should be handled in plugin territory as well? Ultimately, changing the status of a changeset to draft is currently plugin territory so maybe actually the whole logic for garbage-collection should be deferred for a plugin to manage. Core could just be solely concerned with extending the life of the auto-draft stubs to prevent premature deletion, but for now leave the second part up to the plugin that transitioned the changeset to a draft status in the first place.

#13 @utkarshpatel
7 years ago


Essentially we'd have to query the post_content for all changesets...


I am thinking in core whenever we delete changeset if we find reference to auto-draft page/post we should delete those posts without checking for duplication and we should add duplication handling part in the plugin which accounts for checking other references of that post in other changesets before deleting - essentially overriding core's filter.

How does that sound?

#14 @westonruter
7 years ago

  • Keywords has-patch needs-unit-tests added; needs-patch removed
  • Owner set to utkarshpatel

@utkarshpatel Yes, I think that is a good approach, as you also outlined in

Patch for this ticket is located at

#15 @utkarshpatel
7 years ago

  • Keywords needs-unit-tests removed

#16 @westonruter
7 years ago

  • Keywords has-unit-tests commit added
  • Milestone changed from 4.7.5 to 4.8
  • Owner changed from utkarshpatel to westonruter
  • Status changed from assigned to accepted

I'm proposing this for commit. See PR:

#17 @westonruter
7 years ago

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

In 40676:

Customize: Keep alive auto-drafts created for page/post stubs when parent changeset is updated, and delete when changeset is garbage-collected.

Props utkarshpatel, westonruter.
See #31089.
Fixes #39715.

Note: See TracTickets for help on using tickets.