Author: cas
Description: 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]].
In fact it does not work like this, but is instead a link to
http://en.wikipedia.org/wiki/Structural_proof_theory
(ie. with the anchor part stripped out).
This means that redirects cannot be to sections, which restricts the flexibility in handling merges of material, reduces the accuracy of links into long articles, encourages the proliferation of stub articles in Wikipedia or short articles rehearsing parts of material contained in longer articles, perhaps reduces the longevity of links.
Version : 1.3.x Severity : enhancement
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:
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)
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" :-))
wikimedia-bugzilla wrote:
Fixed http://en.wikipedia.org/wiki/Wikipedia:How_does_one_edit_a_page
*** 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.
Erm, that should be:
<script language="JavaScript"><!-- if(window.location.hash == '') {
window.location.hash = '#Structural_proof_theory';
"* 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:
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 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
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
its 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.
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.
*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.
brian wrote:
(In reply to comment #6)
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]].
If one creates a redirect with a named anchor, such as:
Personally I think that [[Proof theory#Structural_proof_theory]] is the target and *not* [[Structural_proof theory#Structural_proof_theory]].
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
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 (working copy) @@ -225,7 +225,7 @@
if ($rarticle->mTitle->mArticleID) { $article = $rarticle; $wgTitle = $target;
$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>
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.
(In reply to comment #39)
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. ***
*** Bug 7176 has been marked as a duplicate of this bug. ***
nyenyec wrote:
(In reply to comment #37)
Omegatron, is that a pure JavaScript workaround that requires no MediaWiki patches? Could you point me to details?
(In reply to comment #43)
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?
(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.
No, open a new bug. Either link to it here or mark this bug as blocking it.