Page MenuHomePhabricator

Don't mark external links to the current wiki as external
Open, LowPublic

Description

If we link a page using the full url instead of the internal link syntax, the external link arrow appears next to it. However, in some cases you don't have the choice, like a link to a diff, which has parameters and is tipically something like http://xx.wikipedia.org/w/index.php?param=value&param?value

I think that a choice should be provided by automatically marking links created with {{fullurl}} and similar templates as plainlinks. Also, if that template allowed a parameter for an alias, that would be good . But this probably would be another bug...


Version: unspecified
Severity: enhancement

Details

Reference
bz11477

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:54 PM
bzimport added a project: MediaWiki-Templates.
bzimport set Reference to bz11477.
bzimport added a subscriber: Unknown Object (MLST).
demon added a comment.Feb 7 2009, 3:21 PM
  • Bug 17331 has been marked as a duplicate of this bug. ***

old_school_junkie wrote:

{{fullurl}} and similar shouldn't be handles as plainlinks but as normal
internal a so the color is the same as internal ones (.plainlinks uses the
a.external color).

Furthermore links posted like http://mywiki.com or [http://mywiki.com... should
be handled the same.

Forgive my naiveness :P -- I don't think I was clear enough back when I originally reported this (and made some mistakes, like assuming that {{fullurl:}} was a template).

What I believe should be done is to avoid marking full urls as external links (i.e. add the external arrow) if the domain is the same as {{SERVER}}.

It makes sense that the color should be the same as internal links, too.

demon added a comment.Feb 7 2009, 3:34 PM

cf bug 16659, prettify permalinks. Kinda tangentially related.

old_school_junkie wrote:

The title of this bug is confusing (can it be changed?). As posted {{fullurl..., http://mywiki.com or [http://mywiki.com... should be recognized / handled as internal links. Class plainlinks can be removed from the css after this was fixed.

It can be done from Monobook.css but better to do it from the skin to take advantage of $wgServer. It just needs to add:
#bodyContent a.external[href ^="{$wgServer}"] { background: none ; padding-right: 0; }

(properly escaping $wgServer)

demon added a comment.Feb 7 2009, 4:31 PM

Thinking about this some more, what if we went the following route:

  1. Format external links that point internally as internal links (no class, no icons)
  2. Leave normal external links as-is
  3. Leave .plainlinks in place, it has uses beyond just the external links to internal targets.

How does that sound?

old_school_junkie wrote:

  1. yeah
  2. yeah
  3. can't think of any but I'm not that experienced.
  1. the current block/ban templates and ip contrib footers use it for whois links and ect

ayg wrote:

(In reply to comment #7)

Thinking about this some more, what if we went the following route:

  1. Format external links that point internally as internal links (no class, no

icons)

  1. Leave normal external links as-is
  2. Leave .plainlinks in place, it has uses beyond just the external links to

internal targets.

This sounds best. The place to make this decision is during link rendering, before HTML output, *not* in CSS. class="external" but display like an internal link isn't right.

old_school_junkie wrote:

Do we only talk about {{fullurl.. links or is it also possible to recognize "lazy links" like http://mywiki.com or [http://mywiki.com as internal links? Cos most users a too lazy to format a {{fullurl... just to point to some special page using parameters in the URL. It would still be correct for special pages to do so and no need to use {{fullurl... cos no "what links here" etc.

ayg wrote:

We're talking about anything that uses [http://mywiki.com ...], whether that's generated from {{fullurl}} or typed out by hand or assembled by voodoo magic. The external link processor doesn't know or care about templates or magic words, it runs after those have all been substituted to wikitext. It could also apply to bare links like just "http://mywiki.com".

  • Bug 11124 has been marked as a duplicate of this bug. ***

herd wrote:

*** Bug 19249 has been marked as a duplicate of this bug. ***

  • Bug 30883 has been marked as a duplicate of this bug. ***
MC8 added a subscriber: MC8.Feb 17 2016, 5:33 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 17 2016, 5:33 PM
Krinkle removed a subscriber: wikibugs-l-list.
Krinkle added a subscriber: Krinkle.

This task doesn't seem to be related to the ResourceLoader framework.

demon removed a subscriber: demon.Jul 18 2016, 7:49 PM
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptAug 8 2016, 1:52 AM

Where would the check for the siteurl being part of a link (and then not setting the 'external' icon) have to happen?
makeExternalLink() in /includes/Linker.php (and /tests/phpunit/includes/LinkerTest.php), by checking against fullurl from the CoreParserFunctions ?

Krinkle removed a subscriber: Krinkle.Jan 4 2017, 5:28 AM
demon removed a subscriber: demon.Mar 9 2017, 9:45 PM

Removing good first bug until someone answers T13477#2877377. Please re-add after answering.

Pcj added a subscriber: Pcj.Jan 3 2019, 3:25 PM
Restricted Application added a project: Design. · View Herald TranscriptMay 22 2019, 9:09 PM
Restricted Application added a subscriber: Liuxinyu970226. · View Herald Transcript

@alexhollender @Volker_E This seems related to on-going design research about external links:

Is this worth keeping a separate task for, or should this be incorporated elsewhere? Also, if kept separately, is there an easy answer to this from a user experience? Even if not a priority, if this an acceptable change, feel free to add patch-welcome.

alexhollender added a subscriber: Krinkle.

@Krinkle if I understand this correctly: in some cases there are internal links that are getting marked as external. This seems like a bug that we should fix independent of T190549.