Separate into a multi-file project

[Nathan2055]

AfC/R-C, AfC, and cleanup should be moved into at least four separate files.

[wikipedia-mabdul]

blocks Issue #25

[theopolisme]

Can we just do the split anyhow? It'll make the project as a whole a helluva lot more manageable.

[Nathan2055]

@theopolisme - Mabdul will supposedly get to it on Thursday. Hang tight.

[theopolisme]

I actually have some time on my hands and am working on implementing this now...who knows if i'll really get anywhere though.

[Nathan2055]

@theopolisme - I'm in the IRC room if you wish to chat. :P

[theopolisme]

Thoughts on a multi-file script Alright, so I was looking into how other projects handle multi-file scripts. AutoEd, for example, uses a series of WP:AutoEd/blah.js subpages. Meanwhile, Twinkle has a script to compress all of its files into one single javascript file which is then uploaded to wiki. AFCH... ?

Here's one possibility which I think could be really useful... mw.loader.load. In other words, we upload the following file (or something like it) as the official AFCH gadget file:

mw.loader.load( '//raw.github.com/WPAFC/afch/master/src/afch.js' );

And that's it! After that, we never have to update the on-wiki version of the script. Instead, we just push builds to master when we're absolutely ready with them, and then they immediately (give or take a few minutes for browser-based caching) go live on wiki. I have no idea if this is frowned upon or not, but if not, i think it'd be really useful. Plus, if users wanted to help test the beta of AFCH, they could just import the "official AFCH beta gadget file"...which would consist of

mw.loader.load( '//raw.github.com/WPAFC/afch/develop/src/afch.js' );

Note the develop -- this means that this file would automatically reflect the latest commits pushed to the develop branch. This could also obviously be extended for any other branch as deemed fit for feature-by-feature testing and such (workflow example: create branch feature-lalala, then on test.wikipedia mw.loader.load that specific branch for testing).

Meanwhile, what goes on with the file afch.js? Well, it would just import other scripts -- right now, three of them:

• redirect.js - for afc/r
• article.js - for main article processing
• cleanup.js - for functions and such shared between both

They key to this is if we are "allowed" to mw.loader.load an external github script. I don't see why not, but it's worth looking into. Your thoughts on this proposal?

[legoktm]

I'm pretty sure this is disallowed due to an XSS vulnerability. If it isn't, it really should. Regardless, this is a bad idea because it lets anyone (aka non-admins) load stuff into the MediaWiki: namespace.

IMO a better way of doing this would be a simple pywikibot script which uploads the master --> gadget file, develop --> some beta script. It would be a pretty simple script.

We can split up modules by doing "MediaWiki:Gadgets-afch-redirect.js", and in the main gadget file that is loaded for all users, have a mw.loader.load('redirect.js'); (or whatever).

[theopolisme]

Psshh, don't go all pro-admin on me. ;)

I guess the bigger question is: what's the difference between a pywikibot script auto-uploading (okay, maybe with a manual "special admin button push" here and there) and just, well, auto-uploading? The idea that only administrators should be "trusted" to upload a gadget is ridiculous and you of all people know that...non admins create gadgets all the time, and while theoretically a sysop checks the JavaScript file first, I don't think someone was there babying Mabdul all the time as he worked on the script when it was just a file on-wiki.

Only a trusted group of editors -- those with commit access to the repo -- would be able to commit changes to master. I just don't see how that's any more vulnerable than our motley crew of admins. XSS vulnerabilities were the deal blocker I was talking about though, yeah. :/

Another option: going the twinkle route and just merging all of the files into one before uploading to the wiki. @Technical-13 said he spoke to azatoth about possibly helping with this...

[Nathan2055]

@theopolisme - If we were to do a merge, I was half working on a program you could use to do that. However, I would need to see the setup before going any farther with it.

[theopolisme]

I've read about various tools to do it, so I don't think that would be an issue (e.g., merge all javascript files in a directory into one). Azatoth's Twinkle "merger" Perl script is particularly cool, though, since it does a variety of other nifty things (for example, it grabs the commit information to be used in the edit summary).

[Nathan2055]

For some laughs as to how bad our current code is, see this SO chat log.

[theopolisme]

@Nathan2055: Haha, well, I think maybe that spurs at least partly from the fact that most of us suck at JavaScript. Myself, I've only been writing in it for 3 days or so :/

[Nathan2055]

@theopolisme - Hah, now you know why I held off from coding this for so long. Of all the languages I'm trying to "learn" (Python, Java, JS), Java is my favorite and JS is my least favorite.

[hasteur]

Confirmed as seperated on production @Technical-13: Please milestone and close