Set $wgMFEditorOptions['anonymousEditing'] = true by default for all wikis
Closed, ResolvedPublic

Description

Per broad global consensus at https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum&oldid=11628429#Proposal:_restore_normal_editing_permissions_on_all_mobile_sites (see "Conclusion" for the summary) and per the closure of T55069, it's been decided to set $wgMFEditorOptions['anonymousEditing'] on all wikis.

The request is to get this done by the end of March, with a preference for getting T54165 fixed as soon as possible.

From an operational perspective, it may be advisable to have a staggered release, perhaps by triggering the configuration change in correspondence with the enabling of 1.25wmf23 (between Wednesday, 25 March 2015 and Wednesday, 1 April 2015). By not purging the caches, the effect will be gradual; while purging the caches would be required if site-wide consistency is desired. Either way, the effects in terms of traffic are negligible, based on it.wikipedia's experience (and even in case of a difference of one order of magnitude in other wikis).

Related Objects

Nemo_bis created this task.Mar 19 2015, 3:43 PM
Nemo_bis added a subscriber: Nemo_bis.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 19 2015, 3:43 PM
Nemo_bis edited the task description. (Show Details)Mar 19 2015, 3:58 PM
Nemo_bis set Security to None.
greg added a subscriber: greg.
greg added a subscriber: Eloquence.
greg added a subscriber: JKatzWMF.Mar 20 2015, 3:38 PM
greg added a comment.Mar 20 2015, 11:49 PM

@JKatzWMF: can I get your opinion on rollout strategy? Does this need a staggered rollout, or can/should it be a "do it everywhere on date" thing?

JKatzWMF added a comment.EditedMar 21 2015, 12:12 AM

@greg I believe a staggered rollout is preferable (as this will have an unknown impact on edits), but defer to others as I am honestly 95% unfamiliar with the ask. @Nemo_bis Is this merely a settings change? Who is doing the work for this? What are the metrics for success?

Moushira added a comment.EditedMar 21 2015, 12:40 AM
  1. Do we want a user who clicks edit to go directly to an edit page? Or do we want to use the new feature as an opportunity to educate/introduce more people to editing WP? It is possible that investing in this step is more valuable than investing in counter-vandalism.
  2. As a starter, and as we test, can we align anon edit with WP Zero to allow a full functionality for free, and to start with relatively smaller Wikipedias like: Arabic, Urdu, Malay, Bengali..etc.
  3. Talk pages will help with controversial discussion, what else could help?

Thanks :-)

The problem in activating anonymous editing is, like Jon said on mobile-l[1], that the config var is cache related (it is actually stored in the html output, generated by SkinMinerva.php through OutputPage::addJsConfigVars() [2]). To avoid the same problems like on itwiki (See T74855: Purge is required to edit some page as unregistered user and T74856: Purge cache for all it.m.wikipedia.org pages) it would (in the actually state) be needed to purge page caches on all wikis, where this settings changes (in fact all wikis except itwiki), which is fairly a bad idea.

