[solved] External links, set default target as "_blank"

I would very much like to have external links automatically open up in a new window (e.g. target="_blank") while internal links remain in the same window.

Is it possible to set this as a default somehow?

1 Like

Problem resolved by going to: Administration Wiki, Look & Feel, Presentation, HTTP Meta Info

and adding the following into the meta box

<script>
  function fixExternalLinks() {
    document.querySelectorAll('.wikiexternallink a').forEach(function(link) { 
      if (link.hasAttribute('target') == false)  {
        link.setAttribute('target', '_blank');
      }
    })
  }
  document.addEventListener("DOMContentLoaded", fixExternalLinks);
</script>indent preformatted text by 4 spaces

Now, any link that xwiki thinks is an external link and has no predefined target now has a target to a new window.

(This might break something else later, but so far it works)

3 Likes

Cool. Note that there’s another (possibly cleaner) way of doing this. Use a JSX object with a wiki level scope.

See http://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/Tutorials/SkinExtensionsTutorial/

Thanks for posting back your solution! That’s great

1 Like

Yes, I looked briefly at making a skin, and then decided that it was more effort than I needed.

I was more interested in something quick that requires little, if any, maintenance as the software changes.

Hmm… Looking more closely, A skin extension maybe just the right way to do it. I’ll have a look at that when I have a bit more free time to see if I can make that work.

yes it’s not a skin, just a way to inject CSS or JS when viewing a given page or when viewing any page.

Hi,

I have a question linked to this subject: in version XWiki 9.11.1, why the popup to define an URL/link properties does not contain “target” attribute anymore? I find this annoying or maybe I missed something? (I use a Wiki hosted on myxwiki.org).

Thanks for your answer,

If you’re talking about CKEditor’s WYSIWYG, see http://extensions.xwiki.org/xwiki/bin/view/Extension/CKEditor%20Integration/#HAdministrationSection

Note that AFAIK this has always been like this since we introduced CKEditor. Maybe you’re remembering some old feature with the GWT WYSIWYG editor?

Thomas, you’re “twice” right: I was used to the old WYSIWYG editor and it’s easy to change the new CKEditor behaviour.

Many thanks for your quick and relevant answer.

Vincent maybe ? :slight_smile:

@tmortagne and @vmassol you’re are both right … most of the time :rofl:.

lol :slight_smile:

I did it! I created my first skin extension using this JS code!

Well done! :slight_smile:

Well, geez, I never tested this in Internet Explorer - works fine in Chrome, but not at all in IE and we use IE a lot still here at work.

      function fixExternalLinks() {
        document.querySelectorAll('.wikiexternallink a').forEach(function(link) { 
          if (link.hasAttribute('target') == false)  {
            link.setAttribute('target', '_blank');
          }
        })
      }
      document.addEventListener("DOMContentLoaded", fixExternalLinks);

Object doesn’t support property or method ‘forEach’

Sorry laurin1, I didn’t test with IE as I consider the browser too old and out of date to support.

Can you tell me what version of IE you are using and I’ll see if I can find a workaround for you.

1 Like

IE 11, which supports almost all of the modern web development standards. I know people don’t like it, but in an Active Directory domain, we still have more control over it in an enterprise environment and so that is still our standard internally. I’ve reviewed the code (I’m a web developer myself) and I actually don’t see why it would not work.,

document.querySelectorAll is supported in IE (since version 8), except with pseudo classes, which this is not using. Given some time, I can write the JS necessary to fix this, so don’t spend too much time on it, I’m sure I can hammer it out eventually.

As an aside, I’m using chrome in an AD environment, and I can set all the useful defaults in the group policies.

1 Like

Looks like IE is not implementing forEach on the the nodelist querySelectorAll provides. But a standard for loop should work.

Something like

nodes=…querySelectorAll()
for(var i=0; i< nodes.length; i++){
// do sth. with nodes [i]
}

Obviously this is only pseudo code and I did not try it, put typing this little code on a mobile is already killing me :wink:

1 Like

:slight_smile: Well, it’s your thread we are hijacking, but yes, we use those for the limited usage of Chrome we allow, but they are not as granular (and some just don’t work as well) for Chrome - we are healthcare and keep things locked down pretty tight here. Still, we are evaluating what our next option will be, but we will possibly move to Edge and not Chrome - the main reason is that, while the us IT people love Chrome, it’s a resource hog (and I’ve got the stats to prove it), and we have some older hardware out there. Still, we are considering Chrome as an option, depending on the how the next iteration or two of of Edge goes…

1 Like

I considered that as well and just needed time to test it - thanks for the leg up!