MediaWiki talk:Common.js/Archive Aug 2007

message: Looks like developers did the same thing for global JS/CSS files as they already did before for personal js/css files: now the whole page is shown inside <pre class="mw-code mw-js"> tag, which means nothing is going to work inside and we can remove all templates (e.g.  in MediaWiki:Monobook.css and MediaWiki:Common.css), User: links, headings, <pre> tags and so on. However, there is still one little reason to keep <source> tag: you can trasclude the file on another page and then still enjoy it with syntax highlighting ∴ Alex Smotrov 22:29, 27 June 2007 (UTC)
replies: text: For highlighting add both </pre> before  and <pre> after  tags.--AlefZet 21:57, 28 June 2007 (UTC)
replies: text: Well, that was my first idea as well, but it doesn't work since Mediawiki simply replaces all < into <. Note that this doesn't happen immediately after saving (I have no idea why), so if markup on js/css pages seems to work for you, just wait a little and it won't ;) ∴ Alex Smotrov 22:13, 28 June 2007 (UTC)

text: →AzaToth 17:07, 29 June 2007 (UTC)

text: There is ongoing discussion about this on bugzilla (bugs 10196, 10314, 10410, 10422), so don't be surprised if it changes again soon. --ais523 15:39, 2 July 2007 (UTC)
thread_title: Global JS/CSS "safe" now

message: There are a few things that I would like to propose for en: when uploading files. Most of these are not original ideas. I could provide a link to where they were first proposed but I don't think it's that important. I think they can be done with js of some kind.
# Remove the "Upload file" link in the "toolbox" and move the "File upload wizard" into the "toolbox". I believe this has been done on zh: and can probably be done here with js.
# Have the  preloaded into the editbox, again, much like at commons, and much of the info filled out. It has been suggested rather to have a link that will fill it in if needed, but personally I don't like the later idea. Having it automatically in the editbox will give people a better idea of what info is needed. I have located how it was done on commons, it is a simple js here.
# A small thing is to have the editbox 50% larger, or more.
This same message went trough the Village Pump (Make "Upload file" more like on Commons) without anyone noticing. So I thought I'd add it here.  --Steinninn 16:03, 4 July 2007 (UTC)
replies: text: These sound like good ideas, get consensus for them then re-enable the template. Thanks, GDonato (talk) 12:53, 6 July 2007 (UTC)
replies: text: I already posted it at the village pump, what more do you need? --Steinninn 13:55, 6 July 2007 (UTC)
replies: text: Unfortunately, I am unwilling to make such changes without agreement of the community. The only thing I would say is trying re-listing, possibly at WP:VPT too. GDonato (talk) 18:32, 6 July 2007 (UTC)
thread_title:  Make "Upload file" more like on commons 

message: I have just reverted Martinp23's addition of the search engine images. Adding images like these violates our fair use policy and may be interpreted as ads. Sean William 22:46, 19 May 2007 (UTC)
replies: text: Agreed. (H) 22:50, 19 May 2007 (UTC)
replies: text: Likewise.  I factored the images out, but apparantely I'm not allowed to do that, so putting this reversion up for discussion - to be clear, the ideal way to give the external searches would be server-side, in the mediawiki text, but as no params are available in the relevant text, something client side is required.  This has been requested in various places, including WP:AN (which, incidentally, is where I decided to add the images code, from fr.wiki, as a favour - still somewhat sick at the hostility of some to an easily reversible mistake...).  The removal of the code which I changes is reverted here.  Martinp23 00:21, 20 May 2007 (UTC)
replies: text:  Unfortunately any code pasted here is not easily reverted as it can stayed cached in visitors' browser cache for weeks. Any mistakes in the code can cause anything from annoying popups to appear to all pages on Wikipedia showing up blank during that time. From the simple cut 'n paste job you did I assumed you are not familiar with Javascript yourself, while adding executable code to one of the most visited websites is something that should not be doen without a little care. There are usually enough people hanging around on this page who van evaluate (and perhaps improve the code) on it's correctness, performance impact, maintainability etc. This was not meant as a hostile action, but as necessary caution. A reaction you can sometimes expect when being bold. —Ruud 13:27, 20 May 2007 (UTC)
replies: text: I understand your reasons, but should note that this wasn't a "simple cut-and-paste job" - in fact I did test my extensive changes to the code in my personal monobook.js before adding it here - the code below (as I added) is somewhat different from the code on fr.wiki, but I of course do invite people to look over (and inevitably improve) it. Martinp23 14:37, 20 May 2007 (UTC)
replies: text:  Okay, better safe than sorry was my motto here. No hurt feelings I hope. —Ruud 18:59, 20 May 2007 (UTC)
replies: text: Not at all!  Thank you for your diligence in taking that care.  Feel free to re-enter the js when/if you feel it has been suitably reviewed. Martinp23 19:25, 20 May 2007 (UTC)

