timwi wrote:

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.

jeluf wrote:

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

beesley wrote:

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.

timwi wrote:

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" :-))

wikimedia-bugzilla wrote:

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

jeluf wrote:

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

rowan.collins wrote:

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

wiki wrote:

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.

wiki wrote:

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?

wiki wrote:

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.

rowan.collins wrote:

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

gangleri wrote:

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

robchur wrote:

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

gangleri wrote:

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.

robchur wrote:

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.

brian wrote:

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

rowan.collins wrote:

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

robchur wrote:

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

robchur wrote:

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

gangleri wrote:

(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?

patrick wrote:

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;

}

?>

pietdesomere wrote:

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

rotemliss wrote:

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

ui2t5v002 wrote:

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

phlipping wrote:

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.

ui2t5v002 wrote:

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?

brian wrote:

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>

ayg wrote:

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.

ui2t5v002 wrote:

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

DmitryKo wrote:

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

ayg wrote:

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

nyenyec wrote:

(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?

ui2t5v002 wrote:

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

herd wrote:

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?

ayg wrote:

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