User is completely unable to edit content when `wp_enable_real_time_collaboration` is missing from `wp_options`

[desrosj]

When wp_enable_real_time_collaboration is not present as an option, the editor is unusable because the "Connection lost" screen to be shown almost immediately (as soon as the first wp-json/wp-sync/v1/updates request occurs) and basically prevents the user from editing any post on their site.

I discovered this because my site had enable_real_time_collaboration but no wp_enable_real_time_collaboration present in the options table.

Here is the timeline of events:

• Real-time collaboration was first introduced into trunk with the enable_real_time_collaboration option added to the default schema with a value of 1 in [61689].
• The $db_version was bumped in [61696].
• At some point between [61969] and [61702], the nightly build was refreshed.
• The default value was changed to 0 in [61702].
• Renamed to wp_enable_real_time_collaboration in [61722].
• Removed entirely in [61828].
• The option was re-added in [61833] as wp_enable_real_time_collaboration with a default value of 1, and this is the current state (as of [61862]).

It seems that any site that updated to the nightly build generated between 19 February and 20 February is likely to not have wp_enable_real_time_collaboration but enable_real_time_collaboration instead. The $db_version of the site would have updated to 61696, and wp_enable_real_time_collaboration never would have made it into the database because populate_options() only runs when $db_version is higher than the one stored in the database.

Related: #64622.

[desrosj]

Both edge cases of a site running the nightly generated on that fateful day, and wp_enable_real_time_collaboration missing entirely can be fixed simply by bumping the $db_version to 61833, which was the most recent commit to modify the default options in populate_options().

I don't think an upgrade_770() routine to remove enable_real_time_collaboration is necessary. I tested both 0 and 1 as the value for this option and it had no effect on the functionality.

However, database updates don't happen during the time between releases. It's almost never bumped for minor releases, and a bump is not guaranteed in every major version (only when there are changes to the schema). I bet that a non-zero number of users will manually delete the option from the database thinking that it will disable the feature if they don't want it.

Because of this, I think that the user should not be completely locked out of editing their site when the option is missing entirely. Instead, "disabled" should be assumed in this scenario.

I'm on the fence about this next suggestion, but maybe Site Health could include a health check that notifies the user when the option is missing from the database that "Real-time collaboration is disabled because the option is missing".

[dlh]

I also encountered this issue today. But I think there's an issue in [61833] that contributes to the problem.

[61833] added a filter to default_option_wp_enable_real_time_collaboration to enable RTC by default. This happens in default-filters.php.

However, on rest_api_init, the wp_enable_real_time_collaboration setting is registered as part of register_initial_settings(). The registration arguments include a default of false, which adds another filter to default_option_wp_enable_real_time_collaboration. Because this filter is added later, it runs later and overwrites the filter from default-filters.php.

In my multisite installation running beta3, this was the cause of my seeing the immediate "Connection lost" message. If I change the priority of the __return_true filter to be greater than 10, it works as intended, and I don't see the message.

[desrosj]

@dlh Good catch! I'd bet that is what's causing this lock-out behavior.

It took me a minute to spot the second filter. For anyone else looking, filter_default_option() is hooked at the end of register_setting().

I'm going to commit the $db_version bump now because that fixes the edge cases that I outlined above. The absence of wp_enable_real_time_collaboration and what the correct filter hooks/values should be will need a bit more discussion.

Thinking this through, the options seem to be:

• Switching the $default in the register_setting() to true I believe this would end up overriding a false/off value from some combination of removing the default hook/an earlier hooked function.
• Removing the filter in default-filters.php would probably cause more edge cases where no value is returned at all or the feature is unexpectedly off by default.
• Remove the default from register_setting() entirely.

The last option seems like it may be the best choice because it would always fall back to true when the option is not present at all. @dlh Did you arrive at that path forward as well?

[desrosj]

In 61864:

Editor: Bump the database version to 61833.

The option to enable real-time collaboration was first added in [61689] as enable_real_time_collaboration with a value of 1 and the $db_version was bumped in [61696].

The option then went through a series of changes. This included: the default value changing to 0 in [61702], being renamed to wp_enable_real_time_collaboration in [61722], removed entirely in [61828], and finally being re-added as wp_enable_real_time_collaboration in [61862].

Because the $db_version was not bumped after these changes, it’s possible that the wp_enable_real_time_collaboration option is not present on any site that ran the nightly build generated between [61696] and [61702], or a nightly build/beta release published after [61828]. Since populate_options() runs when a new site is installed, this issue only affects pre-existing sites that had upgradd their database when wp_enable_real_time_collaboration was not specified as a default option within $defaults.

This bumps the database version to 61833, which is the most recent changeset to have modified the $defaults array in populate_options().

Props dlh, maxschmeling, smithjw1, kbat82.
See #64824, #64622.

[desrosj]

I did some testing, and it does seem like removing the default argument when calling register_setting() for wp_enable_real_time_collaboration fixes the issue. But I've only performed basic testing.

[dlh]

Replying to desrosj:

The last option seems like it may be the best choice because it would always fall back to true when the option is not present at all. @dlh Did you arrive at that path forward as well?

I don't really have a conclusion at this point, since I haven't been closely following the development of RTC, and so I don't know the reasoning behind the decisions that have been made.

I think I would just say:

1. As a developer, it's puzzling to read that the default is false in one place and true in another. (As a developer, I also understand that these things can happen!)

2. As a user, it's really puzzling to discover that nobody can edit anything when RTC fails, rather than there being a graceful degradation back to allowing one person to edit the post. I know that's not the point of this ticket, but it was the most salient part of the whole experience. But, like I said, I haven't been following the decisions closely.

[desrosj]

It looks like the second part of this was fixed as part of #64814.