Experiment: Add revisions panel to templates, template parts and patterns#77008
Merged
ntsekouras merged 4 commits intotrunkfrom Apr 9, 2026
Merged
Experiment: Add revisions panel to templates, template parts and patterns#77008ntsekouras merged 4 commits intotrunkfrom
ntsekouras merged 4 commits intotrunkfrom
Conversation
ntsekouras
commented
Apr 2, 2026
| */ | ||
| const PANEL_NAME = 'post-status'; | ||
|
|
||
| export function OpenRevisionsClassicScreen( { revisionId } ) { |
Contributor
Author
There was a problem hiding this comment.
This change is not related to the revisions panel, but it's a leftover I noticed now, from my previous refactoring when I created PostRevisionSummary.
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: -5 B (0%) Total Size: 7.74 MB 📦 View Changed
ℹ️ View Unchanged
|
|
Flaky tests detected in aba4492. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/24183788295
|
t-hamano
reviewed
Apr 3, 2026
Contributor
t-hamano
left a comment
t-hamano
left a comment
There was a problem hiding this comment.
LGTM! Personally, I feel that it might be acceptable to address the template parts in this PR.
As a side note, should we override the default padding of the activity layout in the Revision panel? It feels like the spacing is a bit too large.
| Current | No padding |
|---|---|
 |
 |
Member
|
I've made my reservations for this panel; I think I mentioned this in the issue. I don't think this timeline is very useful when editing a template or post, and it will take up space in the sidebar. Maybe we should replace the topbar slider with this panel when the user is viewing revisions. P.S. @t-hamano, I agree that reduced padding looks better. |
Contributor
Author
This will be looked into again in DataViews layer (see 1, 2).
I'd defer to @WordPress/gutenberg-design for thoughts on that. Personally I think it's fine to have a way to select quickly among the last ones and that the slider is better UI to navigate a whole bunch of revisions. The panel space in sidebar is something that it does takes some space, although it's collapsed..
I'll take a look into it. It's probably a line of code and it will work, but I had focused on templates for start, testing multiple things. If it's the one liner I'll add it here. |
ntsekouras
force-pushed
the
revisions-panel-in-templates-df-experiment
branch
from
6efe8d9 to
45ebf3d
Compare
Contributor
Author
|
@t-hamano I tested now and added the panel for template parts and patterns. |
ntsekouras
changed the title
oandregal
reviewed
Apr 6, 2026
| <TemplateContentPanel /> | ||
| { window?.__experimentalDataFormInspector && | ||
| [ 'post', 'page' ].includes( postType ) && ( | ||
| [ |
Member
There was a problem hiding this comment.
Small practical thing: can we have this logic in a single place? The sidebar component could be that place, which means we move these checks to the sidebar.
By doing the above, the bigger question is more obvious. How do we absorb all the parts of the inspector into the view config endpoint? Right now, it only provides the DataForm config for the summary. What are the blockers, if any, to provide config for every panel?
Member
There was a problem hiding this comment.
Small practical thing: can we have this logic in a single place? The sidebar component could be that place, which means we move these checks to the sidebar.
Tracked this at #76076 as "Centralize logic to load experiment in the sidebar component (conversation)."
Member
There was a problem hiding this comment.
By doing the above, the bigger question is more obvious. How do we absorb all the parts of the inspector into the view config endpoint? Right now, it only provides the DataForm config for the summary. What are the blockers, if any, to provide config for every panel?
This is connected with a conversation I had with @mcsf that's tracked #76544
Identifier. How do we support screens that don't match 1:1 to entities (e.g., Connectors, Settings?).
This is the case here as well: revisions are not an entity, but a feature of an entity. Alternatives we discussed are:
- Switch to a specific id. For example, to address this, we could have
postType/templateas id (for the summary) but alsopostType/template/revisionsas an id for the revisions part. - Alternatively, we could add a 3rd parameter (
variant) to address those alternate situations related to the kind/name. In this case,kind: postType,name: template,variant: revisions, for example.
In both cases, we'd have two requests to the endpoint to retrieve the data we need (summary and revisions of the entity).
Member
There was a problem hiding this comment.
Or, given this premise: revisions are not an entity, but a feature of an entity, we add revisions by default as a new prop in the view config endpoint. But, again, the view config endpoint may need to work with screens that don't match 1:1 to entities (in which case, what'd be the usage of the revisions prop for them?).
Contributor
Author
There was a problem hiding this comment.
I encountered part of what you describe (1:1 match) in this PR where we want a template to have a form for site settings and even for a different page altogether (see blog title). I used different forms in that case and I think that's something the consumer should need to handle per use case - for us it was post-summary with more forms.
Small practical thing: can we have this logic in a single place? The sidebar component could be that place, which means we move these checks to the sidebar.
If I'm understanding right, you'd like to have a way for the view config endpoint to return panels too?
oandregal
reviewed
Apr 6, 2026
oandregal
reviewed
Apr 6, 2026
oandregal
reviewed
Apr 6, 2026
oandregal
reviewed
Apr 6, 2026
oandregal
reviewed
Apr 6, 2026
Comment on lines
+91
to
+109
| render: ( { item } ) => { | ||
| const dateNowInMs = getDate( null ).getTime(); | ||
| const date = getDate( item[ dateField ] ?? null ); | ||
| const displayDate = | ||
| dateNowInMs - date.getTime() > DAY_IN_MILLISECONDS | ||
| ? dateI18n( | ||
| getSettings().formats.datetimeAbbreviated, | ||
| date | ||
| ) | ||
| : humanTimeDiff( date ); | ||
| return ( | ||
| <time | ||
| className="editor-post-revisions-panel__revision-date" | ||
| dateTime={ item[ dateField ] } | ||
| > | ||
| { displayDate } | ||
| </time> | ||
| ); | ||
| }, |
Member
There was a problem hiding this comment.
All this render code can be replaced by:
{
id: 'date',
label: __( 'Datetime' ),
type: 'datetime'
}And the only difference are the styles attached to the field (uppercase, font weight&size).
| Before | After |
|---|---|
 |
 |
Some questions:
- Are those styles necessary? If so, how can we make it easier for consumers to provide styles for fields without having to reimplement a render function that's already provided by DataViews via the type? Note the render provided by the type also handles formats.
- What if we moved this field definition to the fields package?
Contributor
Author
There was a problem hiding this comment.
The styles were added in v1 to match the GS revisions. Since we want to see if we can consolidate those two, it's the minor detail for now.
All this render code can be replaced by:...
And the only difference are the styles attached to the field (uppercase, font weight&size).
I guess the datetimeAbbreviated could be supplied as the datetime format, but the other thing missing is the humanTimeDiff and the handling of conditional logic of when to show it (here is only for changes in the same day).
how can we make it easier for consumers to provide styles for fields without having to reimplement a render function that's already provided by DataViews via the type?
Maybe we need to explore supporting a render declarative config like we do for Edit? 🤔 It would probably require a wrapper for each field and a className prop at least?
What if we moved this field definition to the fields package?
This is tied with humanTimeDiff specific logic. If we want to keep that, it's too specific for being reused - at least for now where there are no other cases.
11 tasks
ntsekouras
force-pushed
the
revisions-panel-in-templates-df-experiment
branch
from
45ebf3d to
b42151d
Compare
6 tasks
Contributor
Perhaps we should consider this first? Certainly, just because the classic revision uses a slider doesn't mean we have to follow suit. So, will the UI be something like a global style, like this? 
|
Contributor
Author
|
I don't disagree about revisiting the revisions UI in general and the feedback is good, but this PR shouldn't be blocked by it. I think it's better to create a new issue about this and involve design. I think the temp blocker for this to land would be the change for templates' date field. |
ntsekouras
force-pushed
the
revisions-panel-in-templates-df-experiment
branch
from
b42151d to
aba4492
Compare
oandregal
approved these changes
Apr 9, 2026
Member
The thing I agree with here: we should add a timeline view to the document inspector in the revisions screen. That was the plan, but got distracted with general 7.0 stuff. I'm also not sure how much it makes sense to add a timeline "preview" as a panel in the editor, it feels like it would only be harder to get to the revisions screen. The thing I disagree with: to remove the slider. Having two distinct ways to navigate the revisions is fine. One navigates revisions on a coarse level and allows you to browse them really quickly. It will also allow us to add a sort of "flame graph" in the next release. (Didn't have time for that either this cycle.) The timeline proves a finer way to navigate revisions with different details. It's a bit like a sewing machine having a pedal to sew fast and a wheel to slowly get through a tricky part. Having different ways to browse something is not a bad thing in my opinion, I don't think we have to choose. |
Contributor
Author
Contributor
|
Agree with all the feedback. In the context of this PR I suppose it raises a question about whether we need to show the timeline in both locations. Access to revisions could theoretically be much simpler if we're going to display the timeline in the Revisions UI, for instance maybe the "Last edited 2 days ago" text links through and we don't need a dedicated panel? Fine to explore separately I guess. |
This was referenced Apr 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
Part of: #76076
Extracted from: #76934
In the linked PR I'm working on expanding the
Editor Inspector: Use DataFormexperiment to other post types (focusing on templates so far). This PR adds the revisions panel (under the experiment) fortemplates, template parts and patterns.Noting that in this PR revisions are shown both in the post summary and the experimental panel, but it's fine for now in order to iterate with smaller PRs.
Testing Instructions
Editor Inspector: Use DataFormexperimentTesting Instructions for Keyboard
Site editor template editing
Screen.Recording.2026-04-02.at.7.56.33.PM.mov
Post editor template editing
Screen.Recording.2026-04-02.at.7.57.43.PM.mov