Add extensibility points to Visual Revisions for 3rd party devs - pave the way for experimentation with Future and Public revisions - #81710

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: sethrubenstein <smrubenstein@git.wordpress.org>
Co-authored-by: adamsilverstein <adamsilverstein@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>

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

Screenshot from @sethrubenstein's Slack post:

Thanks for the initiative; I think this is interesting. A couple of surface thoughts.

I think we should avoid the PluginPostRevisionHeader slot. The header has limited space, and similar slots can be easily abused by plugins for attention. It's already a case where the editor and project don't even provide slots there.

I think the scheduled revision (based on the screenshot) can have controls in the document sidebar summary card, and the "Restore" label can change to "Schedule" or something similar, based on the revision type.

PluginPostRevisionInfo - we should find a better name for this 😄 Maybe PluginPostRevisionSummary|Details or something.

editor.PostRevision.badges - have we considered an API shape for this? For example: registerRevisionBadge. Filters can lock down certain decisions, making it impossible to ship architectural changes without breaking BC.

A related read - https://make.wordpress.org/core/2024/09/12/gutenberg-development-practices-and-common-pitfalls/.

I think we should avoid the PluginPostRevisionHeader slot. The header has limited space, and similar slots can be easily abused by plugins for attention. It's already a case where the editor and project don't even provide slots there.

Fair enough; I can pull that out of this PR and rethink how that would work in the interface.

I think the scheduled revision (based on the screenshot) can have controls in the document sidebar summary card, and the "Restore" label can change to "Schedule" or something similar, based on the revision type.

PluginPostRevisionInfo - we should find a better name for this 😄 Maybe PluginPostRevisionSummary|Details or something.

Will do!

editor.PostRevision.badges - have we considered an API shape for this? For example: registerRevisionBadge. Filters can lock down certain decisions, making it impossible to ship architectural changes without breaking BC.

🤔 let me think on this one and see if there's a way around a filter for this. Is there a way to hook into the DataViews Timeline view?

FWIW, I’m not suggesting slot fills just for the sake of it. I’m also working on porting our prc-revisions plugin to a feature plugin: https://github.com/pewresearch/wp-feature-future-revisions. I’m hoping to iterate on it to address the needs outlined in these issues:

#60096
#60394

FWIW, I’m not suggesting slot fills just for the sake of it.

I know, but there are some areas where adding SlotFills can make UX worse, which is unfortunate.

let me think on this one and see if there's a way around a filter for this. Is there a way to hook into the DataViews Timeline view?

@ntsekouras, might have more details for this.

I’m making a few more tweaks today. I’ve already removed the filter and the other slot fill. On second thought, those additions aren’t necessary for developing this feature as a plugin for future public revisions. All I really need is something in the postcard, with the one slot fill I added remaining.

Will update here when ready for another review.

Thanks, @sethrubenstein!

As the saying goes, "less is more" 😄

Hey 👋 I wanted to give you a heads-up since this pull request adds new files containing JSX.

#80123 enables an ESLint rule that requires that files containing JSX must use the .tsx file extension. This is in line with coding guidelines expecting new code to be written as TypeScript.

What you'll need to do: You'll need to rename any new files containing JSX to use the .tsx file extension. This may also require you to address type errors that were not previously caught due to the use of the .js file extension.

This comment is automated, based on pull requests with recent activity that contain affected .js or .jsx files. But if you have any questions or if I can help with the migration in any way, please let me know and I'll do my best to help!

Thanks for the PR @sethrubenstein! The pain point is real, since the plugin slots unmount in revisions mode, but I'm hesitant about adding public slots there in general, while this UI is still iterating. There are also these related issues 1, 2.

I think what's missing for me here is a separate issue with the limitations and requests and not a PR directly. Maybe we could gather them in #76785 or a dedicated one. That way we could plan better and address some things separately, because we need to be careful what we make a public API, especially since we want to consolidate the global style revisions too. Also, some of the requests might make sense to be in core directly if they are useful for everyone.

For example making some selectors public (like getCurrentRevisionId) could be fine as a first step. --cc @ellatrix

let me think on this one and see if there's a way around a filter for this. Is there a way to hook into the DataViews Timeline view?

This is actually being discussed here and while I had a comment more against it, it's for different reasons (filters). Fields addition should be fine.