MediaWiki talk:Common.js/Archive 18

This is an archive of past discussions about MediaWiki:Common.js. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 15

Archive 16

Archive 17

→

Always secure Wikipedia

proposal it so add

if(wgServer == 'https://secure.wikimedia.org')
importScript( 'MediaWiki:Common.js/secure.js')

This changes any http links to interwiki or diffs on a page to links for the secure server. The script is originally User:Anakin101/alwayssecurewikipedia.js. —TheDJ (talk • contribs) 20:45, 17 January 2010 (UTC)

Go for it, imo. If you're on the secure wiki, you should stay there until you leave it, not because you've clicked a random link. Ale_Jrb^talk 20:56, 17 January 2010 (UTC)

I found issues and suggestion with the script http:\/\/([^\/]+?)\. should be http:\/\/([^a-z0-9\-]+?)\., change (page ? page : 'wiki/') to (page || 'wiki/'), \/? is unnecessary since browser automatically add this in (I think), if (sub === undefined) continue; seems to be in the wrong place. There one question, should this be supporting old links? Wikibooks use to be en.wikibook.com (no s), wikipedia.com/wiki/ redirects to the English Wikipedia, meta-wiki was meta.wikipedia.org. — Dispenser 07:43, 18 January 2010 (UTC)

I wouldn't rely on all browsers always appending a slash to URLs like http://en.wikipedia.org. Better to be safe than sorry. However, I don't think the script as written will correctly handle such valid (or at least working) URLs as http://en.wikipedia.org?title=Foo. To fix it, you could replace "\/?(.*)$" with e.g. "(\/[^?#]*|)([#?].*|)$" in the regexps and append the value of m[4] to the fixed URL unconditionally. Also, there should be some way (e.g. setting window.disableSecureLinks=true in their monobook/vector.js) for users to turn this script off if they don't want it.

Anyway, the one problem we can't fix is that one could still end up back on the insecure site in two clicks via another Wikimedia project which doesn't run this script. That's why I wrote my version as a Greasemonkey user script. Of course, merely fixing things like diff links to en.wikipedia.org itself would probably be worth having this for. —Ilmari Karonen (talk) 16:36, 18 January 2010 (UTC)

Yes please add it, we need something like this. And here's some notes and links:

The discussion that led to this: Wikipedia:Village pump (technical)#Interwiki/interlanguage links not changing to secure. (Will later end up in /Archive 69 or 70.)
Wikipedia:Secure server and its talk page.
{{sec link auto}} – The current clumsy solution that we use in some places like the main page and some system messages. (I coded it, so I can call it clumsy. :))

When I created {{sec link auto}} I also tested User:Anakin101/alwayssecurewikipedia.js. I noticed that the script doesn't handle all the cases that {{sec link auto}} handles. I'll see if I can dig up my notes or do the tests again, but here's what I remember:

I think it doesn't handle all the projects listed at Wikipedia:InterWikimedia links, especially it didn't handle links to oldwikisource:. "Old Wikisource" still handles many of the Wikisource languages, so it isn't really "old".
And it doesn't handle cases like wikt:pt:São Paulo the way I think they should be handled. The script sends you to the English Wiktionary with a secure link, then it lets Wiktionary resolve the "pt:" part to take you to the Portuguese Wiktionary, which sends you to the normal servers. {{sec link auto}} instead resolves both the "wikt:" and "pt:" parts and gives you a secure link directly to the Portuguese Wiktionary. Although I cheat in {{sec link auto}}, I let the humans manually feed "lang=pt" so my template doesn't need to know the site matrix.

I'm sorry that I don't know enough javascript, so I can't help out with the code. But taking a look at {{sec link auto}}, or more specifically its sub-template {{sec link/secure url}} might give you some useful hints about what to resolve.

--David Göthberg (talk) 17:48, 18 January 2010 (UTC)

I have made a whole set of improvements. Many more types of links should now be recognized (at least all valid links in User:TheDJ/Sandbox2). Feedback welcome. —TheDJ (talk • contribs) 21:31, 18 January 2010 (UTC)

This seems reasonable to me to implement. I wish there were a way for this to be implemented into core MediaWiki, but that doesn't seem very possible due to parser cache issues (at least for the time being). --MZMcBride (talk) 00:30, 19 January 2010 (UTC)

