Manual talk:$wgExternalLinkTarget

Common misconception: _new versus _blank
I am posting this here to help avoid a common misconception, that is possibly also the cause why some "new window" hacks (seem to) fail.


 * target="_new" is NOT the same as target="_blank"

The value of the target attribute can either be a reserved name, or a custom name.

Reserved names are one of _self (default, targeting the current frame or window), _blank (a new, unnamed window), _parent (the immediate frameset parent of the current frame) and _top (the topmost frame level, replacing any frameset).

Any other value (for example "_new") is a custom name. If no frame or window with this name exists, a new window is created, and the custom name is assigned to that window. If a frame or window with that name already exists, then the link is opened in that window. Even if that window is obscured by the current window, giving no visual feedback that the link has actually been opened.

Read more on this in the W3C HTML spec at http://www.w3.org/TR/html401/types.html#type-frame-target

The specifications even state that custom target names must begin with an alphabetic character (a-zA-Z), and that all other custom names (like "_new") should be ignored. Hardly any webbrowser follows this last rule, which only adds to the confusion.

In short, using target="_new" may result in one of the following errors:
 * False positive; the links is opened in a new window, if no previous window with the name "_new" exists.
 * Target attribute is ignored; the link opens in the current window, if the webbrowser follows the W3C spec to the letter.
 * Nothing seems to happen at all; if a window labeled "_new" already exists and is (partially) obscured by the current window, the user may not be aware that the link is opened in this "hidden" window.


 * Pbb 22:23, 6 March 2009 (UTC)

I inserted that stuff, but it doesn't work: web links still open the same (own) window... huwi
 * It does work, but you have to edit every page that has an external link and then save it. Then it will update those pages to open the links in a new window.
 * Well, you can use "&action=purge" in place of "&action=edit" to get the same effect. Basically, the "wrong" version of each page will still be cached in the database until you do one or the other. - IMSoP 23:38, 2 December 2005 (UTC)

Isn't it possible to use a variable so that one can choose whether or not to openb a new window ?

how to USE this mod
does this mean we're supposed to include the target=_blank into the External Link tag on the link we put in a document? or will the mod make it automatically open up in an external window?

-d

still not works on Version 1.5.4
i used this hack on an earlier version -> no probs, but now, after an update to 1.5.4 my wiki opens every external link in the same window / tab, although i "re-saved" the artikel and cleared the browser-cache. Anyone know this problem and solved it already?

This work with Mediawiki 1.5.5
This work with Mediawiki 1.5.5

You must edit include/Linker.php

RaZor Edge

opening windows optionally
I use 1.5.5. It seems that this is an all or nothing. It would be more useful to be able to choose which links opens in a new window.Sohailhussain

This work with Mediawiki 1.5.6
This work with Mediawiki 1.5.6

Make sure you edit and then save all pages that have external links... for them to open in a new window.

Sidebar?
I can't seem to make this work on the sidebar in v1.6.3. Any ideas?

In version 1.13.3, i edited the skin file. if you use the monobook skin, edit skins/Monobook.php. find "<div class='generated-sidebar portlet'" and make changes like below. before changes after changes I refered to External links in new window except for links to the same server (for v1.13)

Extending wiki syntax
The described method isn't really a good way to solve the problem of opening external links in a new window, because you only have the choice of opening all or none external links in a new window. Who wants this? I'll prefer a solution where you can choose whether the link has a target attribut or not. Can anybody give me a hint, how to expand the wiki syntax for example like this: [external link with target=_new]. This should be treated like any other external link, except that it has the additional target attribute. --Netsurfer 18:04, 12 September 2006 (UTC)

Is there a way open images in a new window?
Raimund 14:33, 13 September 2006 (UTC)

open links in new window, when in navigation bar?
If anyone knows how to make it so that links in the navigation could open in new windows, I'd appreciate it :)

SoftDux 11:32, 9 March 2007 (UTC)

Version for Mediawiki 1.9.2
I have tried setting this up for v 1.9.2 of mediawiki and managed to get this to work by substituting the | for a ~ in the code. This was because in tables the $link $text and $pos were being passed as [ UNIQ65e2e5ba2208a5b0-nowiki-00000009-QINU_new][] all working fine. --Markw21 10:47, 13 April 2007 (UTC)

All or nothing is right.
So this works just as described... except that every link (internal or external) opens in a new window.

Am I misunderstanding this or is that the expected behavior?

I want to open internal link in the same window. How can I do?

This may help!
Make sure you have modified the value "YourdomainWithoutHttp" in getXterlinks, otherways also internal links are opening in a new window.

Editing Help opens in new window without a hack
It's suggested the method to allow choice of which external links open in a new window is dangerous. But unhacked Wiki can open selective internal links in new window i.e. "Editing help" at bottom of edit window. How is that done in the code?

Two versions at the same time
(2008 may 19 verion 1:10 and 1:12)

I can’t see any reasons why it is not possible to have several versions/options of wiki-codes for ”open in new window” at the same time, i.e.   |new SR |_new SR |target=’_new’ SR (or the same with _blank)

