MediaWiki talk:Common.js/Archive 14
Latest comment: 15 years ago by Happy-melon in topic Main Page tab
 | This page is an archive of past discussions. 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. |
{{Link GA}}
I'd like to add the support for a Link GA template, similar to Link FA. All this has already been implemented and tested on the French wiki. (fr:Modèle:Lien BA) I currently have a bot overthere that is adding the template, and I wanted to do the same here. An example of a GA link in interwikis can be found overthere : fr:Pi.
In fact you would need to alter LinkFA() into
function LinkFAorGA()
{
if ( document.getElementById( "p-lang" ) ) {
var InterwikiLinks = document.getElementById( "p-lang" ).getElementsByTagName( "li" );
for ( var i = 0; i < InterwikiLinks.length; i++ ) {
if ( document.getElementById( InterwikiLinks[i].className + "-fa" ) ) {
InterwikiLinks[i].className += " FA"
InterwikiLinks[i].title = "This is a featured article in another language.";
}
else if ( document.getElementById( InterwikiLinks[i].className + "-ga" ) ) {
InterwikiLinks[i].className += " GA"
InterwikiLinks[i].title = "This is a good article in another language.";
}
}
}
}
addOnloadHook( LinkFAorGA );
and add into Monobook.css
li.GA {
list-style-image: url("http://upload.wikimedia.org/wikipedia/fr/8/86/Icone_BA.png");
}
(You might need to find another link in en: to that very same image, thought)
Thanks,
NicDumZ ~ 17:46, 20 December 2007 (UTC)
- The template in question was deleted after discussion at Wikipedia:Templates for deletion/Log/2007 October 4#Template:Link GA, and I don't think MediaWiki_talk:Common.js is a good place for a new discussion whether we need this template at all ∴ AlexSm 18:14, 20 December 2007 (UTC)
- Yeah, I know, it was deleted because the function was not supported in the monobook and because it was adding wieird categories on the articles itself: "Category:Good Article in French", etc... It was stupid. Now that this is working on fr:, I'm asking this again.
- And... Where should I ask if not here ? NicDumZ ~ 18:23, 20 December 2007 (UTC)
- This idea has been rejected a few times already. I think the discussions should be somewhere in the archives of this talk page. —Ruud 09:31, 21 December 2007 (UTC)
Edit made without consensus
{{editprotected}}
Please undo this recent edit. This edit does not have consensus. The TeX markup was not intended to be displayed in the tooltips of images, and if we are going to make a change to display the markup in image tooltips, the change should be made for all browsers, not just Internet Explorer. —Remember the dot (talk) 21:26, 29 December 2007 (UTC)
- I restored Internet Explorer's default behaviour in this respect. The tooltips were showing before PngFix, and now they do again, as expected. Just because they are not supposed to show, does not mean we should not respect IE's default behaviour. IE shows alt tags as tooltips, and is not a matter that shoud be "fixed", even if it "breaks" HTML standards. — Edokter • Talk • 21:41, 29 December 2007 (UTC)
- If IE has quirky behavior and we can't fix it, that's one thing. But where IE has quirky behavior, and it's fixable (and it was fixed), that's another. Your change actually decreases performance on Internet Explorer for no other reason than to re-introduce one of Internet Explorer's quirks. If you think that we should make the TeX markup show up in tooltips, then that change needs to be made for all browsers, not just Internet Explorer. —Remember the dot (talk) 21:49, 29 December 2007 (UTC)
- Proposal
- Change
if (img.useMap)toif (img.useMap || img.className == "tex") Take outDone.outerSpan.title = img.title...
img.title is always empty anyway. Also, the img.classname lookup seems to have no speed impact at all (probably because it is cached). — Edokter • Talk • 17:06, 30 December 2007 (UTC)
- If you want to make the TeX markup show in the tooltips, make it appear there for users of all browsers, not just Internet Explorer. —Remember the dot (talk) 02:25, 31 December 2007 (UTC)
- You have a point about
outerSpan.title = img.title...and I wouldn't mind if you removed this statement. —Remember the dot (talk) 02:26, 31 December 2007 (UTC)
- Make another script that copies TeX alt attributes into TeX title attributes, and do not restrict that script to any one browser. —Remember the dot (talk) 19:29, 31 December 2007 (UTC)
- Thank you for altering common.js appropriately. Here is code you can use for displaying the alt attribute in the tooltip:
/* Use alt attribute as the tooltip text, for example with TeX-generated images.
The MediaWiki software never adds title attributes to images anyway, so there is no danger of
overwriting an existing tooltip. */
function useAltForTooltips()
{
var documentImages = document.images
for (var i = 0; i < documentImages.length; i++)
{
var img = documentImages[i]
img.title = img.alt
}
}
if (!window.useAltForTooltipsDisabled)
{
window.addOnloadHook(useAltForTooltips)
}
- I don't have a strong opinion on whether we should use this code or not, so you can do what you like. Just try to keep the experience consistent across all browsers. —Remember the dot (talk) 22:06, 1 January 2008 (UTC)
- My intention was simply to restore IE's default behaviour, which I do not regard as a bug. If you want TeX-tooltips to display in other browsers as well, I suggest asking the community first (on WP:VPT) to see if non-IE users want the tooltips. In that case, a change should be made to TeX rather then add yet another script. I do intend to implement the other change listed above; that would at least speed up pages with TeX rendering. — Edokter • Talk • 22:46, 1 January 2008 (UTC)
- Sure, go ahead and make the other change. As long as the squid servers don't kill themselves again it should be fine. And feel free to ask the community about whether or not TeX markup should show up in tooltips. The major issue that I have is making it show up in the tooltips only for Internet Explorer, which results in inconsistency between browsers. —Remember the dot (talk) 23:19, 1 January 2008 (UTC)
- My point is just that it is an inconsistency that has always existed, and therefor not something that should be 'fixed'. People using IE expect certian behaviuour, users using ohter browser expect other behaviour. But I am dubbing over the squid issue... It does make me wonder why the standard monobook bullet doesn't kill the squids. — Edokter • Talk • 23:59, 1 January 2008 (UTC)
- IE has all sorts of inconsistencies that have always existed that cause all sorts of problems. Just because it's always been there doesn't mean that it's worth keeping there. The casual user knows nothing of all this, of course. They might actually wonder why Wikipedia shows tooltips on TeX images in IE7 but not in IE6, Firefox, Opera, Safari, etc. The answer is that there's not a good way to keep IE7 from displaying them, but there is in the other browsers. But, if we decide that having those tooltips there is a good thing, then we can make the change, and make it for all browsers. —Remember the dot (talk) 20:40, 2 January 2008 (UTC)
class,IPA
The {{IPA}} template which is based on class.IPA forces Firefox to display the IPA correctly, but adding to a table class="IPA" or class="IPA wikitable", which are based on the same class, does not. Instead, it displays with Arial Unicode, which is defective in its IPA range. How do we fix this? kwami (talk) 07:06, 3 January 2008 (UTC)
- The IPA class is never intended to be used directly; It should only be used by the several Unicode templates in order to display Unicode characters. — Edokter • Talk • 13:52, 3 January 2008 (UTC)
- I was under impression that IPA class is here only to fix IE shortcomings. I wish someone could write a detailed help page on this topic ∴ AlexSm 01:36, 7 January 2008 (UTC)
- There are two problems in FF: One, if you don't format all IPA with a specific font, you get the browser's default font for letters it covers, which often doesn't match and looks very unprofessional. Two, whenever the font includes replacement pairs, such as IPA tone letters or Indic akshara, a simple class="wikitable" table doesn't force them to combine. However, a class="wikitable" style="text-align:center" table displays them properly. I have no idea why the behavior is so odd, but suspect it's a bug in Wikipedia coding. kwami (talk) 02:02, 7 January 2008 (UTC)
Hide "user page" link for anonymous users
{{editprotected}}
I proposed this at Wikipedia:Village pump (proposals)#Hide "user page" link for anonymous users and there were no serious objections, so I'd like to have this code added to the site-wide JavaScript. If this causes a revolt then just remove it. If people like it then we can ask the developers to provide a way to do this more elegantly through CSS.
/** Automatically hide "user page" link for anonymous users that do not have user pages
* Created by Remember_the_dot
*/
function hideAnonUserPageLink()
{
var userPageLink = document.getElementById("ca-nstab-user")
if (!window.hideAnonUserPageLinkDisabled && userPageLink.className == "new")
{
document.getElementById("ca-nstab-user").style.visibility = "hidden"
}
}
if (wgPageName.search(/^(User_talk:(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))$/) == 0)
{
window.addOnloadHook(hideAnonUserPageLink)
}
I can also make a gadget to disable this behavior if there is demand for it. —Remember the dot (talk) 01:48, 4 January 2008 (UTC)
- No please. Good suggestion, however, some of them have user pages. Also, this adds a few lines of code with no real net gain. Regards, Mercury 02:25, 4 January 2008 (UTC)
- It would only hide links to nonexistant user pages. —Remember the dot (talk) 03:00, 4 January 2008 (UTC)
- Not done. This code makes a change that is arguably deceptive; there's a standard that tabs exist, regardless of page existence, and adding this code would change that expected behavior. I also fear that it would lead to a lot of confusion among the community. In addition, there are legitimate reasons for wanting to post to an anonymous user's user page, and this code change would make it more difficult. It also adds more code to an already lengthy file, with little net gain, and very likely net losses. However, you're free of course to add it to your personal subpage. Also, it could be made into a gadget for users to choose to enable or not, however, the default should be off. Cheers. --MZMcBride (talk) 02:30, 4 January 2008 (UTC)
- What are the legitimate reasons for putting anything on an IP user page? IP user pages are never linked to, in fact if you type "User:78.86.150.44" into the search box and hit "Go", it will take you to the contributions page. —Remember the dot (talk) 03:00, 4 January 2008 (UTC)
- For one, it is common to place (shared) IP information and blocked sock templates on an IP's userpage, which would be hard to do if there is no tab. — Edokter • Talk • 12:15, 4 January 2008 (UTC)
- That information is almost always given on the IP's talk page where people will see it. —Remember the dot (talk) 18:00, 4 January 2008 (UTC)
- For one, it is common to place (shared) IP information and blocked sock templates on an IP's userpage, which would be hard to do if there is no tab. — Edokter • Talk • 12:15, 4 January 2008 (UTC)
- What are the legitimate reasons for putting anything on an IP user page? IP user pages are never linked to, in fact if you type "User:78.86.150.44" into the search box and hit "Go", it will take you to the contributions page. —Remember the dot (talk) 03:00, 4 January 2008 (UTC)
You can estimate how often IP user pages are used with about 200 searches like Special:Prefixindex/User:78.. It seems like not very often, most are redirects to talk pages. I agree that this kind of script is a hack and instead we need either a MediaWiki fix or a policy which would say "only use user_talk: for IPs" ∴ AlexSm 16:40, 4 January 2008 (UTC)
- The idea was that if people liked the change, we could get the MediaWiki software to allow us to do this through CSS, which would be a much more elegant solution. I would much prefer CSS to JavaScript. —Remember the dot (talk) 18:00, 4 January 2008 (UTC)
If we could do this through CSS, and the CSS only changed the link's color from red to gray instead of removing it entirely, would you support the change? —Remember the dot (talk) 18:57, 4 January 2008 (UTC)
I've filed bug 12509 about doing this more elegantly with CSS. —Remember the dot (talk) 02:11, 5 January 2008 (UTC)
addDismissButton in Opera
I don't think addDismissButton() should continue after it finds out that the cookie is set to hide the message. There is no point to create [dismiss] link after that. Besides, for some reason this link is still visible in Opera (9.25) while the whole message is hidden (probably Opera's fault, but still...). In other words, we need a return immediately after watchlistMessage.style.display = "none" ∴ AlexSm 01:36, 7 January 2008 (UTC)
On subpages and tabs
Currently, when you're at a subpage, e.g., Template:Infobox Election/doc, the "discussion" tab links to the /doc talk page rather than the main talk page. I asked User:Splarka if there was a JavaScript way to fix this, and he wrote the code found below. It changes the tab to blue and links it to the main talk page if the tab is already non-existent. It's currently written to only work on /doc and /sandbox pages. Would there be any objections to implementing it site-wide? It would save a lot of unnecessary redirects. Improvements are, of course, welcome. Cheers. --MZMcBride (talk) 06:22, 7 January 2008 (UTC)
if(wgPageName.indexOf('/')!=-1 && (wgNamespaceNumber % 2)==0) addOnloadHook(redirSubpageTalk)
function redirSubpageTalk() {
var redir = [
/\/doc/i,
/\/sandbox/i
]
var talk = document.getElementById('ca-talk')
if(talk.className.indexOf('new')==-1) return;
var talka = talk.getElementsByTagName('a')[0];
for(var i=0;i<redir.length;i++) {
if(talka.href.search(redir[i])!=-1) {
talka.href = talka.href.replace(redir[i],'').replace(/action\=edit/i,'action=view');
talk.className = '';
}
}
}
- Wouldn't it be better to submit a bug report? (rather than link-munge) GracenotesT § 16:38, 7 January 2008 (UTC)
- On second note, I'm not sure this is a good idea, given that it violates the principle of least astonishment – users shouldn't have to check the status bar to see where a user interface link leads. it would make a good user script, however. GracenotesT § 18:21, 7 January 2008 (UTC)
- Yeah, I thought about that; however, the code stops if the /doc talk page actually exists, and I think it would be justifiable to do this if the result was easier accessibility. Currently, people are creating redirects, which simply seems kinda silly. --MZMcBride (talk) 21:31, 7 January 2008 (UTC)
- Why is it silly? Creating redirects is the way in which redirection is meant to be handled in MediaWiki wikis, not with kludgy javascript. Adding the above code would be very annoying; I'd have to disable javascript on Wikipedia and manually copy the rest of the scripts from various different places into a local file and use that, which would be a lot of fuss – Gurch 22:10, 7 January 2008 (UTC)
- It's silly because the pages are never going to be used for anything other than redirects to the target they should go to. And even if there is legitimate content, the script takes that into account and shuts down. Currently, most of the /doc talk subpages aren't redirects and the interface is just a little clunkier. Instead of being able to just click the tab and go to the page that they intended, users either have to create redirects or go back and then go to the talk page. Meh. I'll probably just enable it for myself; let them have red tabs. --MZMcBride (talk) 02:51, 8 January 2008 (UTC)
- That is proof only that the /doc subpage system was a stupid idea in the first place. There was nothing wrong with having the documentation on the discussion page – and avoiding all that silly meta-templating on the template page itself – but it just had to be changed, didn't it? – Gurch 18:34, 8 January 2008 (UTC)
- It's silly because the pages are never going to be used for anything other than redirects to the target they should go to. And even if there is legitimate content, the script takes that into account and shuts down. Currently, most of the /doc talk subpages aren't redirects and the interface is just a little clunkier. Instead of being able to just click the tab and go to the page that they intended, users either have to create redirects or go back and then go to the talk page. Meh. I'll probably just enable it for myself; let them have red tabs. --MZMcBride (talk) 02:51, 8 January 2008 (UTC)
- Why is it silly? Creating redirects is the way in which redirection is meant to be handled in MediaWiki wikis, not with kludgy javascript. Adding the above code would be very annoying; I'd have to disable javascript on Wikipedia and manually copy the rest of the scripts from various different places into a local file and use that, which would be a lot of fuss – Gurch 22:10, 7 January 2008 (UTC)
- Yeah, I thought about that; however, the code stops if the /doc talk page actually exists, and I think it would be justifiable to do this if the result was easier accessibility. Currently, people are creating redirects, which simply seems kinda silly. --MZMcBride (talk) 21:31, 7 January 2008 (UTC)
- On second note, I'm not sure this is a good idea, given that it violates the principle of least astonishment – users shouldn't have to check the status bar to see where a user interface link leads. it would make a good user script, however. GracenotesT § 18:21, 7 January 2008 (UTC)
- If people are competent enough to edit doc pages, why would they ever click the red link or think a redirect would be intuitive rather than misplaced? That's like making a redirect in articlespace to correspond with every talk archive. A trivial solution would be to add a link to the talk page to {{Documentation}}, if it's likely to be noticed. –Pomte 00:52, 9 January 2008 (UTC)
Problems with collapsible shells and older safari browsers
Hi - I've just realised that the reason so many navigation templates and WikiProject banners seem to have disappeared from Wikipedia in the last few months is that they haven't gone - I've just been unable to see them. With the combination of browser and platform I (and presumably other) WP editors use (Mac OS 10.2.8/ Safari 1.0.3) the shell renders all templates within it as thin, unexpandable lines. Is there any way to fix this so that I don't have to physically edit the article to see what templates are on it? There's some discussion of this already at Template_talk:WikiProjectBannerShell, which is where I first raised this issue, but the suggestion there is that this is the place to come. As an example of what I mean, here's how the top of Talk:Algeria looks to me:
User:Anomie suggests that: " If that is the case, I suspect the problem is on line 126 of the current version as I remember hearing that particularly old versions of Safari do not correctly support the table "rows" collection."
Any possible way of fixing the problem? Grutness...wha? 23:21, 18 January 2008 (UTC)
{{editprotected}}- We've done some experimentation, and it seems I was correct as overriding the function in Grutness's monobook.js with a fixed version has fixed the problem. Please change line 126 from
var Rows = Table.rows;tovar Rows = Table.getElementsByTagName( "tr" );. Thanks. Anomie⚔ 13:33, 19 January 2008 (UTC)
- The other function implementing this feature,
createCollapseButtons, usesgetElementsByTagNameto get the list of table rows, so if this would break anything then it is already broken. I suppose to be 100% safe you should use lower-case "tr" instead of "TR"; I have edited the request accordingly. Anomie⚔ 14:46, 19 January 2008 (UTC)
- The other function implementing this feature,
I have had to revert this change, unfortunately. It broke functionality in nested tables in that they automatically expanded (and still showing the [show] link) when the main table is expanded. This needs more testing. — Edokter • Talk • 15:12, 19 January 2008 (UTC)
- Ok, I have another attempt at User:Anomie/Sandbox.js. The code there can be copied into a monobook.js for testing, I'm not going to be so hasty this time ;) So far, it seems to work for Grutness in the old Safari version and me in Firefox 2.0.0.11. Anomie⚔ 03:54, 20 January 2008 (UTC)
smaxage=0
Due to persistent caching of user/site scripts and stylesheets, what do you think of temporarily modifying the following two lines from importScript and importStylesheet?
+ '&action=raw&ctype=text/javascript';
+ '&action=raw&ctype=text/css";'
to include &smaxage=0 so as to reduce the server-side cache to as low a number as possible? Eg:
+ '&action=raw&smaxage=0&ctype=text/javascript';
+ '&action=raw&smaxage=0&ctype=text/css";'
Notes:
- In practice, this still seems to take up to 5 minutes.
- This is not a drastic change or server bombing, client side caching is still up to 31 days by default.
- If the devs don't like it, they can fix the bugs hampering meaningful script development! Grr, arg.
Please reach consensus before implementing (if at all?). An implement/revert/implement/revert battle over this, coupled with the caching bugs, would be worse than no action taken at all. --Splarka (rant) 05:27, 21 January 2008 (UTC)
- r27456 --Splarka (rant) 06:15, 22 January 2008 (UTC)
- What exactly did that change do? Will I have caching problems now when I try to rewrite and debug a script? —Remember the dot (talk) 18:14, 22 January 2008 (UTC)
- I didn't analyze that PHP change, but I do have caching problems when developing scripts for WikiMedia projects. Despite purging, clearing my local cache, and forcing reloads, it takes currently between 5 to 10 minutes until changes are seen. This is behavior that I didn't see formerly. If I understand Splarka's suggestion right, setting maxage to zero should resolve this by forcing the server to serve always the latest version of a script, not some cached one. Lupo 07:23, 23 January 2008 (UTC)
- What exactly did that change do? Will I have caching problems now when I try to rewrite and debug a script? —Remember the dot (talk) 18:14, 22 January 2008 (UTC)
- Followup: A dev has disabled the cache server hack that was ignoring a "Pragma: No-cache" from the browsers. This apparently makes it possible to [reload] a page and re-request new raw CSS/JS. With some minimum testing it seems to work again (for now). --Splarka (rant) 08:02, 1 February 2008 (UTC)
import*() better?
A secondary request is to have these functions able to import scripts/styles from elsewhere, for example:
- importScript('User:Foo.js') would grab the page as normal
- importScript('http://en.wikipedia.org/w/index.php?title=User:Zocky/SearchBox.js&action=raw&ctype=text/javascript&dontcountme=s') would see 'http:' and load the path as absolute.
- importScript('file:///c:/foo.bar.js','mediawiki') would see the local path and load it as absolute.
This would only take a quick if() block around the URL generator, eg for importScript something like... (the css version would be similar):
if(page.indexOf('http://') == 0 || page.indexOf('https://') == 0 || page.indexOf('file://') == 0) {
var url = page;
} else {
var url = wgScript + '?title=' + encodeURIComponent( page.replace( / /g, '_' ) )
+ '&action=raw&ctype=text/javascript';
}
Note: You may be tempted to ask for an tertiary interwiki feature, eg to [[m:User:Foo/bar.js]] but this would be... very hard to implement, as well as support, while the above modification would be relatively easy if done properly.
Thoughts? --Splarka (rant) 05:27, 21 January 2008 (UTC)
- One potential issue is that people might grab script files off other sites, when really everything should be hosted on Wikimedia servers. I think the API might be able to enable interwiki imports. A quick Ajax request to the API to grab the URL (no more than a kilobyte or two round trip), and off you go. But overall, it might be more trouble than it's worth. —Remember the dot (talk) 06:17, 21 January 2008 (UTC)
- Well, the problem of people trying to load JS from external sites can be solved easily enough by just allowing the "absolute path" import only if the server is *.wikipedia.org or *.wikimedia.org. Could even add the "&action=raw&ctype=text/javascript&dontcountme=s" part automatically. Lupo 07:33, 21 January 2008 (UTC)
I have made versions of import* that do this for myself so that I can test them: See my diff. I agree that there is a risk for increased usage of external scripts, but I'm not sure wether that is a real problem. It is already happening with some of our most profound scripts (Lupin's tools, mini atlas, and CH2 all use commons and local servers for scripts). I don't really see the added danger, but; we could check for something like if(page.indexOf( wgServer ) == 0 || page.indexOf( 'http://meta.wikimedia.org') ==0 || page.indexOf('http://commons.wikimedia.org') ==0 || page.indexOf('file://') == 0) which is probably quicker than hitting the API with an ajaxreq. and still suit most of our problems. Lastly, perhaps its about time we re-discuss including scripts from other users. The Gadgets are a good first step, and I wouldn't want to loose the current ability to load scripts from other users because its just too damn easy, but I was thinking that perhaps having a bot look at our .js pages for any URL changes might be a good idea to prevent issues. --TheDJ (talk • contribs) 16:20, 21 February 2008 (UTC)
Problem with importStylesheet on Internet Explorer
{{edit protected}}
I mainly use Firefox, but I write some javascript that I want IE users to be able to use too. With Internet Explorer 7, I can't do appendChild on a STYLE element, nor can I set the innerHTML (both gives me errors). Thus, the importStylesheet() function here does not work with IE7 (though it does work fine with Firefox, Opera, and Safari). Instead, IE can use the document.createStyleSheet() function. -Pan Sola (talk) 09:31, 27 January 2008 (UTC)
- This is a known issue yes. Adding
if (document.createStyleSheet) document.createStyleSheet( theurl ); else { our current code }should take care of it according to various websources.... --TheDJ (talk • contribs) 14:17, 27 January 2008 (UTC)- There are also other ways to fix this for IE, like using cssText property, or creating <link> element (instead of <style> with @import), but I agree that
document.createStyleSheetseems to be the best option ∴ AlexSm 14:27, 27 January 2008 (UTC)
- There are also other ways to fix this for IE, like using cssText property, or creating <link> element (instead of <style> with @import), but I agree that
Is there a specific edit that needs to be done? If not, please do not use the editprotected template as a general call for help. — Edokter • Talk • 15:15, 27 January 2008 (UTC)
- Sorry I wasn't clear. I would like to advocate for the importStylesheet() function defined here to incorporate the IE check and calls document.createStyleSheet() from within, so that other javascripts needing to import stylesheets does not have to deal with the browser detection. Alternately, if for some reason importStyle() should not be modified to work on Internet Explorer, then I would advocate a note in the comments for the function here warning people that it will not work on Internet Explorer. -Pan Sola (talk) 21:23, 27 January 2008 (UTC)
Here is the diff that would do this. --TheDJ (talk • contribs) 22:10, 27 January 2008 (UTC)
- Hmm, the
{{edit protected}}says it's for requesting immediate edit. Should I use it if I believe the edit should be made but without any urgency? -Pan Sola (talk) 20:37, 31 January 2008 (UTC)
See also #import.2A.28.29_better.3F, but this createStylesheet() implementation is currently active in my private implementation of the import*() functions. --TheDJ (talk • contribs) 16:22, 21 February 2008 (UTC)
Big performance improvement
{{editprotected}}
It's been suggested before that we factor out all the IE fixes, but nobody actually took the time to do it. Were this done, we would see two improvements:
- Those not using IE (who consequently do not need the IE scripts) would not have to waste time downloading them
- Only one check would need to be made to see whether the browser is IE or not
So, I went through and came up with the code necessary to do it. The scripts will all continue to work as before, but users will see an improvement in page load time. Since this doesn't involve an appreciable change in behavior, we should be able to just go ahead and do it.
Please create MediaWiki:Common IE.js with:
/* Import fixes specific to Internet Explorer 6.0 *****************************/
if (navigator.appVersion.substr(22, 1) == "6")
{
importScript("MediaWiki:Common IE6.js")
}
/** Internet Explorer bug fix **************************************************
*
* Description: Fixes IE horizontal scrollbar bug
* Maintainers: [[User:Tom-]]?
*/
if (document.compatMode == "CSS1Compat")
{
var oldWidth;
var docEl = document.documentElement;
function fixIEScroll()
{
if (!oldWidth || docEl.clientWidth > oldWidth)
doFixIEScroll();
else
setTimeout(doFixIEScroll, 1);
oldWidth = docEl.clientWidth;
}
function doFixIEScroll() {
docEl.style.overflowX = (docEl.scrollWidth - docEl.clientWidth < 4) ? "hidden" : "";
}
document.attachEvent("onreadystatechange", fixIEScroll);
attachEvent("onresize", fixIEScroll);
}
/** IE 6 Z-index bug workaround for anonnotice **************************
*
* Description: This implements a work around for the Z-index bug found in Internet Explorer.
* It correctly places the anon notice on the page, even under IE6.
* See this Google search for more information about the bug:
* http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=q74&q=z-index+ie6+bug&btnG=Search
* Created by: [[User:Gmaxwell]]
*/
addOnloadHook((function (){
if (wgUserName == null) {
var messageEdu=new Array();
messageEdu[0]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Researching_with_Wikipedia" title="Wikipedia:Researching with Wikipedia">Learn more about using Wikipedia for research</a>';
messageEdu[1]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Ten_things_you_may_not_know_about_Wikipedia" title="Wikipedia:Ten things you may not know about Wikipedia">Ten things you may not know about Wikipedia</a>';
messageEdu[2]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Ten_things_you_may_not_know_about_images_on_Wikipedia" title="Wikipedia:Ten things you may not know about images on Wikipedia">Ten things you may not know about images on Wikipedia</a>';
messageEdu[3]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Citing_Wikipedia" title="Wikipedia:Citing Wikipedia">Learn more about citing Wikipedia</a>';
messageEdu[4]='Have questions? <a href="http://en.wikipedia.org/wiki/Wikipedia:Questions" title="Wikipedia:Questions">Find out how to ask questions and get answers.</a>';
messageEdu[5]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Basic_navigation" title="Wikipedia:Basic navigation">Find out more about navigating Wikipedia and finding information</a>';
messageEdu[6]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Contributing_to_Wikipedia" title="Wikipedia:Contributing to Wikipedia">Interested in contributing to Wikipedia?</a>';
var whichMessageEdu = Math.floor(Math.random()*(messageEdu.length));
/** document.getElementById("contentSub").innerHTML +='<div style="position:absolute; z-index:100; right:100px; top:0px;" class="metadata" id="anontip"><div style="text-align:right; font-size:87%">• <i>' + messageEdu[whichMessageEdu] + '</i> •</div></div>';
*/
}
}));
/**
* Remove need for CSS hacks regarding MSIE and IPA.
*/
if (document.createStyleSheet) {
document.createStyleSheet().addRule('.IPA', 'font-family: "Doulos SIL", "Charis SIL", Gentium, "DejaVu Sans", Code2000, "TITUS Cyberbit Basic", "Arial Unicode MS", "Lucida Sans Unicode", "Chrysanthi Unicode";');
Please create MediaWiki:Common IE6.js with:
/**
* Correctly handle PNG transparency in Internet Explorer 6.
* http://homepage.ntlworld.com/bobosola. Updated 18-Jan-2006.
*
* Adapted for Wikipedia by Remember_the_dot and Edokter.
*
* http://homepage.ntlworld.com/bobosola/pnginfo.htm states "This page contains more information for
* the curious or those who wish to amend the script for special needs", which I take as permission to
* modify or adapt this script freely. I release my changes into the public domain.
*/
function PngFix()
{
try
{
if (!document.body.filters)
{
window.PngFixDisabled = true
}
}
catch (e)
{
window.PngFixDisabled = true
}
if (!window.PngFixDisabled)
{
var documentImages = document.images
var documentCreateElement = document.createElement
var funcEncodeURI = encodeURI
for (var i = 0; i < documentImages.length;)
{
var img = documentImages[i]
var imgSrc = img.src
if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png" && !img.onclick)
{
if (img.useMap)
{
img.style.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + encodeURI(imgSrc) + "')"
img.src = "http://upload.wikimedia.org/wikipedia/commons/c/ce/Transparent.gif"
i++
}
else
{
var outerSpan = documentCreateElement("span")
var innerSpan = documentCreateElement("span")
var outerSpanStyle = outerSpan.style
var innerSpanStyle = innerSpan.style
var imgCurrentStyle = img.currentStyle
outerSpan.id = img.id
outerSpan.title = img.title
outerSpan.className = img.className
outerSpanStyle.backgroundImage = imgCurrentStyle.backgroundImage
outerSpanStyle.borderWidth = imgCurrentStyle.borderWidth
outerSpanStyle.borderStyle = imgCurrentStyle.borderStyle
outerSpanStyle.borderColor = imgCurrentStyle.borderColor
outerSpanStyle.display = "inline-block"
outerSpanStyle.fontSize = "0"
outerSpanStyle.verticalAlign = "middle"
if (img.parentElement.href) outerSpanStyle.cursor = "hand"
innerSpanStyle.width = "1px"
innerSpanStyle.height = "1px"
innerSpanStyle.display = "inline-block"
innerSpanStyle.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + funcEncodeURI(imgSrc) + "')"
outerSpan.appendChild(innerSpan)
img.parentNode.replaceChild(outerSpan, img)
}
}
else
{
i++
}
}
}
}
window.attachEvent("onload", PngFix)
And finally, change MediaWiki:Common.js to:
/** Import module *************************************************************
*
* Description: Includes a raw wiki page as javascript or CSS,
* used for including user made modules.
* Maintainers: [[User:AzaToth]]
*/
importedScripts = {}; // object keeping track of included scripts, so a script ain't included twice
function importScript( page ) {
if( importedScripts[page] ) {
return;
}
importedScripts[page] = true;
var url = wgScriptPath
+ '/index.php?title='
+ encodeURIComponent( page.replace( / /g, '_' ) )
+ '&action=raw&ctype=text/javascript';
var scriptElem = document.createElement( 'script' );
scriptElem.setAttribute( 'src' , url );
scriptElem.setAttribute( 'type' , 'text/javascript' );
document.getElementsByTagName( 'head' )[0].appendChild( scriptElem );
}
function importStylesheet( page ) {
var sheet = '@import "'
+ wgScriptPath
+ '/index.php?title='
+ encodeURIComponent( page.replace( / /g, '_' ) )
+ '&action=raw&ctype=text/css";'
var styleElem = document.createElement( 'style' );
styleElem.setAttribute( 'type' , 'text/css' );
styleElem.appendChild( document.createTextNode( sheet ) );
document.getElementsByTagName( 'head' )[0].appendChild( styleElem );
}
/** Internet Explorer fixes ***************************************************/
if (navigator.appName == "Microsoft Internet Explorer")
{
importScript("MediaWiki:Common IE.js")
}
/** Test if an element has a certain class *************************************
*
* Description: Uses regular expressions and caching for better performance.
* Maintainers: [[User:Mike Dillon]], [[User:R. Koot]], [[User:SG]]
*/
var hasClass = (function () {
var reCache = {};
return function (element, className) {
return (reCache[className] ? reCache[className] : (reCache[className] = new RegExp("(?:\\s|^)" + className + "(?:\\s|$)"))).test(element.className);
};
})();
/** Interwiki links to featured articles ***************************************
*
* Description: Highlights interwiki links to featured articles (or
* equivalents) by changing the bullet before the interwiki link
* into a star.
* Maintainers: [[User:R. Koot]]
*/
function LinkFA()
{
if ( document.getElementById( "p-lang" ) ) {
var InterwikiLinks = document.getElementById( "p-lang" ).getElementsByTagName( "li" );
for ( var i = 0; i < InterwikiLinks.length; i++ ) {
if ( document.getElementById( InterwikiLinks[i].className + "-fa" ) ) {
InterwikiLinks[i].className += " FA"
InterwikiLinks[i].title = "This is a featured article in another language.";
}
}
}
}
addOnloadHook( LinkFA );
/** Collapsible tables *********************************************************
*
* Description: Allows tables to be collapsed, showing only the header. See
* [[Wikipedia:NavFrame collapsed]].
* Maintainers: [[User:R. Koot]]
*/
var autoCollapse = 2;
var collapseCaption = "hide";
var expandCaption = "show";
function collapseTable( tableIndex )
{
var Button = document.getElementById( "collapseButton" + tableIndex );
var Table = document.getElementById( "collapsibleTable" + tableIndex );
if ( !Table || !Button ) {
return false;
}
var Rows = Table.rows;
if ( Button.firstChild.data == collapseCaption ) {
for ( var i = 1; i < Rows.length; i++ ) {
Rows[i].style.display = "none";
}
Button.firstChild.data = expandCaption;
} else {
for ( var i = 1; i < Rows.length; i++ ) {
Rows[i].style.display = Rows[0].style.display;
}
Button.firstChild.data = collapseCaption;
}
}
function createCollapseButtons()
{
var tableIndex = 0;
var NavigationBoxes = new Object();
var Tables = document.getElementsByTagName( "table" );
for ( var i = 0; i < Tables.length; i++ ) {
if ( hasClass( Tables[i], "collapsible" ) ) {
/* only add button and increment count if there is a header row to work with */
var HeaderRow = Tables[i].getElementsByTagName( "tr" )[0];
if (!HeaderRow) continue;
var Header = HeaderRow.getElementsByTagName( "th" )[0];
if (!Header) continue;
NavigationBoxes[ tableIndex ] = Tables[i];
Tables[i].setAttribute( "id", "collapsibleTable" + tableIndex );
var Button = document.createElement( "span" );
var ButtonLink = document.createElement( "a" );
var ButtonText = document.createTextNode( collapseCaption );
Button.style.styleFloat = "right";
Button.style.cssFloat = "right";
Button.style.fontWeight = "normal";
Button.style.textAlign = "right";
Button.style.width = "6em";
ButtonLink.style.color = Header.style.color;
ButtonLink.setAttribute( "id", "collapseButton" + tableIndex );
ButtonLink.setAttribute( "href", "javascript:collapseTable(" + tableIndex + ");" );
ButtonLink.appendChild( ButtonText );
Button.appendChild( document.createTextNode( "[" ) );
Button.appendChild( ButtonLink );
Button.appendChild( document.createTextNode( "]" ) );
Header.insertBefore( Button, Header.childNodes[0] );
tableIndex++;
}
}
for ( var i = 0; i < tableIndex; i++ ) {
if ( hasClass( NavigationBoxes[i], "collapsed" ) || ( tableIndex >= autoCollapse && hasClass( NavigationBoxes[i], "autocollapse" ) ) ) {
collapseTable( i );
}
}
}
addOnloadHook( createCollapseButtons );
/** Dynamic Navigation Bars (experimental) *************************************
*
* Description: See [[Wikipedia:NavFrame]].
* Maintainers: UNMAINTAINED
*/
// set up the words in your language
var NavigationBarHide = '[' + collapseCaption + ']';
var NavigationBarShow = '[' + expandCaption + ']';
// shows and hides content and picture (if available) of navigation bars
// Parameters:
// indexNavigationBar: the index of navigation bar to be toggled
function toggleNavigationBar(indexNavigationBar)
{
var NavToggle = document.getElementById("NavToggle" + indexNavigationBar);
var NavFrame = document.getElementById("NavFrame" + indexNavigationBar);
if (!NavFrame || !NavToggle) {
return false;
}
// if shown now
if (NavToggle.firstChild.data == NavigationBarHide) {
for (
var NavChild = NavFrame.firstChild;
NavChild != null;
NavChild = NavChild.nextSibling
) {
if ( hasClass( NavChild, 'NavPic' ) ) {
NavChild.style.display = 'none';
}
if ( hasClass( NavChild, 'NavContent') ) {
NavChild.style.display = 'none';
}
}
NavToggle.firstChild.data = NavigationBarShow;
// if hidden now
} else if (NavToggle.firstChild.data == NavigationBarShow) {
for (
var NavChild = NavFrame.firstChild;
NavChild != null;
NavChild = NavChild.nextSibling
) {
if (hasClass(NavChild, 'NavPic')) {
NavChild.style.display = 'block';
}
if (hasClass(NavChild, 'NavContent')) {
NavChild.style.display = 'block';
}
}
NavToggle.firstChild.data = NavigationBarHide;
}
}
// adds show/hide-button to navigation bars
function createNavigationBarToggleButton()
{
var indexNavigationBar = 0;
// iterate over all < div >-elements
var divs = document.getElementsByTagName("div");
for(
var i=0;
NavFrame = divs[i];
i++
) {
// if found a navigation bar
if (hasClass(NavFrame, "NavFrame")) {
indexNavigationBar++;
var NavToggle = document.createElement("a");
NavToggle.className = 'NavToggle';
NavToggle.setAttribute('id', 'NavToggle' + indexNavigationBar);
NavToggle.setAttribute('href', 'javascript:toggleNavigationBar(' + indexNavigationBar + ');');
var NavToggleText = document.createTextNode(NavigationBarHide);
for (
var NavChild = NavFrame.firstChild;
NavChild != null;
NavChild = NavChild.nextSibling
) {
if ( hasClass( NavChild, 'NavPic' ) || hasClass( NavChild, 'NavContent' ) ) {
if (NavChild.style.display == 'none') {
NavToggleText = document.createTextNode(NavigationBarShow);
break;
}
}
}
NavToggle.appendChild(NavToggleText);
// Find the NavHead and attach the toggle link (Must be this complicated because Moz's firstChild handling is borked)
for(
var j=0;
j < NavFrame.childNodes.length;
j++
) {
if (hasClass(NavFrame.childNodes[j], "NavHead")) {
NavFrame.childNodes[j].appendChild(NavToggle);
}
}
NavFrame.setAttribute('id', 'NavFrame' + indexNavigationBar);
}
}
}
addOnloadHook( createNavigationBarToggleButton );
/** Main Page layout fixes *********************************************************
*
* Description: Various layout fixes for the main page, including an
* additional link to the complete list of languages available
* and the renaming of the 'Article' to to 'Main Page'.
* Maintainers: [[User:AzaToth]], [[User:R. Koot]], [[User:Alex Smotrov]]
*/
function mainPageRenameNamespaceTab() {
try {
var Node = document.getElementById( 'ca-nstab-main' ).firstChild;
if ( Node.textContent ) { // Per DOM Level 3
Node.textContent = 'Main Page';
} else if ( Node.innerText ) { // IE doesn't handle .textContent
Node.innerText = 'Main Page';
} else { // Fallback
Node.replaceChild( Node.firstChild, document.createTextNode( 'Main Page' ) );
}
} catch(e) {
// bailing out!
}
}
if ( wgTitle == 'Main Page' && ( wgNamespaceNumber == 0 || wgNamespaceNumber == 1 ) ) {
addOnloadHook( mainPageRenameNamespaceTab );
}
if ( wgTitle == 'Main Page' && wgNamespaceNumber == 0 ) {
addOnloadHook( mainPageAppendCompleteListLink );
}
function mainPageAppendCompleteListLink() {
addPortletLink('p-lang', 'http://meta.wikimedia.org/wiki/List_of_Wikipedias',
'Complete list', 'interwiki-completelist', 'Complete list of Wikipedias')
}
/** Extra toolbar options ******************************************************
*
* Description: UNDOCUMENTED
* Maintainers: [[User:MarkS]]?, [[User:Voice of All]], [[User:R. Koot]]
*/
//This is a modified copy of a script by User:MarkS for extra features added by User:Voice of All.
// This is based on the original code on Wikipedia:Tools/Editing tools
// To disable this script, add <code>mwCustomEditButtons = [];<code> to [[Special:Mypage/monobook.js]]
if (mwCustomEditButtons) {
mwCustomEditButtons[mwCustomEditButtons.length] = {
"imageFile": "http://upload.wikimedia.org/wikipedia/en/c/c8/Button_redirect.png",
"speedTip": "Redirect",
"tagOpen": "#REDIRECT [[",
"tagClose": "]]",
"sampleText": "Insert text"};
mwCustomEditButtons[mwCustomEditButtons.length] = {
"imageFile": "http://upload.wikimedia.org/wikipedia/en/c/c9/Button_strike.png",
"speedTip": "Strike",
"tagOpen": "<s>",
"tagClose": "</s>",
"sampleText": "Strike-through text"};
mwCustomEditButtons[mwCustomEditButtons.length] = {
"imageFile": "http://upload.wikimedia.org/wikipedia/en/1/13/Button_enter.png",
"speedTip": "Line break",
"tagOpen": "<br />",
"tagClose": "",
"sampleText": ""};
mwCustomEditButtons[mwCustomEditButtons.length] = {
"imageFile": "http://upload.wikimedia.org/wikipedia/en/8/80/Button_upper_letter.png",
"speedTip": "Superscript",
"tagOpen": "<sup>",
"tagClose": "</sup>",
"sampleText": "Superscript text"};
mwCustomEditButtons[mwCustomEditButtons.length] = {
"imageFile": "http://upload.wikimedia.org/wikipedia/en/7/70/Button_lower_letter.png",
"speedTip": "Subscript",
"tagOpen": "<sub>",
"tagClose": "</sub>",
"sampleText": "Subscript text"};
mwCustomEditButtons[mwCustomEditButtons.length] = {
"imageFile": "http://upload.wikimedia.org/wikipedia/en/5/58/Button_small.png",
"speedTip": "Small",
"tagOpen": "<small>",
"tagClose": "</small>",
"sampleText": "Small Text"};
mwCustomEditButtons[mwCustomEditButtons.length] = {
"imageFile": "http://upload.wikimedia.org/wikipedia/en/3/34/Button_hide_comment.png",
"speedTip": "Insert hidden Comment",
"tagOpen": "<!-- ",
"tagClose": " -->",
"sampleText": "Comment"};
mwCustomEditButtons[mwCustomEditButtons.length] = {
"imageFile": "http://upload.wikimedia.org/wikipedia/en/1/12/Button_gallery.png",
"speedTip": "Insert a picture gallery",
"tagOpen": "\n<gallery>\n",
"tagClose": "\n</gallery>",
"sampleText": "Image:Example.jpg|Caption1\nImage:Example.jpg|Caption2"};
mwCustomEditButtons[mwCustomEditButtons.length] = {
"imageFile": "http://upload.wikimedia.org/wikipedia/en/f/fd/Button_blockquote.png",
"speedTip": "Insert block of quoted text",
"tagOpen": "<blockquote>\n",
"tagClose": "\n</blockquote>",
"sampleText": "Block quote"};
mwCustomEditButtons[mwCustomEditButtons.length] = {
"imageFile": "http://upload.wikimedia.org/wikipedia/en/6/60/Button_insert_table.png",
"speedTip": "Insert a table",
"tagOpen": '{| class="wikitable"\n|-\n',
"tagClose": "\n|}",
"sampleText": "! header 1\n! header 2\n! header 3\n|-\n| row 1, cell 1\n| row 1, cell 2\n| row 1, cell 3\n|-\n| row 2, cell 1\n| row 2, cell 2\n| row 2, cell 3"};
mwCustomEditButtons[mwCustomEditButtons.length] = {
"imageFile": "http://upload.wikimedia.org/wikipedia/commons/7/79/Button_reflink.png",
"speedTip": "Insert a reference",
"tagOpen": "<ref>",
"tagClose": "</ref>",
"sampleText": "Insert footnote text here"};
}
/*</nowiki>*/
/** pageview counter ***********************************************************
*
* Description: Please talk to de:User:LeonWeber before changing anything or
* if there are any issues with that.
* Maintainers: [[:de:User:LeonWeber]]?
*/
// this should be adjusted to a good value.
// BE CAREFUL, you will break zedler if it's too low!
// And then DaB. will kill Leon :-(
var disable_counter = 0;
var counter_factor = 6000;
function pgcounter_setup()
{
if(disable_counter == 0)
{
var url = window.location.href;
if(Math.floor(Math.random()*counter_factor)==42) // the probability thing
{
if(wgIsArticle==true || wgArticleId==0) // do not count history pages etc.
{
var pgcountNs = wgCanonicalNamespace;
if(wgCanonicalNamespace=="")
{
pgcountNs = "0";
}
var cnt_url = "http://pgcount.wikimedia.de/index.png?ns=" + pgcountNs + "&title=" + encodeURI(wgTitle) + "&factor=" + counter_factor +"&wiki=enwiki";
var img = new Image();
img.src = cnt_url;
}
}
}
}
// Do not use aOnloadFunctions[aOnloadFunctions.length] = pgcounter_setup;, some browsers don't like that.
pgcounter_setup();
/** "Technical restrictions" title fix *****************************************
*
* Description:
* Maintainers: User:Interiot, User:Mets501, User:Freakofnurture
*/
//
// For pages that have something like Template:Lowercase, replace the title, but only if it is cut-and-pasteable as a valid wikilink.
// (for instance iPod's title is updated. But [[C#]] is not an equivalent
// wikilink, so [[C Sharp]] doesn't have its main title changed)
// Likewise for users who have selected the U.K. date format ("1 March") the
// titles of day-of-the-year articles will appear in that style. Users with any
// other date setting are not affected.
//
// The function looks for a banner like this:
// <div id="RealTitleBanner"> ... <span id="RealTitle">title</span> ... </div>
// An element with id=DisableRealTitle disables the function.
//
var disableRealTitle = 0; // users can set disableRealTitle = 1 locally to disable.
if (wgIsArticle) { // don't display the RealTitle when editing, since it is apparently inconsistent (doesn't show when editing sections, doesn't show when not previewing)
addOnloadHook(function() {
try {
var realTitleBanner = document.getElementById("RealTitleBanner");
if (realTitleBanner && !document.getElementById("DisableRealTitle") && !disableRealTitle ) {
var realTitle = document.getElementById("RealTitle");
if (realTitle) {
var realTitleHTML = realTitle.innerHTML;
realTitleText = pickUpText(realTitle);
var isPasteable = 0;
//var containsHTML = /</.test(realTitleHTML); // contains ANY HTML
var containsTooMuchHTML = /</.test( realTitleHTML.replace(/<\/?(sub|sup|small|big)>/gi, "") ); // contains HTML that will be ignored when cut-n-pasted as a wikilink
// calculate whether the title is pasteable
var verifyTitle = realTitleText.replace(/^ +/, ""); // trim left spaces
verifyTitle = verifyTitle.charAt(0).toUpperCase() + verifyTitle.substring(1, verifyTitle.length); // uppercase first character
// if the namespace prefix is there, remove it on our verification copy. If it isn't there, add it to the original realValue copy.
if (wgNamespaceNumber != 0) {
if (wgCanonicalNamespace == verifyTitle.substr(0, wgCanonicalNamespace.length).replace(/ /g, "_") && verifyTitle.charAt(wgCanonicalNamespace.length) == ":") {
verifyTitle = verifyTitle.substr(wgCanonicalNamespace.length + 1);
} else {
realTitleText = wgCanonicalNamespace.replace(/_/g, " ") + ":" + realTitleText;
realTitleHTML = wgCanonicalNamespace.replace(/_/g, " ") + ":" + realTitleHTML;
}
}
// verify whether wgTitle matches
verifyTitle = verifyTitle.replace(/[\s_]+/g, " "); // underscores and multiple spaces to single spaces
verifyTitle = verifyTitle.replace(/^\s+/, "").replace(/\s+$/, ""); // trim left and right spaces
verifyTitle = verifyTitle.charAt(0).toUpperCase() + verifyTitle.substring(1, verifyTitle.length); // uppercase first character
if ( (verifyTitle == wgTitle) || (verifyTitle == wgTitle.replace(/^(.+)?(January|February|March|April|May|June|July|August|September|October|November|December)\s+([12]?[0-9]|3[0123])([^\d].*)?$/g, "$1$3 $2$4") )) isPasteable = 1;
var h1 = document.getElementsByTagName("h1")[0];
if (h1 && isPasteable) {
h1.innerHTML = containsTooMuchHTML ? realTitleText : realTitleHTML;
if (!containsTooMuchHTML)
realTitleBanner.style.display = "none";
}
document.title = realTitleText + " - Wikipedia, the free encyclopedia";
}
}
} catch (e) {
/* Something went wrong. */
}
});
}
// similar to innerHTML, but only returns the text portions of the insides, excludes HTML
function pickUpText(aParentElement) {
var str = "";
function pickUpTextInternal(aElement) {
var child = aElement.firstChild;
while (child) {
if (child.nodeType == 1) // ELEMENT_NODE
pickUpTextInternal(child);
else if (child.nodeType == 3) // TEXT_NODE
str += child.nodeValue;
child = child.nextSibling;
}
}
pickUpTextInternal(aParentElement);
return str;
}
//fix edit summary prompt for undo
//this code fixes the fact that the undo function combined with the "no edit summary prompter" causes problems if leaving the
//edit summary unchanged
//this was added by [[User:Deskana]], code by [[User:Tra]]
addOnloadHook(function () {
if (document.location.search.indexOf("undo=") != -1
&& document.getElementsByName('wpAutoSummary')[0]) {
document.getElementsByName('wpAutoSummary')[0].value='1';
}
})
/** Add dismiss button to watchlist-message *************************************
*
* Description: Hide the watchlist message for one week.
* Maintainers: [[User:Ruud Koot|Ruud Koot]]
*/
function addDismissButton() {
var watchlistMessage = document.getElementById("watchlist-message");
if ( watchlistMessage == null ) return;
var watchlistCookieID = watchlistMessage.className.replace(/cookie\-ID\_/ig,'');
if ( document.cookie.indexOf( "hidewatchlistmessage-" + watchlistCookieID + "=yes" ) != -1 ) {
watchlistMessage.style.display = "none";
}
var Button = document.createElement( "span" );
var ButtonLink = document.createElement( "a" );
var ButtonText = document.createTextNode( "dismiss" );
ButtonLink.setAttribute( "id", "dismissButton" );
ButtonLink.setAttribute( "href", "javascript:dismissWatchlistMessage();" );
ButtonLink.setAttribute( "title", "Hide this message for one week" );
ButtonLink.appendChild( ButtonText );
Button.appendChild( document.createTextNode( "[" ) );
Button.appendChild( ButtonLink );
Button.appendChild( document.createTextNode( "]" ) );
watchlistMessage.appendChild( Button );
}
function dismissWatchlistMessage() {
var e = new Date();
e.setTime( e.getTime() + (7*24*60*60*1000) );
var watchlistMessage = document.getElementById("watchlist-message");
var watchlistCookieID = watchlistMessage.className.replace(/cookie\-ID\_/ig,'');
document.cookie = "hidewatchlistmessage-" + watchlistCookieID + "=yes; expires=" + e.toGMTString() + "; path=/";
watchlistMessage.style.display = "none";
}
addOnloadHook( addDismissButton );
/** Main Page deletion image *******************************************************
*
* Description: If the Main Page does not exist (i.e., it's been deleted) then insert an image
* instead of showing the "page does not exist" text.
* Created by: [[User:Mark]], with invaluable help from [[User:Pathoschild]]
*/
function MainPageDeletedImage() {
try {
//If the article does not exist and it is the Main Page, proceed
if ( document.getElementById( "noarticletext" ) && wgTitle == 'Main Page' ) {
// Insert a protected commons image at the end of the document explaining it.
var contentbox = document.getElementById('content');
var newimg = document.createElement('img');
newimg.setAttribute('src','http://upload.wikimedia.org/wikipedia/commons/9/99/WikipediaTechnical.png');
contentbox.appendChild(newimg);
// Hide the article-does-not-exist text
var NoArticleMessage = document.getElementById('noarticletext');
NoArticleMessage.style.display="none";
// Hide the edit button
var EditThisPageButton = document.getElementById('ca-edit');
EditThisPageButton.style.display="none";
}
} catch(e) {
// In case it does not work, do nothing
return;
}
}
addOnloadHook( MainPageDeletedImage );
/** Change Special:Search to use a drop-down menu *******************************************************
*
* Description: Change Special:Search to use a drop-down menu, with the default being
* the internal MediaWiki engine
* Created and maintained by: [[User:Gracenotes]]
*/
if (wgPageName == "Special:Search") {
var searchEngines = [];
addOnloadHook(SpecialSearchEnhanced);
}
function SpecialSearchEnhanced() {
var createOption = function(site, action, mainQ, addQ, addV) {
var opt = document.createElement('option');
opt.appendChild(document.createTextNode(site));
searchEngines[searchEngines.length] = [action, mainQ, addQ, addV];
return opt;
}
var searchForm = document.forms['search'];
var selectBox = document.createElement('select');
selectBox.id = 'searchEngine';
searchForm.onsubmit = function() {
var optSelected = searchEngines[document.getElementById('searchEngine').selectedIndex];
searchForm.action = optSelected[0];
searchForm.lsearchbox.name = optSelected[1];
searchForm.title.value = optSelected[3];
searchForm.title.name = optSelected[2];
}
selectBox.appendChild(createOption('MediaWiki search', wgScriptPath + '/index.php', 'search', 'title', 'Special:Search'));
selectBox.appendChild(createOption('Google', 'http://www.google.com/search', 'q', 'sitesearch', 'en.wikipedia.org'));
selectBox.appendChild(createOption('Yahoo', 'http://search.yahoo.com/search', 'p', 'vs', 'en.wikipedia.org'));
selectBox.appendChild(createOption('Windows Live', 'http://search.live.com/results.aspx', 'q', 'q1', 'site:http://en.wikipedia.org'));
selectBox.appendChild(createOption('Wikiwix', 'http://www.wikiwix.com/', 'action', 'lang', 'en'));
selectBox.appendChild(createOption('Exalead', 'http://www.exalead.com/wikipedia/results', 'q', 'language', 'en'));
searchForm.lsearchbox.style.marginLeft = '0px';
var lStat = document.getElementById('loadStatus');
lStat.parentNode.insertBefore(selectBox, lStat);
}
/** Geo-targeted watchlist notice *******************************************************
*
* Description: Allows for geographic targeting of watchlist notices. See [[Wikipedia:Geonotice]] for more information.
* Created by: [[User:Gmaxwell]]
*/
if (wgPageName == "Special:Watchlist")
addOnloadHook((function (){document.write('<script type="text/javascript" src="http://tools.wikimedia.de/~gmaxwell/cgi-bin/geonotice.py"><\/script>')}));
/** Sysop Javascript *******************************************************
*
* Description: Allows for sysop-specific Javascript at [[MediaWiki:Sysop.js]].
* Created by: [[User:^demon]]
*/
function sysopFunctions() {
if ( wgUserGroups && !window.disableSysopJS ) {
for ( var g = 0; g < wgUserGroups.length; ++g ) {
if ( wgUserGroups[g] == "sysop" ) {
importScript( "MediaWiki:Sysop.js" );
break;
}
}
}
}
addOnloadHook( sysopFunctions );
/** WikiMiniAtlas *******************************************************
*
* Description: WikiMiniAtlas is a popup click and drag world map.
* This script causes all of our coordinate links to display the WikiMiniAtlas popup button.
* The script itself is located on meta because it is used by many projects.
* See [[Meta:WikiMiniAtlas]] for more information.
* Created by: [[User:Dschwen]]
*/
document.write('<script type="text/javascript" src="'
+ 'http://meta.wikimedia.org/w/index.php?title=MediaWiki:Wikiminiatlas.js'
+ '&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400"></script>');
—Remember the dot (talk) 21:54, 2 February 2008 (UTC)
Section break
I don't know... it seems that relatively little IE-specific code (less then 7KB) is moved out of common.js, so I'm not convinced of the performance benefits. The file is cached locally and on the squids anyway. Plus it would further fragment all the javascript in MediaWiki. But we could consolidate all version checks into one function at the bottom, and load the rest from there. — Edokter • Talk • 22:37, 2 February 2008 (UTC)
I doubt it's a performance gain for IE users. IE supports special conditions, such as <!--[if IE X]>IE-version-X-specific tags<![endif]-->, that are much more efficient. In both IE and Firefox, JavaScript files must be downloaded before page content after it displays, and chaining JS file downloads like that could produce a delay of a couple of seconds before page display with fast connections. Submitting bug reports for files like this is a good idea. GracenotesT § 23:14, 2 February 2008 (UTC)
- OK. I've disabled the {{editprotected}} request for now. Perhaps we could create a variable such as "isIE" instead to at least centralize the checks for Internet Explorer. —Remember the dot (talk) 23:20, 2 February 2008 (UTC)
- bugzilla:12766. --Splarka (rant) 08:10, 3 February 2008 (UTC)
Optimization: call functions only when needed
Preamble: last night I was debugging my new little script, which sorts watchlist entries by namespace and then alphabetically. For some reason it did not work in IE6, I spent countless minutes rechecking my code, and finally created a loop to display all DOM nodes. Of course, what I found was a SPAN where I expected to see an IMG.
The question is: why do I need PngFix script in my watchlist, where all used images are 256-color and thus do not need transparency fix? Why do I also need Wikiminiatlas, collapsible Tables and Divs on all special pages?
Proposal: move all addOnloadHook() calls to the bottom of the file, after checking some basic conditions, mostly for the current namespace. This should make Wikipedia pages a bit faster to respond after loading. This should also allow to remove several existing checks that are right now inside the functions.
For an example please look at the bottom of ru:MediaWiki:Common.js where I implemented this approach a long time ago ∴ AlexSm 17:06, 6 February 2008 (UTC)
- The proposal has some merit, except a PNG image can appear in any namespace. Begs the question though, why are you quering images on your watchlist, which doesn't have images? Or does your script display images inline? In any case, setting PngFixDisabled to True in your script should also fix the problem. — Edokter • Talk • 17:25, 6 February 2008 (UTC)
- 256-color PNGs should be used for system messages, even if only for IE6 users with JavaScript disabled. As for my script, with "Enhanced recent changes" the watchlist structure is a bit complex, and to find the end of the row you have to traverse the DOM nodes until you find IMG or SPAN#RCMxx; of course, now that I finally figured the problem, I could get around it, but I would rather tell IE6 users that my script doesn't work because of PngFix, which is doing something to watchlist it's not supposed to. Back to proposal: the main purpose is not to "fix my script" but rather to avoid running any scripts when they are not needed ∴ AlexSm 18:22, 6 February 2008 (UTC)
- There's a better solution here. You could simply add "PngFixDisabled = true" to your script and include a modified PngFix function that meets your script's particular needs. Failing that, many of the people still using IE6 can upgrade to IE7 or use a different browser such as Firefox or Opera. —Remember the dot (talk) 18:39, 6 February 2008 (UTC)
- 1) This was already suggested above; 2) The proposal is not about fixing my script; 3) I don't see why do you insist on running PngFix in watchlist where it only slows things down ∴ AlexSm 19:45, 6 February 2008 (UTC)
- I like your proposal for functions that only run in a specific namespace. However, it's possible to put transparent images on the watchlist via JavaScript where PngFix should get to them. As it stands, the PngFix script is very fast and flexible, being able to handle even unusual cases like this, and I don't want to diminish either of those qualities. —Remember the dot (talk) 19:53, 6 February 2008 (UTC)
- Would it be possible to add a user-defined variable (similar to the one you can use to deactivate the whole script) that would allow individual users to decide whether the script should run on pages such as watchlists? This makes more sense to me than either method of running the script on every page or preventing it from ever running on certain pages, and this way, because most visitors will never see a watchlist with a PNG image in it, those who consider it important enough can activate it via their Common.js. —Dinoguy1000 21:46, 7 February 2008 (UTC)
- I realize that the purpose of your complaint above isn't just to "fix my script", but I'd just like to note that, for parsing the extended-mode watchlist (or recentchanges, for that matter), it's probably better to look for the BR elements at the end of each line rather than the IMG elements at the beginning. See User:Ilmari Karonen/watchfilter.js for an (unfortunately rather sparsely commented) example of a script that works on both watchlist variants; look in particular for the case marked with "// enhanced mode". —Ilmari Karonen (talk) 21:23, 8 February 2008 (UTC)
- Not always: I answered in details on User talk:Ilmari Karonen/watchfilter.js. / AlexSm 16:39, 11 February 2008 (UTC)
- I realize that the purpose of your complaint above isn't just to "fix my script", but I'd just like to note that, for parsing the extended-mode watchlist (or recentchanges, for that matter), it's probably better to look for the BR elements at the end of each line rather than the IMG elements at the beginning. See User:Ilmari Karonen/watchfilter.js for an (unfortunately rather sparsely commented) example of a script that works on both watchlist variants; look in particular for the case marked with "// enhanced mode". —Ilmari Karonen (talk) 21:23, 8 February 2008 (UTC)
Can't get it to work
I've copied the appropriate code to my wiki, but I cannot get collapsible tables to work. Ideas? Note that my system doesn't have a common.js file, so I just added it and put it under mediawiki\skins\common.
Any assistance is appreciated. Thanks Timneu22 (talk) 13:31, 11 February 2008 (UTC)
- Did you also copy the relevant collapsible class from common.css? — Edokter • Talk • 15:22, 11 February 2008 (UTC)
- "Collapsible" class does not have any extra CSS. Even if it did (like NavFrame), CSS has nothing to do with the collapsing functionality. Timneu22: please use Opera or Firefox, open error console and check for JavaScript errors. It;s possible e.g. you did not copy required
hasClass()function / AlexSm 16:39, 11 February 2008 (UTC)
- "Collapsible" class does not have any extra CSS. Even if it did (like NavFrame), CSS has nothing to do with the collapsing functionality. Timneu22: please use Opera or Firefox, open error console and check for JavaScript errors. It;s possible e.g. you did not copy required
- Sorry (and don't hurt me!), but I only have IE. How can I tell if there are errors? Also, I'm not sure how it will "just work" by creating this file:
- Common.js didn't exist
- I added it to mediawiki\skins\common
- How does any skin know to use it? I cannot imagine it will "just work" without me doing something else.
- Thanks again Timneu22 (talk) 00:16, 12 February 2008 (UTC)
- Sorry (and don't hurt me!), but I only have IE. How can I tell if there are errors? Also, I'm not sure how it will "just work" by creating this file:
Sorry for some stupidity, I see that I needed to add this to my own MediaWiki:Common.js page. Done.
However, I'm having a problem now, where [hide] shows twice:
---------------------------------------------- - Some title [hide] [hide] - ----------------------------------------------
Ideas? Thanks AGAIN! Timneu22 (talk) 11:59, 12 February 2008 (UTC)
- Finally, looks like I got it right. I commented out the following (because it is unneeded on my wiki):
function sysopFunctions() {
if ( wgUserGroups && !window.disableSysopJS ) {
for ( var g = 0; g < wgUserGroups.length; ++g ) {
if ( wgUserGroups[g] == "sysop" ) {
importScript( "MediaWiki:Sysop.js" );
break;
}
}
}
}
addOnloadHook( sysopFunctions );
That function which you commented out isn't actually part of the collapsible tables code (it actually enables a seperate JS file for sysops only), and can be safely deleted. —Dinoguy1000 18:14, 13 February 2008 (UTC)
- Yeah, I knew it had nothing to do with tables. I just commented (as opposed to deleting) for the possibility that I will need it in the future. Thank you for your comment! I'm glad everything is working for my wiki! :) Timneu22 (talk) 23:57, 13 February 2008 (UTC)
I Can't get it to work, either
I am also having trouble getting common.js to give me a collapsible table.
I have copied the entire source of the common.js page into my own Mediawiki:Common.js area. I am using MediaWiki 1.6.7, could that have something to do with it? I am uncertain what to do, and would appreciate any assistance. Damian - 61.8.101.1 (talk) —Preceding comment was added at 07:09, 20 February 2008 (UTC)
- Hello, the reason MediaWiki:Common.js isn't working on your wiki is because it wasn't enabled in MediaWiki until version 1.10. Unless you care to upgrade your wiki software, you'll have to make do with MediaWiki:Monobook.js. —Dinoguy1000 18:41, 20 February 2008 (UTC)
Can I get it to work with MediaWiki: 1.6.10 ?? Andrew —Preceding unsigned comment added by 124.186.76.93 (talk) 16:34, 5 May 2008 (UTC)
line-spacing with sub & sup
As discussed on MediaWiki talk:Common.css. It is proposed (final idea by AlexSm) to add the following:
/* Function to add simple style blocks. */
/* Use sparsely and larger blocks of CSS should be loaded by importStylesheet() */
function appendCSS(text){
var s = document.createElement('style');
s.setAttribute('type', 'text/css');
if (s.styleSheet)
s.styleSheet.cssText = text; //IE
else
s.appendChild(document.createTextNode(text));
document.getElementsByTagName('head')[0].appendChild(s);
return s;
}
/* This avoids breaking the linespacing when using sup and sub elements */
/* No solution for IE currently exists */
/* See also http://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.css&oldid=193038464#line-spacing_with_sub_.26_sup */
if( is_opera || is_safari || is_gecko) {
appendCSS('sup, sub {line-height:0;}');
}
We all wish there was a better way, but alternatives do not seem to exist. --TheDJ (talk • contribs) 14:52, 21 February 2008 (UTC)
It has not been shown that the line-height:0 causes a problem on IE - the problem that was observed still occurs if it is absent. —Random832 04:10, 24 February 2008 (UTC)
- Seems to be resolved, per MediaWiki talk:Common.css#Space between paragraphs please (References), and specifically this change to MediaWiki:Common.css. Thanks. -- Quiddity (talk) 18:44, 8 April 2008 (UTC)
Other Wikis - unwanted messages
Hello, I have the "meetup message" appearing on my own wiki:
The next New York City meetup is Sunday March 16th. You're invited! [hide]
What part of Common.js do I need to comment so these always go away? Thank you! Timneu22 (talk) 21:48, 24 February 2008 (UTC)
"Show/Hide" link div width on collapsible tables
Something that recently struck me is how excessive the width on the div element for the show/hide link in collapsible tables is. From what I've seen, 6 em is actually far more than is needed in most cases, and I would like to see it cut. However, at this point there are a lot of templates that use it under the assumption that it will be 6em wide, so an outright change would be unacceptable. Therefore, I was wondering if it would be possible to make the exact width configurable, with the default remaining 6em. However, I'm not sure how it might be implemented (except maybe by adding another name to the "class" attribute), and I'd like to hear others' opinions on it as well. —Dinoguy1000 18:13, 26 March 2008 (UTC)
- Yes, it could easily be reduced to 4em, but it would have to be done in conjunction with changing it in {{navbox}} (and possibly other templates). — Edokter • Talk • 19:41, 26 March 2008 (UTC)
- That's great to know, but not exactly what I was asking. I was wanting to know if code could be added which would allow the exact width to be specified by someone using the collapsible class, while leaving a default width of 6em. For instance, if I were to want to cut its width to 3.5em, or increase it to 16em in one particular usage for whatever reason (not that I know what that reason would be, I'm just throwing a couple of examples out there). —Dinoguy1000 18:01, 27 March 2008 (UTC)
Geonotice temporarily removed
I've temporarily removed the geonotice feature because Wikipedia:Wikipedia Takes Manhattan has been postponed a week to April 4, and the geonotice was advertising the wrong date. Wikipedia Takes Manhattan was the only geonotice active at this time, so there's no collateral damage. I'm waiting for Gmaxwell (or whoever else is technically able) to update the geonotice date ASAP, so that we can restore it. Thanks.--Pharos (talk) 05:07, 27 March 2008 (UTC)
- OK, I've restored it.--Pharos (talk) 05:56, 27 March 2008 (UTC)
- I would like to point out that due to browser caching, there is little chance that this actually had any effect for anyone. As a matter of fact for the people who DID actually download this "disabled" version, we might now end up with people who won't have this active for quite a while (not sure what the caching on this page is, but for Common.css its 30days ) --TheDJ (talk • contribs) 11:38, 27 March 2008 (UTC)
Modernista referrer
I put in this notice as prepared by Random832, and it seems to do the job nicely, except for one thing. It's placed above the title so as to appear distinct from the article, which I think is a good thing, but it also means that part of the notice is obscured by the Modernista navigation frame. Could somebody fix the notice so it's just a bit lower down? --Michael Snow (talk) 23:50, 19 April 2008 (UTC)
- The code was removed since then. —AlexSm 18:42, 6 May 2008 (UTC)
- Right, it was removed with a comment, "as it's not legal for them to do what they do, report them instead", which makes no sense to me. What's that supposed to mean, report them? To whom? I've restored the notice. --Michael Snow (talk) 16:56, 16 May 2008 (UTC)
I don't agree with this addition. It goes against the spirit of Wikipedia:No disclaimers in articles. I also don't see why this site is getting special treatment. Who cares if they display Wikipedia in a frame? Really, why does it matter? --- RockMFR 19:17, 16 May 2008 (UTC)
- I also don't like this addition. Let's just worry about making the encyclopedia and not bloat the code worrying about how other people re-use it. —Remember the dot (talk) 00:08, 17 May 2008 (UTC)
- OK, I've removed it again. —Remember the dot (talk) 17:36, 17 May 2008 (UTC)
- It was approached in this fashion specifically because a developer said any administrator could take care of the issue, which is what we did. It has the same effect as referrer filtering. Is it somehow more bloating to do it here than in Apache?
- Regarding "Let's just worry about making the encyclopedia" - this doesn't affect the encyclopedia in any way. It's not a disclaimer about an article, on Wikipedia the article displays normally, it's specifically about the Modernista site and only displays there. Regarding "Who cares if they display Wikipedia in a frame?" - the use potentially confuses visitors to their site about the source of the text, obscures the Wikipedia trademark and logo, and objections have been made to the company and on Talk:Modernista!. For who cares, I could give you Florence Devouard, Jimmy Wales, and Mike Godwin, to start with. --Michael Snow (talk) 04:08, 19 May 2008 (UTC)
- Since nobody has presented an alternative, and the objections are unpersuasive ("I don't like it", as opposed to actually rebutting the need for this), I've restored the referrer code. --Michael Snow (talk) 19:36, 23 May 2008 (UTC)
Michael, I'd appriciate if you didn't go interpret our silence as a "agree by non-resistence", because it's not. Our arguments are valid; we don't need this code bloating up the main script repository that handles the entire site; It slows down page loading and is only used in maybe 0.0001% of all page loads. Plus it is not effective in any way... if you want to be effective, we'd redirect the referrer page to Internet fraud or something like that. — Edokter • Talk • 23:02, 23 May 2008 (UTC)
- All of our content is either freely licensed or fair use. This means that Modernista has the right to do whatever it wants with it. Why are we adding a disclaimer when people do something that we've tried so hard to enable them to do? —Remember the dot (talk) 02:11, 24 May 2008 (UTC)
- They don't pretend to be Wikipedia as far as I can tell...they just show Wikipedia with a Modernista banner laid on top. —Remember the dot (talk) 20:52, 24 May 2008 (UTC)
- The issue, from what I've been told / read, is that their "logo" is covering Wikipedia's. I have to say that I sort of agree with Michael here, if only slightly. Really, getting caught up in every byte is a bit silly. The one thing that will not happen is an edit war here. What it looks like right now is that more outside opinions are needed. Perhaps post to a pump or noticeboard asking for input? Else, I'd suggest leaving the code. --MZMcBride (talk) 00:48, 25 May 2008 (UTC)
- It's really not that bad - take a look at their site and you'll see that the Wikipedia logo is very clearly visible despite the Modernista banner.
- I'm not trying to remove every byte possible from common.js; that would make the file unreadable. I just prefer to keep the common JavaScript to a minimum for reasonable performance and clarity, and also (though this doesn't apply to this thread) because I don't like having to use JavaScript to fix issues that would be better fixed by configuration changes etc. —Remember the dot (talk) 01:28, 25 May 2008 (UTC)
I'm against this code in Common.js. It's unreasonable to append this code just for a very tiny percentage of visitors (which was even lower before someone brought our attention to this "issue"). If another small company does the same trick, are you going to add the second warning for referrers from another website? —AlexSm 02:47, 25 May 2008 (UTC)
- I'm not interpreting silence as consent, but nobody has presented an alternative. The discussion has a variety of guesswork about whether this is a legitimate trademark concern (Wikimedia officials in a position to judge that have indicated that it is) and about whether the "bloat" is a significant detriment (considering that a developer said this was something any administrator could handle, it seems like they had this page in mind; if someone who actually deals with system resources came and said it's a problem, then I'd look at it differently). The decision should be based on information, not speculation and opinion. I would be happy to find there's some other option, but this is already a compromise from someone's earlier attempt to have the notice directly in the article itself. --Michael Snow (talk) 17:56, 25 May 2008 (UTC)
- Who said it was a trademark infringement, and if it is, why aren't we just blocking access to the site entirely until they stop the infringement? —Remember the dot (talk) 16:27, 26 May 2008 (UTC)
- Mike Godwin said it was a trademark issue. As for what steps to take in response, as you pointed out yourself, the text is freely licensed, so there's a balance to be struck in dealing with this. If you think we should block Modernista's access entirely, feel free to persuade the people who would need to implement that. --Michael Snow (talk) 04:57, 28 May 2008 (UTC)
- We could use the exact same kind of JavaScript to blank every Wikipedia page viewed through Modernista, leaving behind only a message about trademark infringement. But before we do that, could you point me to what Mike Godwin said about the issue? —Remember the dot (talk) 01:14, 29 May 2008 (UTC)
- No, I can't point you there, it comes from an email discussion. --Michael Snow (talk) 22:14, 29 May 2008 (UTC)
- Should I just e-mail Mike Godwin and ask him to repeat his response for me? I'd like to hear all the gory details of why this is a trademark infringement. —Remember the dot (talk) 00:39, 30 May 2008 (UTC)
- He didn't give a lot of gory details, he simply encouraged Jimmy Wales in contacting Modernista to object to this particular use because it raised trademark issues. As they've failed to respond appropriately, that leaves us to find alternative ways of protecting Wikipedia's brand. You're welcome to email Mike and see if he would like to give a more elaborate explanation. --Michael Snow (talk) 16:10, 30 May 2008 (UTC)
- If we're going in that direction, it would probably be better to just bust out of the Modernista iframe rather than to blank the page. But I'm not really convinced either is a good idea; if they want to use Wikipedia as a backdrop for their site, why not let them? It's not like they're making it hard to get rid of the banner, anyway. —Ilmari Karonen (talk) 22:45, 29 May 2008 (UTC)
- So, you'd also like to simply eliminate the Modernista code? —Remember the dot (talk) 00:39, 30 May 2008 (UTC)
- I don't really mind having it there if others feel it's needed, but no, I don't personally see much point in it. You may put my opinion down as a resounding "Meh." —Ilmari Karonen (talk) 02:43, 30 May 2008 (UTC)
PngFix() breaking "no pictures" option
Looks like PngFix makes all PNG images to appear despite unchecked "Show pictures" option in IE6. In other words, it breaks the functionality for users who disabled pictures (usually to to save traffic). One possible way to fix this is to check .complete image attribute. —AlexSm 18:42, 6 May 2008 (UTC)
- Got code? --MZMcBride (talk) 19:52, 6 May 2008 (UTC)
- I don't have time, so I was hoping the code author could thoroughly test this or maybe have some better ideas. —AlexSm 20:54, 6 May 2008 (UTC)
- Although I cannot image that anyone in 2008 would not want to see any images, I will have a look. But how does ".complete" into play? I cannot find any references to in online. However, if it only applies to IMG elements, it won't get us anywhere; PNG are converted to DIVs which may not have that attribute. — Edokter • Talk • 23:50, 6 May 2008 (UTC)
- I found this property using JS shell, but here's an official link for you: http://msdn.microsoft.com/en-us/library/ms533688(VS.85).aspx ; as for convertion (into SPAN), that's the whole point: if an image is not "complete" by the time the script is executed, this might mean that all images are disabled, so you do not convert the image. Again, there might be a better way... —AlexSm 13:03, 7 May 2008 (UTC)
- I already received a message on my talk page to "upgrade to IE7". Well, I don't use IE at all (except for compatibility testing) so I guess I'll explain how the issue started. We copied the PngFix code to ru.wp, and a couple of days ago one user complained that he cannot turn PNG images off on IE6. He is using GPRS, which is kind of slow, and he is probably paying for each megabyte of traffic. In any case, if this can be fixed easily, it should be fixed. And if you want all users to upgrade to IE7, then there is no need for IE6 fix (which all users have to download, by the way). —AlexSm 15:53, 7 May 2008 (UTC)
- The IE6 fix is there to limit the problems IE6 causes. Unfortunately, we can't entirely eliminate them from our end. It'd be best if users just stopped using IE6. Users using GPRS and paying by the megabyte could actually save money by using a different browser because many web sites (including Wikipedia) have to send extra CSS files to Internet Explorer to make it work right. —Remember the dot (talk) 16:14, 7 May 2008 (UTC)
- Partly I was hinting at the (failed for some reason) proposal to move the code into separate MediaWiki:IEFixes.js (as in ru:MediaWiki:IEFixes.js). —AlexSm 16:18, 7 May 2008 (UTC)
- The IE6 fix is there to limit the problems IE6 causes. Unfortunately, we can't entirely eliminate them from our end. It'd be best if users just stopped using IE6. Users using GPRS and paying by the megabyte could actually save money by using a different browser because many web sites (including Wikipedia) have to send extra CSS files to Internet Explorer to make it work right. —Remember the dot (talk) 16:14, 7 May 2008 (UTC)
- After I proposed that the comments made me realize that the HTTP header required to send an extra file would be significant compared to the small amount of IE-specific code we send out, so it's probably not worth it. —Remember the dot (talk) 16:22, 7 May 2008 (UTC)
My first thought was: why fix a problem here that only happens on ru.wiki? But then again, you have a point. Anyway, I tested the .complete check and it works without any performance hit. Change the following line:
if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png" && !img.onclick)
to
if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png" && img.complete && !img.onclick)
Now, should we implement it here as well? — Edokter • Talk • 23:04, 7 May 2008 (UTC)
- If there are no further objection, the .complete check is going in. — Edokter • Talk • 17:05, 16 May 2008 (UTC)
- Fine by me (though I can't test it, not having IE available here). I thought for a moment it might break on slow connections where the images might not have finished loading by the time the code runs, but since it's deferred using
window.attachEvent("onload")(rather than the usualaddOnloadHook(), which somewhat confusingly runs earlier), that shouldn't be a problem: any images that are going to be loaded should be complete by the time the onload event fires. —Ilmari Karonen (talk) 17:13, 16 May 2008 (UTC)
- Fine by me (though I can't test it, not having IE available here). I thought for a moment it might break on slow connections where the images might not have finished loading by the time the code runs, but since it's deferred using
Donation banner code changes
Using code written by Splarka, I've updated the donation banner code to detect the skin name and only work on Monobook. It's clear that the banners were laid out specific to Monobook, as they look God-awful in the other skins. Also, the new code moves the onload (making it more efficient). Let me know if there are any issues. Cheers. --MZMcBride (talk) 01:16, 7 May 2008 (UTC)
- Hmm... what's wrong with using MediaWiki:Monobook.js for that code? —AlexSm 01:56, 7 May 2008 (UTC)
- [skinname].js pages are deprecated. They still work in MediaWiki for backwards compatibility purposes. --MZMcBride (talk) 03:05, 7 May 2008 (UTC)
- They're not deprecated at all! They're 100% appropriate for code that's actually skin-specific. --brion (talk) 19:28, 3 June 2008 (UTC)
- bugzilla:4178#c17 is where it indicates that it was deprecated. Perhaps something changed or he was simply mistaken? --MZMcBride (talk) 20:19, 3 June 2008 (UTC)
- They're not deprecated at all! They're 100% appropriate for code that's actually skin-specific. --brion (talk) 19:28, 3 June 2008 (UTC)
- [skinname].js pages are deprecated. They still work in MediaWiki for backwards compatibility purposes. --MZMcBride (talk) 03:05, 7 May 2008 (UTC)
OTRS has been receiving messages lately from unregistered readers that Wikipedia content sometimes gets replaced with a donation request. No browser information yet, and the "sometimes" makes it hard to reproduce too, but there were complaints about this last year as well. Is it the restored anontip[1] or the change[2] that's problematic? Is the use of writeln necessary? --Para (talk) 09:59, 29 May 2008 (UTC)
- Ah. probably Safari users. I think writeln (just like document.write) can be dangerous on Safari. Better to use DOM editing. --TheDJ (talk • contribs) 17:35, 29 May 2008 (UTC)
- I've removed the document.writeln. MSDN docs warn that at least on IE, use of write/writeln after the document is loaded can break, and requires blanking the entire page. This is consistent with the descriptions we've gotten (and finally a screenshot!) from people reporting that Wikipedia was "requiring donations to read" -- pages coming up, then blanking and showing only a donation request link.
- This onload handler _should_ be getting run just before the completion of the <body> tag, but presumably there are mysterious circumstances where it's getting triggered late, or something. I haven't been able to repro it myself though. --brion (talk) 18:28, 3 June 2008 (UTC)
Ok, made one more tweak which works around the Internet Explorer failures. To summarize:
- MSIE throws an "operation aborted" error dialog, then throws away the page when you click "OK" iff:
- the offending JS code is run from a <script> that's inside the <body> and right at the end of it </body>
- worked around by moving the runOnloadHook() call outside of the </div> for globalWrapper
- there's some invalid HTML, especially unclosed tags
- known triggers included an unclosed <span> on login page and an improperly-closed <span/> on shared image description pages.
- you add new stuff to the end of an element it's confused about
- appending to globalWrapper via appendChild() or innerHTML += blah would fail. document.writeln() worked, but could trigger other problems in some cases. Prepending into globalWrapper with insertBefore() appears to nicely avoid both issues.
- the offending JS code is run from a <script> that's inside the <body> and right at the end of it </body>
So, with that change to the anonnotice insertion, at least that particular thing shouldn't be causing the "operation aborted" error anymore, even for people who'll get the old bad HTML in their caches (as long as they're getting the current JS).
Phew! Well let's hope nothing else horrible happens. ;) --brion (talk)
Merge donation banner with anon tips
I think merging the donation banner (above the tabs) with the anon tips (currently below the tabs) would be a good idea. I think having one randomized line above the tabs, with perhaps a slight bias toward the donation message, would be best. Thoughts? --MZMcBride (talk) 04:45, 7 May 2008 (UTC)
Follow-up: After a bit of discussion elsewhere, it has become clear that it would probably be best to merge the two messages in a month or so. The donation banner has been deactivated for four months – it should be more visible for a bit. When the new code is implemented, it will probably be what is proposed directly below. --MZMcBride (talk) 21:26, 7 May 2008 (UTC)
Proposed merged code for the two banners
if(wgUserName == null && skin == 'monobook') addOnloadHook((function (){
var message=new Array();
message[0]='Your <a href="http://wikimediafoundation.org/wiki/Fundraising?source=enwiki_00" class="extiw" title="wikimedia:Fundraising"><b>continued donations</b></a> keep Wikipedia running!';
message[1]='<a href="http://wikimediafoundation.org/wiki/Fundraising?source=enwiki_01" class="extiw" title="foundation:Fundraising"><b>Make a donation</b></a> to Wikipedia and give the gift of knowledge!';
message[2]='Wikipedia is sustained by people like you. Please <a href="http://wikimediafoundation.org/wiki/Fundraising?source=enwiki_02" class="extiw" title="foundation:fundraising"><b>donate</b></a> today.';
message[3]='Help us improve Wikipedia by <a href="http://wikimediafoundation.org/wiki/Fundraising?source=enwiki_03" class="extiw" title="foundation:Fundraising"><b>supporting it financially</b></a>.';
message[4]='You can <a href="http://wikimediafoundation.org/wiki/Fundraising?source=enwiki_04" class="extiw" title="wikimedia:Fundraising"><b>support Wikipedia</b></a> by making a <a href="http://wikimediafoundation.org/wiki/Deductibility_of_donations" class="extiw" title="wikimedia:Deductibility_of_donations">tax-deductible</a> donation.'
message[5]='Help us provide free content to the world by <a href="http://wikimediafoundation.org/wiki/Fundraising?source=enwiki_05" class="extiw" title="foundation:Fundraising"><b>donating today</b></a>!';
message[6]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Researching_with_Wikipedia" title="Wikipedia:Researching with Wikipedia">Learn more about using Wikipedia for research</a>';
message[7]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Ten_things_you_may_not_know_about_Wikipedia" title="Wikipedia:Ten things you may not know about Wikipedia">Ten things you may not know about Wikipedia</a>';
message[8]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Ten_things_you_may_not_know_about_images_on_Wikipedia" title="Wikipedia:Ten things you may not know about images on Wikipedia">Ten things you may not know about images on Wikipedia</a>';
message[9]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Citing_Wikipedia" title="Wikipedia:Citing Wikipedia">Learn more about citing Wikipedia</a>';
message[10]='Have questions? <a href="http://en.wikipedia.org/wiki/Wikipedia:Questions" title="Wikipedia:Questions">Find out how to ask questions and get answers.</a>';
message[11]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Basic_navigation" title="Wikipedia:Basic navigation">Find out more about navigating Wikipedia and finding information</a>';
message[12]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Contributing_to_Wikipedia" title="Wikipedia:Contributing to Wikipedia">Interested in contributing to Wikipedia?</a>';
var weightLimit = 6;
var biasPercent = 90;
var whichMessage = (Math.floor(Math.random() * 100) < biasPercent) ? weightLimit : message.length
whichMessage = Math.floor(Math.random() * whichMessage);
document.writeln('<div style="position:absolute; z-index:40; left:155px; top:0px; clear:both; float:left;" id="anon-banner"><div style="font-size:90%; white-space:nowrap;"><i>' + message[whichMessage] + '</i></div></div>');
}));
- I agree with this proposal. The upper-right anon message has been a source of frustration with respect to overlapping other elements on the page. --- RockMFR 19:03, 10 May 2008 (UTC)
- This code is due to the report here.
Newer proposal code for the two banners
if(wgUserName == null && skin == 'monobook') addOnloadHook((function (){
var message=new Array();
message[0]='Your <a href="http://wikimediafoundation.org/wiki/Fundraising?source=enwiki_00" class="extiw" title="wikimedia:Fundraising"><b>continued donations</b></a> keep Wikipedia running!';
message[1]='<a href="http://wikimediafoundation.org/wiki/Fundraising?source=enwiki_01" class="extiw" title="foundation:Fundraising"><b>Make a donation</b></a> to Wikipedia and give the gift of knowledge!';
message[2]='Wikipedia is sustained by people like you. Please <a href="http://wikimediafoundation.org/wiki/Fundraising?source=enwiki_02" class="extiw" title="foundation:fundraising"><b>donate</b></a> today.';
message[3]='Help us improve Wikipedia by <a href="http://wikimediafoundation.org/wiki/Fundraising?source=enwiki_03" class="extiw" title="foundation:Fundraising"><b>supporting it financially</b></a>.';
message[4]='You can <a href="http://wikimediafoundation.org/wiki/Fundraising?source=enwiki_04" class="extiw" title="wikimedia:Fundraising"><b>support Wikipedia</b></a> by making a <a href="http://wikimediafoundation.org/wiki/Deductibility_of_donations" class="extiw" title="wikimedia:Deductibility_of_donations">tax-deductible</a> donation.'
message[5]='Help us provide free content to the world by <a href="http://wikimediafoundation.org/wiki/Fundraising?source=enwiki_05" class="extiw" title="foundation:Fundraising"><b>donating today</b></a>!';
message[6]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Researching_with_Wikipedia" title="Wikipedia:Researching with Wikipedia">Learn more about using Wikipedia for research</a>';
message[7]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Ten_things_you_may_not_know_about_Wikipedia" title="Wikipedia:Ten things you may not know about Wikipedia">Ten things you may not know about Wikipedia</a>';
message[8]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Ten_things_you_may_not_know_about_images_on_Wikipedia" title="Wikipedia:Ten things you may not know about images on Wikipedia">Ten things you may not know about images on Wikipedia</a>';
message[9]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Citing_Wikipedia" title="Wikipedia:Citing Wikipedia">Learn more about citing Wikipedia</a>';
message[10]='Have questions? <a href="http://en.wikipedia.org/wiki/Wikipedia:Questions" title="Wikipedia:Questions">Find out how to ask questions and get answers.</a>';
message[11]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Basic_navigation" title="Wikipedia:Basic navigation">Find out more about navigating Wikipedia and finding information</a>';
message[12]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Contributing_to_Wikipedia" title="Wikipedia:Contributing to Wikipedia">Interested in contributing to Wikipedia?</a>';
var weightLimit = 6;
var biasPercent = 90;
var whichMessage = (Math.floor(Math.random() * 100) < biasPercent) ? weightLimit : message.length
whichMessage = Math.floor(Math.random() * whichMessage);
wrapper = document.getElementById('globalWrapper');
if(wrapper) {
temp = document.createElement('div');
temp.innerHTML = '<div style="position:absolute; z-index:40; left:155px; top:0px; clear:both; float:left;" id="anon-banner"><div style="font-size:90%; white-space:nowrap; font-style:italic;">' + message[whichMessage] + '</div></div>';
wrapper.insertBefore(temp.firstChild, wrapper.firstChild);
}
}));
- This makes sure that the code is inserted at the correct spot (wikEd and popups operate here as well), and it avoids using the innerHTML += construct which can sometimes be problematic on larger chunks of HTML, especially icw scripts. I did notice however that with a bias of 90 for donation messages, followed by another random, the chances of actually seeing one of the anontips is quite slim. I think the bias needs tweaking, or when we do the 2nd random, we should be forced to select a number between weight-limit and message.length, instead of between 0 and message.length. --TheDJ (talk • contribs) 10:42, 30 May 2008 (UTC)
- I still strongly favor using one merged banner rather than two. If nobody objects in the next few days, I propose adding the code to Common.js, with a biasPercent=81.5. This will make it so that approximately 1 in 10 views hits an anon tip, while 9 in 10 views hit a donation message. (The number is 81.5 vs. 90 due to using a double random.) I also think pushing down the banner with a top:1px would be good. It's a small, but noticeable change in Firefox. My only remaining concern is using nowrap with IE; there are reports that IE6 (shockingly!) doesn't handle nowrap well. The original code used s, which was a major hit for legibility. So... we can use nowrap and hopefully it won't hurt IE6 users, we can restore the non-breaking spaces, or can just use regular spaces. If the screen is that narrow, it's going to hit the "Log in / create account" text anyway... --MZMcBride (talk) 19:17, 3 June 2008 (UTC)
- This is JavaScript, right? We can fix that programmatically (warning: untested code, may have bugs):
- I still strongly favor using one merged banner rather than two. If nobody objects in the next few days, I propose adding the code to Common.js, with a biasPercent=81.5. This will make it so that approximately 1 in 10 views hits an anon tip, while 9 in 10 views hit a donation message. (The number is 81.5 vs. 90 due to using a double random.) I also think pushing down the banner with a top:1px would be good. It's a small, but noticeable change in Firefox. My only remaining concern is using nowrap with IE; there are reports that IE6 (shockingly!) doesn't handle nowrap well. The original code used s, which was a major hit for legibility. So... we can use nowrap and hopefully it won't hurt IE6 users, we can restore the non-breaking spaces, or can just use regular spaces. If the screen is that narrow, it's going to hit the "Log in / create account" text anyway... --MZMcBride (talk) 19:17, 3 June 2008 (UTC)
// walk the DOM tree, replacing spaces with
// note: do this before attaching the branch to the full tree
var node = temp;
while (node) {
if (node.nodeType == 3) // TEXT_NODE
node.nodeValue = node.nodeValue.replace(" ", "\240"); // nbsp = octal 240
else if (node.firstChild)
node = node.firstChild;
else {
while (!node.nextSibling && node.parentNode)
node = node.parentNode;
node = node.nextSibling;
}
}
wrapper.insertBefore(temp.firstChild, wrapper.firstChild);
- —Ilmari Karonen (talk) 08:14, 5 June 2008 (UTC)
- Seems like a lot of code to be loading on every page load just to ensure that the words don't wrap. IE6 simply ignores nowrap, so I'm inclined to just allow the words to wrap for IE6 users. In fact, I'm trying to figure out why the words shouldn't wrap for everyone. But this is trivial in the greater scheme. There don't seem to be any objections to merging the two banners (at least not on-wiki). So, I'm going to go ahead and implement the updated version tomorrow. The final thing I was thinking about was moving it to a subpage and have it only load for anons. --MZMcBride (talk) 18:09, 6 June 2008 (UTC)
MainPageDeletedImage()
I removed the MainPageDeletedImage() function, which appears to be an anti-vandalism measure preventing compromised admin accounts from ruining the main page through deletion. As far as I can tell, this function doesn't serve a purpose anymore because the main page can no longer be deleted, so I've removed it. Please let me know if there is a reason why we should add it back. —Remember the dot (talk) 05:19, 7 May 2008 (UTC)
- Hmm. The Main Page can still be deleted by any semi-competent admin. But it being deleted is a pretty rare occurrence, so... meh. --MZMcBride (talk) 16:44, 26 May 2008 (UTC)
- The devs made it technically impossible to delete the Main Page after this fiasco, see [3]. —Remember the dot (talk) 16:52, 26 May 2008 (UTC)
- /cough/ Link /cough/ "Semi-competent admin." --MZMcBride (talk) 17:07, 26 May 2008 (UTC)
- Oh. Still, you'd really have to be trying, and the deletion would be immediately reverted anyway. —Remember the dot (talk) 17:21, 26 May 2008 (UTC)
- Yowza! Now I know what to do if I ever want to go seriously rogue! Let's have some more people watching that interface message, shall we? —Ilmari Karonen (talk) 20:41, 29 May 2008 (UTC)
- Oh. Still, you'd really have to be trying, and the deletion would be immediately reverted anyway. —Remember the dot (talk) 17:21, 26 May 2008 (UTC)
- /cough/ Link /cough/ "Semi-competent admin." --MZMcBride (talk) 17:07, 26 May 2008 (UTC)
- The devs made it technically impossible to delete the Main Page after this fiasco, see [3]. —Remember the dot (talk) 16:52, 26 May 2008 (UTC)
Broken
recent edits (last 20 minutes) have broken the code I am getting errors on every page load. please fix, its line 644. βcommand 2 21:07, 7 May 2008 (UTC)
- I second this. This is because of the return statement being used on a non-function. —paranomia (formerly tim.bounceback)a door? 21:11, 7 May 2008 (UTC)
- Give me a couple minutes and I'll have it fixed. —Remember the dot (talk) 21:13, 7 May 2008 (UTC)
- OK, I was just about to do an {{editprotected}}. Thanks, —paranomia (formerly tim.bounceback)a door? 21:14, 7 May 2008 (UTC)
- Give me a couple minutes and I'll have it fixed. —Remember the dot (talk) 21:13, 7 May 2008 (UTC)
Why don't you make all changes in a separate file, then announce it here and wait one day for other users to review it? "Be bold" is not about this page. —AlexSm 21:17, 7 May 2008 (UTC)
- Because the changes are mostly minor and incremental and with the exception of this stupid mistake, they have gone through correctly. I don't plan on making any more changes to this file for a while. —Remember the dot (talk) 21:22, 7 May 2008 (UTC)
- Still, errors do happen, inevitably. If every Wikipedia admin is allowed one little error in this file, I may as well turn JS off in my browser. Why not do it the safe way from the start? —AlexSm 21:25, 7 May 2008 (UTC)
- I'll make sure to check for script errors when previewing changes in the future. —Remember the dot (talk) 21:28, 7 May 2008 (UTC)
- I just checked and (unlike personal monobook.js) the Common.js is not inserted inline on preview . In other words, you cannot test new code for errors using Preview button. —AlexSm 06:00, 8 May 2008 (UTC)
Proposed fix:
var page = 'm:MediaWiki:Wikiminiatlas.js';
if( !importedScripts[page] ) {
importedScripts[page] = true;
var url = 'http://meta.wikimedia.org/w/index.php?title=MediaWiki:Wikiminiatlas.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400';
var scriptElem = document.createElement( 'script' );
scriptElem.setAttribute( 'src' , url );
scriptElem.setAttribute( 'type' , 'text/javascript' );
document.getElementsByTagName( 'head' )[0].appendChild( scriptElem );
} —paranomia (formerly tim.bounceback)a door? 21:18, 7 May 2008 (UTC)
Issue is now resolved. —paranomia (formerly tim.bounceback)a door? 21:21, 7 May 2008 (UTC)
- What's the purpose of
if( !importedScripts[page] ...before importing Wikiminiatlas? Common.js is only called once anyway. —AlexSm 06:00, 8 May 2008 (UTC)
- Umm...come to think of it, it probably doesn't do anything and can be removed. —Remember the dot (talk) 15:32, 8 May 2008 (UTC)
- Then again, a gadget might import the script for some reason before common.js executes. —Remember the dot (talk) 21:27, 8 May 2008 (UTC)
Edittools cleanup
I've posted here regarding the current Edittools situation. Thoughts and / or volunteers would be much appreciated. --MZMcBride (talk) 04:33, 12 May 2008 (UTC)
new importScript, importStylesheet, and family
Per rev:35064 and above discussions: #1, #2 (related to bugzilla:12773 and bugzilla:13232), importScript() is now supported in core, along with 4 other slight modifications to make script loading more dynamic.
importScript(page) - imports a local wiki page as a script.
example: importScript('MediaWiki:Something.js');
importScriptURI(url) - imports a script from a remote location, such as another project.
example: importScriptURI('http://test.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=MediaWiki%3ASomething.js');
importStylesheet(page) - imports a local wiki page as a stylesheet.
example: importStylesheet('MediaWiki:Something.css');
importStylesheetURI(url) - imports a stylesheet from a remote location.
example: importStylesheetURI('http://test.wikipedia.org/w/index.php?action=raw&ctype=text/css&title=MediaWiki%3ASomething.css');
appendCSS(css) - appends style data directly to the document.
example: appendCSS('#bodyContent { color:red; }');
These could be used, for example, to reduce the size of the scripts being loaded on Common.js to be more conditional (hint hint). Note that they have been tested in most major browsers for basic functionality, but secondary or tertiary loading of scripts and styles may be buggy in some browsers (although bugzilla:12773 should fix most of those problems). --Splarka (rant) 07:25, 20 May 2008 (UTC)
- Wicked !!! --TheDJ (talk • contribs) 08:39, 20 May 2008 (UTC)
- Yes! I've always wanted these in the core. This will make moving scripts across wikis much easier. —Remember the dot (talk) 02:15, 21 May 2008 (UTC)
- Great! I removed the redundant functions from common.js and everything seems to still be working fine. —Remember the dot (talk) 01:45, 22 May 2008 (UTC)
Overall performance improvement
I have an idea that will result in an overall performance improvement for Wikipedia visitors. I've given this quite a bit of thought and I am confident that it will be worth it.
Internet Explorer 6's market share is dwindling. As of April 2008, it's down to about 29% and is expected to continue to decline. We currently have about 8 KB of scripts that are specifically for IE6 users and no one else. This means that the majority of users have to download an extra 8 KB of code. Having been a dial-up user, I can tell you that 8 KB is quite significant on dial-up, resulting in a 1-2 second delay when loading a Wikipedia page when common.js has not yet been cached. It is also significant to mobile device users that have to pay for bandwidth by the kilobyte.
I know that it's a bad idea to just remove all the IE6 the code because we can't turn our backs on that 29% of our readers. However, I did some testing with Fiddler and discovered that it only takes an extra 900 bytes to make an extra HTTP request. Since web browsers, including IE, re-use TCP connections instead of creating a new connection for every request, this 900 bytes would be the only cost of the request.
This means that if we split the IE6 code off onto a separate page:
- 71% of users would save the transfer time of 8 KB.
- 29% of users would have to download an extra 0.9 KB.
The extra IE6 file would be downloaded right after Common.js, so it would execute at the same time as it would if it were still in Common.js.
Another benefit is that factoring out the IE6 code would put less strain on the Wikimedia servers, meaning that the servers would perform better in general for both IE users and non-IE users alike. —Remember the dot (talk) 21:39, 24 May 2008 (UTC)
- I'm not sure this is something we should really be concerned with. There are many optimizations that could be made that would decrease the bandwidth used for loading this page, but we just don't do them. I'd recommend running this past a developer before discussing it here. --- RockMFR 21:51, 24 May 2008 (UTC)
- Every optimization helps (provided that it doesn't make the code unreadable etc.), and input from Wikimedia developers is always welcome. What other optimizations did you have in mind? —Remember the dot (talk) 21:58, 24 May 2008 (UTC)
- While I generally want to beat someone over the head when they point out this guideline to me, I think WP:PERF applies here. This was discussed a few sections above. Has anything really changed since then? --MZMcBride (talk) 00:52, 25 May 2008 (UTC)
- Two things have changed since this was discussed last. First, the market share of IE6 has continued to dwindle and will continue its decline into the forseeable future. We can't leave the IE6 code in there forever. Second, I researched the problem more with Fiddler and determined that splitting the IE6 code off into its own page would not have a significant performance impact on IE6 users.
- I'm proposing a way to gracefully phase out the IE6 code as users move to other browsers, and at the same time improve performance a bit. While there's generally nothing we can do about performance, the common JavaScript file is definitely an exception. I shudder to think how slow Wikipedia would be if the common JavaScript was sloppily written and bogged down with excessive scripts. —Remember the dot (talk) 01:15, 25 May 2008 (UTC)
- Just as before, I support moving IE6 code into separate page (as I already did on another Wikimedia project). And I don't think WP:PERF applies here, because we are talking about some benefits for (non-IE6) users, not just servers. —AlexSm 03:06, 25 May 2008 (UTC)
- I support as well. WP:PERF does not apply here. --TheDJ (talk • contribs) 08:48, 25 May 2008 (UTC)
- OK, based on the comments above and below I've moved the IE6 code to Mediawiki:Common.js/IE60Fixes.js. For now, I've only split off the PngFix code because I'm pretty sure the "IE 6 Z-index bug workaround for anonnotice" is for all browsers, despite the title. Additional clarification about this script would be appreciated, but even with only the PngFix script split off there will still be a slight performance improvement. —Remember the dot (talk) 18:14, 25 May 2008 (UTC)
- I support as well. WP:PERF does not apply here. --TheDJ (talk • contribs) 08:48, 25 May 2008 (UTC)
- Just as before, I support moving IE6 code into separate page (as I already did on another Wikimedia project). And I don't think WP:PERF applies here, because we are talking about some benefits for (non-IE6) users, not just servers. —AlexSm 03:06, 25 May 2008 (UTC)
- While I generally want to beat someone over the head when they point out this guideline to me, I think WP:PERF applies here. This was discussed a few sections above. Has anything really changed since then? --MZMcBride (talk) 00:52, 25 May 2008 (UTC)
- Every optimization helps (provided that it doesn't make the code unreadable etc.), and input from Wikimedia developers is always welcome. What other optimizations did you have in mind? —Remember the dot (talk) 21:58, 24 May 2008 (UTC)
Functional breakdown by size
I've been intermittently working on breaking functional pieces out of the global wikibits.js to reduce load times for low-bandwidth users (this'll particularly affect dial-up and mobile devices). Of particular note is code that's used only on some pages, such as when editing, or searching, or on a particular browser.
The same would probably be nice to do here on English Wikipedia. Here's a quick breakdown of some things that can be easily broken out from MediaWiki:Common.js:
| Bytes | What |
| 2129 | Special:Watchlist tweaks |
| 2451 | Special:Search tweaks |
| 3869 | Internet Explorer tweaks |
| 4129 | displaytitle replacement (can be replaced by fixes to MediaWiki) |
| 4318 | edit page tweaks (toolbar, summary check) |
| 16429 | (everything else) |
| 33325 | Total current MediaWiki:Common.js |
(Note that the actual transferred file sizes will in most cases be lower, as these will be sent compressed for most browsers.)
About half the total can be broken out and loaded up only when on that special action or on that particular browser, reducing the bandwidth impact for first-time visits. (There'll be an extra hit when you do go into edit, or search, or whatever, but if you don't you'll never see it, and once you do it too will be cached.)
You guys can probably do much of this with just a brief JS check and a conditional importScript() call, but if you want/need native support in MediaWiki for fetching extra JS on particular actions, we can talk. --brion (talk) 16:41, 25 May 2008 (UTC)
- Thanks for your message! I've split off the IE6-specific code, see the above thread. It probably wouldn't be a good idea to split off the general IE code because the majority of our users use IE7, and we don't want the majority to take a performance hit. The other areas you pointed out, however, would be great to split off, as relatively few people use the special pages etc. —Remember the dot (talk) 18:41, 25 May 2008 (UTC)
- OK, I split the editing scripts off to MediaWiki:Common.js/edit.js, the watchlist scripts to MediaWiki:Common.js/watchlist.js, and the searching scripts to MediaWiki:Common.js/search.js, which shaved off another 9 KB. What can be done to remove the need for the displaytitle script? —Remember the dot (talk) 23:37, 25 May 2008 (UTC)
- Hmm, i'm on cable and even I can notice the difference if I clear my cache. Nice work Remember the dot. Although I have to say that you "undefined" the isIE variable, which I was using in a testscript that thus broke. Not sure if other people use it, but something to keep in mind for the next couple of days. --TheDJ (talk • contribs) 17:23, 26 May 2008 (UTC)
- Perhaps move MediaWiki:Sysop.js to MediaWiki:Common.js/sysop.js for consistency? Or move the others to MediaWiki:Edit.js, etc. ... --MZMcBride (talk) 17:30, 26 May 2008 (UTC)
- If we're going to move something then let's move MediaWiki:Sysop.js to MediaWiki:Common.js/sysop.js. I chose to make the scripts pseudo-subpages to keep them logically linked together. —Remember the dot (talk) 17:40, 26 May 2008 (UTC)
- Why is this naming illogical? —Remember the dot (talk) 18:47, 26 May 2008 (UTC)
- Yes...I was hoping to keep all the common scripts linked together, rather than scattered throughout the MediaWiki namespace. —Remember the dot (talk) 18:56, 26 May 2008 (UTC)
(Deindent) How about names like MediaWiki:Common-sysop.js or MediaWiki:Common/sysop.js? — Edokter • Talk • 19:00, 26 May 2008 (UTC)
- MediaWiki:Common-sysop.js would be fine, but I don't think it really matters. —Remember the dot (talk) 19:04, 26 May 2008 (UTC)
- Wikipedia doesn't have any of the subpage enhancements enabled, so I don't really think there's much point to subpaging them. And as Edokter mentioned above, having a .js in the path name seems kinda weird. I would say that MediaWiki:Common sysop.js would be the cleanest way to put it (along with the benefits of Special:Prefixindex/MediaWiki:Common. -- Prod (Talk) 04:46, 8 June 2008 (UTC)
Wikiminiatlas JS load tweak
I tweaked the Wikiminiatalas JS load to pull from secure.wikimedia.org when viewing through the SSL interface. Previously, Firefox 3 was considering the page insecure and showing a broken lock & plain background on the favicon (in addition to it simply being potentially open to man-in-the-middle attacks injecting evil JavaScript. :) --brion (talk) 17:58, 26 May 2008 (UTC)
- Excellent, thanks! —Remember the dot (talk) 18:00, 26 May 2008 (UTC)
- Updated at least the form I see on San Francisco. --brion (talk) 00:29, 31 May 2008 (UTC)
Multiple watchlist dismisses
There is ongoing discussion about implementing multiple dismiss buttons for the watchlist notice here. Comments / input / etc. welcome. --MZMcBride (talk) 04:30, 4 June 2008 (UTC)
Poor error handling in "IPv6 AAAA connectivity testing"
The code added in this edit adds some web bugs to the footer, and then tries to access them via javascript without testing that they were actually successfully added. I noticed this because my ad blocker stripped out the webbugs. The code should fail gracefully, by checking if the getElementById calls returned successfully instead of blindly assuming they worked. Anomie⚔ 01:03, 9 June 2008 (UTC)
- Easy enough to test. Though thats a pretty obnoxious adblocker... behavior like that going to actively wedge the future automagic detection of working IPv6 support. What are you using? The issue you saw should now be gone. --Gmaxwell (talk) 01:08, 9 June 2008 (UTC)
- Privoxy with the standard "webbugs" filter. I've added a fix to my monobook.js that solves the js error for me. Why does IPv6 support need to be tested? Anomie⚔ 01:15, 9 June 2008 (UTC)
- Some small number of clients believe they have IPv6 connectivity but actually do not. If DNS resolution returns a v6 address these hosts will attempt to use it and fail. For these clients any IPv6 enabled sites will appear non-functional. (There is no problem for clients which merely do not have IPv6 support enabled)
- Getting a good handle on exactly how many broken clients are out there is the first step to dealing with it, and a pre-requisite for turning on IPv6 for the main sites. Special:Watchlist on EnWP is being used first simply because we know we'll get good reports related to corner cases like yours, and since the page already remote loads toolserver we didn't expect any major errors. Latter steps will involve running the test on all Wikimedia pages, and further steps may involve things like alerting users to their misconfiguration and helping them fix their systems. The statistics this is gathering can be seen at http://ipv6and4.labs.wikimedia.org/stats.html.--Gmaxwell (talk) 01:39, 9 June 2008 (UTC)
- Privoxy with the standard "webbugs" filter. I've added a fix to my monobook.js that solves the js error for me. Why does IPv6 support need to be tested? Anomie⚔ 01:15, 9 June 2008 (UTC)
Common.js broken for Konqueror
Please remove the strange unicode char in front of __ipv6wwwtest_startTest(); (end of common.js). It breaks the javascript execution for Konqueror. --Dschwen 13:55, 10 June 2008 (UTC)
- It looks as though there was a stray byte-order mark in the code. I've removed it. Try bypassing your local cache to see if that fixed it. Cheers. --MZMcBride (talk) 14:05, 10 June 2008 (UTC)
- Yay, thanks, that did it. --Dschwen 14:28, 10 June 2008 (UTC)
Editintro for disambiguation pages
There is a proposal at Wikipedia talk:WikiProject Disambiguation#Template to caution against frequent mistakes to have an edit intro (text above the edit box) on disambiguation pages. This would be accomplished by using the code at User:RockMFR/disambigeditintro.js. Are there any objections, technical or otherwise, to adding this to Common.js? --- RockMFR 02:22, 14 June 2008 (UTC)
- Possible non-JS solution: disambiguation templates themselves could display an extra message only in edit mode, by checking {{REVISIONID}}. Disadvantage: message will not be seen by users who do not use preview at all. Advantages: message will be seen by users with JS off, by users with Classic, Cologne Blue and Nostalgia skins, and by users who are creating disambigs. —AlexSm 03:00, 14 June 2008 (UTC)
- Hmm, that is an interesting idea. The disadvantage is a big one, though, since the default on the first edit is to not show a preview. --- RockMFR 03:43, 14 June 2008 (UTC)
- I suspect the warning is most needed for the default, average editor who does not preview. I am willing to help expand the {{disambig}} template to have the note too, but I think the JS solution is probably best. Also the JS is fairly simple and short, so not too much of a burden. Unfortunately, it runs before one clicks on "edit", so it has to be added to the main common.js instead of /edit.js. JackSchmidt (talk) 18:39, 20 June 2008 (UTC)
uploadwizard_newusers
If this was discussed beforehand, at least we wouldn't have a JS error in Common.js... —AlexSm 04:19, 15 June 2008 (UTC)
- Okay, if this is not obvious from the code: log out and visit Wikipedia:Upload, you'll be greeted by JavaScript error. —AlexSm 05:33, 16 June 2008 (UTC)
Sysop.js load
The MediaWiki:Sysop.js loader is overly complex, and should not be adding an onload hook unconditionally as those checks can be done before document load. Eg:
if(wgUserGroups && wgUserGroups.join(' ').indexOf('sysop') != -1) {
addOnloadHook(function() {
if(!window.disableSysopJS) importScript('MediaWiki:Sysop.js')
});
}
Note that the onload hook is required before calling MediaWiki:Sysop.js due to the way it is written. Also note that there is no longer a maintainer. heh. --Splarka (rant) 21:54, 16 June 2008 (UTC)
- disableSysopJS is probably defined in the user's monobook.js (in my case it is), so it isn't loaded until after common.js is. This is probably why the current setup is the way it is, isn't it? I guess the disableSysopJS check could be moved to Sysop.js... --- RockMFR 21:59, 16 June 2008 (UTC)
- The idea is that you can disable the loading of Sysop.js by adding
disableSysopJS = trueto your /monobook.js. I use the feature, as do a few other admins, I suspect. --MZMcBride (talk) 23:09, 16 June 2008 (UTC)
New and much improved version of importScript()
function importScript(src, attrs) {
var script = document.createElement(isCSS ? "link" : "script");
script.setAttribute("type", "text/javascript");
if (src.indexOf("[[") == 0 && src.indexOf("]]") == src.length-2) script.setAttribute("src", (function() {
var path;
src = src.substring(2, src.length-2).replace(/\s/g, "_");
for (var interwikiNamespace in importScript.interwikiNamespaces) {
if (src.indexOf(interwikiNamespace + ":") == 0) {
src = src.substring(interwikiNamespace.length + 1);
path = importScript.interwikiNamespaces[interwikiNamespace](src);
break;
}; // break the loop if filter recognised
};
return path || importScript.interwikiNamespaces["#default"](src);
})());
else script.setAttribute("src", encodeURI(src));
if (attrs) {
if (typeof attrs.onload == "function") {
if (script.addEventListener) script.addEventListener("load", attrs.onload, true);
else script.onreadystatechange = function() {
if (this.readyState == "complete" || this.readyState == 4)
attrs.onload.apply(null, arguments);
};
delete attrs.onload;
};
for (var attr in attrs) script.setAttribute(attr, attrs[attr]);
};
document.getElementsByTagName("head")[0].appendChild(script);
};
importScript.interwikiNamespaces = {
"hrwiki": function(src) {
return "http://www.hrwiki.org/index.php?title=" + encodeURIComponent(src) + "&action=raw&ctype=text/javascript";
},
"hrfwiki": function(src) {
return "http://fanstuff.hrwiki.org/index.php?title=" + encodeURIComponent(src) + "&action=raw&ctype=text/javascript";
},
"w": function(src) {
return "http://" + ((src.indexOf(":") == 2) ? src.substring(0, 2) : "en") + ".wikipedia.org/w/index.php?title=" + encodeURIComponent((src.indexOf(":") == 2) ? src.substr(3) : src) + "&action=raw&ctype=text/javascript";
},
"js-frame": function(src) {
switch (src.toLowerCase()) {
case "yui": return "http://yui.yahooapis.com/2.5.2/build/yuiloader/yuiloader-beta-min.js"; break;
case "prototype": return "http://www.prototypejs.org/javascripts/prototype.js"; break;
case "mootools": return "http://www.mootools.net/assets/scripts/mootools.js"; break;
case "jquery": return "http://code.jquery.com/jquery-latest.pack.js"; break;
};
},
"#default": function(src) {
return wgScript + "?title=" + encodeURIComponent(src) + "&action=raw&type=text/javascript";
}
};
(function(a,b){for(var c in a)b(a[c])})("wiktionary wikinews wikibooks wikiquote wikisource wikiversity wikispecies".split(" "), function(a) {
importScript.interwikiNamespaces[a] = function(src) {
return "http://" + ((src.indexOf(":") == 2) ? src.substring(0, 2) : "en") + "." + a + ".org/w/index.php?title=" + encodeURIComponent((src.indexOf(":") == 2) ? src.substr(3) : src) + "&action=raw&ctype=text/javascript";
};
});
—Preceding unsigned comment added by Year2000Prob (talk • contribs)
- You will have to argue your case here. For now, i do not see the advantage over the current version in wikibits.js, and it has som issues with loading CSS files after loading the main HTML file on some browsers with this method (that's why we changed that in wikibits.js) --TheDJ (talk • contribs) 10:44, 18 June 2008 (UTC)
- OK. I got rid of the CSS support. What else should I fix? --58.173.104.186 (talk) 01:39, 20 June 2008 (UTC)
- I think you missed my point somewhat. What makes this better ? As far as I can tell, it's only advantage is that it has shortcuts for some oft used JS libraries, but people can simply use importScriptURI() for that atm, and more features != better I think. This is a lot of code and we need some pretty strong rationale in order to add even more into wikibits.js (which btw would be primarily decided upon by the MediaWiki developers and not by Wikipedia contributors here (though we probably have some influence). --TheDJ (talk • contribs) 09:41, 20 June 2008 (UTC)
- Well, the reason I added
importScript.interwikiNamespacesis because I noticed a bug: if you import scripts expecting the system to parse the interwiki reference, the resulting redirect goes to the actual HTML page for the script, not the script source. For example, http://en.wikipedia.org/w/index.php?title=de:Benutzer:ASM/quickedit.js&action=raw&ctype=text/javascript redirects to http://de.wikipedia.org/wiki/Benutzer:ASM/quickedit.js and not http://de.wikipedia.org/w/index.php?title=Benutzer:ASM/quickedit.js&action=raw&ctype=text/javascript --[[ year2000prob ]] 01:57, 23 June 2008 (UTC)- If you privately want to include Javascript from other servers, that's fine. But I'd strongly object to offering this on a global level. People will use it, and we'll end up with site-wide JS that depends on off-site Javascripts. If that external JS is changed or contains bugs or even malicious hacks, we may end up with broken site-wide Javascript. This should not be allowed at all. Cross-domain JS inclusion should've never been allowed, maybe even cross-site inclusion. (Some people at the Commons for instance use Lupin's popups, including it directly from en-WP. But that script contains an error that breaks other scripts at the Commons.) At the very least I think
importScriptURIandimportStylesheetURIshould include a check to allow inclusions only from wikipedia (and maybe wikimedia) domains. Lupo 10:02, 23 June 2008 (UTC)- P.S.: my browser is set anyway to disallow cross-domain JS inclusion. Lupo 10:02, 23 June 2008 (UTC)
- If you privately want to include Javascript from other servers, that's fine. But I'd strongly object to offering this on a global level. People will use it, and we'll end up with site-wide JS that depends on off-site Javascripts. If that external JS is changed or contains bugs or even malicious hacks, we may end up with broken site-wide Javascript. This should not be allowed at all. Cross-domain JS inclusion should've never been allowed, maybe even cross-site inclusion. (Some people at the Commons for instance use Lupin's popups, including it directly from en-WP. But that script contains an error that breaks other scripts at the Commons.) At the very least I think
- Well, the reason I added
- I think you missed my point somewhat. What makes this better ? As far as I can tell, it's only advantage is that it has shortcuts for some oft used JS libraries, but people can simply use importScriptURI() for that atm, and more features != better I think. This is a lot of code and we need some pretty strong rationale in order to add even more into wikibits.js (which btw would be primarily decided upon by the MediaWiki developers and not by Wikipedia contributors here (though we probably have some influence). --TheDJ (talk • contribs) 09:41, 20 June 2008 (UTC)
- OK. I got rid of the CSS support. What else should I fix? --58.173.104.186 (talk) 01:39, 20 June 2008 (UTC)
How to install ?
Found the answer alone, and give it to newbies : make a link to [[{{ns:MediaWiki}}:Common.js]] on your wiki, edit this page and copy/past all the content of the "view source" page. That's all folks !--New morning (talk) 17:15, 24 June 2008 (UTC)
Main Page tab
{{editprotected}}
Either something must have been done to the lines of coding that changed the namespace tab when viewing the main page, or this is an incompatibility with Firefox 3 that results in the code not doing what it was intended to do. What can be done to fix this? —Animum (talk) 22:19, 22 June 2008 (UTC)
- The Javascript was recently removed, because it was replaced with a new technique to do this. However that new solution was subsequently reverted again. MediaWiki_talk:Nstab-main. Ergo, we need this Javascript back. --TheDJ (talk • contribs) 23:30, 22 June 2008 (UTC)
- Meh. (1) Is it really so important to require the extra JS to be loaded on every page load? (2) The code that was used to do it previously seems more complex than it probably needs to be. So if you all insist upon re-adding the code, let's at least be sure it's as efficient as possible. But really, there should either be a software change for this of some sort, or the tab should simply say 'article' (as heretical as that may be). --MZMcBride (talk) 01:20, 23 June 2008 (UTC)
- I strongly support making this a MediaWiki feature. Meanwhile, if JS code is to be readded, it should be simplified and merged with another Mainpage function, something like this below. —AlexSm 22:09, 23 June 2008 (UTC)
- Meh. (1) Is it really so important to require the extra JS to be loaded on every page load? (2) The code that was used to do it previously seems more complex than it probably needs to be. So if you all insist upon re-adding the code, let's at least be sure it's as efficient as possible. But really, there should either be a software change for this of some sort, or the tab should simply say 'article' (as heretical as that may be). --MZMcBride (talk) 01:20, 23 June 2008 (UTC)
function mainPage(){
addPortletLink('p-lang', 'http://meta.wikimedia.org/wiki/List_of_Wikipedias',
'Complete list', 'interwiki-completelist', 'Complete list of Wikipedias')
var nstab = document.getElementById('ca-nstab-main')
if (nstab && wgUserLanguage=='en') nstab.firstChild.firstChild.nodeValue = 'Main Page'
}
if (wgPageName == 'Main_Page' || wgPageName == 'Talk:Main_Page') addOnloadHook(mainPage)
- Well, I support moving the Main Page to the Portal namespace where it belongs, rather than resorting to hacks like this. --ais523 15:06, 25 June 2008 (UTC)
- I recommend moving the main page to Wikipedia:Front Page to make it more human-friendly. This should also work well for other projects that do not have a Portal namespace.
- Also, a JavaScript hack is even more inefficient than the MediaWiki:Nstab-main hack. The code must be sent down to the client computer, parsed, and then executed for every page, rather than being quickly executed on the server side with the client none the wiser. So, if the Nstab-main hack should not be used because of inefficiency, then we should not be using the JavaScript hack either. Furthermore, Google cannot cache the main page correctly if we rely on JavaScript - it will only see "article" and not "main page". —Remember the dot (talk) 05:03, 1 July 2008 (UTC)
- Well, I support moving the Main Page to the Portal namespace where it belongs, rather than resorting to hacks like this. --ais523 15:06, 25 June 2008 (UTC)
- The move has been discussed before and failed to get consensus. I too feel the main page should stay where it is. I don't mind the javascript; it is fully cached server- and client side, so there should be no performance hit. It also seems to be the establiched practice across projects. — Edokter • Talk • 13:40, 6 January 2009 (UTC)
- Another 'hack' the developers could implement is MediaWiki:Nstab-mainpage variable. — Edokter • Talk • 13:42, 6 January 2009 (UTC)
- The JavaScript has to be executed on every page load. That is a performance hit, consuming more resources than the nstab-main hack that the developers rejected for performance reasons. The developers have also explicitly told us that they will not create a special message for the main page's tab. Hacks are bad ideas in general, this one is no exception. —Remember the dot (talk) 18:06, 6 January 2009 (UTC)
- That is completely incorrect. JavaScript is performed by the client browser; any 'performance' hit would apply to the browser, not Wikimedia. The 'performance' overhead of a browser's javascript module executing two if() comparisons on two static variables is truly infintesimal (on the order of a few microseconds), and what's more, those queries are currently run anyway by the code. The part of the code that actually performs any actions runs only on the main page. The only possible performance impact is in the increased code size; the extra line adds about 150 bytes, pre compression, to the output files, which are cached for 30 days in browsers and so are only transmitted in a tiny fraction of cases. Happy‑melon 18:21, 6 January 2009 (UTC)
- All I was trying to say is that the collective performance impact of millions of computers executing JavaScript hacks is almost certainly greater than the Wikimedia servers executing a parser function. You do have a good point though that since we're already using JavaScript to change other stuff on the main page, tacking another hack on would not have much of an impact. Still, the JavaScript hack is a really inelegant solution. The problem could be better solved by either moving the main page to a namespace with a more appropriate tab text or editing MediaWiki:Nstab-main to be less specific. We could even ask the developers to cache nstab-main with the page title so that the ParserFunctions workaround didn't hurt performance so much. —Remember the dot (talk) 19:52, 6 January 2009 (UTC)
- That is completely incorrect. JavaScript is performed by the client browser; any 'performance' hit would apply to the browser, not Wikimedia. The 'performance' overhead of a browser's javascript module executing two if() comparisons on two static variables is truly infintesimal (on the order of a few microseconds), and what's more, those queries are currently run anyway by the code. The part of the code that actually performs any actions runs only on the main page. The only possible performance impact is in the increased code size; the extra line adds about 150 bytes, pre compression, to the output files, which are cached for 30 days in browsers and so are only transmitted in a tiny fraction of cases. Happy‑melon 18:21, 6 January 2009 (UTC)
- The JavaScript has to be executed on every page load. That is a performance hit, consuming more resources than the nstab-main hack that the developers rejected for performance reasons. The developers have also explicitly told us that they will not create a special message for the main page's tab. Hacks are bad ideas in general, this one is no exception. —Remember the dot (talk) 18:06, 6 January 2009 (UTC)
- (←) The "collective performance impact" is a bit of a misnomer. This single line of JavaScript has no real impact on any user. It has been here for years and was removed during a cleanup in which some things were removed without need. I see absolutely no problem in including the code, at least until the developers themselves come up with a workaround (if ever). — Edokter • Talk • 22:03, 6 January 2009 (UTC)
- I still think it's a poor solution. —Remember the dot (talk) 16:23, 14 January 2009 (UTC)
- Move the main page to the Wikipedia namespace, thus removing the need for this hack, removing the need for the "Cite this page" (#t-cite) hack in MediaWiki:Monobook.css, removing the need to subtract 1 from the article count, and removing the main page from the list of permanently protected "articles". Or, edit MediaWiki:Nstab-main to be less specific.
- It's not just me that doesn't like the JavaScript hack. Please read the developers' comments on the issue:
- Do keep in mind that with the default messages, there's no problem at all. The default nstab for namespace 0 is "page", which is totally appropriate for the main page. If enwiki wants to create problems for themselves by changing what namespace 0 is supposed to contain and then refusing to actually stick to their decision by leaving the main page there, that's not something we need to consider supporting in software, IMO. If they think the extra X lines of JavaScript are superior to adjusting their other customizations, that's their decision as site admins. Lots of people do stupid stuff with the software -- we don't have to support it just because it happens to be a big wiki.
- —Remember the dot (talk) 17:18, 14 January 2009 (UTC)
- He explicitly called the extra X lines of JavaScript "stupid". In any case the location of the main page is relevant because its location determines the tab text. Were the main page in the Wikipedia namespace, its tab would say "project page" which is perfectly acceptable. —Remember the dot (talk) 17:57, 14 January 2009 (UTC)
- (←) Your interpretation is quite a stretch. The literal quote is "...people do stupid stuff..."; that does not relate to the javascript alone. And since the main page isn't in Project space, and the proposal to move it there has been shot down, it isn't relevant. If and when the page is moved, the code is easily removed. — Edokter • Talk • 18:41, 14 January 2009 (UTC)
- I have to agree with Remember the dot here... I was one of those who commented that the main page should be moved to the project namespace, and personally, I never saw much substance in the opposition's arguments. Moving the main page would fix oodles of issues, problems, and hacks, while leaving it as-is seems mostly to be from ILIKEIT stubbornness. 「ダイノガイ千？！」(Dinoguy1000) 19:00, 14 January 2009 (UTC)
- I agree that the main page should be moved, but that doesn't appear likely to happen any time soon. So for the time being, let's just get rid of the "article" tab again. It's sloppy and misleads readers. —David Levy 19:41, 14 January 2009 (UTC)
I have re-added the two lines of javascript that compromise this tweak. I third the motion that the Main Page should be moved, but that is entirely tangential to this issue. Happy‑melon 19:55, 14 January 2009 (UTC)