Done code deployed. —TheDJ (talk • contribs) 20:44, 21 January 2010 (UTC)

JavaScript Loading

Up in the "WikiMiniAtlas" discussion it was mentioned that "(All our other special scripts are only loaded when needed.)." I'm getting ready to implement a lot of JavaScript on my Wiki and I was just curious if this was simply a reference to doing a quick getElementById existence check in addOnloadHook for each script, or if there is some other system in place that I don't know about. I'm basically just trying to make sure that if I have 100 scripts, I don't have to do 100 checks on every page load to see if any of them apply to that page.
--Cogniac (talk) 18:11, 29 January 2010 (UTC)

simply a reference to doing a quick getElementById existence check would be my answer. But there is a more advanced scriptloader system in the making by Michael Dale. Check the Wikitech mailing list archives for details.
--Dschwen 20:43, 29 January 2010 (UTC)

I tracked this down to here: http://www.mediawiki.org/wiki/JS2_Overview in case anyone else is interested. They seem to be developing this for the upcoming 1.16 release.
--Cogniac (talk) 19:16, 4 February 2010 (UTC)

Proposal to add "withJS" feature to Common.js

Wikimedia commons has the following function in their MediaWiki:Common.js. This is useful for doing feature preview links like timed text preview. Any objections to adding the following?

/** &withJS= URL parameter *******
 * Allow to try custom scripts from MediaWiki space 
 * without editing [[Special:Mypage/monobook.js]]
 */
var extraJS = getParamValue("withJS");
if ( extraJS && extraJS.match("^MediaWiki:[^&<>=%]*\.js$") ) {
  importScript(extraJS);
}

mdale (talk) 22:42, 4 February 2010 (UTC)

Its usage will probably be pretty limited, since for security reasons it seems to be limited to only load scripts from the MediaWiki space. I think I slightly agree with this addition, but I have doubts since its usage is so limited and the code will be loaded by all users and most of those that "need" this functionality can just as well edit their personal /monobook.js. Although I see that this function can be useful for demonstration purposes when testing new scripts.

Platonides isn't the maintainer here, unless you have asked him. Here's a cleaned up version of the code: ( above )

~~Could someone who understands the code in the .match() part check what that code means and that~~ it only allows loading scripts from MediaWiki space?

--David Göthberg (talk) 16:17, 5 February 2010 (UTC)

Is alert() preferred to a silent failure? --MZMcBride (talk) 16:35, 5 February 2010 (UTC)

I think the alert is useful, but not especially necessary. The alert is only shown when an invalid script name like "User:Example/myscript.js" is used. Unfortunately the alert does not show if the name is a correct but non-existing MediaWiki file name, then it silently fails which is slightly confusing.

But MZMcBride has a point. This will probably be a seldomly used function and all users always load those lines of code, so let's remove the alert to save some lines of code. I have updated my above code.

And I have read up on regular expressions and done some testing, the code in the .match() part does exactly what it should.

--David Göthberg (talk) 17:08, 5 February 2010 (UTC)

I agree with the removing the alert ( its of little value ). If people are happy with it in its present form I suggest a maintainer of Common.js plops it in there. ( I have updated the discussion to just focus on the recommended code addition) --mdale (talk) 22:28, 6 February 2010 (UTC)

I have no problem with this. I can deploy it tomorrow when I get back home, or someone else can do it in the meantime. —TheDJ (talk • contribs) 13:03, 7 February 2010 (UTC)

any updates on this? --mdale (talk) 17:39, 10 February 2010 (UTC)

I have now deployed this code. Thanks for the watchlist bump :D —TheDJ (talk • contribs) 18:15, 10 February 2010 (UTC)

OK, that was not fun. I'm so used to getParamValue being available (either trough commons or Navigation popups) it didn't occur to me it would be missing. For now I have deployed a getURLParamValue(), since i wasn't sure about potential conflicts with other tools that have their own getParamValue. I think those implementations are pretty consistent, but I'll want to run a check on that before using that name in Common.js. In the future we can use ParseURI, once the new JS2, jquery and mwEmbed tools are finally fully deployed, but that is not an option at this time of course. —TheDJ (talk • contribs) 18:49, 10 February 2010 (UTC)

