Jump to content

Wikipedia talk:User scripts: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
Using JS libraries: we may be required to use GPL2+ for our user scripts
Line 42: Line 42:
:::{{ping|Helder.wiki}} Good question. I believe it ''is'' one-way compatible provided you keep the copyright notice, which is also required by CC-BY-SA. But of course, I'm not a lawyer, so I can't say for sure. To clarify, the question is whether you can copy the script to Wikipedia, I see no possible problem with importing the script from somewhere else with mw.loader.load(). --[[User:V111P|V111P]] ([[User talk:V111P|talk]]) 17:16, 9 August 2014 (UTC)
:::{{ping|Helder.wiki}} Good question. I believe it ''is'' one-way compatible provided you keep the copyright notice, which is also required by CC-BY-SA. But of course, I'm not a lawyer, so I can't say for sure. To clarify, the question is whether you can copy the script to Wikipedia, I see no possible problem with importing the script from somewhere else with mw.loader.load(). --[[User:V111P|V111P]] ([[User talk:V111P|talk]]) 17:16, 9 August 2014 (UTC)
::::See also [[Wikipedia:Village pump (policy)/Archive 98#Proper licensing of gadgets, user scripts and lua modules]]. [[User:Helder.wiki|Helder]] 18:30, 9 August 2014 (UTC)
::::See also [[Wikipedia:Village pump (policy)/Archive 98#Proper licensing of gadgets, user scripts and lua modules]]. [[User:Helder.wiki|Helder]] 18:30, 9 August 2014 (UTC)
:::::{{ping|Helder.wiki}} Now I realize that technically we should probably license our user scripts with ''GPL v. 2 or later'' at least in addition to the default CC-BY-SA, otherwise we may be in violation of the license of the MediaWiki JavaScript modules we are using, including mw.loader. --[[User:V111P|V111P]] ([[User talk:V111P|talk]]) 22:22, 9 August 2014 (UTC)


== Asynchronous ends too late ==
== Asynchronous ends too late ==

Revision as of 22:22, 9 August 2014

Preloads for easier installing

Why are there no easy links to preloads to install scripts more easily? For example this link : [1] will automatically fill in the contents of the Template:! on a new section of the sandbox. Similarly, code could be appended to the bottom of the user's script page via preloads. The preload could perhaps be stored on the User:Example/Script.js/preload page. That would mean installing the script is only 1 click to open the user's script page, and 1 click to submit - instead of requiring the users to copy over the contents themselves.

From personal experience I say that in general it's best to do the work for users as much as possible, when it comes down to code. Of course this would not automatically insert the preload-link, but I think it would be good to add the option to add a preload link to the template. Any thoughts? Joeytje50 (talk) 21:28, 23 February 2014 (UTC)[reply]

Creating these extra preload pages and hiding from the user what is actually happening is not a good idea in my opinion. Plus we can't have new sections in the script files. But thanks for the suggestion. --V111P (talk) 08:58, 20 April 2014 (UTC)[reply]
A script could be made that adds a script to the user's javascript file. It would load the text of the file, append the new importScript() call, and edit the page with the new text. Then the user would only have to add a script once and then simply click a button to add new scripts. It could even be made to remove scripts if desired.--Dudemanfellabra (talk) 17:06, 20 April 2014 (UTC)[reply]
You can try Equazcion's ScriptInstaller. Having to install a script in order to install another script kind of defeats its purpose though. But if you want to try many different scripts it makes sence. --V111P (talk) 23:24, 20 April 2014 (UTC)[reply]

Automatic totals for a table?

Following a discussion at WT:FOOTY#Career totals template, we were wondering if anyone here would be able to create a script to automatically total up the numbers from the rows above. For example, this could be used for medal tables, where the bottom row is a sum of all medals won, or for career statistics, such as at Scott Loach#Career statistics. - 97rob (talk) 15:30, 6 June 2014 (UTC)[reply]

A link to the now archived discussion: #. I suggested using User:V111P/js/Sum numbers to sum the numbers manually. --V111P (talk) 19:44, 23 June 2014 (UTC)[reply]

Using JS libraries

Hello. I'm starting to do user scripts, previously I did mostly Python bots. I'm thinking about a user script that shows charts/graphs using Flotr library or similar. Is it possible to use these libraries in a user script? How? Thanks. emijrp (talk) 18:00, 22 June 2014 (UTC)[reply]

You can copy the contents of excanvas.min.js to a sub page of your user page and then load it from the main file of your user script, for example with mw.loader.load('//en.wikipedia.org/w/index.php?title=User:Emijrp/excanvas.min.js&action=raw&ctype=text/javascript'). You should also include the license [2] somewhere (the original Github page may disappears one day so just adding a link to it may not be enough). Another option is to try to load excanvas.min.js directly from Github, but I'm not sure if that's a good idea. --V111P (talk) 19:38, 23 June 2014 (UTC)[reply]
The simplest thing to do would be to copy the whole script directly into your user script. But what I like to do is to have a small main script file which loads the larger script when the user requests to use the tool. --V111P (talk) 23:45, 23 June 2014 (UTC)[reply]
@Emijrp and V111P: is that license compatible with CC-BY-SA? If not, the script could not be importedcopied to English Wikipedia. Helder 01:51, 8 August 2014 (UTC)[reply]
@Helder.wiki: Good question. I believe it is one-way compatible provided you keep the copyright notice, which is also required by CC-BY-SA. But of course, I'm not a lawyer, so I can't say for sure. To clarify, the question is whether you can copy the script to Wikipedia, I see no possible problem with importing the script from somewhere else with mw.loader.load(). --V111P (talk) 17:16, 9 August 2014 (UTC)[reply]
See also Wikipedia:Village pump (policy)/Archive 98#Proper licensing of gadgets, user scripts and lua modules. Helder 18:30, 9 August 2014 (UTC)[reply]
@Helder.wiki: Now I realize that technically we should probably license our user scripts with GPL v. 2 or later at least in addition to the default CC-BY-SA, otherwise we may be in violation of the license of the MediaWiki JavaScript modules we are using, including mw.loader. --V111P (talk) 22:22, 9 August 2014 (UTC)[reply]

Asynchronous ends too late

Hello. Here is a basic script that queries the API as explained in the documentation. But the result arrives too late, because the JS continues without waiting the api.get() finish, and numberOfEditors is [0, 0]. How can I stop the run until api.get() is really ".done()" ? emijrp (talk) 18:14, 22 June 2014 (UTC)[reply]

You cannot use return in a callback; when done() is fired, there is nothing to return to, because the function already returned [0, 0]. You need to point the callback to a separate function. -- [[User:Edokter]] {{talk}} 21:57, 22 June 2014 (UTC)[reply]
Using asynchronous I/O really requires a different way of looking at how a program operates. Assuming that you do not have significant additional processing to perform while the asynchronous operation is in process, you need to complete whatever operations you can/should do prior to getting the data from the asynchronous operation and then just return. You rely on getting a callback from the async op to start your processing back up again. You absolutely should not just sit and spin in a loop waiting for a flag to be set indicating completion. Doing so effectively changes the async op to synchronous which undermines the purpose of having asynchronous operations.
The typical method to accomplishing this is that you continue everything that should happen after the asynchronous action is complete from the callback function passed to the function which actually initiates the asynchronous action. Very specifically, there is a period of time during which your script is not actually running, except for the asynchronous action.
Conceptually, you really should not view it as something like a synchronous readFile(), but more of a requestURL(callWhenDataAvailable,callIfError). Your processing then stops, you return(), until you get a response. You should also set up a timeout so that you definitely get a callback to something that makes your script return to being processed. You should also initiate the async request as soon as you know that you are going to need it. Given that JS is, generally, single threaded, you don't have to worry about the issue of having the callback routing being called while you are still completing your initial processing.
I'm not sure I've done a decent job of explaining this, but how much of the surrounding concepts should be explained here is not clear. From your question, the fundamental thing that appears to be an issue is that you have not made the paradigm shift in your thinking from how to use synchronous I/O to how to use asynchronous I/O. One of the things that appears to help people conceptually is to use the difference in nomenclature I indicated above (i.e. don't use getURL(), but requestURL()). This helps keep in mind that you are actually making a request for the data rather than starting a blocking I/O operation. — Makyen (talk) 00:53, 23 June 2014 (UTC)[reply]

Add only local scripts?

Means this page that only local "English WP" scripts are allowed? Script functions are mostly language independent (or can be made multilingual extended), is it not useful to add some more existing Wiki scripts? Concretely I would suggest an auto. signing script and an auto. section link corrector for the edit summary. This could also be useful as moduls for other scripts!?User: Perhelion22:39, 22 June 2014 (UTC)[reply]

No, the scripts should work on this Wikipedia and they should be documented in English, but their source code doesn't have to be on the English Wikipedia. --V111P (talk) 19:03, 23 June 2014 (UTC)[reply]

Removing scripts

How do you change back to the default skin after you add a script? --UserJDalek 01:29, 8 August 2014 (UTC)[reply]

Go to your common.js page and remove the line that imports any scripts you no longer want to affect your skin. You may have also added some custom CSS to your common.css page which you may want to remove.
Gadgets are another possible way your skin may have been changed.
For a completely default (vanilla) experience, reset all your gadgets to the default, and remove all the text from both your common.js and common.css pages. That should do it. fredgandt 01:40, 8 August 2014 (UTC)[reply]
Thanks. --UserJDalek 02:04, 8 August 2014 (UTC)[reply]
You're welcome. I might suggest (even though I do say so myself) that in future you use something like my userResourceManager (see the entry overleaf) to make the task of organising your enhancements easier. fredgandt 05:24, 8 August 2014 (UTC)[reply]