Opened 8 years ago
Closed 8 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 | Owned by: | westonruter |
---|---|---|---|
Milestone: | 4.8 | Priority: | normal |
Severity: | normal | Version: | 4.7 |
Component: | Customize | Keywords: | has-patch has-unit-tests commit |
Focuses: | Cc: |
Description
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)
Change History (18)
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
8 years ago
This ticket was mentioned in Slack in #core by swissspidy. View the logs.
8 years ago
#6
@
8 years ago
The proof of concept was implemented in Customize Posts: https://github.com/xwp/wp-customize-posts/pull/348/files
The patch in the PR can be adapted for core.
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
8 years ago
#11
@
8 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: https://github.com/xwp/wp-customize-posts/blob/ac604f19d50b13c1fbe009cf51ea2b23c6252d4e/php/class-customize-posts-plugin.php#L436-L443
#12
@
8 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
@
8 years ago
@westonruter
Essentially we'd have to query the post_content for all changesets...
Right.
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
@
8 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 https://github.com/xwp/wp-customize-snapshots/issues/133
Patch for this ticket is located at https://github.com/xwp/wordpress-develop/pull/224
#15
@
8 years ago
- Keywords needs-unit-tests removed
Added unit-test, New PR here https://github.com/xwp/wordpress-develop/pull/226.
#16
@
8 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: https://github.com/xwp/wordpress-develop/pull/226
Proof of concept (plugin)