RTC: Disable custom autosave controller when RTC is disabled

[ingeniumed]

What?

Closes #80662

Makes Gutenberg_REST_Autosaves_Controller delegate to WP_REST_Autosaves_Controller::create_item() when real-time collaboration is disabled.

Adds regression coverage confirming that collaboration-disabled autosaves use Core’s behaviour.

Why?

Gutenberg registers its collaboration autosaves controller for normal post types regardless of whether collaboration is enabled.

Although the RTC-specific draft behaviour was disabled through conditional branches, the controller’s custom redundant-autosave comparison still ran. When an edited title was reverted to the published value, this comparison returned the parent post without updating or removing the previous autosave.

Core Data consequently retained the previous autosave and its preview link, causing Preview to display stale content.

The collaboration controller should only alter autosave behaviour when collaboration is enabled. When collaboration is disabled, WordPress Core should remain responsible for handling the request.

How?

Adds an early return to Gutenberg_REST_Autosaves_Controller::create_item():

if ( ! wp_is_collaboration_enabled() ) {
	return parent::create_item( $request );
}

The existing RTC implementation remains unchanged.

The PHP regression test creates an existing autosave, disables collaboration, submits content matching the parent, and verifies that the response follows Core’s autosave behaviour rather than Gutenberg’s RTC-specific no-op handling.

Testing Instructions

1. Go to Settings → Writing and disable real-time collaboration.
2. Create a post titled Sample Page and publish it.
3. Change the title to Sample Page 2.
4. Preview the post and confirm that the preview displays Sample Page 2.
5. Return to the editor and change the title back to Sample Page.
6. Preview again.
7. Confirm that the preview displays Sample Page, rather than the stale Sample Page 2 autosave.
8. Enable real-time collaboration and repeat the steps.
9. Confirm that autosaving and Preview continue working with collaboration enabled.

Run the automated tests if you'd prefer that instead.

There are two specific tests:

• phpunit/tests/collaboration/restAutosavesController.php
• test/e2e/specs/editor/various/preview.spec.js > "should not use stale autosave data after reverting title"

Testing Instructions for Keyboard

Not applicable. This PR does not change the user interface.

Screenshots or screencast

Check out the issue for the bug video

Use of AI Tools

Codex was used for this PR.

[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: ingeniumed <ingeniumed@git.wordpress.org>
Co-authored-by: alecgeatches <alecgeatches@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: chriszarate <czarate@git.wordpress.org>

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

[ingeniumed]

Since RTC is not shipping in 7.1, and the existing changes in the controller were removed in core as part of the 7.0 release these changes do not need to be backported. These changes isolate the existing changes to only run when RTC is enabled, and those would be ported into core when RTC ships in core.

[Mamaduka]

Any reason we don't avoid whole class override if RTC isn't enabled in gutenberg_override_autosaves_rest_controller?

[chriszarate]

Any reason we don't avoid whole class override if RTC isn't enabled in gutenberg_override_autosaves_rest_controller?

I had essentially the same question here. Linking for visibility.

[ingeniumed]

Any reason we don't avoid whole class override if RTC isn't enabled in gutenberg_override_autosaves_rest_controller?

No reason for this to not be the case. My initial proposal limited the scope of changes to just the guard.

This has now been changed in f538be1.

I updated the autosaves controller registration so Gutenberg’s custom controller is selected only when RTC is enabled. When RTC is disabled, the post type keeps WordPress Core’s autosaves controller and follows Core’s existing autosave and preview behaviour.

The guard in Gutenberg’s controller remains as a defensive fallback in case the class is instantiated directly or explicitly registered while RTC is disabled. In that situation, it delegates to Core’s create_item() implementation. Tests cover controller selection with RTC enabled and disabled, preservation of an explicitly configured controller, and the defensive fallback to Core behaviour.

If adding the guard in is overtly defensive, happy to take it out but figured it couldn't hurt.

[ingeniumed]

@chriszarate / @alecgeatches - since RTC will be enabled for this section of the code, I simplified it down. In case I've missed some important logic, let me know.

[ingeniumed]

This is necessary due to the change made to how the controller is registered based on if RTC is enabled or not

[alecgeatches]

Should we also add another early return for wp_is_post_type_collaboration_disabled( ... )? It could be possible to have RTC enabled generally but disabled for a post type, which would cause RTC autosave behavior on a non-RTC post.

[ingeniumed]

Good point, that should be in there as well. I've added this in fad947e. I've also added in extra tests to ensure this is thoroughly tested.

[alecgeatches]

@ingeniumed Looks pretty good to me! I left a comment above about how we should also cover wp_is_post_type_collaboration_disabled() and delegate to core, but otherwise looks solid. Thanks!

[github-actions]

Size Change: 0 B

Total Size: 7.78 MB

_{compressed-size-action}