text: I support the image free version. Good idea. (H) 19:28, 20 May 2007 (UTC)

text: See my note below. I'm not a fan, but at least I can do onloadFuncts.splice(onloadFuncts.indexOf(SpecialSearchEnhanced3), 1). GracenotesT § 19:41, 20 May 2007 (UTC)

text: I agree, a drop-down list should be used to let the user select which search engine he wants to use (defaulting to MediaWiki's internal search engine). —Ruud 19:49, 20 May 2007 (UTC)
replies: text: What I think would look nice would be to have them as links instead of buttons, and to have them side-by-side instead of one-under-the-other, to save screen space. Tra (Talk) 20:40, 20 May 2007 (UTC)

text: I personally like Ruud's solution: all it requires is creating a menu, and then changing the action of the form when the selection is changed. And only one form is required. GracenotesT § 20:57, 20 May 2007 (UTC)

text: Could we add Wikiwix to that?  It has been requested on AN and not objected to there, and the development team for that have (AFAIK) gone to great lengths to ensure a quick and very accurate search, optimised to Wiki*edia projects.  Martinp23 09:48, 23 May 2007 (UTC)
replies: text: Done. Feel free to change the order. GracenotesT § 17:10, 23 May 2007 (UTC)

text: I've requested the changes; does anyone object for any reason? GracenotesT § 21:26, 23 May 2007 (UTC)
replies: text:  Done. Cheers. --MZMcBride 23:34, 24 May 2007 (UTC)

text: The code that says '/w/index.php' should be changed to wgScriptPath + '/index.php'. Mike Dillon 01:40, 26 May 2007 (UTC)
replies: text:  Done. Purge and all that.... Cheers. --MZMcBride 02:06, 26 May 2007 (UTC)

text: Done. Cheers. --MZMcBride 01:11, 9 June 2007 (UTC)

text: It would require a bit of tweaking to the script since it assumes that there is only one additional parameter besides the free text field used for the search term. For Yahoo!, this is currently being used for vs=en.wikipedia.org. The code would have to be changed to add a hidden element to the form for the ei parameter on submit, which would significantly alter the structure of the code. Mike Dillon 02:24, 10 July 2007 (UTC)
thread_title:  Search images 

message: Hm... could we possibly keep the buttons down to a minumum? Mere links would be good, I think. I mean... I dislike them: too large, and too many of them. GracenotesT § 19:23, 20 May 2007 (UTC)
replies: text: I agree, a drop-down list should be used to let the user select which search engine he wants to use (defaulting to MediaWiki's internal search engine). —Ruud 19:49, 20 May 2007 (UTC)
replies: text: What I think would look nice would be to have them as links instead of buttons, and to have them side-by-side instead of one-under-the-other, to save screen space. Tra (Talk) 20:40, 20 May 2007 (UTC)

text: I personally like Ruud's solution: all it requires is creating a menu, and then changing the action of the form when the selection is changed. And only one form is required. GracenotesT § 20:57, 20 May 2007 (UTC)

text: Could we add Wikiwix to that?  It has been requested on AN and not objected to there, and the development team for that have (AFAIK) gone to great lengths to ensure a quick and very accurate search, optimised to Wiki*edia projects.  Martinp23 09:48, 23 May 2007 (UTC)
replies: text: Done. Feel free to change the order. GracenotesT § 17:10, 23 May 2007 (UTC)

text: I've requested the changes; does anyone object for any reason? GracenotesT § 21:26, 23 May 2007 (UTC)
replies: text:  Done. Cheers. --MZMcBride 23:34, 24 May 2007 (UTC)

text: The code that says '/w/index.php' should be changed to wgScriptPath + '/index.php'. Mike Dillon 01:40, 26 May 2007 (UTC)
replies: text:  Done. Purge and all that.... Cheers. --MZMcBride 02:06, 26 May 2007 (UTC)

text: Done. Cheers. --MZMcBride 01:11, 9 June 2007 (UTC)
thread_title: Drop-down approach

message: There's some problems when searching some terms including the CJK characters when searching using the Yahoo! option. And I've found out that a field name and a value is required in addition of the existing search term that using the Yahoo! sarch engine. i.e. the [ei=utf-8] is required when a Yahoo! search engine is selected. Any idea how to solve this issue? Shinjiman ⇔ ♨ 13:46, 9 July 2007 (UTC)
replies: text: It would require a bit of tweaking to the script since it assumes that there is only one additional parameter besides the free text field used for the search term. For Yahoo!, this is currently being used for vs=en.wikipedia.org. The code would have to be changed to add a hidden element to the form for the ei parameter on submit, which would significantly alter the structure of the code. Mike Dillon 02:24, 10 July 2007 (UTC)
thread_title:  CJK character problems with Yahoo! 

message: The definitions of importScript and importStylesheet call page.replace( ' ', '_' ), but this will only replace the first space in page, without touching the rest.
This is not a big deal, because Wikipedia generates a 301 Moved Permanently for the spaced URL, but the code should probably be corrected to page.replace(/_/g, ' '), for neatness and efficiency.  --Piet Delport 01:42, 5 July 2007 (UTC)
replies: text: That is, switch that around, page.replace(/ /g, '_') (or page.replace(/\s/g, '_')). GracenotesT § 04:13, 5 July 2007 (UTC)
replies: text:  Done (after testing the relevant expressions). (There are certainly a lot of ways to express the intended concept; I went for / /g in the actual change, but when writing my own code I often use /\ /g (which is correct in both JavaScript and Perl, even when using Perl's /x modifier) or even split(" ").join("_") (which has the advantages of accepting non-literal strings). --ais523 17:22, 6 July 2007 (UTC)

text:  Right, my copy&paste mistake.  --Piet Delport 10:14, 11 July 2007 (UTC)
thread_title:  small replace() bug 

message: Has anyone ever thought about using a JavaScript framework (ex. jQuery) to make it easer for people to create plugins for MediaWiki? It would also make this page allot nicer and easer to read. — 12.65.6.217 22:19, 7 July 2007 (UTC)
replies: text: While that may be true, it would also add another 20k of overhead to the site JavaScript. I'm not sure if the readability benefit is enough, since 99.9% of the people for whom this code executes will never even know about it, let alone read it. Mike Dillon 14:54, 14 July 2007 (UTC)
thread_title:  JavaScript framework 

message: The "Technical restrictions" title fix can be removed due to the new magicword .  It functions exactly the same as the "Technical restrictions" title fix does (it only displays as long as the displayed title is a valid link to that page).  We need a bot to update all the pages to use this instead of the js class and then we can remove it from here. 81.34.54.162 18:24, 17 July 2007 (UTC)
replies: text: Since most if not all of the additions of the RealTitle id are done by templates, it should be possible to change this without a bot by just putting  into the relevant templates. Mike Dillon 20:21, 17 July 2007 (UTC)
replies: text: Looks like this has already been done for . Mike Dillon 20:23, 17 July 2007 (UTC)
replies: text: It's not as simple for , for example see P*U*L*S*E (film): the javascript code is smart enough not to replace the heading but it does replace the page title, also the template shows "The correct title is …" message. P.S.   This seems to be a revision which enabled  ∴ Alex Smotrov 16:20, 18 July 2007 (UTC)
thread_title:  "Technical restrictions" title fix 

message: I found the instructions that all changes to Common.js must be discussed on the Village Pump, so I have moved this request there. All discussion should take place there. ←BenB4 01:35, 25 July 2007 (UTC)
replies: text: I dont think it was such a good idea to cross-post (a notice and a link imho would be better) ∴ Alex Smotrov 03:49, 25 July 2007 (UTC)
replies: text: Agreed, moved. ←BenB4 04:54, 25 July 2007 (UTC)
replies: text: If consensus develops, then add an editprotected request again. — Carl (CBM · talk) 01:01, 27 July 2007 (UTC)
replies: text: This bug fix has two supporters and no dissent -- the exact change requested is the section at that VP/T archive link. ←BenB4 00:27, 8 August 2007 (UTC)
replies: text:  Done. Cheers. --MZMcBride 03:45, 8 August 2007 (UTC)
replies: text: Thanks.  I believe I've fixed all of the docs and repercussions, modulo some remaining editprotects. ←BenB4 12:07, 8 August 2007 (UTC)
thread_title:  Please set NavigationBarShowDefault = 0