RTC: [Interface] Allow limiting Real-Time Collaboration to specific post types

[smithjw1]

What problem does this address?

It is currently difficult for sites with diverse content architectures to adopt real-time collaboration safely. Real-time collaboration is an all-or-nothing feature, which creates several pain points:

• Legacy meta box incompatibility – Custom post types that rely on classic meta boxes (e.g., for statistics, structured data, or plugin-specific fields) don't fully participate in real-time sync. We are working on this, but support may never be universal.
• CPT-specific breakages – In beta testing, some custom post types have admin page implementations that conflict with real-time collaboration, causing errors (including 500s). Site owners have no way to keep real-time collaboration enabled for standard posts while troubleshooting these issues.
• Gradual rollout needs – Editorial teams want to validate real-time collaboration on their primary content types before expanding to all post types. Currently, there's no supported way to do this.
• Workflow mismatch – Some post types (e.g., simple landing pages, reusable blocks, or programmatically-generated content) may never benefit from collaborative editing, while others (e.g., long-form articles) benefit greatly.

What is your proposed solution?

Provide a supported mechanism for developers to opt specific post types out of real-time collaboration. RTC would remain enabled by default for all post types, but developers could disable it where needed.

A filter hook would offer the most flexibility:

add_filter( 'gutenberg_rtc_enabled_for_post_type', function( $enabled, $post_type ) {
    // Disable RTC for the 'gallery' post type
    if ( 'gallery' === $post_type ) {
        return false;
    }
    return $enabled;
}, 10, 2 );

Alternatively, a registration-based approach using existing patterns could work:

remove_post_type_support( 'gallery', 'real-time-collaboration' );

Either approach would allow developers to:

• Opt out CPTs with known incompatibilities until those are resolved.
• Disable real-time collaboration for post types where collaborative editing doesn't fit the workflow.
• Maintain a fallback if a specific CPT breaks without disabling real-time collaboration site-wide.

[Mamaduka]

IIRC, the current collaboration feature is closely tied to the editor. Having it as a sub-feature for it might be a good option.

We did the same thing with the Notes (#71682).

[smithjw1]

We have also discussed "temporal" restrictions. Limiting real-time collaboration in the moments before publishing or when a post is in a certain workflow state.

"Always" is a time period. I wonder if a more "just-in-time" approach will be easier to deal with. In other words before real-time collaboration starts up, there is a moment to ask, "Should it?"

You could use the post type to answer that question "no" all the time and achieve a similar effect.

[JDeepD]

Hi. I am working on this for past few days as the implementation of it is linked to how #77380 is implemented. In my opinion, in all cases where Custom Post Types are registered through plugins, it should be upto the plugin developers to allow RTC. I like the approach suggested by @smithjw1 on having filters for opting out of RTC.

There is also a downside to this, that is, in all the existing sites where plugins are not updated to account for RTC, things might break if we enable RTC globally for all post types and then rely on plugin developers to push an update to opt out of RTC. Regarding the "just in time" approach, if we prompt the user to enable RTC manually per session, it could introduce unnecessary friction into the writing experience.

I think we could enable RTC by default for core types (posts, pages) but require explicit opt-in for custom post types. This resolves the backward compatibility issues for post types introduced by plugins. Let me know what you think of it.