A solution could be to load wgMFEditorOptions via RL (e.g. through ResourceLoaderGetConfigVars hook [3]), for which, iirc, the cache-time is very short (15 minutes, see T91372#1081364)?

[1] https://lists.wikimedia.org/pipermail/mobile-l/2015-March/008809.html
[2] https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/skins/SkinMinerva.php#L837
[3] https://www.mediawiki.org/wiki/Manual:Hooks/ResourceLoaderGetConfigVars

greg assigned this task to Jdlrobson.Mar 21 2015, 1:33 AM
greg added a subscriber: Jdlrobson.

The problem in activating anonymous editing is, like Jon said on mobile-l[1]

@Jdlrobson Given that, can I please assign this to you to write the config patches/sheperd them out (it'd be the week the 30th, ie not in 3 days but 10 days)?

It's not just config changes it is probably php/js changes too.

In terms of my time you'll have to okay that with @JKatzWMF first as I need to get Gather in a MVP deployable state first.

I fear 30th may be far too soon (see my reply to Nemo's email on wikitech). I'd rather we did this carefully and properly then rush it and mess up.

Jdlrobson removed Jdlrobson as the assignee of this task.Mar 21 2015, 1:42 AM

I don't want to give the false impression I'm doing this yet. I'm super swamped with work right now.

greg moved this task from Unscheduled to June 2015 on the Roadmap board.Mar 21 2015, 1:45 AM

It's not just config changes it is probably php/js changes too.

In terms of my time you'll have to okay that with @JKatzWMF first as I need to get Gather in a MVP deployable state first.

Official request placed, @JKatzWMF :)

I fear 30th may be far too soon (see my reply to Nemo's email on wikitech). I'd rather we did this carefully and properly then rush it and mess up.

Noted. I placed this in the "April-June" column on the roadmap given that.

I don't want to give the false impression I'm doing this yet. I'm super swamped with work right now.

Noted and agree :)

Thanks @greg April - June seems much more realistic.

Also I echo @Moushira particularly 1. Would be great if @jaredzimmerman could have a quick glance at how its working on Italian Wikipedia and suggest cheap ways to improve it if any.

Mmm.. Also looks buggy just tried to get past through the first screen on Italian Wikipedia and couldn't do it on my nexus 5 (maybe a bug?)

Would be good to add some browser tests to this before putting in production.

Elitre added a subscriber: Elitre.Mar 21 2015, 11:15 PM
Nemo_bis claimed this task.EditedMar 23 2015, 6:28 AM

Mmm.. Also looks buggy just tried to get past through the first screen on Italian Wikipedia and couldn't do it on my nexus 5 (maybe a bug?)

That's T91372.

@greg I believe a staggered rollout is preferable

Ok. Your other questions are answered in the discussion.

[...]
Thanks :-)

1 and 3 are discussed in the respective bugs and are not blockers, see T55069 and discussion. As for 2, we could use small.dblist etc.

As for Jon's question, 4, the "feature" of unregistered editing is not new but exists since 2001, it's rather a fundamental characteristic of our projects. So, yes, it only needs to be enabled. 1–3 were answered in the discussion.

it would (in the actually state) be needed to purge page caches on all wikis

As we want a staggered release, there might be no urgent need of a cache purge. T91372, as currently described, can be addressed later and is not a blocker.

Change 198691 had a related patch set uploaded (by Nemo bis):
Restore unregistered editing on mobile sites (staggered)

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

Added the gerrit link to https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=prev&oldid=149551 . This is only a site request; if you have suggestions or reports which involves code changes, please post them on separate tasks so that we have a clear overview.

As we want a staggered release, there might be no urgent need of a cache purge. T91372, as currently described, can be addressed later and is not a blocker.

I don't know, how this would solve our problem? I thought we don't want to purge page caches on any wikipedia version, which would be needed at the moment. Background: The config var, which controls, if unregistered users can edit or not, is delivered as a skin config var, which will be in the page html output (directly in the head of a page's source). And as far as i know, html pages are cached for unregistered users 30 days (?), which would result in the same problem like on itwiki:

Some pages (which are edited and rerendered) are already editable by unregistered users, and others are not (maybe because they aren't edited so often). Because of this we had to purge _all_ page caches on itwiki to enable anonymous editing.

To be clear: I want to resolve this task as soon as possible, too, but i must agree with Jon: It would be terrible to have the same problems on enwiki (or dewiki or any other wmf-wiki) like we had on itwiki. So i would welcome it, if we are totally sure, that we don't need to change anything (or purge caches or something else) before we merge the config change :)

So, open questions for me (maybe they are already answered and i haven't read it, than : sorry :():

  • Are JS Skin Config variables (added through OutputPage::addJsConfigVars()) cached? (They life in html source, so i think: yes)
    • How long they are cached?
    • Would it help to move the config var to a Resourceloader hook (which are, iirc, cached for 15 minutes only)?

I'm pretty sure if the option is moved to the RL startup module (using the Resourceloader hook the cache can be cleared in 5 mins) Basically we want to do what VE is doing since I guess they have the same problem. This would roll it out to all users in 5 minute window and allow us to disable it for all users within a 5 minute window,

So I think although we want a staggered release we want the ability to turn off instantly? It may be better to release it to projects one at a time on a daily basis, starting with the smaller ones. Would that work?

Change 199227 had a related patch set uploaded (by Florianschmidtwelzow):
Move wgMFEditorOptions to ResourceLoaderGetConfigVars hook

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

Change 199227 merged by jenkins-bot:
Move wgMFEditorOptions to ResourceLoaderGetConfigVars hook

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

Restricted Application added a project: Notice. · View Herald TranscriptMar 24 2015, 10:30 PM
gpaumier moved this task from Backlog to Triaged on the Notice board.Mar 25 2015, 9:58 PM
revi added a subscriber: revi.Mar 29 2015, 12:48 PM

Please exclude kowiki; Per the consensus here (It is support for Prohibiting them)

Stryn added a subscriber: Stryn.Mar 29 2015, 1:29 PM

Please exclude kowiki; Per the consensus here (It is support for Prohibiting them)

Please file a separate report, so that it can be correctly referenced in the configuration.

Florian changed the title from "Set $wgMFAnonymousEditing = true by default for all wikis" to "Set $wgMFEditorOptions['anonymousEditing'] = true by default for all wikis".Mar 30 2015, 9:07 AM
Florian edited the task description. (Show Details)

Missed one question:

So i would welcome it, if we are totally sure, that we don't need to change anything (or purge caches or something else) before we merge the config change :)

As far as I know (and of course we can always improve our knowledge), there is no *need* to purge the cache immediately. it.wiki wanted to get the configuration applied to all pages as soon as possible, hence it asked an immediate purge of the whole cache. Are you aware of a reason which *forces* us to do the purge, or something else? If so, it would be nice to have it filed.

@Nemo_bis: The "problem" (which would require to purge page caches) was resolved with https://gerrit.wikimedia.org/r/199227 (which is part of MediaWiki train release 1.25wmf23). So, technically, there is no need to purge caches, just change the configuration (like every other config change).

@Nemo_bis: The "problem" (which would require to purge page caches) was resolved with https://gerrit.wikimedia.org/r/199227 (which is part of MediaWiki train release 1.25wmf23). So, technically, there is no need to purge caches, just change the configuration (like every other config change).

Thanks! I'll update the commit message of the configuration change.

Change 198691 merged by jenkins-bot:
Restore unregistered editing on mobile sites (staggered)

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

Hi Everyone--I apologize for the delayed response. It took me some time to get up to speed on the ask. The mobile web team is looking forward to deploying this, provided we can assure all implications are well understood and okayed. Anonymous editing is already enabled on test.wikipedia.org and @Moushira is going to be inviting community members to test the current workflow so that we can identify any bugs and workflow issues before deploying it. We also might have to have some internal conversations about the implications of such a move. @Amire80, any ideas around testing this for other languages before deploying elsewhere?

@Amire80, any ideas around testing this for other languages before deploying elsewhere?

Nothing special. I continuously test RTL, and it works well (I just checked master again).

All the relevant messages are translatable and well-documented, but it never hurts to publish an invitation to complete the translations to their languages:
https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-mobilefrontend#sortable:3=desc

AFAIK local admins don't bother to change CSS and JS for mobile sites, but some post-deployment testing on a sample of wikis won't hurt.

Nikerabbit moved this task from June 2015 to March 30-April 3 on the Roadmap board.Apr 1 2015, 9:41 AM
Glaisher closed this task as "Resolved".Apr 2 2015, 12:41 PM
Glaisher removed a project: Patch-For-Review.
Krenair added a subscriber: Krenair.Apr 8 2015, 2:21 AM
gpaumier moved this task from Triaged to Archive on the Notice board.Apr 9 2015, 5:45 PM
Mjbmr moved this task from Backlog to Done on the Wikimedia-Site-requests board.May 4 2015, 2:22 PM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptJun 27 2015, 10:46 AM