MediaWiki talk:Common.js/Archive 15

Archive 10

←

Archive 13

Archive 14

Archive 15

Scripting errors on external wiki

Sorry for asking this here, but I asked it on MediaWiki.org a couple of weeks ago and never got a reply there. I don't know if there's a better place to ask this on Wikipedia, if there is, feel free to move it for me and leave a note on my talk page. Anyway, for awhile now, I've been having trouble with the Javascript on an external wiki that I help maintain. IE complains of two scripting errors ('wgBreakFrames' is undefined on line 55, and 'tooltipAccessKeyRegexp' is null or not an object on line 533), and they seem to be preventing Common.js from executing. The wiki is currently running MediaWiki 1.11.0 (upgraded directly from 1.6, if that affects things) on PHP 5.1.4 (cgi-fcgi) with a MySQL 4.1.20 database ([1]). Any help? —Dinoguy1000 18:17, 24 June 2008 (UTC)

I think you upgrade didn't went 100%. wgBreakFrames was an error that was fixed in MediaWiki 1.9 I think. So at least some of your files are still from 1.6 it seems. --TheDJ (talk • contribs) 21:54, 24 June 2008 (UTC)

All right, thanks for telling me wat the problem is... so should I try reinstalling 1.11, or just try upgrading to 1.12, or do something else? —Dinoguy1000 16:32, 25 June 2008 (UTC)

editprotected

{{editprotected}} Add this:/** Main Page layout fixes *********************************************************

 *
 *  Description:        Renames the namespace tab from 'Article' to 'Main Page' on
 *                      the Main Page.
 *  Maintainers:        User:AzaToth, User:R. Koot (on Wikipedia)
 */ 

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!
    }
} 

Dagoth Ur, Mad God (talk) 12:16, 25 June 2008 (UTC)

This is already being discussed above. --- RockMFR 14:14, 25 June 2008 (UTC)

Simplified "technical restrictions" fix

I took some time and rewrote the "technical restrictions" fix code. The new version is much cleaner, and features these main advantages:

• The real title banner is cleanly deleted, removing it from screen readers' view.
• Template:Unicode can be used in page titles that use unusual characters.
• It is standards-compliant with the W3C DOM specification.

I did a bunch of testing on the Commons, and the new code appears to work great! However, I wanted to post it here so that others can look it over and spot any remaining problems.

Code

if (wgIsArticle) //prevents the "Editing " prefix from disappearing during preview
{
    addOnloadHook(function()
    {
        var realTitle = document.getElementById("RealTitle")
        if (realTitle.textContent) //everyone but IE
        {
            var realTitleText = realTitle.textContent
        }
        else //IE
        {
            var realTitleText = realTitle.innerText
        }
        
        var normalizedRealTitle = realTitleText.replace(/^_+/, "").replace(/_+$/, "").replace(/[\s_]+/g, "_") //trim leading and trailing underscores and convert double spaces and underscores to single underscores
        var normalizedPageName
        
        //make namespace prefix lowercase and uppercase the first letter of the title
        if (wgNamespaceNumber == 0) //namespace 0 does not have a prefix
        {
            normalizedRealTitle = normalizedRealTitle.charAt(0).toUpperCase() + normalizedRealTitle.substring(1)
            normalizedPageName = wgPageName.charAt(0).toUpperCase() + wgPageName.substring(1)
        }
        else
        {
            normalizedRealTitle = normalizedRealTitle.substring(0, normalizedRealTitle.indexOf(":") + 1).toLowerCase() + (normalizedRealTitle.charAt(normalizedRealTitle.indexOf(":") + 1).toUpperCase() + normalizedRealTitle.substring(wgPageName.indexOf(":") + 2))
            normalizedPageName = wgPageName.substring(0, wgPageName.indexOf(":") + 1).toLowerCase() + wgPageName.substring(wgPageName.indexOf(":") + 1)
        }
        
        if (normalizedRealTitle == normalizedPageName) //normalized titles match, so we can do full replacement
        {
            var h1 = document.getElementsByTagName("h1")[0]
            
            //remove all child nodes, including text
            while (h1.firstChild) 
            {
                h1.removeChild(h1.firstChild)
            }
            
            //populate with nodes of real title
            while (realTitle.firstChild) //the children are moved to a new parent element
            {
                h1.appendChild(realTitle.firstChild);
            }
            
            //delete the real title banner since the problem is solved
            var realTitleBanner = document.getElementById("RealTitleBanner")
            realTitleBanner.parentNode.removeChild(realTitleBanner)
        }
        
        //no matter what, correct the page title
        document.title = realTitleText + " - Wikipedia, the free encyclopedia"
    })
}

—Remember the dot ^(talk) 05:10, 1 July 2008 (UTC)

The current code was added before DISPLAYTITLE magic word was implemented. At this moment the code is mostly used for sub- and superscript in articles names, through Template:Wrongtitle and Template:Downsize. If I'm not mistaken, this makes about 300 articles, or approx 0.01% of all articles. I suggest the code is simply removed from Common.js. —AlexSm 06:14, 1 July 2008 (UTC)

Agreed, support delete as "deprecated". --Splarka (rant) 07:08, 1 July 2008 (UTC)

Disagree. I think 300-400 articles is still worth it. --TheDJ (talk • contribs) 23:13, 1 July 2008 (UTC)

OK, I found and fixed several more bugs and made the code live. The new code is actually much more flexible than the old code because it can handle some interesting cases that the old code couldn't. For example, placing {{wrongtitle|title=___:___A^BC}} in the article ABC would make the title appear as ___:___A^BC. But don't do that, that would be vandalism ;-) —Remember the dot ^(talk) 04:38, 2 July 2008 (UTC)

Well, when developers fix bugzilla:14226 Allow <sup> and <sub> in {{DISPLAYTITLE:}} (and maybe also permit case-insensitive DISPAYTITLE namespaces) then I guess this JS code can be removed. —AlexSm 03:53, 3 July 2008 (UTC)

• Are there any real examples with ___:_ (which could be handled by DISPLAYTITLE) and <sup> at the same time?
• It is inconvenient that the title is not changed on previewing (unlike DISPLAYTITLE)

Coding:

• using huge if {} statements creates big indents and less readable code (should have been simple if (!realTitle) return;
• it's already been suggested before that instead of checking for textContent/innerText one could simply get firstChild.data; ... (removed later, that was a stupid thought —AlexSm 03:53, 3 July 2008 (UTC))

Also, things that can be removed:

• 10-lines explanation that should be moved into Template:Wrongtitle documentation
• duplicate statement var indexOfColon = realTitleText.indexOf(":")
• temporary realPageTitle variable
• 2 semicolons

—AlexSm 18:17, 2 July 2008 (UTC)

Thanks for the suggestions. I doubt there are any articles that combine ___:_ and <sup>. My point was that the code now more closely follows MediaWiki's normalization scheme, so it should be able to handle unusual cases like this if the need arises.

I implemented a couple of your suggestions just now, but I am pressed for time and will have to look into the rest of them later. Thanks again! —Remember the dot ^(talk) 03:39, 3 July 2008 (UTC)

For some reason only just now I realized that the code allows for any HTML, so one can make page title italic, blinking or even partially hiddden (which creates possibility for any user subpage to pretend to be an article), some users might find that a bit too flexible... —AlexSm 03:53, 3 July 2008 (UTC)

Not any HTML. Only HTML that can be used in wikitext is allowed. For example, <script> tags cannot be inserted into the article title, period.

You do have a point about people being able to use <span style="display:none"> to alter page titles somewhat. I suppose we could add regexp checking to disable the script if something like this is present, but I'm not sure it's worth it. What do you think? We do need to be able to add style declarations to titles sometimes, such as using Template:Unicode in a page with an unusual title. This is why I opened up the script to permit CSS styling in the first place. —Remember the dot ^(talk) 05:27, 3 July 2008 (UTC)

fixIEScroll()

Function fixIEScroll() was added into Common.js in 2005. It doesn't have a maintainer, it doesn't have documentation and I doubt anybody knows how it's supposed to work. Previously it was mentioned at MediaWiki talk:Common.js/Archive Jan 2008#Internet Explorer bug fix. Now please do this: open either IE6 or IE7, make your browser window wide enough and visit some random article like Test. Then make your browser window very narrow: there is no horizontal scroll bar even though it's definitely needed. This is a site accessibility problem and I suggest this function is simply removed. Note: when the window is initially narrow enough to have a scrollbar then the scrollbar stays, and the function simply doesn't seem to make any difference. —AlexSm 22:01, 1 July 2008 (UTC)

The function should not be removed just like that, but it should be tested for efeect in IE7 (it is defenitely needed for IE6). — Edokter • Talk • 22:24, 1 July 2008 (UTC)

What is it supposed to correct? The effect that Alex noted also occurs in IE7 (even on articles with an image), I tested it out of curiosity. —Dinoguy1000 22:28, 1 July 2008 (UTC)

What it's doing is pretty easy to tell: it hides the horizontal scrollbar if the page is no more than 3 pixels wider than the window it's being shown in, presumably because something in the MonoBook skin in causing IE to display pages a few pixels too wide. It's supposed to recheck it whenever the window is resized, though, so I'm not sure why the scrollbar isn't showing up when you shrink the window. I have a hunch, and if I'm right it might be that sticking a docEl.style.overflowX = "" statement inside the "else" clause in fixIEScroll() could fix it, but I'm not really able to test that theory myself. —Ilmari Karonen (talk) 23:20, 1 July 2008 (UTC)

Okay, I did some testing and research, see below —AlexSm

• The bug is probably the same as described here. Please do the following on e.g. testwiki:Special:RecentChanges, so the current en.wp code does not interfere. Take IE6 and make your browser window really narrow. Then take it by the lower right corner and slowly make it wider. At some point horizontal (bottom) scrollbar disappears. Keep making the window wider (by little steps) and in normal browsers the scrollbar never comes back. In IE6, however, it's fairly easy to make the scrollbar appear again, especiallly if you also change window height a little.
• What happens: when window becomes wider, there is more room, so the browser unwraps long strings. Unfortunately, IE miscalculates the result by 1 to 3 pixels, and then has to display horizontal scrollbar.
• Current code is supposed to check (on window load and on every resize) the difference between content width and window width, and hide scrollbar if it's less than 4 pixels. However, document.attachEvent("onresize") doesn't do anything, because resize is the event of window object.
• Proposed code, can be tested e.g. in testwiki:Special:Mypage/monobook.js:

//of course, this has to be inside if(IE){...} block
function doFixIEScroll(){
  var d = document.documentElement
  d.style.overflowX = (d.scrollWidth - d.clientWidth < 4) ? 'hidden' : ''
}
document.attachEvent('onreadystatechange', doFixIEScroll)
window.attachEvent('onresize', function(){setTimeout(doFixIEScroll, 1)})

• IE7 is also affected by the bug, but it's much more difficult to make it show scrollbar on a wide window. Personally, I would move the code into /IE60Fixes.js.

—AlexSm 16:50, 10 July 2008 (UTC)

NavFrame 'Show' Symbol versus Arrow

The Wikibooks version of NavFrame uses a simple arrow-to-click instead of a Show/Hide text which takes up much more space than is necessary. Can this be changed by the user? Would it not be better to consider the arrow as a more generic form, independent of language? Regards, WPHyundai (talk) 12:55, 2 July 2008 (UTC)

They can be changed (just for you) by setting string variables collapseCaption (default "hide") and expandCaption (default "show") in your personal monobook.js. I doubt there's gonna be a consensus for sitewide change, I seem to remember this was already proposed and rejected before. —AlexSm 18:19, 2 July 2008 (UTC)

NavFrame has been deprecated in favor of collapsible tables, anyway, hasn't it? (I've actually been meaning to ask if anyone has any idea how many occurences of NavFrame still exist on Wikipedia... It'd be nice to see it removed from Common.js) —Dinoguy1000 18:37, 2 July 2008 (UTC)

It is deprecated for navboxes, not all together. I believe there was some instances where a choice between them could be handy. --TheDJ (talk • contribs) 21:35, 2 July 2008 (UTC)

GA

Can someone add this? This is for good articles.

/** Interwiki links to featured articles ***************************************
 *
 *  Description: Highlights interwiki links to good articles (or
 *               equivalents) by changing the bullet before the interwiki link
 *               into a plus.
 *  Maintainers: User:R. Koot
 */
 
 function LinkGA() 
 {
     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 + "-ga" ) ) {
                 InterwikiLinks[i].className += " GA"
                 InterwikiLinks[i].title = "This is a good article in another language.";
             }
         }
     }
 }
 
 addOnloadHook( LinkGA );

