Last modified: 2014-02-22 03:41:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T16323, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 14323 - Redirect pages should render all text
Redirect pages should render all text
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Redirects (Other open bugs)
1.13.x
All All
: Low enhancement with 6 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 15164 17436 17690 21045 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-29 01:12 UTC by Chris
Modified: 2014-02-22 03:41 UTC (History)
18 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch against r47095 (1.01 KB, patch)
2009-02-10 17:18 UTC, Happy-melon
Details
Better patch, against r50568 (1.04 KB, patch)
2009-05-14 09:42 UTC, Happy-melon
Details

Description Chris 2008-05-29 01:12:53 UTC
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?
Comment 1 Brad Jorsch 2009-02-10 16:49:38 UTC
*** Bug 17436 has been marked as a duplicate of this bug. ***
Comment 2 Happy-melon 2009-02-10 17:18:39 UTC
Created attachment 5797 [details]
Patch against r47095

Can it really be *this* simple?  What's the catch?
Comment 3 Chad H. 2009-03-19 18:07:37 UTC
*** Bug 15164 has been marked as a duplicate of this bug. ***
Comment 4 Chad H. 2009-03-19 18:07:49 UTC
*** Bug 17690 has been marked as a duplicate of this bug. ***
Comment 5 Chad H. 2009-03-19 18:12:32 UTC
(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.
Comment 6 Happy-melon 2009-03-23 17:09:40 UTC
(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?
Comment 7 William Allen Simpson 2009-05-13 06:26:31 UTC
This used to work, and stopped working. That's a regression. The {{R from}} templates relied upon it.
Comment 8 Brad Jorsch 2009-05-13 12:49:30 UTC
(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!").
Comment 9 Happy-melon 2009-05-13 14:20:35 UTC
(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
Comment 10 Happy-melon 2009-05-14 09:42:43 UTC
Created attachment 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.
Comment 11 Brad Jorsch 2009-05-14 13:40:41 UTC
(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.
Comment 12 Chad H. 2009-07-28 11:05:52 UTC
*** Bug 17183 has been marked as a duplicate of this bug. ***
Comment 13 Chad H. 2009-09-20 08:31:13 UTC

*** This bug has been marked as a duplicate of bug 13595 ***
Comment 14 Brad Jorsch 2009-09-21 13:23:16 UTC
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.
Comment 15 Chad H. 2009-10-08 02:05:41 UTC
*** Bug 21045 has been marked as a duplicate of this bug. ***
Comment 16 Paine Ellsworth 2012-03-25 16:23:10 UTC
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?
Comment 17 Chris McKenna 2012-11-24 12:20:00 UTC
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?).
Comment 18 Andre Klapper 2012-11-25 00:02:39 UTC
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.
Comment 19 Paine Ellsworth 2012-11-27 02:19:36 UTC
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.
Comment 20 Paine Ellsworth 2012-11-28 00:04:22 UTC
> . . . 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?
Comment 21 Brad Jorsch 2012-11-28 00:12:01 UTC
(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.
Comment 22 Paine Ellsworth 2012-11-28 00:47:18 UTC
(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?
Comment 23 Paine Ellsworth 2012-12-03 05:40:54 UTC
Bug 42642 has been opened to report the text removed from redirect Diff pages.
Comment 24 Gerrit Notification Bot 2014-01-06 21:30:32 UTC
Change 105829 had a related patch set uploaded by Anomie:
Move redirect rendering into WikitextContent

https://gerrit.wikimedia.org/r/105829
Comment 25 Gerrit Notification Bot 2014-01-06 21:31:41 UTC
Change 105831 had a related patch set uploaded by Anomie:
Use WikitextContent to render redirects

https://gerrit.wikimedia.org/r/105831
Comment 26 Gerrit Notification Bot 2014-01-06 21:32:02 UTC
Change 105832 had a related patch set uploaded by Anomie:
Use WikitextContent to render redirects

https://gerrit.wikimedia.org/r/105832
Comment 27 Gerrit Notification Bot 2014-01-07 22:45:07 UTC
Change 105829 merged by jenkins-bot:
Move redirect rendering into WikitextContent

https://gerrit.wikimedia.org/r/105829
Comment 28 Gerrit Notification Bot 2014-01-07 22:49:07 UTC
Change 105832 merged by Aaron Schulz:
Use WikitextContent to render redirects

https://gerrit.wikimedia.org/r/105832
Comment 29 Gerrit Notification Bot 2014-01-07 23:18:31 UTC
Change 105831 merged by jenkins-bot:
Use WikitextContent to render redirects

https://gerrit.wikimedia.org/r/105831
Comment 30 Brad Jorsch 2014-01-08 16:47:21 UTC
Should be deployed to WMF wikis with 1.23wmf10, see https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap for the schedule.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links