Potential security issue

While, I'm sure that whoever runs http://toolserver.org/~para/geoip.fcgi is perfectly trustworthy it seems like a very weak link in the chain. Whereas scripts from Wikipedia have high cache values, publicly viewable edit histories, and notify many people when they are modified; making it likely that malicious changes can be reverted without too much damage; a modification to this script could pass unnoticed for quite some time. Are there any mechanisms in place to prevent this being horribly abused? Conrad.Irwin (on wikt) 22:55, 4 February 2010 (UTC)

As you say, the assumption that toolserver users are trustworthy. Javascript is by its very nature a potential security issue. Happy‑melon 23:45, 4 February 2010 (UTC)

It's not as if we allow just any external script to be included. So far those are only WikiMiniAtlas and the geolocating script. Those are maintained by trusted users on the toolserver. Users who have been around for a LONG time and who are not likely to go rogue. But it's like Happy-Melon says. —TheDJ (talk • contribs) 13:01, 7 February 2010 (UTC)

It took me some searching to find out what this is about, so in case anyone else is wondering: That toolserver script is called from the beginning of MediaWiki:Common.js/watchlist.js, the result of that then seems to be used in MediaWiki:Geonotice.js to display some watchlist notices only in some parts of the world. A little more searching turned up Wikipedia:Geonotice. (I have now added a code comment to watchlist.js and a page notice to Geonotice.js explaining what it is.)

--David Göthberg (talk) 01:00, 5 February 2010 (UTC)

hasClass

The hasClass function...variable...thing uses some fairly advanced JavaScript that I'm just trying to figure out. I'm assuming that the reason it is set up as a variable and not just straight "function hasClass(className)" is part of the caching optimization. But I'm not getting how it basically amounts to "var hasClass = ()();" with stuff happening inside the first pair of parentheses. I have no idea what the deal is with the two pairs of parentheses or why it relies on an anonymous function inside an anonymous function to do the work, and I'm looking for a basic explanation, if anyone would be so kind.
--Cogniac (talk) 21:19, 12 February 2010 (UTC)

The outer anonymous function, which is immediately called, creates a "global" variable reCache and returns another function which is assigned to the name hasClass. Due to JavaScript's scoping rules reCache is now only accessible from hasClass, but it's value still persists over multiple invocations of hasClass.
—Ruud 15:37, 13 February 2010 (UTC)

I understand that it's a prime example of JavaScript closures, but what I truly don't understand is the second set of parentheses at the end. I have no clue why those are necessary and/or don't break everything. I can't find any JavaScript construct that requires such a thing.
--Cogniac (talk) 20:49, 16 February 2010 (UTC)

It's a plain function call (of the outer anymous function). So hasClass is equal to the return value of the outer function (which happens to be the inner function). Without that call hasClass would be a reference to the outer function itself, which is not the intention.
—Ruud 21:19, 16 February 2010 (UTC)

Ahhhh. I get it now. It's like a standard function execution call, except the first set of parentheses stands in for the name of the function. var myVar = myFunction(); => var myVar = (function() { do stuff })();
--Cogniac (talk) 22:27, 18 February 2010 (UTC)

Actually, the first set of parenthesis just stand for the parameters (none in this case) and there is no function name before the parameters because it's anonymous.
—Ruud 12:53, 19 February 2010 (UTC)

