Add WP_ALLOW_COLLABORATION constant by alecgeatches · Pull Request #11311 · WordPress/wordpress-develop · GitHub

Update from @ingeniumed:

Noting that it's now WP_ALLOW_COLLABORATION wherein:

true - this means collaboration can be turned on false - this means collaboration cannot be turned on not defined - this means collaboration can be turned on

It can be defined in a way to allow hosts to disallow the feature at an environment level.

Trac ticket: https://core.trac.wordpress.org/ticket/64904

Screenshots

With

define( 'WP_ALLOW_COLLABORATION', false );

With

define( 'WP_ALLOW_COLLABORATION', true );

or no WP_ALLOW_COLLABORATION configuration at all, the default checkbox:

Use of AI Tools

AI assistance: Yes
Tool(s): Claude
Model(s): Opus 4.6
Used for: Implementation

…_enabled() function

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.

Core Committers: Use this line as a base for the props when committing in SVN:

Props alecgeatches, ingeniumed, zieladam, peterwilsoncc, tyxla.

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

…collaboration`

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

All changes will be lost when closing a tab with a Playground instance.
All changes will be lost when refreshing the page.
A fresh instance is created each time the link below is clicked.
Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

I have a few of suggestions.

Instead of a constant with a negative intent, it is clearer to use a positive intent. This avoids having code along the lines of if ( CONSTANT === true ) then false;
It's more precise to describe the constant as whether or not RTC is permitted, than whether RTC is enabled or disabled. I think WP_ALLOW_COLLABORATION is a better match for that intent.
As a part of the consideration is to allow hosts to disallow the feature at an environment level, allowing an environment variable to be set will help meet their needs
Instead of needing to repeat the ! defined() && ..., define the default value in wp_functionality_constants()

My suggestion is to add the following to wp_functionality_constants() and modify the PR for the various implications

/**
 * Whether real time collaboration is permitted to be enabled.
 *
 * @since 7.0.0
 */
if ( ! defined( 'WP_ALLOW_COLLABORATION' ) ) {
	if ( false !== getenv( 'WP_ALLOW_COLLABORATION' ) ) {
		// Environment variable is defined.
		if ( 'true' === getenv( 'WP_ALLOW_COLLABORATION' ) ) {
			define( 'WP_ALLOW_COLLABORATION', true );
		} else {
			define( 'WP_ALLOW_COLLABORATION', false );
		}
	} else {
		// Environment variable is not defined, default to true.
		define( 'WP_ALLOW_COLLABORATION', true );
	}
}

I have a few of suggestions.

Instead of a constant with a negative intent, it is clearer to use a positive intent. This avoids having code along the lines of if ( CONSTANT === true ) then false;

It's more precise to describe the constant as whether or not RTC is permitted, than whether RTC is enabled or disabled. I think WP_ALLOW_COLLABORATION is a better match for that intent.

As a part of the consideration is to allow hosts to disallow the feature at an environment level, allowing an environment variable to be set will help meet their needs

Instead of needing to repeat the ! defined() && ..., define the default value in wp_functionality_constants()

My suggestion is to add the following to wp_functionality_constants() and modify the PR for the various implications
/**
 * Whether real time collaboration is permitted to be enabled.
 *
 * @since 7.0.0
 */
if ( ! defined( 'WP_ALLOW_COLLABORATION' ) ) {
	if ( false !== getenv( 'WP_ALLOW_COLLABORATION' ) ) {
		// Environment variable is defined.
		if ( 'true' === getenv( 'WP_ALLOW_COLLABORATION' ) ) {
			define( 'WP_ALLOW_COLLABORATION', true );
		} else {
			define( 'WP_ALLOW_COLLABORATION', false );
		}
	} else {
		// Environment variable is not defined, default to true.
		define( 'WP_ALLOW_COLLABORATION', true );
	}
}

Thanks for the feedback @peterwilsoncc. I've updated the code with that in mind.

I did have to leave the defined check in collaboration.php as it was erroring out without that.

Let me know what you think of the updated code 🙏🏾

Noting that it's now WP_ALLOW_COLLABORATION wherein:

true - this means collaboration can be turned on
false - this means collaboration cannot be turned on
not defined - this means collaboration can be turned on

It can be defined in a way to allow hosts to disallow the feature at an environment level.

There's a potential edge case to verify here: if wp_is_collaboration_enabled() is called before WP_ALLOW_COLLABORATION is defined, RTC will also be disabled regardless of the database option.

Can we verify that this function can't be called before the constant is defined? If we can't verify this, or we found a way to call wp_is_collaboration_enabled() before the constant was declared, can we amend the docs to make this edge case clear?

The constant is defined in wp_functionality_constants(); which is called in wp-settings.php (after require "collaboration.php") so the premature reference would have to happen at some point in the WordPress boot flow before that call (or via SHORTINIT). Two possible solutions I see are:

Accept that edge-case, since the same gotcha is true for other constants defined in that function: AUTOSAVE_INTERVAL, EMPTY_TRASH_DAYS, WP_POST_REVISIONS, and WP_CRON_LOCK_TIMEOUT.
Define the constant before the function is defined, e.g. directly in collaboration.php, maybe even inside of that function if it's not defined by the time of the call. That would look something like this:

function wp_is_collaboration_enabled() {
	if ( ! defined( 'WP_ALLOW_COLLABORATION' ) ) {
		$env_value = getenv( 'WP_ALLOW_COLLABORATION' );
		if ( false !== $env_value ) {
			define( 'WP_ALLOW_COLLABORATION', 'true' === $env_value );
		} else {
			// Environment variable is not defined, default to true.
			define( 'WP_ALLOW_COLLABORATION', true );
		}
	}

	if ( ! WP_ALLOW_COLLABORATION ) {
		return false
	}

	return (bool) get_option( 'wp_collaboration_enabled' );
}

Which would be fine with me. There's a precedence of a similar behavior in kses.php:

https://github.com/alecgeatches/wordpress-develop/blob/be03ad089eae148e2d95e429579022bef69c77c9/src/wp-includes/kses.php#L32-L53

I suggest we keep this part as it is for beta6 and revisit it in RC1 cc @ellatrix

Confirming that this makes sense to me 👍

The constant is defined in wp_functionality_constants(); which is called in wp-settings.php (after require "collaboration.php") so the premature reference would have to happen at some point in the WordPress boot flow before that call (or via SHORTINIT). Two possible solutions I see are:

Thanks for catching this, I hadn't noticed the order of operations.

Of the two suggestions I think defining the constant in wp_is_collaboration_enabled() is the safest approach for RC1. @adamziel are you able to look in to this in #11322 (I'm at a mate's 50th today so won't have a chance, sorry).

@peterwilsoncc I started a new PR for that here: #11333

I think we should also have a defined() check before we actually use the constant, just in case someone is loading the writing settings admin page in an unconventional way.

Something like

Suggested change

      
            	<?php if ( ! WP_ALLOW_COLLABORATION ) : ?>
          
            	<?php if ( ! defined( 'WP_ALLOW_COLLABORATION' ) || true === WP_ALLOW_COLLABORATION ) : ?>

I'll take the liberty of merging the suggestion. Feel free to rollback my commit if needed.

@adamziel this seems wrong; did you mean:

<?php if ( ! defined( 'WP_ALLOW_COLLABORATION' ) || false === WP_ALLOW_COLLABORATION ) : ?>

If we make it true we're inverting what we had there before, which looks unintentional.

My intention was "if collaboration is allowed, allow the user to decide whether they want to use it". Yours reads to me like "If collaboration is implicitly allowed by not defining the constant OR the collaboration is explicitly not allowed, then allow the user to decide" which seems off to me.

Ah no, you're right and I'm wrong. Good spot. I'll open a PR to correct this, CC @ellatrix

wp_functionality_constants() doesn't seem to be called during SHORTINIT, so any code path that refers to WP_ALLOW_COLLABORATION will fail with:

Fatal error: Uncaught Error: Undefined constant "WP_ALLOW_COLLABORATION" in

What would be the best way to document that? While the same is true for AUTOSAVE_INTERVAL and other constants defined in wp_functionality_constants(), WP_ALLOW_COLLABORATION seems to have some potential to pop up in different places around the PHP codebase.

Co-authored-by: Marin Atanasov <8436925+tyxla@users.noreply.github.com>

Looks good to me and works as intended. Note: I've merged a few suggestions @tyxla and I proposed. I know it's not the typical workflow, but I took that liberty in the name of beta 6. I think they're good additions and I'm also happy for any of them to be reverted as needed.

This provides an easy way at config level to disable real-time collaboration. Developed in: #11311. See #64904. Props alecgeatches, ingeniumed, zieladam, peterwilsoncc, tyxla. git-svn-id: https://develop.svn.wordpress.org/trunk@62075 602fd350-edb4-49c9-b593-d223f7449a82

This provides an easy way at config level to disable real-time collaboration. Developed in: WordPress/wordpress-develop#11311. See #64904. Props alecgeatches, ingeniumed, zieladam, peterwilsoncc, tyxla. Built from https://develop.svn.wordpress.org/trunk@62075 git-svn-id: http://core.svn.wordpress.org/trunk@61357 1a063a9b-81f0-0310-95a4-ce76da25c4cd

Closing since it's been committed

The WP_ALLOW_COLLABORATION constant was introduced in PR WordPress#11311 to support disabling RTC at the host level or at the wp-config.php level. A part of that PR was hiding the "Enable RTC" checkbox in the writing options when RTC is explicitly disallowed via the constant. In the process of reviewing the change and merging suggestions, I have used the wrong condition to hide that checkbox. This PR makes the condition right. Props to @tyxla for noticing! \# Testing instructions * Set the WP_ALLOW_COLLABORATION constant to false, go to writing options, confirm the checkbox is replaced by a message "Real-time collaboration has been disabled". * Set it to true, confirm the checkbox is there. * Remove the constnat, confirm the checkbox is there.

Add WP_DISABLE_COLLABORATION constant and wrapper wp_is_collaboration…

3041494

…_enabled() function

alecgeatches mentioned this pull request Mar 19, 2026

First pass at constant for forcing enable/disable of real time collab #11310

Open

alecgeatches added 2 commits March 19, 2026 15:05

Merge branch 'trunk' into add/disable-collaboration-flag

6727bfb

Use wp_collaboration_enabled instead of old flag `enable_real_time_…

