Wikimedia Bugzilla is closed!

Anchors have never worked (and were never meant to work) in redirects.  I have
no idea why people keep putting them in, apparently not noticing that they
simply don't work.

There is no easy way of fixing this.  One could either:

* have [[Structural proof theory]] turn into a link to
  /wiki/Structural_proof_theory#Structural_proof_theory,
  but this would mean that, when we parse a page, we would have to check *all*
  the pages linked to to see if any of them happens to be a redirect with an
  anchor in it, thereby increasing the database load significantly; or

* have redirects with an anchor produce a 502 response that actually redirects
  the browser to /wiki/Proof_theory#Structural_proof_theory,
  but this would mean that the user will no longer see the "redirected from"
  message, and hence, it will be very difficult for people to change the
  redirect (because one would have to manually fiddle with the URL, or go
  through Whatlinkshere, but the latter is difficult to think of if you don't
  know).

This is why we'd rather not have redirects with an anchor.

302'ing to
/w/wiki.phtml?title=Proof_theory&from=Structural_proof_theory#Structural_proof_theory
could do the job

The reason people keep putting them in us because
http://en.wikipedia.org/wiki/Wikipedia:How_does_one_edit_a_page says "This
feature may be implemented in the future, so such redirects could be used now
for future compatibility."

(In reply to comment #2)
> 302'ing to
> /w/wiki.phtml?title=Proof_theory&from=Structural_proof_theory#Structural_proof_theory
> could do the job

I'd recommend against that sort of thing. First, it's ugly as heck. :) Second, it harms caching and 
googlability (since that page would be forbidden by robots.txt).

Note also that the fragment identifier (the bit from the #) isn't sent to the server, so we can't tell whether we're 
being requested to go to a particular fragment already -- we'd lose subsection fragments, for instance, if 
someone wanted to use such.

> 302'ing to /w/wiki.phtml?title=X&from=Y#Z could do the job

I should have thought of this, and should have mentioned the concerns with this
(which brion already did).  We don't want to add too many URL parameters that
don't really do much (this one would only add the "redirected from" message).

> The reason people keep putting them in us because
> http://en.wikipedia.org/wiki/Wikipedia:How_does_one_edit_a_page says [...]

This seriously needs to be changed.  I'm afraid this feature is not feasible, as
much as I would like to have it.  (I wish in addition to "WONTFIX" there was
"CANTFIX" :-))

Fixed http://en.wikipedia.org/wiki/Wikipedia:How_does_one_edit_a_page 

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

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

Maybe there's a JavaScript solution, something like (untested):

<script language="JavaScript"><!--
if(frame.location.hash == '') {
  frame.location.hash = '#Structural_proof_theory';
}
//--></script>

According to http://wp.netscape.com/eng/mozilla/3.0/handbook/javascript/ref_h-l.htm#146128 setting the hash does not reload the document.

This could be injected along with the "Redirected from" message.

Erm, that should be:

<script language="JavaScript"><!--
if(window.location.hash == '') {
  window.location.hash = '#Structural_proof_theory';
}
//--></script>

"* have [[Structural proof theory]] turn into a link to
  /wiki/Structural_proof_theory#Structural_proof_theory,
  but this would mean that, when we parse a page, we would have to check *all*
  the pages linked to to see if any of them happens to be a redirect with an
  anchor in it, thereby increasing the database load significantly; or"
How does this require higher server load than a regular redirect?  When I go to
http://en.wikipedia.org/wiki/William_Clinton, it notices that the page is a
redirect and sends me to http://en.wikipedia.org/wiki/Bill_Clinton, and serves a
notice that it did so.  If I have a redirect at
http://en.wikipedia.org/wiki/Bill_Clinton trivia]] to
http://en.wikipedia.org/wiki/Bill Clinton#Trivia, how is that more work for the
servers?

I MEANT:

"* have [[Structural proof theory]] turn into a link to
  /wiki/Structural_proof_theory#Structural_proof_theory,
  but this would mean that, when we parse a page, we would have to check *all*
  the pages linked to to see if any of them happens to be a redirect with an
  anchor in it, thereby increasing the database load significantly; or"
How does this require higher server load than a regular redirect?  When I go to
http://en.wikipedia.org/wiki/William_Clinton, it notices that the page is a
redirect and sends me to http://en.wikipedia.org/wiki/Bill_Clinton, and serves a
message that it did so.  If I have a redirect at
http://en.wikipedia.org/wiki/Bill_Clinton_trivia to
http://en.wikipedia.org/wiki/Bill Clinton#Trivia, how is that more work for the
servers?

If you go to http://en.wikipedia.org/wiki/William_Clinton it shows you the contents of the [[Bill Clinton]] page (with a redirection note), but it does *not* redirect you to http://en.wikipedia.org/
wiki/Bill_Clinton in the HTTP sense.  The MediaWiki redirection that is done is purely server-side.  An HTTP redirection requires the server to instruct the browser to ask the server for a different 
page.  This involves another browser-server round trip, and another server request, so increases both latency and server load.

Normally, an HTTP redirect is required to change the URL, and this is why the URL remains at "William Clinton" while you see the "Bill Clinton" page.  Adding a secttion anchor would require 
changing the URL.  The JavaScript above gives a way to do a browser-side redirect to a section anchor within the same document.  This would allow MediaWiki redirection to go to a specific section 
without sending another request to the server.

The remaining flaw in my proposed solution is that the redirection notice at the top would likely not be visible when the page is scrolled down to the section, thus potentially increasing user 
confusion.  I don't think that moving the redirection notice down to the section header would be a good idea, however.

My preferred "solution" to this would be in combination with a "manual text in
redirect message" feature, as discussed here:
http://mail.wikimedia.org/pipermail/wikitech-l/2005-May/029142.html 

Basically, "#redirect [[foo#bar]]" could add a string to the end of the
"Redirected from..." message so that it read something like "Redirected from
[[X]]. For information on [[X]] see the section titled [[#bar|bar]] below." As I
say in that message, though, I would consider this solution to depend on bug
1521 in some form...

Oh, and note Lee Crocker's response in that thread, which also applies here I
think: http://mail.wikimedia.org/pipermail/wikitech-l/2005-May/029158.html

Hallo!

Today I used
http://en.wikipedia.org/wiki/IPA#Note:_This_page_uses_special_characters
and this was equivalent to
http://en.wikipedia.org/wiki/International_Phonetic_Alphabet#Note:_This_page_uses_special_characters
From Wikipedia, the free encyclopedia that anyone can edit
(Redirected from IPA)

I was puzzeled!!! I never tried this before.
I was more puzzeled when making the redirect tests at
[[en:User:Gangleri/tests/bugzilla/00218]].
I was more and more and more puzzeled reading the "historical" comments here.

Whould it be possible *today* (whit MediaWiki as far as is is now) to simply
change the redirect.php (or whatever) and do the following:

a) preserve the anchor when rendering the redirect page; if necessary preserve
it in another variable as #bar
b) forward the anchor as parameter in order to be displayed as (Redirected from
foo|bar)

best regards reinhardt [[user:gangleri]]

P.S.
duplicates of bug 218
- Bug 466: redirects don't lead to the precise anchor specified with them
- Bug 1282: #redirect [[lemma#sublemma]] does not work

I searched a bug which depends on bug 218 and 1476. The searched bug is bug 1333
(==bug 2688).

The whole dupes and dependencies should be updated.

Bug 1476: Category tag on redirect pages does not work
ignore bug 1476 comment 1 about relation to Bug 710: Redirect to category page
doesn't work
duplicates of bug 1476
- (reopened) Bug 491: Categories need piping feature to list by alternative name
- ** Bug 1333: Would like the ability to list an article under multiple names in
its categories **
-- duplicate of bug 1333
--- ** Bug 2688: Pages cannot be listed multiple times in a category **
- Bug 2278: redirect pages cannot be added to categories
- Bug 3344: Redirected terms cannot be included in categories

