Page MenuHomePhabricator

Don't remove custom user options when using Special:Preferences
Closed, ResolvedPublic

Description

With [[mw:API:Options]] it is now possible for gadgets/user scripts/etc. to set their own custom options. But there is one drawback: Whenever the user changes his settings on Special:Preferences, those custom options are removed.
Steps to reproduce:

  1. Visit [[Special:APISandbox]], get a token to change your options and then use action=options with change "gadget-foo-options-bar=baz".
  2. Verify that the custom option is set by inspecting mw.user.options.
  3. Visit [[Special:Preferences]] and click save.
  4. Repeat step 2.

Desired result: The custom option is still present.
Actual result: The custom option doesn't exist any more.


Version: 1.21.x
Severity: enhancement

Details

Reference
bz37187

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:26 AM
bzimport set Reference to bz37187.

The Preferences reset first all to avoid storing all preferences in the database. Custom preferences are unknown to mediawiki and therefor removed.

Maybe custom preferences should by forbidden.

(In reply to comment #1)

The Preferences reset first all to avoid storing all preferences in the
database. Custom preferences are unknown to mediawiki and therefor removed.

Maybe custom preferences should by forbidden.

Can we just remove known preferences?

(In reply to comment #2)

(In reply to comment #1)

The Preferences reset first all to avoid storing all preferences in the
database. Custom preferences are unknown to mediawiki and therefor removed.

Maybe custom preferences should by forbidden.

Can we just remove known preferences?

Sorry, I mean old preferences, see the comment in Preferences.php:

"Keeps old preferences from interfering due to back-compat code, etc."

Custom preferences should be forbidden or there are allow with a fixed prefix, than it is possible to find that preferences and not removing it.

As pointed out in Bug 40124, this would be a great help for community-scripts if properly implemented.

Fixed by gerrit change I5f9ba5b0.

(See bug 40124 for details and discussion.)