Redirect pages should render all text
Closed, ResolvedPublic

Description

Author: lenoxuss

Description:
Right now, redirect pages are limited to rendering the usual redirect information, plus categories at the bottom. It would be pretty cool if, for example, templates could be rendered as well, either on the first line, or after it, or on any line, or whatever. This is related to bug 927 but is not identical; that one was closed as FIXED because the specific problem of text after the first line not being rendered has been fixed. However, this only means that categories after the first line are rendered; it's still the case that no other kind of text on any line is rendered.

So what, if anything, is preventing the possibility of other text rendering? Could we see this in a near-future update?


Version: 1.13.x
Severity: enhancement

bzimport added a project: MediaWiki-Redirects.Via ConduitNov 21 2014, 10:09 PM
bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz14323.
bzimport created this task.Via LegacyMay 29 2008, 1:12 AM
Anomie added a comment.Via ConduitFeb 10 2009, 4:49 PM
  • Bug 17436 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitFeb 10 2009, 5:18 PM

happy_melon wrote:

Patch against r47095

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

attachment bug14323.txt ignored as obsolete

demon added a comment.Via ConduitMar 19 2009, 6:07 PM
  • Bug 15164 has been marked as a duplicate of this bug. ***
demon added a comment.Via ConduitMar 19 2009, 6:07 PM
  • Bug 17690 has been marked as a duplicate of this bug. ***
demon added a comment.Via ConduitMar 19 2009, 6:12 PM

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

bzimport added a comment.Via ConduitMar 23 2009, 5:09 PM

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?

bzimport added a comment.Via ConduitMay 13 2009, 6:26 AM

William.Allen.Simpson wrote:

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

Anomie added a comment.Via ConduitMay 13 2009, 12:49 PM

(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!").

bzimport added a comment.Via ConduitMay 13 2009, 2:20 PM

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

bzimport added a comment.Via ConduitMay 14 2009, 9:42 AM

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

Anomie added a comment.Via ConduitMay 14 2009, 1:40 PM

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

demon added a comment.Via ConduitJul 28 2009, 11:05 AM
  • Bug 17183 has been marked as a duplicate of this bug. ***
demon added a comment.Via ConduitSep 20 2009, 8:31 AM
  • This bug has been marked as a duplicate of bug 13595 ***
Anomie added a comment.Via ConduitSep 21 2009, 1:23 PM

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.

demon added a comment.Via ConduitOct 8 2009, 2:05 AM
  • Bug 21045 has been marked as a duplicate of this bug. ***
Paine_Ellsworth added a comment.Via ConduitMar 25 2012, 4:23 PM

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?

Thryduulf added a comment.Via ConduitNov 24 2012, 12:20 PM

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?).

Aklapper added a comment.Via ConduitNov 25 2012, 12:02 AM

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.

Paine_Ellsworth added a comment.Via ConduitNov 27 2012, 2:19 AM

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.

Paine_Ellsworth added a comment.Via ConduitNov 28 2012, 12:04 AM

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

Anomie added a comment.Via ConduitNov 28 2012, 12:12 AM

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

Paine_Ellsworth added a comment.Via ConduitNov 28 2012, 12:47 AM

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

Paine_Ellsworth added a comment.Via ConduitDec 3 2012, 5:40 AM

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

gerritbot added a comment.Via ConduitJan 6 2014, 9:30 PM

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

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

gerritbot added a comment.Via ConduitJan 6 2014, 9:31 PM

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

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

gerritbot added a comment.Via ConduitJan 6 2014, 9:32 PM

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

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

gerritbot added a comment.Via ConduitJan 7 2014, 10:45 PM

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

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

gerritbot added a comment.Via ConduitJan 7 2014, 10:49 PM

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

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

gerritbot added a comment.Via ConduitJan 7 2014, 11:18 PM

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

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

Anomie added a comment.Via ConduitJan 8 2014, 4:47 PM

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

Add Comment