Bug 1476 works (again). Else I did not get the point. See
[[en:User:Gangleri/tests/bugzilla/00218/Icelandic Sheepdog section External links]]
http://en.wikipedia.org/w/index.php?title=Category:Dog_breeds&from=I

(In reply to comment #15)

In pure, clean English, without loading it full of URLs and unrelated test
cases, please explain what the hell you did, and what your comment *means* -
that's complete gibberish, I'm afraid to say, and frankly, incomprehensible.

from irc://irc.freenode.net/#mediawiki

<gangleri> robchurch : re: http://bugzilla.wikimedia.org/show_bug.cgi?id=218 Why
does http://en.wikipedia.org/wiki/IPA#Note:_This_page_uses_special_characters
work ???
<gangleri> This is an anchor used with as a redirect to [[en:IPA]].
<robchurch> Because the browser is instructed to go to that anchor on whatever
it loads, when it finishes loading it.
<gangleri> ok.
<gangleri> can we use this?
<robchurch> Because IPA redirects to International Phonetic Alphabet, there ends
up being an anchor with that name on what the browser sees.
<robchurch> So no, it's of o use to us.
<gangleri> I did not know these details.
----
*note*
The anchor works for me with the redirect in Firefox but *not* in IE.

----
regarding all these "unrelated testcases"
Rob I appreciate that you are and think like a developer. I am intersted to find
out the dependencies in order to find solutions as for bug is bug 1333 (==bug
2688). If bug 218 would be fixed it would be half the job. The other half is
related to "adding redirects to categories". But the relations between all the
reports in MediaZilla relating to "adding redirects to categories" are not up to
date.

It is not clear at all the "adding redirects to categories" works at WP:, WIKT:
... and is not clear which MediaWiki revisions / branches support this and which
not.

After having reviewed the above with Gangleri in IRC, where we worked a couple
of these things out, marking as WONTFIX once more owing to the fact that we
can't implement this in a nice, clean fashion.

(In reply to comment #6)
> Fixed http://en.wikipedia.org/wiki/Wikipedia:How_does_one_edit_a_page 

On what basis can we guarantee that this feature will *never* be implemented? All I can see is 
that *currently* the consensus is that using the *current* tools it is not practical.

(In reply to comment #19)
> On what basis can we guarantee that this feature will *never* be implemented?
All I can see is 
> that *currently* the consensus is that using the *current* tools it is not
practical.

I've changed the text in question to state that it's "very unlikely" - the key
point is that people shouldn't use redirects like that as though they are about
to work, because the chances are they never will. Yes, someone might implement a
cunningly innovative way of dealing with them, but there's no point anyone
holding their breath for it, as it were.

The JavaScript bit ten comments above would do the job fine. The remaining question is whether we *want* to support that or not.

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

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

(In reply to comment #21)
> The JavaScript bit ten comments above would do the job fine. The remaining
question is whether we *want* to support that or not.
> 

Thanks Brion for your feedback!

If it is possible to implement this it will be great thing. If some wikies do
not like it anabeled please make it as an option.

There are more aspects:
a) the *functionality*
It is the *most* important. If somebody makes a redirect to a section / anchor
in a very long page this would help visitors to go to this section / anchor
b) the *details*
b1) redirect to section
If a redirect from [[foo]] could be displayed below the section via Java this
would be great. If this will cause problems with caching do not implement b1).
b2) redirect to anchors
These can be at any place inside the page wiki source and render also to places
inside tables, image captions, galeries etc.
It is obvious that the link is pointing somewhere else then to the top of the
page. I assume that people can live with that.
c) robots: follow / no follow 
I have no idea about this. Some spommers could start to vondalize redirects if
they will think that they can have a benefit from this ...
&redirect=no does not show their actions immediatelly. Only &diff and
&action=edit will show them. Not all such ottacks might be detected. But this is
another issue / possibly another bug / request.
d) others