Well, based on that explanation, none of it makes any sense anymore. It would essentially be var myVar = myFunction(parameters go here)(what the hell are these parentheses for?); => var myVar = (supposedly there are no parameters, despite the fact that there's stuff in here)(still no idea what these parentheses are for); I thought that the first set of parentheses just grouped the outer anonymous function and the second set of parentheses was a call to execute that function.
--Cogniac (talk) 19:01, 26 February 2010 (UTC)

Custom Edit Buttons

I'm trying to implement some custom edit buttons on my Wiki. They work, but only when placed in Common.js. I cannot get them to work when they are placed on Common.js/edit.js like they are here. I stuck an alert() call in my Common.js/edit.js to see if it was even being loaded, and it's not. Comparing my wikibits.js with Wikipedia's wikibits.js, and thus my importScript() with Wikipedia's, I notice the following differences:

Mine: var uri = wgScript + '?title=' + encodeURIComponent(page.replace(/ /g,'_')).replace('%2F','/').replace('%3A',':') + '&action=raw&ctype=text/javascript';
Wikipedia: var uri = wgScript + '?title=' + encodeURIComponent(page.replace(/ /g,'_')).replace(/%2F/ig,'/').replace(/%3A/ig,':') + '&action=raw&ctype=text/javascript';

Could these subtle differences somehow be causing my problem?
--Cogniac (talk) 20:43, 26 February 2010 (UTC)

I think it's more likely that you just don't have the edit.js loader code in your Common.js. Look under the comment "/* Import more specific scripts if necessary */" of wikipedia's Common.js. —TheDJ (talk • contribs) 21:20, 26 February 2010 (UTC)

I already had the importScript calls in Common.js, but it still wasn't working. Unfortunately, after wandering off for a few days and coming back, I have a bunch of messages from contributors about a certain "alert()" call I left in Common.js/edit.js when I thought it wasn't working at all. Apparently it just wasn't working in IE7 for some reason. So now there's double the number of buttons (because I had put it back in Common.js and left what I thought was a non-working copy in /edit.js) and a JavaScript alert() box popping up on every edit. Oops. So...perhaps there is an issue with IE7? I only have IE8 on this box, so I will check this out tomorrow on an IE7 box and report back.
--Cogniac (talk) 04:58, 1 March 2010 (UTC)

Well, now it magically works in IE7, too, so I don't really know what to say. Perhaps it was some bizarre caching issue? Although, I was definitely hitting Ctrl+F5 after every time I edited the JavaScript, so I don't even know.
--Cogniac (talk) 13:59, 1 March 2010 (UTC)

The problem is called a browser cache :D WP:BYPASS. —TheDJ (talk • contribs) 14:02, 1 March 2010 (UTC)

A thing which I repeatedly cleared by hitting Ctrl+F5; a circumstance I clearly stated in my last comment. I guess I needed to "Completely clear the cache" instead. Which makes no sense, because every time before now when I've made an edit to the JavaScript, Ctrl+F5 worked perfectly. For some reason, this did not work with the creation of Common.js/edit.js. I have no idea why.
--Cogniac (talk) 15:11, 1 March 2010 (UTC)

I'm not sure if it's because I'm editing the edit bar, or because I'm doing it on Common.js/edit.js, but it seems as though you have to Ctrl+F5 + Completely clear the cache + close and reopen the browser to get it to refresh properly. Wacky.
--Cogniac (talk) 16:02, 1 March 2010 (UTC)

Collapsible rows and columns

I asked on Help whether Collapsing could be extended to cover certain rows and columns only. Then I realized I hadn’t anything to do for the rest of the day and wrote the code myself. It may need further testing (and perhaps optimizing), but the basic cases are covered alright. Collapsing columns is especially helpful for en.m.wikipedia.org. Is there any chance getting this into common.js? — Christoph Päper 11:33, 6 March 2010 (UTC)

Rank in sortable tables

On a related note to collapsible rows and columns above, it would be nice to have a class ‘rank’ on one heading cell in a ‘sortable’ table that would result in the cells below it – if they contain only whitespace, digits and punctuation – bearing a dynamically generated rank number which is updated on sorting (and perhaps restored on sorting based on that very column, otherwise ‘rank’ should imply ‘unsortable’). The workaround with two tables side by side (inside a third one) is really ugly and fails with rows of different height. — Christoph Päper 15:21, 2 March 2010 (UTC)

Update getURLParamValue per Commons common.js User:Lupo cleanup

This is essentially the same function but includes the # hash to not include #anchors when you getURLParamValues

function getURLParamValue( paramName, url) 
{
 if (typeof (url) == 'undefined' || url === null) url = document.location.href;
 var cmdRe=RegExp( '[&?]' + paramName + '=([^&#]*)' ); // Stop at hash
 var m=cmdRe.exec(url);
 if (m && m.length > 1) return decodeURIComponent(m[1]);
 return null;
}

mdale (talk) 20:41, 3 March 2010 (UTC)

Ah, you see, this is exactly why I wanted to separate getParamValue of Lupin from this one in Common.js, now we have differing implementations... Thanks for the notification ! —TheDJ (talk • contribs) 21:25, 3 March 2010 (UTC)

Adding a script to collapse template transclusion list

Please see Wikipedia:Village_pump_(proposals)#Collapse_template_transclusion_list_in_Edit_view. I'm not quite sure if the script is ready - I had some problems last time I used it and had to uninstall. But is this reasonable in principle? Rd232 ^talk 20:00, 8 April 2010 (UTC)

It probably needs a bit more work, but I think that in general we should consider this. —TheDJ (talk • contribs) 20:33, 8 April 2010 (UTC)

Frame breaking

Moved from WP:AN Happy‑melon 11:24, 13 April 2010 (UTC)

I know we once blocked a system that iframed wikipedia for it's own purposes. There is now this "ad service" http://www.magic-banner-bot.com/ which inserts images into wikipedia. It cannot be disabled, uses an iframe and insert ads into the wikipedia content, without explaining why. I think such is grounds for blocking that via Javascript. What do others think ? —TheDJ (talk • contribs) 00:35, 11 April 2010 (UTC)

I thought we already did break iframes thanks to that advertising agency that was framing Wikipedia as a part of their homepage. If we don't, then yes, we absolutely should. Of course any webmaster who purchases a spamming tool that requires disclosing their webserver FTP password to work deserves to lose at life generally. — Gavia immer (talk) 01:01, 11 April 2010 (UTC)

??? Can you block people from reading wikipedia? 'Cause all that script is doing... Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 02:57, 11 April 2010 (UTC)

What you can do is use Javascript to detect if the page is being served in a third-party iframe, and if it is, redirect to the Wikipedia page itself with no iframe. This won't stop anyone from reading Wikipedia, but it will prevent them from being forced to view a defaced version of our content. N.B., I haven't been able to force the "magic banner" to actually advertise to me, despite turning off many layers of anti-advertising protection, so I can't tell exactly how it's supposed to work; if it's just accomplished by redirecting through the web domain above, it's even simpler to block, since we could just detect the referer. — Gavia immer (talk) 03:18, 11 April 2010 (UTC)

I don't know much about this, but it looks like it simply creates a new webpage like http://magic-banner-bot.com/468/ . I see it says (Redirected from Banner ads), so apparently the subpage "468" is linked to what is now a redirect. Maybe that gives a clue on how it works... Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 03:27, 11 April 2010 (UTC)

Yeah, but I'm not sure if that example is just a canned demonstration or if it's the way their spam works in general. — Gavia immer (talk) 03:44, 11 April 2010 (UTC)

Is this targeting specific pages, or all of Wikipedia in general? Noscript doesn't seem to be picking anything up, and I don't recall it doing so recently when viewing articles and/or other pages. The Thing // Talk // Contribs 04:25, 11 April 2010 (UTC)

Noscript detects it for me, but there seem to be two things going on. One is an IFRAME, which Noscript won't detect because it's just HTML, not a script of any kind; and an actual script which makes the banner that the IFRAME creates move around on the page and become generally more intrusive. I was actually looking at it with the script part turned off when I wrote what I wrote down below, confusing their banner with our own example banner, and didnt realize I was missing most of the effect until just now. —Soap— 17:48, 11 April 2010 (UTC)

An easy way to test would be to make an edit to the target article, then see if it shows up on the iframe. I'm going to do that now.— Dæ dαlus^Contribs 06:32, 11 April 2010 (UTC)

Sadly, the test was .. well, I don't know if I could call it a success, or a failure, but the end result was certainly bad. It isn't a canned picture. It's a live frame of wikipedia. I made a small insertion of a period on that article, and refreshed the ad-bot page. The change was immediately visible. We have to find a way to prevent this.— Dæ dαlus^Contribs 06:37, 11 April 2010 (UTC)

I think the way this software is supposed to work is that you, a blogger or other website designer, have to use "fake" links everywhere on your blog that go to sites that are technically still on your website, but look like they are where youre actually trying to go apart from the parasitic banner ads. I dont know from the context given on his site whether the ads will be served entirely through his own website and thus have the same referrer every time, or if youre supposed to store the ads somewhere else (in which case the referrer could be anything, or may not even exist). The code is ridiculously obfuscated, because according to the HTML source it's copyrighted and the designer of the software doesnt want people copying the source and using it without paying him. However, I think all we really need to know is whether it's an IFRAME, which it is. —Soap— 17:24, 11 April 2010 (UTC)

We appear to have disabled the javascript for breaking iframes about 3 years ago. Not sure why. Dragons flight (talk) 08:54, 11 April 2010 (UTC)

Well that's just evil. Both because it makes it look like various innocent websites are using banner ads and because he's charging $27 for a big-deal box of software that could fit on a floppy disk and is essentially just ~~a few lines of obfuscated Javascript~~ a script that generates HTML code, not really a "program" at all. I have seen other websites doing this sort of thing, though, and it's not always "bad". For about a year the homepage of Skittles (the candy) featured our article integrated into their website in a way that made it function as if it was part of Skittles' own site, but with a sort of navigation panel that made it clear that it wasn't, and that you could also see their pages on Facebook, YouTube, etc. At least to my eyes, there was no deception involved. There was also, amazingly, no spike in vandalism on our Skittles articles despite the fact that none of them were even semi-protected as far as I can tell. The Skittles homepage no longer features Wikipedia, but I think that it if we used to block out this sort of thing in the past, we must have stopped doing it sometime before Skittles started. If we start blocking it again, it'd be nice, if it is at all possible, to think about possible "legitimate" uses of the same kind of HTML trick. (While I wont say that the Skittles campaign necessarily did us any good, since we make no profits and kids eating candy arent likely to be big donors, it didnt really do us any harm either.) —Soap— 17:18, 11 April 2010 (UTC)

This discussion doesn't seem to concern admins. We aren't generally well versed in the technical aspects of the mediawiki software or these issues brought up here. These fixes would be nice, but if they are to be noticed by people who care, this discussion should be moved to WP:VPT and someone also should probably file a bugzilla request with the devs. --Jayron32 03:30, 12 April 2010 (UTC)

If we decided to break frames, we could do that locally with a few lines of javascript without needing to bother the devs. Dragons flight (talk) 05:42, 12 April 2010 (UTC)

The adding following code to Mediawiki:Common.js should do the trick:

if (document.referrer.indexOf("magic-banner-bot.com") != -1) {
	location.href = "http://en.wikipedia.org/w/index.php?title=User:Chris_G/Leech_detected&action=render";
}

The user will see this page with instructions on how to navigate to Wikipedia directly (someone might want to edit that page to be a bit nicer/user friendly first though). I've tested the script and it works in Firefox + Opera, but if a Windows user would please check it in IE (the older the version the better :) ) that would be good. Javascript isn't my forte so if someone could please double check that it won't break the site etc that would be great (maybe we should move it into it's own function? make it easier to add more sites as they pop up?) --Chris 12:03, 12 April 2010 (UTC)

