Page MenuHomePhabricator

Migrate non-CSS/JS content stored in CSS/JS pages
Open, MediumPublic


As a regular user who across got used to editing css/js subpages for storing non-css/js content across the years, I want to be able to use/edit them again without worries, e.g. without wondering what CSS/JS even is or should be and without receiving a warning I don't undestand.

Cf. for a more limited case; cf. "MediaWiki should allow creation of empty pages" bug, which I can't find due to T85303/T1375 and T76942+T85302.

For a start, a bot could comment out all the content in EditCounterOptIn.js subpages.

In T76204#800953, @TTO wrote:

I generated a list of all user JS subpages on the entire WMF cluster (all 222592 of them) and checked the first 20000 (from aawiki down to commonswiki) to see if they contain valid JavaScript.

Valid: 18300
Invalid: 1189
Failed: 511 [my script choked on be-x-old, cbk-zam, etc]
Total: 20000

See P117 for full output.

That's at least 6% containing invalid content, which is a significant proportion. Many of these are #REDIRECT pages, caused by T36930 and its see-alsos.

I came across a significant "abuse" of user JS pages: opt-in to the xtools edit counter e.g. [[ast:User:Savh/EditCounterOptIn.js]], [[az:User:Araz Yaquboglu/EditCounterOptIn.js]].

Event Timeline

Nemo_bis assigned this task to Krinkle.
Nemo_bis raised the priority of this task from to Medium.
Nemo_bis updated the task description. (Show Details)
Nemo_bis updated the task description. (Show Details)
Nemo_bis set Security to None.
Nemo_bis added subscribers: TTO, eranroz, Rillke and 14 others.

We could at least start by doing something about #REDIRECTs. Either make redirect syntax count as "valid JS" for MediaWiki purposes (although obviously #REDIRECT [[bla]] should never be served up to the user as JS content), or implement an alternative syntax for redirects on JavaScript pages.

I think at first this task should be limited to migrate content on JS pages (the scope of the blocked task).

Also it should be identified which apps (mis)use such pages.
EditCounterOptIn.js is easy task to fix whereas e.g. for css-pages Huggle requires significant work and a planned strategy.