Phase 3: Revisions

[priethor]

This overview is a living document originally based on @mtias' Phase 3 Revisions post.

Collaboration workflows require revisions and edit history to be clear, usable, and performant. The design of the traditional post revisions interface needs to evolve to become fully aware of blocks. It should offer better visual comparison capabilities beyond the classic HTML code diffing, which is getting less and less adequate for illustrating block modifications. It should provide easy mechanisms for spotting changes regardless of the content type being shown.

Mockup showing a paragraph block with three words highlighted in green as "additions".
As part of improving the overall experience, we should also go beyond document level history and explore how the interface could let users browse through single block changes and offer the ability to restore them individually rather than requiring full post restores. For global styles, we should evolve the revisions panel to allow comparing two revisions side by side. For synced patterns, we could allow browsing edit history with side by side and overlay comparison tools.

There’s also a semantic overlap between conflict resolution in real-time collaboration, offline reconciliation, and restoring or managing edit history. At the same time, internal revisions in WordPress are not a replacement for version control systems, so there has to be points of contact to ensure developers can lift from or deploy changesets down to the filesystem as needed. Plugins should also be able to extend the capabilities and develop more advanced integrations on top of what Core provides. For example, consider the case of using all the site editor tools but ensuring user modifications are saved back into files so they can be managed by git or svn workflows, including wp-cli integrations. Exploring some of these problems should also help outline what architectural considerations multi-lingual would present in Phase 4 when managing content over all possible site objects.

Finally, we should investigate if we can adapt customize_changeset to orchestrate revision grouping across all new entities and requirements — such as grouping multiple revisions together, reference and orchestrate changes to entities, etc.

Scope

• Design a revisions interface that can better highlight visual differences beyond markup diffing. Align presentation of added & removed content with how edit suggestions might be presented in the other collaborative workflows.
  • Revisions: add a way to share and preview a specific revision #60096
• Integrate with blocks. Allow selecting a block (like an image) and see all changes that have occurred to it. It should work out of the box with nested contexts, so if you select a parent it tracks and shows changes across all its children as well. Users should be able to focus at any level within a document.
• Make it easy to restore changes on a document or per block basis. For example, reverting some design changes to an embedded pattern but keeping the rest of the post as is, even if the pattern is not synchronized separately. The flows for restoring should be connected with the flows for publishing, so a revision can be made the currently published view.
• Explore ways in which branching could work for multi-entity history. For example, site title changes won’t be naturally covered in the edit history of a template that contains a site title block, but it could be referenced through a customizer changeset that connects template revision and discrete entity values. The multi-entity saving flow should evolve to take this into account.
• Evaluate any possible shortcomings in storage and performance of the various revision systems if they are to be used broadly (for example, everything going through posts tables).
• Improve the visual comparison tools so a user can check their content side by side or using overlays to spot differences. This can be rehearsed on the global styles revisions history and focused pattern views.
  • Style Revisions: Offer comparison views #53484
• Develop more immediate clarity over what properties were changed on certain revisions. For example, on style revisions list if there were changes to color palettes, to typography, etc, to improve the browsing experience.
  • Style revisions: add search and consider bringing in data views sorting #58353
  • Style revisions: reconsider identical styles messaging and apply button behaviour  #58526
• Explore viability of naming or grouping revisions, particularly for staging changes in the future. Connect “save” area in site editor flows with customize_changeset or equivalent. Keep track and list entity modifications.
  • Introduce Named Revisions/Versions #60394
• Review the revisions extended plugin for scheduling updates to already published posts.