I just tried it in IE8 and it works. I'd suggest changing the order of the two bullet points - "adverts" first, "server load" second. JohnCD (talk) 20:38, 12 April 2010 (UTC)

I would like to point out that it is probably easy to obfuscate the referrer if the agency would like to do so and that any usage of what he is selling seems to require to run from the domain the user wants to use it on. We can also block all iframes of course, but i'm not sure if that is desirable. Not sure if there are any tools that use wikipedia in a frame. I guess we could start logging that information in a way, in order to find out...

if( window != top ) {
  // this window is run inside a frame
}

The above code should detect when a page is run inside a frame. —TheDJ (talk • contribs) 01:13, 13 April 2010 (UTC)

Just as a general note, that page would need to be moved into the project-space if this code were added. --MZMcBride (talk) 18:30, 13 April 2010 (UTC)

I'd definitely support breaking frames on a general basis, assuming we don't use frames legitimately ourselves, which I don't think we do. Thoughts? Happy‑melon 12:42, 13 April 2010 (UTC)

I can't think of anywhere that we use frames, and if we do we should possibly stop, and I support breaking all of them. Ale_Jrb^talk 13:02, 13 April 2010 (UTC)

Breaking frames will break Toolserver tools and maybe that Google translation tool. There's a reason why the built-in frame breaking script (wgBreakFrames) been turned off. — Dispenser 15:51, 13 April 2010 (UTC)

