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...