(In reply to comment #0)
> If one creates a redirect with a named anchor, such as:
>   Page http://en.wikipedia.org/wiki/Structural_proof_theory
>   contains just "#REDIRECT[[Proof theory#Structural_proof_theory]]"
> I expected the behaviour to be, the tag [[Structural proof theory]]
> either links to the page [[Proof theory#Structural_proof_theory]]
> or to [[Structural_proof theory#Structural_proof_theory]].

Personally I think that [[Proof theory#Structural_proof_theory]] is the target
and *not* [[Structural_proof theory#Structural_proof_theory]].

best regards reinhardt [[user:gangleri]]

Who the hell keeps marking this WONTFIX?

The following works for me as an extension:

<?php

$wgHooks["ArticleViewRedirect"][] = 'wfRedirectJump';

function wfRedirectInjectJS($data, &$parser, &$text) {
    $text .= $data;
}

function wfRedirectJump (&$array) {
    global $wgHooks;

    $section = $array->mTitle->mFragment;
    if($section) {
        $inject = '<script>'
                 .'window.location.hash = \''.$section.'\';'
                 .'</script>';
        $wgHooks['ParserAfterTidy'][] = array('wfRedirectInjectJS', $inject);
    }

    return true;
}

?>

How about adding a notice to the "Redirected from ..." message.
If there is a section with the right name, a link could be added

(Redirected from [[Proof Theory]])
(Jump to [[#Structural Proof Theory]])

That seems no big deal implementationwise.
The existing links would have a meaning and 
it would be easy for the user to jump to the right section.

Regards,
Piet

(In reply to comment #27)
> How about adding a notice to the "Redirected from ..." message.
> If there is a section with the right name, a link could be added
> 
> (Redirected from [[Proof Theory]])
> (Jump to [[#Structural Proof Theory]])
> 
> That seems no big deal implementationwise.
> The existing links would have a meaning and 
> it would be easy for the user to jump to the right section.
> 
> Regards,
> Piet

I agree.

Here's a javascript workaround:

http://en.wikipedia.org/wiki/User:Omegatron/monobook.js/namedredirect.js

I've been meaning to learn AJAX, and this is my first ever use of
XMLHttpRequest, so it probably needs a lot of work, has strange bugs, etc.

Test cases:

[[User:Omegatron/Sandbox/Redirector]]
[[User:Omegatron/Sandbox/Redirector2]]
[[i.e.]]
[[e.g.]]
[[et al.]]
[[Embiggens]]
[[Skittlebrau]]

I fail to see how doing an HTTP redirect from /wiki/Foo to
/wiki/Bar?redirectedfrom=Foo#anchor would harm caching.

The way it is done now, a cache will have to cache both /wiki/Foo and /wiki/Bar
- making it cache /wiki/Bar and /wiki/Bar?redirectedfrom=Foo instead wouldn't
change anything. Indeed if we want to keep the "Redirected from" link, then we
*need* to keep caching it in 2 places. Having to cache an extra HTTP redirect is
not going to kill anybody, and probably won't happen at all with 303 redirect
(which the standards say must not be cached).

The only effect would be for a brief period after it was changed, when
/wiki/Foo, /wiki/Bar and /wiki/Bar?redirectedfrom=Foo would all be cached, and
even then it would be only until the cache on Foo expired.

Though I'm thinking of end-user caching, and serverside caching might be
different, but I can't think of a way that the server could cache redirects now
that couldn't be done with HTTP redirects.

IT WOULD HAVE NOTHING TO DO WITH CACHING. PLEASE NO ONE COMMENT
FURTHER ON THIS BUG UNLESS YOU'RE POSTING A PATCH TO CURRENT
CODE OR COMMENTING DIRECTLY ON THE QUALITY OF THE PATCH.
THANK YOU.

Looks like a typo in Wiki.php:

===================================================================
--- includes/Wiki.php   (revision 13988)
+++ includes/Wiki.php   (working copy)
@@ -225,7 +225,7 @@
                                        if ($rarticle->mTitle->mArticleID) {
                                                $article = $rarticle;
                                                $wgTitle = $target;
-                                               $article->setRedirectedFrom(
$title );
+                                               $article->setRedirectedFrom(
$target );
                                        } else {
                                                $wgTitle = $title;
                                        }


Commited as r13993 in trunk, not backported in REL1_6 yet.

There is some code in Article::view() ( line 800 and below ) that seems
to be a duplicate of the above Wiki.php code. Need investigation :)

Given an article [[RedirectAnchor]] that contains:

#REDIRECT [[218/longtext#anchorlast]]

It redirects to:
$wgServer/wiki?title=218/longtext&lrfrom=RedirectAnchor#anchorlast

It is an ugly URL but it works, commited in my branch as r14000

I have reverted r13993

Please don't make some ugly URL, it's totally unnecessary.

I've been using my javascript workaround since March with no problems.  Is this
something that people would want to put into Monobook.js sitewide?  Is there a
Common.js for all skins?

Judging by this crazy line, there is a Common.js:

<style type="text/css">/*<![CDATA[*/
@import "/w/index.php?title=MediaWiki:Common.css&action=raw&ctype=text/css&smaxage=2678400";
@import "/w/index.php?title=MediaWiki:Monobook.css&action=raw&ctype=text/css&smaxage=2678400";
@import "/w/index.php?title=-&action=raw&gen=css&maxage=2678400";
/*]]>*/</style>

Those are all CSS.  I believe wikibits.js is common to all skins, but there's no
in-wiki equivalent of [[MediaWiki:Common.css]], no.  See bug 4178.

(In reply to comment #39)
> Those are all CSS.  I believe wikibits.js is common to all skins, but there's no
> in-wiki equivalent of [[MediaWiki:Common.css]], no.  See bug 4178.

Ah.  Well it could be added to wikibits, if desired.  Same thing.

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

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

(In reply to comment #37)
> I've been using my javascript workaround since March with no problems.  Is this
> something that people would want to put into Monobook.js sitewide?  Is there a
> Common.js for all skins?

Omegatron, is that a pure JavaScript workaround that requires no MediaWiki
patches? Could you point me to details?

(In reply to comment #43)

> Omegatron, is that a pure JavaScript workaround that requires no MediaWiki
> patches? Could you point me to details?

Yes.  Details were in comment #29.  It checks to see if you were redirected to
the current page.  If so, it checks the redirector page to see if there's a hash
in the link.  If there is, it navigates to it.

You can try it out by adding this to your monobook.js:

document.write('<scr' + 'ipt type="text/javascript" src="' 
             +
'http://en.wikipedia.org/w/index.php?title=User:Omegatron/monobook.js/namedredirect.js'
             + '&action=raw&ctype=text/javascript&dontcountme=s"></scr' 
             + 'ipt>');

Then click my example links in comment #29

Fixed in r18220.

Long delayed followup:

Now that there are redirect tables listing redirects, and also now that each link is checked for redirectitude (they are given a CSS class if they are), could this be done in the base links rather than on the target page, eliminating the need for the javascript hack? Do the redirect tables store the section hash?

 /wiki/Structural_proof_theory#Structural_proof_theory <-- per above, best would be to generate the link and keep the link to the redirect, but include the hash for the target (same as the javascript code does).

If possible, maybe worth reopening?

(In reply to comment #46)
> Now that there are redirect tables listing redirects, and also now that each
> link is checked for redirectitude (they are given a CSS class if they are),
> could this be done in the base links rather than on the target page,
> eliminating the need for the javascript hack?

It wouldn't eliminate the need for the hack, because people could still type the URL directly into their address bar, or into the search bar, etc.  However, it would reduce the need for it, I suppose, if that's a big deal.

> Do the redirect tables store the
> section hash?

No.

> If possible, maybe worth reopening?

No, open a new bug.  Either link to it here or mark this bug as blocking it.