--Nazzzz (talk) 14:23, 4 July 2008 (UTC)

This has been proposed a few times before. I would not be opposed, but it should be integrated in function LinkFA instead of having it's own code. — Edokter • Talk • 14:32, 4 July 2008 (UTC)

/** 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.";
            }
            if ( document.getElementById( InterwikiLinks[i].className + "-ga" ) ) {
                 InterwikiLinks[i].className += " GA"
                 InterwikiLinks[i].title = "This is a good article in another language.";
             }
        }
    }
}

addOnloadHook( LinkFA );

That's what that would look like. However more importantly, this would require the re-creating of {{Link GA}} which is required for this trick to work. That template was deleted because the hacks to Common.js and Common.css to make the template work were not in place. Reading the deletion discussion of the template, seems to indicate that very few people would desire, appreciate and even tolerate, GA indicators for other languages. But you are welcome to try and open a proposal on this. --TheDJ (talk • contribs) 15:46, 4 July 2008 (UTC)

Agree with TheDJ here. At this point, it's not about technical feasibility in the slightest, it's about whether or not the community wants something like this. Current indications are that it doesn't. --MZMcBride (talk) 21:43, 4 July 2008 (UTC)

Mdash in signature button

Section name is changed from "Minor idea". —AlexSm 21:37, 14 July 2008 (UTC)

Probably not the right place to ask this but how bout changing the double dash in the sig function to an mdash? It seems to link a message to the one posting it better. —[DeadEyeArrow – Talk – Contribs] 16:26, 13 July 2008 (UTC)

Note that a user script to do that already exists: Wikipedia:WikiProject User scripts/Scripts/Sigdash. Admittedly it's a bit of a hack, but it works well. —Ilmari Karonen (talk) 17:35, 13 July 2008 (UTC)

Thanks for the script. I'm just wondering if there's objection to making this standard. I couldn't find where the button was in the MW space, so I made the request here where the custom buttons are. —[DeadEyeArrow – Talk – Contribs] 18:01, 13 July 2008 (UTC)

Please don't. Removing the dashes entirely was debated on Bugzilla (bugzilla:12472) where it was determined that longstanding behavior of the button shouldn't change. If there is a consensus to change the button's output, please include an option to retain the two dashes. --MZMcBride (talk) 18:18, 13 July 2008 (UTC)

Heh kay, wasn't gonna be boldly doing it myself. Just an idea after I woke up and redesigned my sig. —[DeadEyeArrow – Talk – Contribs] 18:50, 13 July 2008 (UTC)

Personally, I'd rather just see a request for doubled dashes to be auto-converted to an emdash, but I should probably just keep dreaming... —Dinoguy1000 19:32, 14 July 2008 (UTC)

That would be bugzilla:1485. ; - ) --MZMcBride (talk) 19:36, 14 July 2008 (UTC)

(Not that I support this change) the above Sigdash is overly complicated, a better JS hack would be like this below (in /edits.js) (of course, until devs decide to rearrange the buttons). —AlexSm 21:37, 14 July 2008 (UTC)

if (mwEditButtons.length >= 10) 
  if (mwEditButtons[9].imageId == 'mw-editbutton-signature')
     mwEditButtons[9].tagOpen = '— ~~\~~'

This would be rearrangement proof:

for (var i = 0; i < mwEditButtons.length; i++) {
  if (mwEditButtons[i].imageId == 'mw-editbutton-signature')
     mwEditButtons[i].tagOpen = '— ~~\~~'
}

Incidentally, the reason the sigdash userscript works the way it does is that I wrote it before addButton() was changed to append to the mwEditButtons array instead of adding the button directly, and never bothered to change it afterwards. I agree that yours is simpler. —Ilmari Karonen (talk) 23:14, 14 July 2008 (UTC)

Although, come to think of it, I do foresee a potential problem with execution order: your code only works if it's executed after the addButton() calls but before the window.onload event has fired. Putting it directly in MediaWiki:Common.js/edit.js will probably run it too early, though I haven't actually tested that. Running it via addOnloadHook() should do it — but there seem to be some obscure circumstances where some browsers may only run those hooks during the actual window.onload event. —Ilmari Karonen (talk) 23:28, 14 July 2008 (UTC)

Custom edit button «Insert a table»

I suggest a little correction to the «Insert a table» button:

mwCustomEditButtons[mwCustomEditButtons.length] = {
    "imageFile": "/wiki/images/6/60/Button_insert_table.png",
    "speedTip": "Insert a table",
    "tagOpen": '{| class="wikitable"\n|',
    "tagClose": '\n|}\n',
    "sampleText": "-\n! hdr 1\n! hdr 2\n! hdr 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"};

This way it works both on empty and selected text:

• Selected text will be encased in one-cell table.
• For no selection the sample table appears.

77.41.55.203 (talk) 08:34, 19 July 2008 (UTC)

Good idea. Done. --- RockMFR 08:57, 19 July 2008 (UTC)

Password strength meter

I have created a password strength meter which attempts to estimate the password strength of passwords entered in the new accounts page. It measure the strength differently from other scripts, by calculating the bit strength instead of using a weighted checklist. I would like to see this get loaded by Common.js when on that page. The script can be tested using importScript(), but at the moment it works only in Firefox. — Dispenser 00:05, 27 July 2008 (UTC)

Not too bad. Maybe a little too optimistic though: "fuckyou" and "monkey1", both found near the top of various lists of common passwords, get a rating of "Fair". (By the way: to test the script, go to the signup page, paste "javascript:void(importScript("User:Dispenser/passwdmeter.js"))" into the browser URL bar and hit enter. Then type something in the password field, obviously.) —Ilmari Karonen (talk) 01:11, 27 July 2008 (UTC)

This would go on its own subpage if added. --- RockMFR 01:52, 27 July 2008 (UTC)

I think this is better as a user script. — Carl (CBM · talk) 13:04, 27 July 2008 (UTC)

Er, you do realise that this is for users creating a new account, who by definition don't have access to user scripts?? :D Happy‑melon 20:46, 30 July 2008 (UTC)

I think this could be scary to new users, as silly as that may sound. If implemented, I would like to see it as an optional link that users have to click in order to test their password. And, as with all JS, it needs a nice fallback if the user doesn't have JS enabled (it may now, I haven't tested). --MZMcBride (talk) 13:17, 27 July 2008 (UTC)

Bit strength

Time	Bits
9 h	35
19 h	36
38 h	37
3 d	38
6 d	39
13 d	40
3½ w	41
7½ w	42
¼ y	43
½ y	44
1 y	45
2 y	46
4 y	47
2.7 GHz Apple G5 able to hash and compare 1,000,000 words/sec.

I've changed the dictionary table to include more of the common passwords and increased the required strength at each level as detailed below. The problem with making it voluntary only is people who should be using it are not. The recent news that an administrator had an easily guessed password despite warnings on the login page. This area obviously needs more attention drawn to it. Perhaps users should be scared that the passwords that they have been using are week. At least my sister is thankful now for learning that her passwords were not secure before anything bad happened. And knowing what to avoid when creating her new passwords. — Dispenser 03:57, 28 July 2008 (UTC)

Details

The script divides the character set up into the following parts. It will use the set if any characters are contained in the password.

• etaoinshr (69.56% of letters used in English, see letter frequency)
• dlcumwfgyp (26.73% of letters used in English)
• bvkjxqz (3.71% of letters used in English)
• If one is uppercase double the search space
• 1 (Happens to be the number 2/3 of the time)
• 2-9, 0
• !.,?-_:;#$@*/ (Common symbols)
• The rest of the symbols

It then figures out how many bits are used from the set. Then Multiplies that by the length the password.

This is the follow by to step to check integerty. First, looking for common patterns that are often used to defeat the password mechanism, tacking numbers to the end, capiltizing, containing 19XX or 200X. Second, it reduces bit strength by half if part of the password is found in the (smallish) dictionary.

The final bit strength is pass through a linear function which then output a rating from 0 to 4 on the bit strength of the password.

If users don't have the mininum version of javascript enabled then the meter doesn't appear on the page at all.

Indicator	Rating	Bits ranges		Time to crack
		Old	New	Old	New
Too short	0	-∞ to 26	-∞ to 32	-	-
Weak	1	26 to 32	30 to 35	1.1+ minutes	18+ minutes
Fair	2	32 to 38	35 to 40	1.2+ hours	9+ hours
Good	3	38 to 44	40 to 45	3+ days	13+ days
Strong	4	44 to +∞	45 to +∞	½ years	1 years