My problem is that I am hosting several wikis and I want to simplify the code as far as possible. The version |new SR is a goal. But at the same time there are over 160 old articles written with external links like |target=’_new’ SR (and to change the users habit also a complicated thing!)

I have been trying to add some (and or change the) code in the version “Dynamically defining an href target” with (PHP) ereg and ereg_replace – with no result. Any suggestions?

Surprisingly the code works even for |target=’_new’ SR (in IE and Firefox) but the html-code is very ugly  (i.e. target='target='_new'' ).

At the same time it might be possible to stop any attempt to add any java-script. From my point of view, the only options necessary is _new _blank new or blank

/dan – Karlstad in Sweden

bottomScripts - Mod not compatible to MediaWiki ≥ 1.11 ?!
I've tested the automatic ("virtual") JavaScript-Mod and it works with version 1.11.1 but something strange happend so that I immediately removed that Mod:


 * The "last modified" information at the bottom of the page was no longer updated but it was correctly shown in e.g. "recent changes"! And much worse:
 * Since I've removed the Mod, the "last modified" info now doesn't update to the current time, but it updates to the next timestamp of an edit that was not shown (see above), so it looks like I can never ever have the correct "last modified" information for that pages again!!! (At least not without directly hacking the datatables itself...

What I assume to be the reason is the SkinAfterBottomScripts-Hook that is new since 1.11.0. But I've got no idea how to solve this. Has anybody a workaround for this? How to integrate it correctly?

The "old" bottomScripts function of MediaWiki 1.11.1: function bottomScripts { global $wgJsMimeType; $bottomScriptText = "\n\t\tif (window.runOnloadHook) runOnloadHook; \n"; wfRunHooks( 'SkinAfterBottomScripts', array( $this, &$bottomScriptText ) ); return $bottomScriptText; }

The "new" bottomScripts function from this Manual: function bottomScripts { global $wgJsMimeType; return "\n\t\tif (window.runOnloadHook) runOnloadHook; \n" ."  \n" ." getXterlinks \n"; }

Thank you for your help. --193.130.97.35 14:57, 5 June 2008 (UTC)

Dynamically defining an href target
The code for adding dynamic href targets doesn't work in MediaWiki 1.13, even after adding the modified code to the getLinkAttributesInternal function and the MakeExternalLink function.

Cleared cache and got it to work...

DISAPPOINTED ABOUT HOW THIS WORKS
I am going to share my views about the fact that MediaWiki sites are not able to open in a new window when navigating to an off-site domain. Not to have the option readily available in preferences is an absolute nuisance. I think that this should be incorporated in the user's preference pages, to let the user choose what he/she wants when navigating a wiki page.

Let me explain:


 * When I am in a website and I click on an off-site link, without being notified that I am switching domains, I find it as an insult. When it opens in a new window I can close the new tab because I know that I navigated to a new site; I can always go back and continue browsing the original site.  I've been in situations in which I am browsing a site and I am switched over 2-3 different domains in the same page and I have no clue!  By the time I find out I am so confused!  Often I don't even know how to get back to the original page I came from!


 * For Windows users it's as easy as right mouse clicking. Well, I AM on a Mac.  No right mouse button.  In the Mac you need to press control key and click.  This is ok the majority of times, but NOT at 3am when I am sitting on my iBook in the dark and I can not see where the control key is.


 * If you had a choice to de-activate off site switching but NO. Why not let the users choose what fits them best rather than setting a rule for everyone just because the market is set to favor certain number of people... where are we supposed to be?  So for people like me they made lefty baseball gloves.  Why don't I have the option to choose if I want to open off-site links in a new window?

Well, I made a wiki some months ago, about a pet site. There must be at least 20 links that point to the site in every page. Meanwhile my users will be fascinated with what they see in the pet site, or busy; and may never come back to my wiki. I also have a page with links that point to about 50 daily activities to be done in the game, each has its own link. It is very uncomfortable to keep hitting that back button, specially because there is that extra second for the page to reload. This is fine for me, but for people with older computers, it will take them up to 2-3 seconds to reload the page when the back button is hit. What a nuisance. And what about those times when you lose connection for a second or two, and the annoying "couldn't load the page" message comes up? If the new page had opened in a new window, all the user has to do is check his connections, fix the issue, and go back to clicking the links without the need to reload the page again.

I tried to use all of the recommended javascript options listed, but many things in my wiki got out of place and I even lost some images! Not worth it, I had to undo everything. Plus I have no idea how javascript works, I know HTML and I am beginning to learn wikitext, but javascript that's a little too much. Its getting to the point that to be able to have a common wiki site you need to be a rocket scientist!

In conclusion

This is not the only problem I have found when working with MediaWiki wikitext. The truth is, it is very buggy and almost impossible to work with. I am an admin in Wikianswers and I've been contacted about bugs at least 10 times. Sad but true. It is evident that MANY people NEED this feature available. Otherwise this page wouldn't be here to begin with. I myself I am regretting moving my site to Wikia, and perhaps a freewebs would have been a better choice. I don't know. But MediaWiki engine needs a LOT of improvements.

--Molokaicreeper 14:19, 9 August 2009 (UTC)