#53072 closed enhancement (fixed)
Enable revisions for the reusable block custom post type
Reported by: | matveb | Owned by: | desrosj |
---|---|---|---|
Milestone: | 5.8 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Posts, Post Types | Keywords: | has-patch has-screenshots has-unit-tests commit needs-codex has-dev-note |
Focuses: | Cc: |
Description
Let's enable post revisions for the wp_block
custom post type.
This has not been pursued yet in suspense of broader improvements to block management, reusable blocks, and editorial flows. However, there's really no reason to lock this functionality out in the meantime, which can be very useful today for people.
Also reported https://github.com/WordPress/gutenberg/issues/19149.
Attachments (1)
Change History (18)
This ticket was mentioned in PR #1205 on WordPress/wordpress-develop by mtias.
4 years ago
#1
- Keywords has-patch added
#3
@
4 years ago
- Keywords has-screenshots commit added
Ah! Thank you for opening this ticket, I completely support this proposal.
The pull request works great on my side.
Marking for commit
action.
This ticket was mentioned in PR #1206 on WordPress/wordpress-develop by desrosj.
4 years ago
#4
- Keywords has-unit-tests added
Supersedes https://github.com/WordPress/wordpress-develop/pull/1205/.
Trac ticket: https://core.trac.wordpress.org/ticket/53072.
#5
@
4 years ago
- Keywords commit has-unit-tests removed
It looks like the PR has a unit test failure that needs to just be fixed before this can be committed.
Also, it looks like the branch was pushed directly to the mirror repository. @matveb for future reference, because wordpress-develop
is a mirror, any changes to that repo not found in SVN get overwritten when the repo syncs (I believe this happens every few minutes), so looks like while your PR is still open, your branch is now gone. It's best to open a PR from your fork to prevent that.
I've created a fresh PR on my fork with an update that should make the unit tests pass.
One question I had was when a revision would actually be created for a reusable block. I did some testing and it seems a revision is only created when the block is actually saved (which is good).
#7
follow-up:
↓ 8
@
4 years ago
@desrosj Ah, good to know! I was trying that flow since I've never used it before for patches :)
Yes, it should only commit revisions upon saving, and the saving flow for reusable blocks is not dependant on the post that may harbor it.
To test, also go to edit the reusable block directly via "manage reusable blocks" and the selecting it from the list. Both saving flows should work.
#8
in reply to:
↑ 7
@
4 years ago
Ah yes, indeed thanks @desrosj good catch. I directly tested the code, I didn't try to apply the PR.
Replying to matveb:
To test, also go to edit the reusable block directly via "manage reusable blocks" and the selecting it from the list. Both saving flows should work.
Or go directly to /wp-admin/edit.php?post_type=wp_block
#9
@
4 years ago
- Keywords commit added
To clarify my concern, I just wanted to confirm that there were no autosaves of reusable blocks happening that were triggering many revisions.
Looks like the tests are good now! Feel free to commit, @matveb.
#11
@
3 years ago
- Owner set to desrosj
- Resolution set to fixed
- Status changed from new to closed
In 50835:
3 years ago
#12
Merged into Core in https://core.trac.wordpress.org/changeset/50835.
3 years ago
#13
Merged into Core in https://core.trac.wordpress.org/changeset/50835.
Trac ticket: https://core.trac.wordpress.org/ticket/53072