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

happy_melon wrote:

Patch against r47095

Can it really be *this* simple? What's the catch?

attachment bug14323.txt ignored as obsolete

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

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

(In reply to bug 15614 comment #4)

This is working as designed, they were never meant to resolve all this fancy
stuff. Redirect resolution is currently a simple regex on the raw wikitext.

(In reply to bug 17690 comment #1)

Recommend WONTFIX. Whether a page is a redirect (and where to) is stored in and
read from the database, not from the page itself. Having a page that is a
redirect under certain circumstances and not a redirect under other
circumstances ranges from crazy to impossible, depending on who you ask.

We do not parse redirects. We have a simple regex to parse the raw links and--because it was so highly requested--the categories on the page. Asking for more is requesting a full parse of the page, which is IMO a bad idea. Going ahead and WONTFIXing this per this and the above comments.

happy.melon.wiki wrote:

(I assume you meant bug15164 comment #4, not the one about Cortado :D)

I know we don't parse redirects currently; that's why it's listed as an enhancement. Your comments in the two bugs you duped to this one both merely highlight this point. Nothing in any of these bugs suggests *why* you insist that parsing redirect pages is a Bad Idea. I don't think your WONTFIX is responding to the right question.

I'm not saying that we should make redirects dynamic: #REDIRECT[[{{CURRENTYEAR}}]] is still a Bad Thing; this is AFAIK what you're really concerned about. My patch doesn't change the way redirect targets are resolved, only the way the redirect page *itself* is displayed. What's so bad about that?

William.Allen.Simpson wrote:

This used to work, and stopped working. That's a regression. The {{R from}} templates relied upon it.

(In reply to comment #5)

We do not parse redirects. We have a simple regex to parse the raw links
and--because it was so highly requested--the categories on the page. Asking for
more is requesting a full parse of the page, which is IMO a bad idea. Going
ahead and WONTFIXing this per this and the above comments.

Err... Then what is line 996 in Article.php (r50332) doing? Looks like it parses the whole redirect page in order to update category links, template transclusions, and so on; just the output text is not actually used.

(In reply to comment #7)

This used to work, and stopped working. That's a regression. The {{R from}}
templates relied upon it.

As far as I can tell from looking at the history of Article.php, redirect content (when viewed with redirect=no) was rendered as a normal page up until r4568; however, redirects were limited to only a single line of wikitext until r12339. I don't see any reason given for r4568 to stop displaying the rest of the redirect page's content, although that doesn't mean there wasn't one.

The only objection I can see to rendering the redirect page content would be the opportunity it presents for someone to vandalize a page that few would ever look at (and then, presumably, post a link on some other website with redirect=no to say "Ha ha! Stupid Wikipedia didn't fix my vandalism!").

happy.melon.wiki wrote:

(In reply to comment #8)

Err... Then what is line 996 in Article.php (r50332) doing? Looks like it
parses the whole redirect page in order to update category links, template
transclusions, and so on; just the output text is not actually used.

My thoughts exactly; my patch above only changes this one line. There is clearly no fundamental reason why it *can't* be done't; for some reason a conscious decision has been made not to.

The only objection I can see to rendering the redirect page content would be
the opportunity it presents for someone to vandalize a page that few would ever
look at (and then, presumably, post a link on some other website with
redirect=no to say "Ha ha! Stupid Wikipedia didn't fix my vandalism!").

I expect that if my patch was applied straight, we'd get "#REDIRECT[[Foo]]" output at the top of the page; that would need to be stripped from the wikitext before rendering. Maybe I'll load up that patch on my new test wiki and see what happens, and how easy it is to fix. It shouldn't be difficult. Other than that, I can't see any reason not to; the 'lulz' factor is even lower here because vandalism is not normally visible to readers No, Stupid Wikipedia didn't fix the vandalism, but only because Stupid Vandal put it somewhere no one would ever see it :D

happy.melon.wiki wrote:

Better patch, against r50568

Tested my original patch; as I expected, it did indeed render the "#REDIRECT[[Foo]]" in plaintext underneath the 'proper' redirect. I stole the code from Title::newFromRedirectInternal to remove the code from the wikitext. A better solution would be to have the Parser replace the #REDIRECT marker with Article::viewRedirect when it encounters it, but this method works. Patch tested and works for normal display, however for some reason it does not render the page contents on page preview, which is a bit wierd.

attachment bug14323-2.txt ignored as obsolete

(In reply to comment #10)

Created an attachment (id=6117) [details]
Better patch, against r50568

Tested my original patch; as I expected, it did indeed render the
"#REDIRECT[[Foo]]" in plaintext underneath the 'proper' redirect. I stole the
code from Title::newFromRedirectInternal to remove the code from the wikitext.
A better solution would be to have the Parser replace the #REDIRECT marker with
Article::viewRedirect when it encounters it, but this method works. Patch
tested and works for normal display, however for some reason it does not render
the page contents on page preview, which is a bit wierd.

One criticism: "#REDIRECT [[foo]] {{bar}}" renders as " {{bar}}" rather than "{{bar}}", which means the template output is rendered in <pre></pre> tags. That will be a problem on enwiki, as many redirects still follow the pre-r12339 rule. Perhaps either "\s*" or " *" (depending on whether you want to eat blank lines or just the problematic spaces) should be added to the end of your regex?

Other than that, it seems to work well.

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

• This bug has been marked as a duplicate of bug 13595 ***

Bug 13595 is about showing some redirect-specified content ''on the target page'' when visited via the redirect. This bug is about showing the content of the redirect page ''on the redirect page itself'' when you visit it with redirect=no.

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

Very curious about this enhancement! There's been no activity for half a lustrum, and when reading the comments, it seems like such an easy thing to do. Has it become exceedingly difficult?

I second Paine's comment above. If there is a reason why this has not been fixed please can someone explain the reasons why so that the problems can be addressed? It seems such a trivial thing to implement, but with so many duplicates it seems well desired.

I came here via http://en.wikipedia.org/wiki/Wikipedia:Templates_for_discussion/Log/2012_April_8#Template:This_is_a_redirect and comments there may help developers understand the desire for this enhancement (is lack of understanding why it's wanted perhaps the reason why nothing has been done yet?).

As long as no developer closes this ticket as WONTFIX your patches are welcome, however if comment 5 is still valid some performance testing should probably also take place.

Thank you for the "second". I've been an advocate for the "This is a redirect" template, which enhances the way redirect category templates are resolved on Diff pages. If something similar to that enhancement can be produced directly on Redirect pages, along with other pertinent text, then the need for the This is a redirect template would be gone. Until this bug is resolved, though, I will continue to support that template. I use it on every Redirect page that I categorize.

It was previously stated that a full parse of the page would be a bad idea. Then there was something about a full parse being already in place, with the text the only exception, and so on. Nothing is really helped when a WONTFIX is reopened, and it's ignored. This bug's been reopened at least two times.

This so far looks like a good idea that has no significant implementation hassles, so please assign this to a dev and let's get the Redirects fixed.

. . . I've been an advocate for the "This is a redirect" template, which
enhances the way redirect category templates (their texts) are resolved on
Diff pages. . .

I just checked some Diff pages and found something peculiar. In fact, this might qualify as a new bug. I'm not sure if I should open a new bug or if this new challenge might be related to this bug. I indicated above that redirect category templates (Rcats) render their text on Diff pages, and that the "This is a redirect" template enhances the way that text appears. That does not happen anymore. The Rcats still place redirects into appropriate categories, as is their main function to do. However, their texts are no longer rendered even on Diff pages!

I tested this in three browsers: IE v9, Firefox v16 and Chrome v23, and I checked several redirects with Rcats, both with the This is a redirect template and without it by using the bare Rcats on the top line of the redirect page.

In no case was there any text rendered on the Diff pages, anymore.

So fellow editors and you devs, is this a new but related problem? Or do you think I should open a new bug report?

(In reply to comment #20)

So fellow editors and you devs, is this a new but related problem? Or do you
think I should open a new bug report?

New, but probably not worth a separate bug since the change seems to have been made to standardize with the article display.

(In reply to comment #21)

(In reply to comment #20)

So fellow editors and you devs, is this a new but related problem? Or do you
think I should open a new bug report?

New, but probably not worth a separate bug since the change seems to have been
made to standardize with the article display.

That's difficult to understand. I know that articles will be displayed beneath the Diff panels, but how exactly does removing "redirect category template" texts entirely from the Diff pages work toward standardization with article displays?

Bug 42642 has been opened to report the text removed from redirect Diff pages.

Change 105829 had a related patch set uploaded by Anomie:
Move redirect rendering into WikitextContent

https://gerrit.wikimedia.org/r/105829

Change 105831 had a related patch set uploaded by Anomie:
Use WikitextContent to render redirects

https://gerrit.wikimedia.org/r/105831

Change 105832 had a related patch set uploaded by Anomie:
Use WikitextContent to render redirects

https://gerrit.wikimedia.org/r/105832

Change 105829 merged by jenkins-bot:
Move redirect rendering into WikitextContent

https://gerrit.wikimedia.org/r/105829

Change 105832 merged by Aaron Schulz:
Use WikitextContent to render redirects

https://gerrit.wikimedia.org/r/105832

Change 105831 merged by jenkins-bot:
Use WikitextContent to render redirects

https://gerrit.wikimedia.org/r/105831

Should be deployed to WMF wikis with 1.23wmf10, see https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap for the schedule.