This page is within the scope of WikiProject JavaScript, a collaborative effort to improve the coverage of articles related to JavaScript, and to the development of user scripts for use on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.JavaScriptWikipedia:WikiProject JavaScriptTemplate:WikiProject JavaScriptJavaScript articles
What scripts are you working on or maintaining, or would like to build?
Feel free to share the details of your user script projects, your problems, your ideas, and your JavaScript-related technological fantasies on this page. :) The Transhumanist01:10, 14 April 2017 (UTC)[reply]
I'm looking to build a userscript the interacts with a template call, and I was hoping that there's another one out there that I can see how this functionality works. Specifically, I want the userscript to do the following:
Scan a page on load for a particular template call.
Insert a button for openning up a javascript window if the template is found, preferably at the template's location on the page.
Load template parameters into fields in the new javascript window.
Does anyone know of a userscript that does something like this, or a set of userscripts that together do all of these functions? Am I completely crazy thinking this is even possible? It's been about 20 years since I last programmed anything in javascript, so I'm very much looking for a place to start connecting the dots again. Thanks for any help you have. VanIsaacWScont18:28, 24 June 2020 (UTC)[reply]
For looking for a template call within wikitext, and finding the parameters and their values, you can use the parseTemplates function of MediaWiki:Gadget-libExtraUtil.js (which is a gadget, so can be loading using ResourceLoader's mw.loader.using). Actually finding the parsed html of the template within the page's html is going to be more tricky, and may not be possible, e.g. if the template output is indistinguishable from regular wikitext, such as {{ndash}} or other formatting templates. - Evad37[talk]03:24, 25 June 2020 (UTC)[reply]
I've wanted a user script that finds and highlights occurrences of a given template for a while – extending such a user script to meet your specification wouldn't be that hard. Both scripts are completely feasible with Parsoid. However, from my past experience, I know they'll probably be pretty annoying/difficult to write, so I haven't written anything yet. I'd be happy to give advice or an outline of how to proceed to anyone who wants it, though. Enterprisey (talk!) 06:42, 25 June 2020 (UTC)[reply]
It's certainly fine to have this script parse wikitext only while editing if that makes things easier. But since the script is only useful interacting with a few specific templates, it's completely reasonable to just program the templates with custom HTML classes for the script data. I would assume that would vastly simplify extracting those values. VanIsaacWScont18:04, 25 June 2020 (UTC)[reply]
A little late, but is it supposed to scroll down to where the template is and open up a screen, then load the parameters?
Anyone know how I can authenticate a request from a user script to a Toolforge tool? I'm not sure OAuth would work, since I figure that uses cookies (but I would be happy to be wrong about that). I could always have the user script make an edit or a log entry and pass the diff/log entry ID with the request, but that seems spammy. Enterprisey (talk!) 07:12, 3 July 2020 (UTC)[reply]
Evad37, so I was thinking that I would send a request from the user script to the tool, and the tool would then query rest.php/oauth2/resource/profile to see if the user is logged in. That's not the correct use of OAuth, I think (because I would be sending a token associated with the user to /profile, so the answer (barring token expiration) would always be "yes, the user's logged in"). I'm not sure how else to validate that a user is logged in without somehow making a request from the tool that carries the en.wp session cookies. Enterprisey (talk!) 08:30, 3 July 2020 (UTC)[reply]
A tool for watchlisting a section (a user can subscribe/unsubscribe to a section). I don't want to store subscription lists onwiki because sections can move, be merged, etc, which would require a bot to update them. Also, just as watchlists aren't public, section watchlists shouldn't be, either. Thus, I want the userscript to make authenticated requests to a tool that stores the subscription lists in a database. Enterprisey (talk!) 00:15, 4 July 2020 (UTC)[reply]
Enterprisey, do you mean editing on behalf of a user or just authenticating that the user is that user? For the latter, I've already had some ideas about this for RW - so the script would generate a random token on the user side (the private token), have that be passed to toolforge which will store the token and also hand back a public token string which will then be used to make a public edit on Wikipedia somewhere, be it a config file or authentication page (similar to the way WP:DISCORD authenticates users). Then, the script will give the private token and the revision ID which will then link the user who made that edit to the owner of both the public and private token. From then on, the requests would be authenticated by including the private token in the request which is only known to the server and the client - the private token would be stored in a cookie or document storage so it's never made public, and when it expires the process will just run again - but this isn't the most secure solution, but I'd say its more ideal over handing auth cookies. Doing this means that authentication would be far less often. Ed6767talk!18:09, 3 July 2020 (UTC)[reply]
Looks good, and thanks for the infographic! (Very high-effort!) I will probably end up trying this if I can't find an existing solution. Enterprisey (talk!) 01:31, 4 July 2020 (UTC)[reply]
Indeed - for people stumbling across this - this should be noted as a very basic sketch in my head, untested verification system and should never ever ever ever be used as authentication of to carry any sort of sensitive info. OAuth2 or another existing system is always ideal. Ed6767talk!22:07, 4 July 2020 (UTC)[reply]
Calling for volunteers for RedWarn - a fast growing new JavaScript counter-vandalism tool
The RedWarn team is currently in the process of renaming to Ultraviolet. Some documentation pages are still in the process of being written/transferred. Read the announcement here.
Ultraviolet is a new, fast-growing JavaScript counter-vandalism tool, specifically designed for user friendliness. Ultraviolet has gained over 200 new users and is rapidly growing every day. So far, 40,000+ edits have been made with the tool. Thanks to your help, Ultraviolet is now backed by a team of hard-working and trusted volunteers. If you'd like to join us, you don't need to be a genius, or have any major experience to volunteer — and, to be cliche, it may even be a great thing to put on your resume. Engaging in Ultraviolet's development is a good way to get your work in use by hundreds of editors across the globe. If you've had any JavaScript, PHP, HTML, CSS, design, translation, counter-vandalism, or other experience that would aid in Ultraviolet's development, your contributions would be highly valued!
It's not uncommon to need to restore a discussion from a talk venue archive, but it's not easy to do it correctly and exceeds the ability of many editors. I wonder if anyone would be interested in creating a restore-from-archive script modeled after OneClickArchiver. Instead of clicking an "Archive" link on a talk page, one would click a "Restore" link on an archive page. The coding would be a little simpler than OneClickArchiver, which has to worry about whether it's time to create a new archive page. Any taker? ―Mandruss☎22:08, 27 November 2020 (UTC)[reply]
JS on wikimedia is currently too antiquated to ever bloom
I would love to contribute code to wikipedia, but I'm once again failing at the same obstacle I did 6 months ago. Wikimedia is geared to a now over 10 years old version of JavaScript. Let's put that in perspective: Wikimedia is geared to a version of JavaScript that's that was released the same year as Windows 7! Back then I was barely a teenager. JQuery is now not much more than a relic, and all it does now is encouraging sloppy code-style and making debugging a lot harder. Combine this with the relatively large API of Wikimedia and the complete lack of modern comforts like Intellisense and TypeScript it becomes nearly unsurmountable to produce a functional script while keeping your sanity for someone who has become accustomed to the modern ways.
There is sadly no easy way to remedy this...
The changes necessary would be large enough to warrant an essentially total rewrite of the MediaWiki software. And while this would open up some awesome opportunities, I won't blame anyone breaking out in cold sweat when they just imagine it.
True. WP:RedWarn ran into this issue (cc Ed6767). Would be nice if you could specify some build options to be applied to a JS/TS file after you hit "Save", so we could at least use Babel. Or maybe the devs could give us a few checkboxes with various transpilers (Babel, TS compiler) for each user script. Shouldn't be that tough to add. Enterprisey (talk!) 17:01, 13 December 2020 (UTC)[reply]
(not Ed, but) Hard agree with the sentiments here. As a developer more skilled with modern web technologies, trying to piece together code for Wikipedia has been a hassle. Old MediaWiki JavaScript has been quite the problem for RedWarn, especially now when we're rewriting RedWarn from the ground up using TypeScript. MediaWiki's codebase not having type definitions is another pain in the rear, since every time we want to use a function or property within MediaWiki's mw, we've had to place whatever we need in a declaration file that has been expanding even more and more as progress goes on. I've tried to automatically grab the types based on the provided JSDoc inside of the source, but to no avail, as it it extremely complicated to do so. Since a rewrite of MediaWiki's JavaScript parts is (unfortunately) out of the question (unless WMF wants to spend some funds to make that happen), we've had to deal with this old and clunky method. My best advice would be to have the MW JS documentation at hand whenever making scripts, and just rely on your best senses to see which goes with which. Sure, it's a strong timesink, but once you're used to the extremely old and aging JavaScript codebase, it shouldn't really be a problem. Babel/TS transpilers don't sound that bad, but that might raise some security or performance issues. I guess the only way to find out if that's the case would be to actually bring that suggestion to the Phab. But if there's anything that Wikipedia has taught me about its developers, it's that there's a lot of people who are overly attached to old processes and tech, and that introducing changes as big as these (especially when it uses newer technologies) is commonly met with a lot of criticism. Chlod (say hi!) 17:31, 13 December 2020 (UTC)[reply]
They're finally converting JSDuck to JSDoc? 🎉 Finally! It's a bit disappointing that the Babel idea was shot down, though. It would have provided a universally better experience for writing user scripts. Chlod (say hi!) 18:11, 13 December 2020 (UTC)[reply]
I wrote about the issue on Wikipedia:Village pump (technical)#Proper ECMAScript support, and there are discussions ongoing T75714. Some people are so afraid of new technology, to quote from an issue written just a few days ago: "JS is a hazard and was a mistake.". For me there is just no way I can justify the amount of work and time needed to produce even the smallest thing. It's really a shame because I think this is a major hindrance for the loads of skilled JS/ES/TS devs who regularly contribute to OSS projects that may be interested in contributing here... SkSlick (talk) 20:57, 13 December 2020 (UTC)[reply]
And see here for a spirited discussion on upgrading Twinkle to use TypeScript as part of a rewrite for localizability (spoiler: it doesn't seem to be going well).
@Chlod: Actually just a few weeks ago I too started out writing a mediawiki.d.ts file. It seems my raw coverage is greater, but I have put in just the types and not doc-comments. Can we please collaborate on this so that the same definitions can be used across Twinkle and Redwarn and hopefully, many more scripts/gadgets to come? Open to setting up a separate repo for this that can be published to npm. – SD0001 (talk) 14:47, 17 December 2020 (UTC)[reply]
On another note, I also think it might be useful to make a project on Meta-Wiki where we do this, and additionally can provide warning/xfd/tag definitions in a standard format that can be used across all bots/scripts/tools/etc. It'd make things much easier for everyone just having one standard library that can be installed via NPM, or the raw JSON data that can be fetched/stored locally. It'd also mean Wiki localisation would be so much easier, and all the tools can provide the same templates. What do you think? 🎄🎄 Edtalk! 🎄🎄 15:48, 17 December 2020 (UTC)[reply]
@Ed6767: That would be a nice thing to aim for. But I'm not sure if that's straightforward as all that data isn't easily represented in JSON form. Here's the file for tag data. 95% of it is JSON, but it gets tricky to stay within JSON limits for the data on what inputs to ask the user for each tag. – SD0001 (talk) 17:46, 18 December 2020 (UTC)[reply]
@SD0001, it'd just take a rework of the way the data is processed and the logic works, which is a plus if anything as you wouldn't have to write/copy more code if you needed to add a different tag with similar functionality. We could provide example code to aid any new tool developers with this. 🎄🎄 Edtalk! 🎄🎄 18:59, 18 December 2020 (UTC)[reply]
So I did this, and then out of curiosity looked at the pageviews stats for WP:US. Looks like they went from 60-80ish daily earlier this year, and then plunged at the beginning of May to 20-40ish daily, where they remain. Did it get de-linked from somewhere big? (pinging people from the discussion at TT:Script doc auto, who definitely didn't ask to get pinged but I figure might still be interested: Sj, SD0001, and DannyS712) Enterprisey (talk!) 09:25, 19 December 2020 (UTC)[reply]
Hi there! I am going to suggest moving these user script "snippets" formerly managed by WikiProject User scripts to be migrated to user space. This brings multiple advantages, but mainly improves security (they would be interface-admin protected essentially), and readability / ease-of-use (the pages that are not currently marked as JS in terms of content model would be able to be installed using scripts like scriptinstaller). 🐶 EpicPupper(he/him | talk)19:13, 13 March 2022 (UTC)[reply]
You are invited to join the discussion at Wikipedia:Village pump (technical)#Creating and saving a preloaded page with one click. {{u|Sdkb}} talk 19:42, 14 June 2020 (UTC)
Done - Evad37 [talk] 12:38, 19 December 2020 (UTC)
You are invited to join the discussion at WP:VPIL § Bold idea: the Generic Queue Toolkit. Enterprisey (talk!) 07:12, 11 August 2021 (UTC) Enterprisey (talk!) 07:12, 11 August 2021 (UTC)