7d114c8

…collaboration`

peterwilsoncc reviewed Mar 19, 2026

View reviewed changes

Switch the constant to be a positive intent based on feedback

c77ced1

ingeniumed mentioned this pull request Mar 20, 2026

Add backport for WP_ALLOW_COLLABORATION WordPress/gutenberg#76716

Merged

alecgeatches changed the title Add WP_DISABLE_COLLABORATION constant Add WP_ALLOW_COLLABORATION constant Mar 20, 2026

Merge branch 'trunk' into add/disable-collaboration-flag

9bd0e60

tyxla reviewed Mar 20, 2026

View reviewed changes

adamziel and others added 3 commits March 20, 2026 14:58

Check if the constant is defined() before using it

72f9195

Update src/wp-admin/options-writing.php

be03ad0

Co-authored-by: Marin Atanasov <8436925+tyxla@users.noreply.github.com>

Clarify the string "false" vs boolean "false" in collaboration.php

c76e32b

adamziel approved these changes Mar 20, 2026

View reviewed changes

ellatrix closed this Mar 20, 2026

adamziel mentioned this pull request Mar 20, 2026

Adjust the WP_ALLOW_COLLABORATION check in writing options #11322

Closed

adamziel mentioned this pull request Mar 23, 2026

RTC: Define WP_ALLOW_COLLABORATION in wp_is_collaboration_allowed() #11333

Closed

github-actions Bot mentioned this pull request Mar 30, 2026

PHP backports for WP 7.0 WordPress/gutenberg#74043

Closed

maxschmeling mentioned this pull request Apr 29, 2026

RTC: Allow swapping the built-in polling provider via environment variable WordPress/gutenberg#77810

Open

-              		<input name="wp_collaboration_enabled" type="checkbox" id="wp_collaboration_enabled" value="1" <?php checked( '1', (bool) get_option( 'wp_collaboration_enabled' ) ); ?> />
-              		<?php _e( 'Enable real-time collaboration' ); ?>
-              	</label>
+              	<?php if ( ! WP_ALLOW_COLLABORATION ) : ?>

+               * If the WP_ALLOW_COLLABORATION constant is false,
+               * collaboration is always disabled regardless of the database option.
+               * Otherwise, falls back to the 'wp_collaboration_enabled' option.

	<?php if ( ! WP_ALLOW_COLLABORATION ) : ?>
	<?php if ( ! defined( 'WP_ALLOW_COLLABORATION' ) \|\| true === WP_ALLOW_COLLABORATION ) : ?>

Add WP_ALLOW_COLLABORATION constant by alecgeatches · Pull Request #11311 · WordPress/wordpress-develop · GitHub

Uh oh!

Add WP_ALLOW_COLLABORATION constant - #11311

Add WP_ALLOW_COLLABORATION constant#11311alecgeatches wants to merge 8 commits intoWordPress:trunkWordPress/wordpress-develop:trunkfrom alecgeatches:add/disable-collaboration-flagalecgeatches/wordpress-develop:add/disable-collaboration-flagCopy head branch name to clipboard

Conversation

alecgeatches commented Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Screenshots

Use of AI Tools

Uh oh!

github-actions Bot commented Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Mar 19, 2026

Test using WordPress Playground

Some things to be aware of

Uh oh!

peterwilsoncc left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ingeniumed commented Mar 20, 2026

Uh oh!

ingeniumed commented Mar 20, 2026

Uh oh!

Uh oh!

tyxla Mar 20, 2026

Choose a reason for hiding this comment

Uh oh!

adamziel Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adamziel Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tyxla Mar 20, 2026

Choose a reason for hiding this comment

Uh oh!

peterwilsoncc Mar 20, 2026

Choose a reason for hiding this comment

Uh oh!

adamziel Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

tyxla Mar 20, 2026

Choose a reason for hiding this comment

Uh oh!

adamziel Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adamziel Mar 20, 2026

Choose a reason for hiding this comment

Uh oh!

tyxla Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adamziel Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adamziel Mar 20, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

adamziel commented Mar 20, 2026

Uh oh!

adamziel left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ellatrix commented Mar 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Add WP_ALLOW_COLLABORATION constant#11311
alecgeatches wants to merge 8 commits into
WordPress:trunkfrom
alecgeatches:add/disable-collaboration-flag

alecgeatches commented Mar 19, 2026 •
edited
Loading

github-actions Bot commented Mar 19, 2026 •
edited
Loading

peterwilsoncc left a comment •
edited
Loading

adamziel Mar 20, 2026 •
edited
Loading

adamziel Mar 20, 2026 •
edited
Loading

adamziel Mar 20, 2026 •
edited
Loading

tyxla Mar 20, 2026 •
edited
Loading

adamziel Mar 20, 2026 •
edited
Loading

adamziel left a comment •
edited
Loading