What toolserver tools rely on frames? Ale_Jrb^talk 15:55, 13 April 2010 (UTC)

If there is no damage to important toolserver tools, I support breaking frames. Snowolf ^{How can I help?} 15:59, 13 April 2010 (UTC)

Which toolserver tools are important? Arguably none since they would've been intergrated into MediaWiki. — Dispenser 18:12, 13 April 2010 (UTC)

<AryehGregor>	Happy-melon, it used to be always true. Non-configurably.
<Happy-melon>	until Dec 2006
<AryehGregor>	A few years ago the config option was added, set to false by default in case anyone actually wanted it.
<AryehGregor>	It's never been true on Wikimedia since it's existed AFAIK.

The only reason why $wgBreakFrames is disabled is that no one ever asked for it to be turned on. There's a whitelist built into it, which has Google translate exempted by default, and other exemptions can be added. What toolserver tools would break? Happy‑melon 16:15, 13 April 2010 (UTC)

Before rev:18220 it was stuck to on, no way of turnning it off. And the exception code used in that revision doesn't work since it would be a security risk. On the Toolserver tools:~flacus/IWLC/ uses it as does a new tool of mine. It also breaks most translation services (Google), image searches result page (Bing, Google). It seems the only reason why we are considering breaking the website is because an obscure scumbag is selling banner software (There's a precident). Yet we have taken no steps to break about.com's banner ads and the encourghed hotlinking of our images. — Dispenser 18:12, 13 April 2010 (UTC)

