Set $wgEnableRestAPI = true; by default;
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Legoktm
	Jul 9 2020, 9:06 PM

Description

/**
 * Enable the experimental REST API.
 *
 * This will be removed once the REST API is stable and used by clients.
 */
$wgEnableRestAPI = false;

What is missing before we can set this to default enabled? Since VisualEditor/Parsoid being shipped in 1.35 is expected to rely on rest.php. As we would like to push most users to enable VE/Parsoid, doing so would effectively enable the Rest API for most users...in which case we should just flip the default to enabled.

If there are blockers, we should have them block this task so we can figure out how reasonable this is for 1.35 and in general.

Details

	Subject	Repo	Branch	Lines +/-
	Set $wgEnableRestAPI = true; by default and deprecate	mediawiki/core	master	+6 -8

Customize query in gerrit

Related Objects

Mentioned In: T248343: Uncached VisualEditor w/ Parsoid/PHP (no JS, no RESTBase) for MW 1.35 LTS

Event Timeline

Legoktm created this task.Jul 9 2020, 9:06 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 9 2020, 9:06 PM

Reedy added a project: MW-1.35-release.Jul 9 2020, 11:28 PM

Legoktm renamed this task from Enable $wgRestAPI = true; by default; to Set $wgEnableRestAPI = true; by default;.Jul 10 2020, 1:48 PM

Legoktm mentioned this in T248343: Uncached VisualEditor w/ Parsoid/PHP (no JS, no RESTBase) for MW 1.35 LTS.

Jdforrester-WMF awarded a token.Jul 10 2020, 2:15 PM

Jdforrester-WMF subscribed.

Akuckartz awarded a token.Jul 10 2020, 5:14 PM

Akuckartz added a project: MediaWiki-Stakeholders-Group.

Akuckartz subscribed.

The subtlety here is that Parsoid in 1.35 will use the REST API, but only as a short-term bridge while we wait for some deeper ParserCache integration to be done post-1.35. So although Parsoid satisfies the "used by clients" phrase in the configuration comment, Parsoid is only a temporary client; Parsoid won't use the REST API in 1.36ish (maybe 1.37, depending on how the critical path goes).

So there may be some justification for continuing to label the REST API in core experimental and temporary. But we'd still like to enable $wgEnableRestApi by default in 1.35 to make VE work out of the box, even if we eventually turn it off/break it/change it/don't use it in 1.36/1.37.

Tagging the Core Platform Team's clinic duty group to get confirmation that this is OK to enable by default. I think it is, but it'd be great to know for sure.

In T257628#6300348, @Jdforrester-WMF wrote:

Tagging the Core Platform Team's clinic duty group to get confirmation that this is OK to enable by default. I think it is, but it'd be great to know for sure.

Should be enabled per default I think, but @EvanProdromou should confirm.

By the way, I'd rather remove the config variable than just default it to true. At least deprecate it.

In T257628#6300456, @daniel wrote:

In T257628#6300348, @Jdforrester-WMF wrote:

Tagging the Core Platform Team's clinic duty group to get confirmation that this is OK to enable by default. I think it is, but it'd be great to know for sure.

Should be enabled per default I think, but @EvanProdromou should confirm.

By the way, I'd rather remove the config variable than just default it to true. At least deprecate it.

Even better; would be lovely to drop the config and unconditionally run this code (new in 1.35, so no deprecation needed). Config bloat is a thing we wish to avoid, after all.

Ah, damn it, it shipped in 1.34. Oh well.

Change 612179 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] Set $wgEnableRestAPI = true; by default and deprecate

https://gerrit.wikimedia.org/r/612179

gerritbot added a project: Patch-For-Review.Jul 13 2020, 11:11 AM

I think the way forward proposed by the patch is confusing. Either we should remove the setting altogether, or keep it functional for another version of MediaWiki. Removing its functionality without removing the setting seems unhelpful at best.

In T257628#6300694, @MGChecker wrote:

I think the way forward proposed by the patch is confusing. Either we should remove the setting altogether, or keep it functional for another version of MediaWiki. Removing its functionality without removing the setting seems unhelpful at best.

Welcome to the terrible world of MediaWiki config deprecations. :-(

In T257628#6300835, @Jdforrester-WMF wrote:

Welcome to the terrible world of MediaWiki config deprecations. :-(

This is for the benefit of extensions that may rely on the setting, right? Would be nice to have a Config wrapper that triggers deprecation warnings when deprecated settings get accessed.

Please enable by default.

In T257628#6301094, @daniel wrote:

In T257628#6300835, @Jdforrester-WMF wrote:

Welcome to the terrible world of MediaWiki config deprecations. :-(

This is for the benefit of extensions that may rely on the setting, right? Would be nice to have a Config wrapper that triggers deprecation warnings when deprecated settings get accessed.