Page MenuHomePhabricator

Suppress redirects when moving *.js and *.css pages during a user rename
Closed, ResolvedPublic

Description

After usernames are renamed more than once, the move creates pointless .css and .js double redirects that clutter Special:DoubleRedirects and an admin is needed to fix them as these pages are treated like protected pages.

I see three ways to fix this.

  1. Ignore .css and .js pages while populating Special:DoubleRedirects
  2. Do not create a redirect after moving .css and .js pages
  3. Allow bots to edit .css and .js pages if these pages are redirects or allow bots to edit .css and .js pages like admins.

The problematic .css and .js pages are almost always the ones in the former userspace of renamed users.


Version: unspecified
Severity: normal
See Also:

Details

Reference
bz34930

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:09 AM
bzimport set Reference to bz34930.
bzimport added a subscriber: Unknown Object (MLST).

Stop having accounts renamed multiple times...

They are not my accounts though so I have no influence on how other people rename their accounts on all wikis.

Special:DoubleRedirects is full of such renames as evidently people do rename two or more times fairly often.

The user rename issue is a red herring. The issue here is that after a page move, CSS and JS redirects behave in a very funky way. I changed the summary from "Handling of .js and .css pages post rename" to "Handling of .js and .css pages post page move".

A few parts to this. Behavior is user moves a JS/CSS page from one title to another using MediaWiki page move form. This leaves behind a redirect (by default).

Redirect's current behavior is broken by the page's syntax highlighting, which assumes that everything in the text area of a page ending in .css or .js is CSS or JS. (This bug might be a duplicate.)

Problems with not redirecting:

  • it's annoying as hell that the redirects don't work as you'd expect them to

Problems with redirecting:

  • redirects can't easily be edited
    • still usually need an admin account to do any edits due to the redirect page titles still ending in .css/.js and getting special protection for it
      • users editing their own personal .css/.js pages shouldn't hit this issue
    • bots trying to fix double redirects hit walls
  • sets up a false expectation about following these redirects programmatically, maybe?
    • not sure what behavior is here nowadays with ResourceLoader

I run my bot on practically every wiki and these need to be dealt with manually or else they pile-up eventually rendering Special:DoubleRedirect's useless.

How about... instead of converting .css and .js pages into "#redirect[[foo]]", they are turned into "importScriptURI('url to foo');"

Code would continue operating and not flood double redirects. This can be done when the account is being renamed.

See also:

  • Bug 33973
  • Bug 30074
  • bug 31827

(In reply to comment #0)

  1. Ignore .css and .js pages while populating Special:DoubleRedirects

No.

  1. Allow bots to edit .css and .js pages if these pages are redirects or allow

bots to edit .css and .js pages like admins.

Never ever. Major security leak that would be.

  1. Do not create a redirect after moving .css and .js pages

Sounds good, that's a task for the Renameuser extension. Rephrased this bug for that.

  1. Do not create a redirect after moving .css and .js pages

Sounds good, that's a task for the Renameuser extension. Rephrased this bug for
that.

Why not to fix T35973 instead?

(In reply to comment #7)

  1. Do not create a redirect after moving .css and .js pages

Sounds good, that's a task for the Renameuser extension. Rephrased this bug for
that.

Why not to fix bug 33973 instead?

That is a separate bug, which may be an invalid bug, even.

He7d3r added a project: JavaScript.
He7d3r set Security to None.
Legoktm claimed this task.

This was fixed when ContentHandler was introduced.