Wikipedia is one of the easiest sites to proxy in the world. You shouldn't be using frames. Nevertheless, those that do can be whitelisted. Ale_Jrb^talk 16:14, 14 April 2010 (UTC)

Toolserver tools are not allow to "serve significant portions of wiki page text", this includes proxying. — Dispenser 17:16, 14 April 2010 (UTC)

Breaking a specific site that's causing a demonstrable issue is one thing. Breaking all use of frames just because is another. There may be a case here for intentionally breaking this magic-banner site, as there was for breaking modernista. But I don't see any compelling case for breaking frames in general, especially as there's a not-remote possibility of collateral damage and unintended consequences. --MZMcBride (talk) 18:30, 13 April 2010 (UTC)

The case against isn't very compelling either - it stands at 'but gooooogle!' - which can be whitelisted (and yes, so can bing). Apart from the search engines, I can't see any valid reason for putting Wikipedia in a frame. The case for means preventing this type of stupid scam in the future, because it just won't work - what if a not-very-savvy person who thought 'oh, that sounds good' actually pays for this crap? They might deserve it, depending on your opinion, but I don't think we should make it possible. Nevertheless, it doesn't bother me a huge amount either way, but we probably should put a stop to this particular one whatever we decide. Ale_Jrb^talk 16:14, 14 April 2010 (UTC)

Oh, and while we don't make any major changes to protect potential foolish people, it is just a config option. In addition, people seeing the frame (plus advertising) might be put off Wikipedia, and less likely to visit/edit/donate in the future. Just a thought. Improbable, maybe, but possible. Meh. Ale_Jrb^talk 16:16, 14 April 2010 (UTC)

How exactly do you purpose to whitelist. Is the method compatible with anonymizers? Will the method work if the frameset is on a HTTPS connection? What will the collateral damage be of application that we don't know about? Wikipedia:Wikipedia CD Selection? Whitelisting would be larger and hard to manage than a blacklist method. — Dispenser 17:16, 14 April 2010 (UTC)

Considering the enormous impact Google's results have on visits to this site, I think it's a pretty legitimate concern that we don't intentionally break them. Whitelisting isn't the answer. Blacklisting is. You can't know if you're just going to break Google and Bing, you could very well break every other search engine (and a whole host of other things that we may or may not become aware of).

There are about a million ways to take content from Wikipedia and put it on your own site. Nobody here should think (or does think) that breaking frames is going to stop any leech with any sort of dedication. As I said, if there's a specific problem with a specific site, by all means, let's work to address that. But large-scale "solutions" that will likely do more harm than good should be avoided. --MZMcBride (talk) 17:21, 14 April 2010 (UTC)