Thanks for writing that explanation. It's worth noting, of course, that the bit strengths are just guesstimates based on the assumption that an attacker will use similar guessing techniques as the script does. If they come up with something the script doesn't currently check for, such as correctly guessing that your password is based on your username spelled backwards with a few numbers tacked on the end, they may be able to easily guess passwords that the script rates as safe. Thus, the strength estimates from the script should be considered lower bounds only.

Also, the relationship between bit strength and expected time to guess the password depends on the resources of the attacker: if they have a fast computer and direct access to the password hashes, they can try several orders of magnitude more passwords per second than if they have to actually try logging in to Wikipedia to test each password. Fortunately, these two effects somewhat cancel each other out: if you rate the passwords based on the assumption that the attacker has direct access to the hashes, that will provide some margin of safety also against attackers who don't have such access but who do a better job of guessing common passwords than the script does. Of course, an attacker who's good at guessing and has access to the hashes may still pwn you, but we can hope that won't happen.

By the way, I'd like to see the script also work on the password change form in Special:Preferences. Shouldn't be too hard to implement. —Ilmari Karonen (talk) 04:33, 28 July 2008 (UTC)

The preferences thing was added in today's update. I was thinking about using AJAX/JSON contacting the Toolserver which would be running something like john the ripper, but security issues like with if the software was comprised an attacker could look at the timestamps and match it with the new accounts created around those times. Its possible use search queries on Wiktionary instead. While not as comprehensive as the Toolserver app would provide a larger dictionary than the 20 K JavaScript one. Thought I don't know how this would affect the server load, if at all. — Dispenser 05:34, 28 July 2008 (UTC)

