Page MenuHomePhabricator
Create Task
Maniphest T85304

Migrate non-JS data from protected user JS subpages to protected JSON subpages
Open, MediumPublic
Actions

Description

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. https://meta.wikimedia.org/wiki/GlobalCssJs 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]].

Related Objects
Search...

Event Timeline

Nemo_bis created this task.Dec 25 2014, 9:09 AM
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 added a project: WMF-General-or-Unknown.
Nemo_bis updated the task description. (Show Details)
Nemo_bis set Security to None.
Nemo_bis added subscribers: TTO, eranroz, Rillke and 14 others.
TTO added a comment.Dec 25 2014, 9:12 AM

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.

Nemo_bis mentioned this in T85306: Handle existing #REDIRECT CSS/JS pages.Dec 25 2014, 9:30 AM
Glaisher subscribed.Dec 25 2014, 3:31 PM
Se4598 added a comment.Dec 26 2014, 12:17 AM

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.

Ricordisamoa subscribed.Dec 31 2014, 10:42 AM
Krinkle removed Krinkle as the assignee of this task.Feb 25 2015, 12:48 AM
Krinkle renamed this task from Migrate non-CSS/JS content stored in CSS/JS pages to Migrate non-JS data from protected user JS subpages to protected JSON subpages.Oct 5 2023, 2:37 AM
In T85304#944162, @Se4598 wrote:

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

Done.

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL