Page MenuHomePhabricator

ERI Metrics fromrc=1 URL-extension breaks heavily used admin script
Closed, ResolvedPublic

Description

The fromrc=1 URL-extension introduced for T158458 breaks a user script used by many admins on the German-language Wikipedia.

I'm reporting here on behalf of our most active bureaucrat and vandal fighter User:Itti that whenever she tries to block someone using a commonly used user script (I believe it is DerHexer/admin.js) the parameter "fromrc=1" gets added to the user name, which then needs to be removed manually before proceeding. As you can imagine, this severely disrupts the workflow.

Two possible solutions come to mind:

  • An option is added to the user settings (or a script is provided to add to the user's custom JS) which disables the feature (and all possible future URL extensions) for the user
  • In case this URL extension and similar features will from now on be used on a regular, longterm basis, a standard is developed which can be incorporated into user scripts which extract information from URLs

For the time being, I'd like to ask for the feature to be disabled on the German-language Wikipedia until a solution is found.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

We've already written and merged https://gerrit.wikimedia.org/r/348504 which disables the ?fromrc=1 addition, and we won't add it back unless and until we find a way to make it non-disruptive.

This week there is a moratorium on non-emergency deployments because of the server switch. I will ask Greg to treat this as an emergency issue and let me deploy the fix; if he doesn't agree to that, then the fix will arrive on German Wikipedia with the next scheduled code update on April 27th.

If the script can't deal with query string parameter, then that probably indicates that the script is fragile or buggy. From a quick look at the script you linked, I think I may have spotted the issue, so I'll see if I can fix it.

Stashbot subscribed.

Mentioned in SAL (#wikimedia-operations) [2017-04-17T22:08:30Z] <catrope@tin> Synchronized php-1.29.0-wmf.20/extensions/WikimediaEvents/modules/ext.wikimediaEvents.recentChangesClicks.js: T158458 T163152 (duration: 16m 23s)

Mentioned in SAL (#wikimedia-operations) [2017-04-17T22:46:01Z] <catrope@tin> Synchronized php-1.29.0-wmf.20/extensions/WikimediaEvents/modules/ext.wikimediaEvents.recentChangesClicks.js: T158458 T163152 (duration: 03m 01s)

Catrope claimed this task.

The fix should be deployed now; it didn't quite work the first time because of T163158: acpi_pad consuming 100% CPU on tin, so I had to deploy it again after that was fixed.

Thanks for the deploy, we as a community really appreciate your quick response on this issue!

If the script can't deal with query string parameter, then that probably indicates that the script is fragile or buggy. From a quick look at the script you linked, I think I may have spotted the issue, so I'll see if I can fix it.

Yes, it is probably easy to fix, the problem just arises because the URLs used in this and other scripts in the past never had query string parameters and there was no warning ahead of time that this would change. When you need these parameters, it is of course not a major issue to adapt user scripts accordingly, but I would ask you to give us as a community at least a months notice so that we can go through our tools and check that they are compatible (the same way you announce the removal of outdated JS for example).

A hack in my script should avoid such problems in the future.