Hushmail has a very nice pw-strength meter that actually changes (weak>medium>etc.) as the new user types more characters into the proposed pw. You can try it out without signing up or even entering a username. [2] Maybe they would share the source code, or license it very cheaply to a non-profit like WP. (Or you could put "password strength meter courtesy of Hushmail" and a link, but that's getting close to "advertising".) It could also be either automatic or voluntary for existing users. Yes, JS must be enabled to use Hush's meter, but that could be explained, and that you can re-disable JS after completing the pw test. Anyway, check it out. Regards, Unimaginative Username (talk) 21:22, 28 July 2008 (UTC)

As far as I'm aware, Common.js and Monobook.js don't load on Special:UserLogin to prevent mischief and abuse. Though, surprisingly Gadgets are imported. --MZMcBride (talk) 20:54, 30 July 2008 (UTC)

Actually they do. User custom JS (from e.g. "User:YourUserName/monobook.js"), however, does not (since r22008), which is exactly why testing this requires pasting the importScript() line into the URL bar. —Ilmari Karonen (talk) 07:25, 31 July 2008 (UTC)

There's a password strength meter thinggy in some versions of PGP (almost all of which are open source, but some are commercial). You might take a peak at those for some ideas on how they calculate "strength." --slakr^\ talk / 07:34, 31 July 2008 (UTC)

From a cryptographic point of view, attempting to measure the strength of a user generated password is somewhat dubious. Certainly checking against standard dictionaries and common password lists is worthwhile as is doing the same thing after stripping one or two non-alphabetic characters. Also length less than 8 characters should be flagged. Going much beyond that is questionable as users tend to game such tests in relatively predictable ways. I certainly wouldn't attempt to predict time to break a password.

I'd rather see effort toward fixing more glaring security problems, such as using secure login as the default and making sure hashed passwords are well protected.--agr (talk) 08:57, 5 August 2008 (UTC)

I'd would like to thank all that have participated in the discussion and those that have emailed me. As McBride and Karonen have pointed out the original vision cannot be used. I will continue my work when I have the opportunity at User:Dispenser/passwdmeter with more mathamtical based foundation. Hopefully at some point release a MediaWiki extension which will allow quering a server side ditionary and other things that can't be done effectively in JavaScript. — Dispenser 02:26, 2 September 2008 (UTC)

Wikibits.js

Why isn't there a similar page as this one for "wikibits.js"? MediaWiki:Wikibits.js is completely blank. SharkD (talk) 02:01, 17 August 2008 (UTC)

wikibits.js, edit.js, etc. are MediaWiki JS files, they're the same for all MediaWiki installations and only devs can change their content. MediaWiki:Common.js is a local (for any particular installation, such as English Wikipedia) system message that can be edited by local admins. —AlexSm 03:50, 17 August 2008 (UTC)

What's the best way to propose/submit modifications to this file? SharkD (talk) 03:57, 17 August 2008 (UTC)

Register at bugzilla and file a request; see Wikipedia:Bugzilla. —AlexSm 04:05, 17 August 2008 (UTC)

Is there a way to at least create the page MediaWiki:Wikibits.js, even if the code itself is left in read-only mode? I would like there to be a centralized location to discuss this file, like there is for Common.js. SharkD (talk) 00:46, 22 August 2008 (UTC)

Bypassing your cache

The note at the top of MediaWiki:Common.js/edit.js and MediaWiki:Common.js is not accurate for the Firefox browser.

A better version of this type of top note can be found here: commons:MediaWiki:CollapsibleTables.js

Here is a template I just created: Template:Bypass your cache

I created it by copying the top note from commons:MediaWiki:CollapsibleTables.js. I don't know if it is all accurate. The Firefox info about Shift-Reload is correct. It worked for me today.

Feel free to categorize the template better. I don't understand the template category tree very well.

The template note can be added to pages with

{{Bypass your cache}}

Just copy and paste it to the top of the relevant pages.

It produces this:

Note: After saving, you have to bypass your browser's cache to see the changes. Internet Explorer: press Ctrl-F5, Mozilla: hold down Shift while clicking Reload (or press Ctrl-Shift-R), Opera/Konqueror: press F5, Safari: press Cmd-Opt-E.

Feel free to edit it further. --Timeshifter (talk) 15:36, 20 August 2008 (UTC)

I've corrected the Firefox instructions. Thanks for the heads up. --- RockMFR 16:52, 20 August 2008 (UTC)

Great! After I created the template I thought that maybe there is already a transcluded doc page for the note on the 2 pages. How does one find the transcluded pages for the note at the top of MediaWiki:Common.js/edit.js and MediaWiki:Common.js? Is the same transcluded doc page used for the note on both pages? --Timeshifter (talk) 17:41, 20 August 2008 (UTC)

That would be MediaWiki:Clearyourcache (why can't it be named something slightly more intuitive, like "Bypassyourcache" or something?). —Dinoguy1000 17:46, 20 August 2008 (UTC)

Thanks. Is there any reason the doc is in protected space? It is only text. --Timeshifter (talk) 19:16, 20 August 2008 (UTC)

Because "bypassing the cache" is a misnomer as it would mean loading the old cache copy after you bypassed it. And it protected since it is in MediaWiki message namespace. — Dispenser 20:26, 20 August 2008 (UTC)

Thanks. Can it be moved out of MediaWiki message namespace? I don't know about the naming. I was going by Wikipedia:Bypass your cache. I guess it makes more sense though to say "clear your cache" since the old cache for that particular page is being cleared, and not just being bypassed once. --Timeshifter (talk) 20:33, 20 August 2008 (UTC)

We could always move/copy it to the Template: namespace and replace the content of the interface message with a transclusion of the template (i.e. "{{Clearyourcache}}") if we wanted. Then again, it is part of MediaWiki's user interface, and so not really something we want to turn into a potential vandalism target. And it's not like it's likely to need editing very often. All in all, I'd recommend just leaving it as is and using {{editprotected}} for any future changes that need to be made. —Ilmari Karonen (talk) 22:53, 20 August 2008 (UTC)

OK. I added {{permprot}} to MediaWiki talk:Clearyourcache. I like to see more and more pages opened up to editing. It could be moved to template space and only semi-protected. The template I just created could be adapted for use. I doubt it would be vandalized since most users wouldn't know how to find the doc page. I am curious. How exactly does one figure out what is transcluded into MediaWiki:Common.css. I don't see anything in the source code that looks like it is used to transclude MediaWiki:Clearyourcache. --Timeshifter (talk) 03:44, 21 August 2008 (UTC)

(reset indent) Well, you can search Special:AllMessages and try to find the relevant text. Other than that, you pretty much have to look at the actual code for MediaWiki. --- RockMFR 07:52, 21 August 2008 (UTC)

Thanks. I don't see anything at Special:AllMessages that indicates transcluded pages. I found "Clearyourcache" on that page but it doesn't say what pages it is transcluded in. I also looked for "Clearyourcache" in the code for these pages: MediaWiki:Common.js/edit.js, MediaWiki:Common.js, and MediaWiki:Common.css. All 3 have the same improved caching note at the top of their pages, but I don't see anything in their code that indicates the transclusion of that note. I used my Firefox browser page search to look for "Clearyourcache" in the code for all those pages and found nothing. How does transclusion work on these type of MediaWiki pages? How are they transcluding MediaWiki:Clearyourcache? --Timeshifter (talk) 11:31, 21 August 2008 (UTC)

The transclusion happens server-side, before the page ever gets shipped off to your browser, and as you found out, it doesn't leave any traces that can be used to identify it. This is something that has annoyed me, too, and it would be nice if the devs added a feature for seeing what system messages get transcluded onto a given page - the only reason I can see to hide it is for fear of vandalism, and with the whole namespace protected, that becomes a moot point. Also, I think your addition of {{permprot}} to MediaWiki talk:Clearyourcache was inappropriate. Reading the template, it's pretty obvious that it's meant to be used on pages that have been permanently protected for vandalism or similar reasons. However, all pages in the MediaWiki: namespace are protected by default, so there's no reason to use a template to indicate this (and besides, we have a different template specifically for MediaWiki pages). —Dinoguy1000 16:52, 21 August 2008 (UTC)

Thanks for the explanations. I did not know of {{Explanation}}. I agree it is better than {{permprot}}. How do people figure out what is transcluded? Is it in the HTML code? It would be nice to know the transclusion pages so that people can go to their talk pages to make comments. --Timeshifter (talk) 17:57, 21 August 2008 (UTC)

AFAIK, there currently is no sure-fire way unless you care to spend the day rooting around in MediaWiki's source. Some of the messages have backlinks to their original page (mostly those that serve as headers on special pages), but obviously, this can't be done on the vast majority of messages. Ultimately, at this time figuring out what messages are used depends on how persistent you are in looking - as I said before, there's currently no way to get a list of them or anything. —Dinoguy1000 19:11, 21 August 2008 (UTC)

Disambig editintro

{{editprotected}} We had a discussion at Wikipedia talk:WikiProject Disambiguation/Archive 10#Template to caution against frequent mistakes (and previously WP:VPT), and came to the strong consensus that the {{Disambig editintro}} template is a good idea.

[It's a template that only appears in edit-mode (just like MediaWiki:Talkpagetext), at the top of any page tagged with one of the disambiguation templates, to warn against the most common disambig-styling mistakes.]

The code is well-tested (works properly, no false-positives found).

1. Please add the code in User:RockMFR/disambigeditintro.js to MediaWiki:Common.js/edit.js
2. Please protect (edit=autoconfirmed;move=sysop) the template {{Disambig editintro}}

Much thanks. -- Quiddity 17:51, 21 August 2008 (UTC) -- Details discussed with Remember the dot, and request updated. -- Quiddity (talk) 17:41, 23 September 2008 (UTC)

Done. Added maintainers and comments as well. Though, I'm not sure you wanted this in /edit.js.... --MZMcBride (talk) 17:56, 23 September 2008 (UTC)

Remember the dot told me (at "discussed" link above): "Scripts related to editing and editing only should be placed into MediaWiki:Common.js/edit.js. That way, the script is only downloaded if the user tries to edit a page, so pages load faster for ordinary readers that don't need the scripts." That sounded logical to me. Feel free to change it if it's wrong. :)

Thanks again. -- Quiddity (talk) 18:25, 23 September 2008 (UTC)

I've reverted for the moment. The namespace check should probably go outside of the addOnloadHook and the code should use getElementsByTagName('a')[0] (or so I've been told). Also, putting code in /edit.js means that it will only be loaded when the action is &action=edit or &action=submit, but the code looks like it is intended to work on &action=view. So it will either have to go into the main Common.js page or we could perhaps make a /view.js page. --MZMcBride (talk) 18:33, 23 September 2008 (UTC)

Yeah, I was just about to add on this bug report: Hmmm, it does appear to be half-broken. If I edit a disambig page it doesn't appear, but if, from that "editing..." page I again click "edit this page" it does then appear. Would this be fixed by moving the code up into the common.js?

I'm not a js wrangler, and RockMFR abandoned me (woe!), so any assistance you can provide would be much appreciated (by all of the disambig cleanup folks!). -- Quiddity (talk) 18:38, 23 September 2008 (UTC)

Yes, such code should be simply in Common.js. After some little improvements (for example, since we check namespace in any case, it makes sense to check it first, so the script terminates faster on non-articles) I would like to suggest this code:

/** Disambig editintro ********************************************************
 *
 *  Description: Adds an editintro on disambiguation pages. Original code
 *  located at [[User:RockMFR/disambigeditintro.js]].
 *
 *  Maintainers: [[User:RockMFR]], [[User:Quiddity]]
 */

if (wgNamespaceNumber == 0) addOnloadHook(function(){
 if (!document.getElementById('disambig')) return
 var el = document.getElementById('ca-edit')
 if (el) el = el.getElementsByTagName('a')[0]
 if (el) el.href += '&editintro=Template:Disambig_editintro'
})

—AlexSm 19:13, 23 September 2008 (UTC)

Ah, I see now. The script appends "&editintro=Template:Disambig_editintro" to the "edit this page" link. Yes, this will have to go in Common.js after all because the link needs to be edited when the page is viewed. —Remember the dot ^(talk) 19:39, 23 September 2008 (UTC)

Can we try out/verify AlexSM's code? (It works in my own monobook.js). Should I re-add the editprotected? -- Quiddity (talk) 20:00, 26 September 2008 (UTC)

Added. --MZMcBride (talk) 04:54, 1 October 2008 (UTC)

Howdy - I notice that the intro does not appear when editing a section, only if editing the entire article. Is this a known issue? Regards, NapoliRoma (talk) 16:00, 2 October 2008 (UTC)

Yes, it is expected issue with the current approach, and imho it's not something that can be fixed easily. —AlexSm 16:40, 2 October 2008 (UTC)

"My sandbox" link for the personal tools menu

We have had a discussion over at Wikipedia:Village pump (technical)#Proposal: add "my sandbox" link to top navbar. (See that discussion for the details why we need this and why it needs to work like this.)

We want to add a "my sandbox" link for logged in users in the personal tools menu at the top of the page. And a "sandbox" link for IP users.

I am not really a javascript programmer but with some reading up and the help of a code example from Ilmari Karonen, here is the code I want to add to MediaWiki:Common.js:

/** The "My sandbox" and "Sandbox" links ****************************
 *
 *  Description: Adds a "My sandbox" link to the personal tools menu 
 *  for logged in users, and a "Sandbox" link for the IP users.
 *
 *  Maintainers: [[User:Davidgothberg]]
 */

addOnloadHook( function () {
    if( wgUserName ) {
      addPortletLink( 'p-personal', wgArticlePath.replace("$1", "Special:Mypage/sandbox"), 'My sandbox', 'pt-sandbox', 'Your personal sandbox', null, document.getElementById('pt-preferences'));
    }
    else {
      addPortletLink( 'p-personal', wgArticlePath.replace("$1", "Wikipedia:Sandbox"), 'Sandbox', 'pt-sandbox', 'A sandbox where you can experiment' );
    }
  }
);

I would like if you guys could sanity check the code. And I would like advice on where in MediaWiki:Common.js I should add it. That is, is there some special load order I should take into consideration?

This code runs fine from my user space. And I am aware of that it will only be able to create the links in some skins.

--David Göthberg (talk) 20:21, 1 September 2008 (UTC)

I strongly object to adding this to Common.js. This is the perfect thing for a Gadget or a personal JS page. But adding a link for all registered users to a sandbox that most of them don't have is silly, clutter-y, and unnecessary. I don't see any consensus on the technical village pump or elsewhere for a change, as well. --MZMcBride (talk) 22:47, 1 September 2008 (UTC)

MZMcBride: Now you are being illogical. This would be worthless as a gadget since it is meant for the beginners, and they have no idea about gadgets. If there should be a gadget then it should be for experienced users to turn off the "my sandbox" link, not for beginners to turn on the link. That was an idea, we should perhaps add a variable to the code so people can set "mysandbox=false;" in their monobook.js.

And the only one who was opposed in the discussion at the village pump was you. Almost all were very positive, with some not expressing their view clearly. That is a pretty clear consensus.

--David Göthberg (talk) 23:08, 1 September 2008 (UTC)

You're misunderstanding the purpose of the technical village pump. The original post was about adding a link to the top of bar at the top, and people have commented on ways that that could be implemented from a technical perspective. Gadgets and other forms of JavaScript are the obvious solution in this case, as was discussed at VP/T. However, nine people commenting on the technical feasibility of adding a new link does not mean that the interface (that has remained pretty much the same for years) should be changed for tens of thousands of users. We have a village pump for proposals. We also have WP:CENT and noticeboards to alert people of an ongoing discussion. Use those, build a consensus, implement an off switch, and then feel free to add the code. But let's not pretend that the few people who commented from a technical perspective should be deciding matters for everyone.

On a side note, some type of explanation of what the purpose and use of a sandbox is (perhaps an editnotice-type thing) would be a very wise feature to add to this if the link is added to the toolbar. --MZMcBride (talk) 00:25, 2 September 2008 (UTC)

Probably be better as an addition to the sidebar. And why not let anon users create subpages? Then it wouldn't need any javascript. Anyway, if consensified, suggest using slightly more compact version of code, such as http://p.defau.lt/?WnIQiA6VoWmiFGMEWMM5cg --Splarka (rant) 08:34, 2 September 2008 (UTC)

MZMcBride: As you very well know gadgets don't work for IP users. And I repeat: The sandbox link is especially useful for beginner editors who have no idea about gadgets yet. But you are right that this should perhaps be discussed and announced more before deployed.

Splarka: As I have already explained to you at the Village pump: "Yes, Special:Mypage/sandbox works for IP users too. But that would mean after a year or so we would have perhaps a million IP user sandboxes, some of which might hold pretty nasty content. And some search engines do index all pages on Wikipedia..."

Every now and then we have to delete some revisions of the Wikipedia:Sandbox to get rid of defamatory or otherwise very nasty edits there.

And regarding your more compact code: It has the wrong link name and tooltip description for IP users. They should not have the link name "My sandbox" and the tooltip description "Your personal sandbox" since we send them to a public sandbox. Instead they should have something like "Sandbox" and "A sandbox where you can experiment". If you correct that then your code won't be more compact, apart from that you use less indentation and a more compact syntax for the if-case. (Which some of us think is bad coding since it is less readable for other programmers.)

And exactly why did you place your code example on an external site? Some logged in users refuse to follow such links since that gives you the opportunity to log their IP number and there might even be malicious code on the external site. Oh, I just looked, there actually is some kind of tracking script on your external page. Ouch.

--David Göthberg (talk) 12:55, 5 September 2008 (UTC)

Nitpicky. "It has the wrong link name and tooltip", so it could be made neutral. "And exactly why did you place your code example on an external site?"... it is a fast pastebin, and because filling up discussion pages with suggested revisions of code is very annoying. "there actually is some kind of tracking script on your external page. Ouch.". Yes, now Domas Mituzas knows where you are. Run away. --Splarka (rant) 07:22, 9 September 2008 (UTC)

No, David Göthberg understands the purpose of the proposal perfectly. The proposal is to change the behavior for everyone, especially novice users. The proposal is not simply for tips on adding gadgets and other such things. SharkD (talk) 22:08, 9 September 2008 (UTC)

Hide/show link using too much space

The HTML element containing the 'hide/show' link in collapsible tables has a width of 6em. Is there a way we could reduce this to closer to 3em? Thanks. SharkD (talk) 02:36, 11 September 2008 (UTC)

wgPageName == "Special:Upload"

Edittools appear on the file upload form, so the new version wasn't being imported because the edittools are located at /edit.js and the upload form doesn't specify an edit or submit action. As a quick fix, I added an or statement to make /edit.js import on "Special:Upload" which has resolved the issue. If there's a better way to implement the fix, feel free to implement it. --MZMcBride (talk) 03:35, 11 September 2008 (UTC)

Secure upload link

I've removed the "secure upload link fix" section -- bugzilla:10843 is now fixed server-side. Correct link no longer relies on JavaScript, and my local test wikis won't give me Wikipedia's upload link when I'm testing Wikipedia JS locally. :) --brion (talk) 22:32, 16 September 2008 (UTC)

Extending the collapsible tables module

Further to discussion at Template talk:Tmbox (here, for reference), it has been suggested that a small extension to the collapsible tables module would improve its flexibility and reduce direct human workload in some circumstances (firstly maintaining WikiProject banners). Currently there are two ways to make a table collapse by default: adding class="collapsible collapsed", to collapse it all the time, or to add class="collapsible autocollapse", to collapse it when there are more than a threshold number of collapsible tables on a page. Essentially what is proposed is a third method of invoking the functionality: to collapse a table when it is contained within another object of a specific class. Something along the lines of the following:

{| class="collapsible outercollapse"
|Foo
|-
|
{| class="collapsible innercollapse"
|Bar\
|}
|}

Would cause the inner table to be collapsed by default, while the same inner table on its own would not be collapsed by default. Is this possible? (also)Happy‑melon 14:24, 24 September 2008 (UTC)

Are there any guidelines/recommendations about when we should vs. should not use the hidden-collapsible section code? I've listed a few relevant links, and asked for further details at Wikipedia:Village pump (technical)#When to use hidden/collapsible sections - advice/input there would be appreciated. -- Quiddity (talk) 20:05, 26 September 2008 (UTC)

Not really no, except that the pure javascript version is infinitely preferred to the CSS/JS system for all the reasons mentioned in that thread. Happy‑melon 20:14, 26 September 2008 (UTC)

Ok, I have now written code to achieve this (I surprised myself with how achievable it was!). See diff (also showcasing the new visual diff system that's presumably coming soon!) for added code. I'd appreciate it if someone who's not a complete javascript amateur like myself could take a look and make sure it's not going to take ten minutes to process a large page or something. Happy‑melon 20:14, 26 September 2008 (UTC)

In the absence of any comments, I've tested and found my own mistakes :D; I've now added the correct version to the live script. Hope I didn't break anything! Happy‑melon 10:41, 29 September 2008 (UTC)

Anonnotice during December

Generally during December, we disable the anonnotice (the small text that appears above the tabs for anonymous users) so that the large CentralNotice donation banner is the only one anonymous users are forced to suffer. Last year we forgot to re-enable the anonnotice for several months, so my thought is that we add "new Date().getMonth() != 11" before the addOnloadHook so that it does not display in December. Thoughts?

Also, MediaWiki:Monobook.js is no longer deprecated. Perhaps the code should be moved there? --MZMcBride (talk) 05:16, 28 October 2008 (UTC)

I never really understood why we called Monobook.js "deprecated" in the first place... Either way, this seems like a sensible solution to make sure we don't forget to turn it back on... Happy‑melon 14:07, 28 October 2008 (UTC)

The anonnotice (MediaWiki:Anonnotice) is the sitenotice text that appears in place of the regular sitenotice for non-logged in users, so you might want to change your terminology to avoid conflicting. :)

Perhaps you should just disable it when a sitenotice is present. The exact schedule of the fundraiser is not known, but it should be starting circa November 3 and running through.... January sometime? Tends to be a bit open-ended. --brion (talk) 17:46, 28 October 2008 (UTC)

In that case, it should probably just check:

if(wgUserName == null && skin == 'monobook') addOnloadHook((function (){
    if(window.siteNoticeValue || window.wgNotice) return;

This assumes that CentralNotice _will_ use the normal sitenotice variables. No guarantees this will work since it seems to keep changing.

Also, I was told there was a month to plan. So with 30 day JS cache this'd be kinda useless. Nov 3 is less than a week away. There is no way to fix this other than to change the URI of the call to site js. Heh. --Splarka (rant) 03:55, 29 October 2008 (UTC)

Okay, just got verification from brion, the global will be called wgNotice so the above code is appropriate. Should probably be implemented ASAP. --Splarka (rant) 19:41, 1 November 2008 (UTC)

The code has been updated and moved to MediaWiki:Monobook.js. --MZMcBride (talk) 19:57, 1 November 2008 (UTC)

Javascript caching time

I know that Wikipedia sets the CSS pages to cache in the web browsers for exactly 31 days, or as my web browser states it: 2678400 seconds. But does someone know exactly for how long the javascript pages are set to cache? I would like to document that in Wikipedia:Catalogue of CSS classes#CSS caching is !important, since that question comes up every now and then.

--David Göthberg (talk) 22:33, 28 October 2008 (UTC)

It can be ambiguous: [3] max-age=2678400 or [4] max-age=2592000 (or even both) depending. There are some server-side cache control hacks on Wikimedia. --Splarka (rant) 03:31, 29 October 2008 (UTC)

Thanks Splarka. Oh, nice link to that web-sniffer.net service! I was too lazy to find and install my old snooping web-proxy to check the headers.

The two max-age numbers are in seconds which gives either 30 days or 31 days caching time. So to be on the safe side, and since the difference is only a day anyway, let us assume that some users won't see our changes until 31 days have passed.

The CSS files used to have 30 days caching, but was changed to 31 days some months ago. I now checked using the web-sniffer.net service: Some of the CSS files have 30 days and some have 31 days, and some are marked with both times. I guess the javascript files used to have 30 days too, but the server admins were sloppy when they raised it to 31 days. They perhaps changed it by accident, since it would be weird to change it by just one day like that.

--David Göthberg (talk) 15:05, 29 October 2008 (UTC)

Reminds me: bugzilla:14902 PHP/5.2.1 servers returning dual max-age headers on action=raw. --Splarka (rant) 18:12, 29 October 2008 (UTC)

Improvements

if ( wgUserGroups ) {
    addOnloadHook(function(){
        for ( var g = 0; (wgUserGroups[g]); ++g ) {
            if ( wgUserGroups[g] == "sysop" ) {
                if ( !window.disableSysopJS )
                    importScript( "MediaWiki:Sysop.js" );
                importStylesheet('MediaWiki:Sysop.css');
                break;
            }
        }
    });
}

It loads sysop.css separately allowing us to moves common.css code to sysop.css.

To improve loading it checks if an element exists rather than comparing the pricey length property to the index. This should be changing in other places as well.

While pursing I noticed that uploadwizard_newusers should be included in the /edit.js. But still could be done better by creating a autoconfirmed or anonymous CSS files. — Dispenser 20:57, 1 November 2008 (UTC)

I compared the code above with the current code. I concur with this new code, it is an improvement.

--David Göthberg (talk) 23:15, 1 November 2008 (UTC)

Personally, I would prefer

if (wgUserGroups)
  if (wgUserGroups.join('').indexOf('sysop')!=-1)
    importScript('MediaWiki:Sysop-intro.js')

which would make the code shorter for most of us :) —AlexSm 15:33, 4 November 2008 (UTC)

The join looks like a good idea, but if i remember correctly, it was usually more efficient to have all conditionals for loading in this file, instead of in an imported file. So i would keep the window.disableSysopJS and the importStylesheet in Common.js --TheDJ (talk • contribs) 16:20, 4 November 2008 (UTC)

Yes, I too think the join looks like a good idea. (Provided it works in all browsers, I'll test that in my old browsers later on.)

And I think AlexSm is on to something. It is good if the addOnloadHook() function does not run for non-sysops. But we don't need the extra "MediaWiki:Sysop-intro.js" file that AlexSm seems to be suggesting. Instead we could move the "if(!window.disableSysopJS)" and "addOnloadHook()" code to MediaWiki:Sysop.js. Something like this:

Code for MediaWiki:Common.js:

if ( wgUserGroups )
  if ( wgUserGroups.join('').indexOf('sysop') != -1 )
    importScript('MediaWiki:Sysop.js');

Code for MediaWiki:Sysop.js:

importStylesheet('MediaWiki:Sysop.css');

addOnloadHook( function() {
  if ( !window.disableSysopJS ) {

    //Put all the existing MediaWiki:Sysop.js code here.

  } //End if(!window.disableSysopJS)
} ); //End addOnloadHook()

I think that would be the most efficient code for almost all users. Only the handful of admins that have set "window.disableSysopJS = 1;" will have it slightly less efficient than before.

Note that I here have changed the load time for the MediaWiki:Sysop.css, in my code above it loads before the page load, which I think it should. If we need it to load inside the addOnloadHook() function then we can fix that too.

--David Göthberg (talk) 17:43, 4 November 2008 (UTC)

Just want to make sure, "disableSysopJS = true" will still work in my /monobook.js with this new code, right? --MZMcBride (talk) 18:19, 4 November 2008 (UTC)

MZMcBride: Oops, thanks for catching that bug. I bet you know the answer and are just slightly teasing me so I have to check for my self. I forgot about the load order of the javascript files. You are right, the "if(!window.disableSysopJS)" code must go inside the "addOnloadHook()". Since MediaWiki:Common.js (and thus MediaWiki:Sysop.js) is loaded before the user's /monobook.js. So we must wait to check the "if(!window.disableSysopJS)" until after the user's /monobook.js has been loaded.

I have now fixed that in my code above, instead of adding yet another code example here.

--David Göthberg (talk) 19:12, 4 November 2008 (UTC)

I ran some tests in my user space and I can confirm that the code "if(wgUserGroups.join('').indexOf('sysop')!=-1)" works in all three of my browsers: Firefox 2, Opera 9.02 and even in my very old IE 5.5.

--David Göthberg (talk) 22:56, 4 November 2008 (UTC)

Changes made to Disambig edinintro

I suggest that these changes made by Animum to "disambig editintro" code (at the bottom of the page) are reverted:

• isArticle is a bad choice, as the code now has to query getElementById() in all namespaces, but doesn't do the job from article history page or while already editing article;
• if (el) was used twice as an additional safety check;
• semicolons are not necessary; in fact, it would be better to remove them everywhere else.

—AlexSm 16:16, 4 November 2008 (UTC)

Reverted. Did I miss the memo where we can do whatever we want to the global JS files today without discussion? ;-) --MZMcBride (talk) 17:49, 4 November 2008 (UTC)

Topbar content

Whenever a sitenotice or CentralNotice is enabled, it causes the 'topbar content' (the featured content star, the "Spoken Wikipedia" icon, and the coords) to overlap with the banner due to the use of absolute positioning. Using JavaScript, we can correct the locations of this 'topbar content'. The code found below changes the topbar content to position itself relative to the <h1>.

If a user has JavaScript enabled, it will move the icons appropriately. If a user has JS disabled, they'll (a) not be able to see the donation banner / sitenotice anyway; and (b) the icons will stay where they are currently.

I'm posting here because, barring any serious objections or technical issues, I intend to implement some version of this code in the next few days.

Please review the code and comment on it or change it to make it better. :-) Cheers. --MZMcBride (talk) 07:15, 6 November 2008 (UTC)

Feel free to edit this code box here

/* I Hate Floating Icons, No One Should Ever Rely On the h1.firstHeading Location, version [0.0.0]
Originally from: http://en.wikipedia.org/wiki/User:Splarka/topiconfix.js
 
This is a dirty dirty hack. A much more comprehenstive and all-skin-encompassing solution should be worked out.
But not by me. Ugh.
 
This checks for 
* No sitenotice
* h1.firstHeading
** id="coordinates"
** id="protected-icon"
** all class="topicon"
And then removes the things giving it vague h1.firstHeading positions and inserts them into the h1 simply floating.
 
This encompasses the following templates (which will break when anything changes in them):
* [[Template:Coor at d]] [[Template:Coor at dm]] [[Template:Coor at dms]] [[Template:Coor title d]] 
* [[Template:Coor title dm]] [[Template:Coor title dms]] [[Template:Core article]] [[Template:Featured article]] 
* [[Template:Featured list]] [[Template:Featured portal]] [[Template:FeaturedPicture]] [[Template:FeaturedPictureSet]] 
* [[Template:FeaturedSound]] [[Template:Pp-meta]] [[Template:Pp-meta/sandbox]] [[Template:Spoken Wikipedia boilerplate]] 
*/
 
if((wgAction == 'edit' || wgAction == 'view') && wgNamespaceNumber > -1) addOnloadHook(fixTopiconSucky)
function fixTopiconSucky() {
  if(!document.getElementById('siteNotice') && !window.siteNoticeValue && !window.wgNotice) return
  var h1 = getElementsByClassName(document,'h1','firstHeading');
  if(h1.length == 0) return //lol wut
  h1 = h1[0];
 
  var coord = document.getElementById('coordinates');
  if(coord) {
    appendCSS('h1.firstHeading #coordinatesH1 {border: none;background: none;float: right;margin: 0.0em;padding: 0.0em;line-height: 1.5em;text-align: right;text-indent: 0;font-size: 45%;text-transform: none;white-space: nowrap;}')
    var nc = coord.cloneNode(true);
    coord.parentNode.removeChild(coord);
    nc.id = 'coordinatesH1';
    h1.appendChild(nc); // stick at the end
  }
 
  appendCSS('h1.firstHeading .topiconJS {float:right; display: block !important;margin-right:4px;}')
  var prot = document.getElementById('protected-icon');
  if(prot) {
    var np = prot.cloneNode(true);
    prot.parentNode.removeChild(prot);
    np.style.position = '';
    np.style.right = '';
    np.style.top = '';
    np.className += ' topiconJS';
    try { 
      h1.insertBefore(np,h1.firstChild);
    } catch (e) {
      h1.appendChild(np);
    }
  }
 
  var topi = getElementsByClassName(document,'*','topicon');
  for(var i=topi.length-1;i>=0;i--) /* work backwards when removing */ {
    var nt = topi[i].cloneNode(true);
    topi[i].parentNode.removeChild(topi[i]);
    nt.className = nt.className.replace(/topicon/ig,'topiconJS');
    nt.style.right = '';
    try { 
      h1.insertBefore(nt,h1.firstChild);
    } catch (e) {
      h1.appendChild(nt);
    }
  }
}

Just a note, this was written intended for MediaWiki:Monobook.js rather than common (if ever). It is a dirty hack that could be redone much better by editing the templates themselves to standardize them, but that is a headache waiting to happen. --Splarka (rant) 07:42, 6 November 2008 (UTC)

I have a similar script that does something like this for just the coordinates: User:TheDJ/movecoord.js I use it all the time. I didn't even notice they were broken again due to sitenotice until someone told me this morning :D --TheDJ (talk • contribs) 11:48, 6 November 2008 (UTC)

#bodyContent{position:relative;}
.topicon, #protected-icon, #coordinates{top:0!important;}

— Dispenser 14:35, 6 November 2008 (UTC)

Tested and works under Safari 3, Firefox 3 and Opera 9.6 (P.S. added protected-icon). But we have to remember it only works with monobook of course... --TheDJ (talk • contribs) 15:29, 6 November 2008 (UTC)

Also tested to work with IE6. I think we should change top:0 to top:1px perhaps though... Having the elements flat against the line looks weird at times. --TheDJ (talk • contribs) 19:40, 6 November 2008 (UTC)

Dispenser: Can you elaborate a bit more, please? :-) Does your solution only require CSS? Where would you put the CSS and does any other current CSS need to be changed? Is there overlap when coords and the featured content star are used at the same time (e.g., Stuy)? Isn't making the entire #bodyContent relatively positioned really dangerous? It seems to me that doing something like that is simply bound to break the layout for people.... --MZMcBride (talk) 18:38, 6 November 2008 (UTC)

This is basically example 4 of this Learn CSS positioning in ten steps. If we set relative positioning on bodyContent, then any (relative/absolute and static) elements within bodyContent will be positioned relative to the top left corner of bodyContent. Basically, whenever you make an element "relative", you reset the coordinate system for any child elements to the position of this element. You have to watch out though that when you do something like this, that basically that if you change left/right/top/bottom of this relative element, it's sibling and parent element will not adapt to that. (see example 2). It looks pretty solid to me. --TheDJ (talk • contribs) 20:36, 6 November 2008 (UTC)

I found a solution for a collision of coord and the icons. Pretty simple actually.

/* sitenotice annoyances */
#bodyContent { position:relative; } 
.topicon, #protected-icon{ position:absolute; top:-2em !important;}
#coordinates{ position:absolute; top:1px !important; }

This also moves the "position:absolute" that all these elements require out of their templates. The !important statements are of course only needed because atm, we need to override the style= of these icons in their current templates. Try using importStylesheet('User:TheDJ/topelements.css); to your monobook --TheDJ (talk • contribs) 21:30, 6 November 2008 (UTC)

I've updated the code at Monobook.js (diff). It will break certain pages that are using position:absolute that don't have class="topicon". Please update any instances that you find. :-) --MZMcBride (talk) 22:50, 6 November 2008 (UTC)

Topbar content (section break 1)

Something should also be done for those of us who use an intro edit link script or the gadget... it drives me crazy seeing icons overlap the link on some pages, especially since it usually makes the link unclickable. —Dinoguy1000 21:45, 6 November 2008 (UTC)

That is unavoidable atm I think. the "right" offset for all those icons is hardcoded usually. The 3 icons that are allowed on articles are taken care of by the editsection gadget, but with all the hardcoded userpage icons, this will be of now help... We are looking at the same problem a bit (many folks don't use class=topicon for these, which makes it even more difficult to fix) --TheDJ (talk • contribs) 22:12, 6 November 2008 (UTC)

Random thought... would it be possible to write a metatemplate for the icons to automatically prevent overlap, or would it be obscenely complicated and unwieldy/outright impossible? I don't know nearly enough about CSS positioning (haven't yet taken the time to learn and play around with it) to be able to guess for myself... —Dinoguy1000 22:20, 6 November 2008 (UTC)

Hmmm, maybe... probably most of the functional part would be javascript and css tho... could we have a JS module to find all the topicons (as defined by some class, presumably 'topicon') and position them nicely? We'd have to have some pretty fallback for users without javascript; maybe that could be metatemplated... we can do it with CSS3:

.topicon {position:absolute;}
.topicon:nth-of-type(1){...}
.topicon:nth-of-type(2){...}
.topicon:nth-of-type(3){...}
etc

This seems the nicest solution, but maybe not entirely effective? I'm basically just rambling here, but it seems to me that we have several interlocking issues here: there's the fact that the locations of all the topicons are hardcoded, the fact that adding things to the top screws up the positioning of said icons, and that icons tend to overlap each other and other things (if you apply two protection templates to the same page, for instance, the padlocks overlie each other). So perhaps some system, perhaps with a fallback cascade of CSS3 → JS → CSS2, to pick up all the icons on a page, line them up nicely and then display them in the right place, would be an overall improvement? Happy‑melon 23:04, 6 November 2008 (UTC)

I had suggested on Userpageinfo that we should create a .toptext class. Additionally, we should make a catalog documenting positions occupied by different icons. Backlinks from a template like {{topicon}} or category would be useful. — Dispenser 17:38, 7 November 2008 (UTC)

For that matter, deciding if certain icons should always occupy a certain space or position (e.g. protection icons should always be rightmost or something) would also help. —Dinoguy1000 18:53, 7 November 2008 (UTC)

I'm more thinking of aligning the topicons dynamically: instead of establishing a 'precedence' and then saying "this space is reserved for icon X" (which leaves potentially loads of whitespace if space is reserved for several icons that don't appear on a page) we should have some code that dynamically detects how many topicons there are on a page, assigns a space for each one and slots them all in nicely (moving around anything else that might be there). It would be possible to still have a 'precedence' in that system, but it would be easier to just put the first topicon declared on a page on the right, the next one next to it, and so forth. I'm sure this is not beyond the skills of our javascript programmers. Happy‑melon 19:27, 7 November 2008 (UTC)

