Add Revisions Block to Display Post Revision History

[sarthaknagoshe2002]

What?

This PR introduces a Revisions Block that displays a list of revisions for the current post, page, or custom post type.
Closes #40389

Why?

WordPress supports post revisions, but currently lacks a block-based way to visualize or output revision history on the front end or within block templates. Showing this information improves editorial transparency and can be useful in collaborative environments (e.g., newsroom sites, documentation pages).

How?

1. Displays list of revisions with:

   • Date/time of each revision.
   • Author who made the change.

2. Displays total revision count:

   • Total number of revisions.

3. Set limit revisions:

   • Let the user choose how many recent revisions to display.

Conditionally Rendered: Only shown if revisions are enabled for the post type.

Testing Instructions

1. Enable revisions for the post type you're testing with.
2. Make a few edits to a post or page to generate revisions.
3. Insert the Revisions Block into the template or post.
4. View the block output: revision list should show timestamps and authors.
5. Confirm that it hides when no revisions are present or disabled.

Screenshots or screencast

revision.block.mov

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: sarthaknagoshe2002 <sarthaknagoshe2002@git.wordpress.org>
Co-authored-by: carolinan <poena@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: bhubbard <bhubbard@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[carolinan]

I don't think that this block would be useful for the majority of the WordPress users and I think it should be in a separate plugin.
But this is only my opinion.

[sarthaknagoshe2002]

Thanks for the feedback!

While this block may not be for everyone, like many other blocks, it can still be valuable for a wide range of users. WordPress powers countless content-driven organizations — newsrooms, documentation sites, Education platforms, agencies — where content changes are frequent and often collaborative.

The Revisions Block brings editorial transparency by showing when and by whom changes were made. This can build trust between content teams and end users.

That said, I’m open to further discussion on whether this might be better suited as a plugin for specific use cases.

[carolinan]

Looking at my own content, some of my old pages have over 200 revisions. It does not make sense even for a news agency to display 200 revisions where some of them are changing the height of a spacer block.
What makes sense is showing specific, selectable, content updates.

[sarthaknagoshe2002]

Yes, I also noticed that, and I'm working on a solution using <detail> and <summary> tags, with an option to display only the latest revision information too.

[t-hamano]

A list of who updated a post and when doesn't seem useful to end users. I think end users want to know why and how it was updated. And that information is difficult to generate automatically from revision lists.

I'm not sure if this block is needed by 80% or more of users.

WordPress philosophy states:

The core of WordPress will always provide a solid array of basic features. It’s designed to be lean and fast and will always stay that way. We are constantly asked “when will X feature be built” or “why isn’t X plugin integrated into the core”. The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it. If we stick to the 80% principle then this should never happen.