That's what I meant as well, I just wasn't very clear about it. ;) I meant thinking of the space as divided into plots, one plot for each topicon on a page, and filled right-to-left with certain icons getting preferential placement - if, for instance, icon X has top-tier importance, then it would always be placed farthest to the right when present, otherwise all the other icons would be moved one space right to take its space (hopefully this is clearer than my previous attempt ;P ). This would also allow for a space to be reserved for a lead edit link, if someone is using a script or the gadget. If something like this were done, I'm thinking the order of preference would be something along the lines of "1. Edit link 2. {{featured article}} and company 3. {{Spoken Wikipedia}} and company 4. protection icon(s) 5. everything else" (this is based on looking through Category:Featured articles; also, since {{coord}} and company always (AFAIK) output below the H1 line, as opposed to above it, I've omitted them here). —Dinoguy1000 20:25, 7 November 2008 (UTC)

Then we're reading from the same page; your explanation of your concept is almost identical to mine. So I'm starting to see how this can take shape: we wrap all topicons in a metatemplate (bring forth {{topicon}}!) which contains several useful things: a class to alert the javascript that it needs to be moved, an attribute to identify its place on the precedence scale, and some default absolute positioning (based on that precedence?) for users who don't have javascript. Then some onload JS to pick up all the topicons on a page, count them, sort them, pick a nice clean spot for them and rejig their style attributes to put them there. Sounds fairly straightforward. Thoughts? Happy‑melon 21:27, 7 November 2008 (UTC)

Aah, most definitely. I just have to ask, though, how would, for example, Spoken Wikipedia be handled, since it outputs both a topicon and a box at the bottom of the page? Would each part have to be split out, or what? And similarly with the protection icons, since the templates can output either the icon or an ambox message. —Dinoguy1000 21:52, 7 November 2008 (UTC)

It would be implemented in pretty much the same way as currently: the metatemplate will be a div that gets moved to the top on page load, either by JS or by its own style attributes. This is what happens already: if you look at the HTML of a page that has topicons, you see that they're actually declared inline and are repositioned by the browser. Happy‑melon 22:12, 7 November 2008 (UTC)

I'v been taken a look at this and implemented some stuff that works along that way.

importScript('User:TheDJ/topelements.js);
importStylesheet('User:TheDJ/topelements.css);

However I have to say that this is a lot of "trouble" for something that should not have to be. We need this to be implemented in mediawiki if you ask me. I also just remember flagged revisions, which by my memory has indicators in this area as well. The icons / coordinates etc are not going away, and we need to give them a proper place. --TheDJ (talk • contribs) 19:34, 13 November 2008 (UTC)

I agree fully, but knowing how the devs can be about this type of stuff... -_- We still have to figure out the best way to do this before we can open a bug report, though, it would help encourage them to actually implement it if they don't have to worry about figuring out the details. —Dinoguy1000 19:54, 13 November 2008 (UTC)

CollapsibleTables show/hide button

Is encapsulated in a huge div that takes up a lot of unnecessary space. I understand that it's a good idea to set a specific width for this object so it equivalent left-floating objects can be created for balance, but can we reduce the size a bit? it's clearly intended to be the same size as the text, but on all my browsers it's massively larger. Incidentally, I've created {{showbutton}} (Template:show was taken) to be a wrapper for the left-floating div code, so we should keep the two in sync. Happy‑melon 18:18, 11 November 2008 (UTC)

I've now reduced the width to 3em. Should we perhaps instead add a class here instead and move the style declarations to MediaWiki:Common.css? Happy‑melon 16:13, 17 November 2008 (UTC)

I'd support the class approach, since it would allow individual users to override the styles in their monobook.css files if they so choose (I'd also like to see functionality added to allow individual uses of the script being able to override styles, but that's an entirely different nest of vipers ;P ). —Dinoguy1000 21:45, 17 November 2008 (UTC)

Next on my wishlist here is the option to position the show/hide button manually within the table if necessary (ie if you create an object within the table with a certain class, it will attach the link there rather than its default position). Does anyone else think that this would be a good idea? Happy‑melon 21:49, 17 November 2008 (UTC)

Sorry, I've had to revert this change, because every title on every navbox using the show/hide and tnavbar text is misalligned by a whopping 1.5em. The reason it is 6em is because {{tnavbar}} is using 6em spacing as well. The two need to be in concert for proper allignment of the titles... and tnavbar won't fit on 3em. A better change would be to change both to 4em, but only after sufficient testing of course. — Edokter • Talk • 22:32, 17 November 2008 (UTC)

Oh, and... a class won't work here regretably; since the show/hide button is injected dynamically into the tables, it has no access to classes declared in common.css. Otherwise, It would have been done so ages ago. — Edokter • Talk • 22:35, 17 November 2008 (UTC)

I don't think that's accurate, Edokter: I have a javascript function that appends classes to things, which style correctly from static declarations in my monobook.css. I use it to give everything a red border when I need to see the layout of elements. So I expect giving it a class would work. And don't navboxes use NavFrame? If not, why the hell are we still supporting that? Moving forward then, can we A) resize it as small as possible, and B) indicate somewhere obvious what the limiting factor is? Happy‑melon 23:28, 17 November 2008 (UTC)

Well, {{Tnavbar}} is the main limitation/consideration, and it uses various widths; the long form of view • talk • edit is just short of 6em. That is why 6em was choosen for the show/hide links. I will pose that Tnavbar is due for a major overhaul anyway, but as the two are tied in, what happens here should be dependent on what happens with Tnavbar.

You may be right with regards to classes (or id's), and it is worth testing. And yes, Navbox is a table. Has been for a long time. NavFrame has been decrapated a long time ago, but some templates may still use it. — Edokter • Talk • 00:10, 18 November 2008 (UTC)

Technical restrictions title fix extension

I'd like to propose that we loosen the restrictions on this code such that it accepts any input that can be normalised to any valid internal link, not just valid links to the actual page. Any page on-wiki that can be made into a redirect should be a valid page title. Happy‑melon 14:37, 13 November 2008 (UTC)

Ehm, confused. can you explain a bit further ? Why would we do that, doesn't the current code suit our needs properly? --TheDJ (talk • contribs) 15:24, 13 November 2008 (UTC)

Take, for instance, Project Snowblind. It is supposed to be at "Project:Snowblind" but can't be because "Project:" is a synonym for "Wikipedia:" as a namespace prefix. But we can create a redirect from Wikipedia:Snowblind, so "Project:Snowblind" would be a valid link target. So we should be able to change the page title on that page to read "Project: Snowblind" and create a redirect. Does that clarify? Happy‑melon 16:52, 13 November 2008 (UTC)

Please don't. We've had the technical ability to make the <h1> read "Project:Sandbox" or "_page_title_" or whatever for years. The issue is whether or not a user is able to easily copy and paste the <h1> and create a valid link from it. So, for example, {{DISPLAYNAME}} allows a title to be "user:splarka" because that is a valid link regardless of capitalization. In your specific scenario, you'd also be creating cross-namespace redirects. --MZMcBride (talk) 17:19, 13 November 2008 (UTC)

I am aware of the limitations, it took me quite a while to deduce their precise nature. I know that this would create cross-namespace redirects, I'm saying that in this case it's a good idea. If we create Wikipedia:Snowblind as a redirect to Project Snowblind, then there is no reason why we can't change the h1 title to "Project:Snowblind". It is a valid link text, and it does take readers to the right page. People following a link to Project:Snowblind are momentarily sent out of the mainspace, only to be returned to it by the redirect. In this case the cross-namespace redirect is going into the mainspace, not out of it, so the usual concerns don't apply. We have the opportunity to improve our accuracy in a niche case with minimal downsides (a dozen or so redirects to keep track of with a category, big deal :D); I don't see why we shouldn't do so. For that matter, I don't see why {{DISPLAYTITLE}} doesn't do the same, but that's another issue: obviously if the restrictions on the magic word implementation are ever relaxed, we can convert to using that solution rather than the older JS one. Happy‑melon 15:54, 14 November 2008 (UTC)

In general, we've been trying more and more to reduce the number of cross-namespace redirects, esp. when one of the redirects involves the (Main) namespace. There was also specific bug about something very similar to this issue, bugzilla:12404, which was resolved WONTFIX. --MZMcBride (talk) 18:00, 14 November 2008 (UTC)

I don't think that the bug you link to is particularly relevant, this proposal can't and wouldn't be used in the case of pages forming an interwiki prefix. While I fully support reducing the number of cross-namespace links out of the mainspace (and indeed through a long and convoluted chain of events this is actually blocking us removing some 300 out-of-mainspace redirects) I don't consider into-mainspace redirects in quite the same light, especially when they are designed to improve the appearance of mainspace articles. An option to escape the colon would undoubtedly be the ultimate solution, but I doubt such a quick fix will be forthcoming; this is a simple way to clean up a subset of our articles displaced by technical limits. Happy‑melon 18:07, 14 November 2008 (UTC)

[edit] link for lead section

== Change the default for "My Preferences / Gadgets / User Interface Gadgets / Add an [edit] link for the lead section of a page" to checked instead of unchecked. ==

Hello. Please see the discussion at the village pump [5] for support of this proposal. It was suggested to me there that I seek consensus here too. Can anyone suggest anywhere else I need to raise this issue? Simply changing the default from off to on will save indefinite server time and man hours into the future. -- Another Stickler (talk) 21:43, 25 November 2008 (UTC)

"On by default" gadgets functionality was reverted in rev:37278, so right now this is about adding the code to Common.js. I changed the section name accordingly. By the way, there is currently a proposal for a new code at MediaWiki talk:Gadget-edittop.js#New version that is aware of any topicon. —AlexSm 22:16, 25 November 2008 (UTC)

The one point that I see remaining in this discussion is: "Users might confuse this with the "fullpage" edittab". I can see this being confusing especially for the anon users. Although we could add another JS hack for that of course. --TheDJ (talk • contribs) 22:18, 25 November 2008 (UTC)

I would suggest moving the link under the H1 header. This would also be more logical and consistent with other [edit] links, considering that H1 is the header for the whole article, not for the lead section. This is exactly how it's globally implemented in ru.wp. —AlexSm 22:32, 25 November 2008 (UTC)

You mean where the coordinates are located ? --TheDJ (talk • contribs) 22:37, 25 November 2008 (UTC)

I just checked and in ru.wp we do have coordinates template moved a little to the left so that [edit] links just fits in the right corner. Also, the script itself could move coordinates, anyhow it's easier than moving several types of top icons. —AlexSm 23:27, 25 November 2008 (UTC)

That's also where some of the buttons for User:Js/ajaxPreview get placed (you should know that, of course, but I figured it wouldn't hurt to remind you). In any case, I'm all for a default lead section editlink, regardless of where it ultimately gets placed - if the wording is expanded, or it gets placed under the H1, it'll be fairly quickly that someone writes a user script that adjusts the functionality for those users who don't like it. —Dinoguy1000 22:43, 25 November 2008 (UTC)

Those buttons are in the edit mode, while [edit] link is only in view mode... do I miss something? —AlexSm 23:27, 25 November 2008 (UTC)

TheDJ, only one person suggested that might be a problem--a hypothetical worry posed by one person. The actual experience from Fuhghettaboutit (see Village Pump discussion] who answers a lot of help calls is that hundreds of newbies have asked how to edit the lead at all. Having an edit link at the top of the lead section would be consistent with the rest of the page and make it easier for newbies, not harder. Exceptions make interfaces harder, not easier. -- Another Stickler (talk) 02:43, 26 November 2008 (UTC)

TheDJ, I just noticed, with the gadget turned on, hovering the mouse over the edit link for the lead section gets the help balloon text "Edit lead section". This should help prevent confusion with the "edit this page" tab. -- Another Stickler (talk) 16:30, 27 November 2008 (UTC)

TheDJ, another idea to prevent confusion is to change the link text and the tab text. I suggest (for all sections including the lead) instead of "edit", it should say "edit section", and instead of "edit this page" it should say "edit whole page". This would explicitly distinguish them, provide more self explanation or passive help or clarity in the interface, and only requires a text change. -- Another Stickler (talk) 16:41, 27 November 2008 (UTC)

If this is implemented, please ensure it is very easy to disable through either user javascript or user CSS. Personally, I think that these are better options, order from most to least preferred:

1. Leave it as a gadget that must be manually enabled
2. Add it to the skin directly, instead of using a javascript hack
3. Add a new tab to the top rather than adding a link anywhere else.

— Carl (CBM · talk) 00:00, 26 November 2008 (UTC)

I personally have a User:Dschwen/HighlightSection.js in my monobook.js . This bit of JS highlights the entire section you will be editing when hovering the edeit link. I find it useful, especially when the edit links get shuffled around by broken image or infobox layout. --Dschwen 15:36, 3 December 2008 (UTC)

Adding a new tab at the top would add another special exception to the interface and probably just compound the problem. If "hundreds" of newbies can't even figure out how to edit the lead at all, a new tab will not help them. People are pattern seekers. Every section except one currently gets an edit link by default. Consistency and intuitiveness suggests every section should. (Leaving the "edit this page" as a special exception makes sense for at least two reasons; it's a different function than editing a section, and it's a more dangerous function.) -- Another Stickler (talk) 03:15, 26 November 2008 (UTC)

I agree with Carl. Either find a developer to implement this feature properly (without JS hackery) or leave it enable-able with a gadget. --MZMcBride (talk) 07:44, 26 November 2008 (UTC)

I disagree: there's a chicken-and-egg spiral going on here; the devs have better things to do than hardcode something that can be done with javascript, and we somehow don't want to use javascript for something that "could" be done in MediaWiki? We already have a gadget, which indicates that we're prepared to accept and support the existence of such JS code, but only for users who can be bothered to both find and enable it? If it's useful and not problematic, we should enable it, simple as that. Obviously if it's later built into MediaWiki, we can remove the JS, simple as that. But not making that internediary step just because it might be fixed some time in the next blue moon is crazy. Happy‑melon 08:56, 26 November 2008 (UTC)

This is why my main request/demand is that if this is implemented in Common.js, it needs to be very easy to disable. Regarding the development effort, it's not really any harder to write the PHP code to put the links directly in the skin, than it is to develop the Javascript code to put them onto the page when it is rendered. Anybody an submit patches for Mediawiki. — Carl (CBM · talk) 13:44, 26 November 2008 (UTC)

Indeed, and that should be trivial; just add an id so it can be hidden with CSS. That's assuming that it doesn't muck around with anything else on the page, in which case the hide needs to be a little more refined. Happy‑melon 14:39, 26 November 2008 (UTC)

They're called hacks for a reason. The link won't show up for people who don't have JS enabled, and I can almost guarantee that the link will screw up page layout somehow. There's a reason this bug (number 156, filed more than four years ago) still hasn't been resolved. (See also: comment 38.) The entire "well we can implement it this instant" argument is nonsense. Sure, it can be implemented for people who have JS enabled right now, but that certainly does not mean we should. I've seen too many hacks be placed into the global JS rather than forcing people to implement features properly into core (sidebar links, display title fixes, etc.). The link hasn't been in the skin since Monobook was written. There's no urgency to adding it with JS hackery right now. --MZMcBride (talk) 17:03, 26 November 2008 (UTC)

So you argue that saying "yes, we could easily do it ourselves, and we want it done, but we won't do it ourselves because we'd really like you to do it" is somehow going to spur the developers into action? Most of the issues in that thread stem from RTL scripts, uncertainties over what else might be in the affected area, other site-specific issues that must be considered in a MediaWiki-wide implementation. We don't have those problems: we know exactly where it would be going and what might be in the way, and so we can take simple measures to ensure that it's alright for en.wiki. We don't care about what happens if you start writing titles in Hebrew. Of course the link won't show up for people without javascript. This site looks crap anyway without javascript, missing an extra feature is hardly the most serious of your worries if the head of every talk page is ten screens long because none of the tables will collapse. If it were a fix for a serious problem, yes, we would have to consider what would happen without JS. But saying that we shouldn't improve the editing experience for the thousands of editors who do have javascript just so the second-class citizens who don't don't feel excluded, is cutting off your nose to spite your face. I'm not denying that this feature should be in MediaWiki, will fully support any attempts to integrate it as such, and will applaud the day when this hack, for I agree it is a hack, can be removed. But to say that we should deliberately deprive ourselves of a partial solution in the hope that our display of abstinence somehow encourages a full solution, is simply madness. Happy‑melon 18:39, 26 November 2008 (UTC)

Perhaps I'm more just amused that this is suddenly such a high priority when it's been an "issue" for literally years. I honestly just don't see the sudden 'zomg rush' to implement what everyone agrees is a hack when this has been 'broken' for so long.

On a broader note, the entire system of absolute-positioned icons is a complete and total hack, so perhaps instead of compounding JS hacks with more JS hacks, we stop and instead implement these features correctly?

And as someone above mentioned, this proposed code is going to cause problems for en.wiki, which in some cases we'll be able to mitigate, maybe. I just enabled the gadget and looked at Stuy and it looks pretty shitty. (The [edit] link is right next to the sound icon.) Obviously the [edit] link will be adjusted from its current position in the gadget, but you'll still be dealing with infoboxes and coords (and their 30-day cache expiry assuming you change the global CSS).

All in all, I'm much more in favor of seeing a comprehensive, complete solution than compounding more hacks onto more hacks. (And if that means waiting, so be it.) And I say this as someone who has dealt with the topicons for quite some time, including their awful adaption when things like sitenotice or CentralNotice are enabled. --MZMcBride (talk) 22:25, 26 November 2008 (UTC)

I support having a section 0 [edit] link in the upper right corner of all unprotected pages. Since I think it is logical and most editors do need it, even the IP editors. The current gadget that allows users to enable that edit link doesn't help the IP editors at all. And then instead we can have a gadget that allows users to turn that edit link off, if they happen to dislike it.

And I think we should add it with javascript for now. Since most users do have javascript enabled. So it will be an improvement for the majority of users, while no change for the users that does not have javascript. There is no telling when the devs will add this function to MediaWiki itself since that is way more complex since then it has to work properly for all MediaWiki sites.

MZMcBride: We only place a handful of icons in the upper right corner of pages. We can easily move them out of the way for the [edit] link. Actually, last year we fixed it so that the icons does not overlap each other and that they all align up at the same height. But you got a point that we probably should move the icons out of the way before we add the edit link. So I say we reserve that space for the edit link and start moving the icons.

I don't use the [edit] section 0 gadget since I use my own special version of it instead. And I see no problem with infoboxes and coords. So if there is a problem with that with the current gadget code, then we already have other versions that does not have that problem. (Although the version I currently use is probably messy code since I based it on another such code and haven't updated it for ages. Back then I didn't know much about javascript and Wikipedia CSS layout.)

--David Göthberg (talk) 06:02, 27 November 2008 (UTC)

Moving the topicons is no problem. An update to the Gadget to fix this for any and all case is already in the waiting queue. Having it at the "coordinates" spot, might be a "slight" issue, in that it is untested on en.wp --TheDJ (talk • contribs) 10:54, 27 November 2008 (UTC)

So what happens now? The discussion has stopped but nobody is saying "I'll fix that". Is this not the most appropriate place to raise this request? Who should I be asking? -- Another Stickler (talk) 06:56, 3 December 2008 (UTC)

One of these fine people needs to write and propose the appropriate code on this page. It will then be tested for a week or so (maybe more), and assuming there are no significant issues, it will be deployed site-wide (there seems to be a pretty good consensus for it). In addition, someone will need to write a Gadget that disables the feature for those who wish to not see it. --MZMcBride (talk) 07:02, 3 December 2008 (UTC)

People who don't want to see it can just edit their own CSS or Javascript files. I don't see why we'd need another gadget for something that trivial. — Carl (CBM · talk) 13:50, 3 December 2008 (UTC)

Ok, here's code:

// **********************************************************************
// **                 ***WARNING GLOBAL GADGET FILE***                 **
// **             changes to this file affect many users.              **
// **           please discuss on the talk page before editing         **
// **                                                                  **
// **********************************************************************
// Imported from [[User:Alex Smotrov/edittop.js]], version as of: 2007-06-19T04:28:52 
if ((wgAction == 'view' || wgAction == 'purge') && wgNamespaceNumber >=0)
addOnloadHook(function edittop_hook(){
 var localtitles = {
   en: 'Edit lead section',
   fr: 'Modifier le résumé introductif',
   it: 'Modifica della sezione iniziale',
   ja: '導入部を編集'
 };
 var our_content = document.getElementById('content') || document.getElementById('mw-article') || document.body;
 var editspans = getElementsByClassName( our_content, "span", "editsection");
 var span1;
 for( es_count = 0; editspans && es_count < editspans.length; es_count++ )
 {
  span1 = editspans[es_count];
  if( span1.className.indexOf( "plainlinks" ) == -1 )
    break;
 }  
 if (!span1) return;
 var span0 = span1.cloneNode(true);
 var editwidth = span1.offsetWidth + 10;
 
 var topicons = getElementsByClassName( our_content, 'div', "topicon" );
 for( el=0; topicons && el < topicons.length; el++ )
 {
  topicons[el].style.marginRight  = editwidth+"px";
 }
 
 var parent = our_content.getElementsByTagName('H1')[0];
 parent.insertBefore(span0, parent.firstChild);
 var a = span0.getElementsByTagName('A')[0];
 if (a.href.indexOf('&section=T') == -1){
   a.title = a.title.replace(/:.*$/,': 0')
   a.setAttribute('href', a.href.replace(/&section=\d+/,'&section=0'));
 }else{//transcluded
   a.title = localtitles['en']
   a.setAttribute('href', wgScript+'?title='+encodeURIComponent(wgPageName)+'&action=edit&section=0')
 }
 if (localtitles[wgUserLanguage]) a.title = localtitles[wgUserLanguage]

Absolutley nothing to do with User:TheDJ/Gadget-edittop.js, honest :D. I'm sure it can be cleaned up, consider it a foundation. For instance, I'm rather unsure about the purpose of the lines

 for( es_count = 0; editspans && es_count < editspans.length; es_count++ )
 {
  span1 = editspans[es_count];
  if( span1.className.indexOf( "plainlinks" ) == -1 )
    break;
 }

What is this looking for? Comments? Happy‑melon 18:23, 3 December 2008 (UTC)

It deals with the first transcluded editsection span of {{doc}} on Templates. --TheDJ (talk • contribs) 20:40, 3 December 2008 (UTC)

I don't know enough about javascript to be able to tell what this does by reading it, but I'll give my support to anything that gives section 0 an edit link for newbies by default. -- Another Stickler (talk) 23:23, 8 December 2008 (UTC)