Page MenuHomePhabricator

$wgMaxRedirects totally broke at some point
Closed, ResolvedPublic

Description

I haven't investigated this very thouroughly, but somewhere along the way, $wgMaxRedirects became broken (I tested in 1.18, and it works as expected). The drawing of redirect levels works, but actually following the redirects always goes to 1 level

$wgMaxRedirects = -1; (or 0)
Expected behaviour: Redirects aren't followed, pretty redirect picture isn't drawn (personally I find it weird that it isn't drawn, but that appears to be the intention of the code)
Actual behaviour: Redirects are followed 1 level (unexpected), pretty picture not drawn (Expected).

$wgMaxRedirects = 3
Expected behaviour: Redirects followed 3 levels, pretty redirect picture drawn to 3 levels
Actual behaviour: Redirects are followed 1 level (unexpected), pretty picture drawn for 3 levels (Expected).


Version: 1.20.x
Severity: normal

Details

Reference
bz33520
TitleReferenceAuthorSource BranchDest Branch
builds-builder: bump to 0.0.89-20240117142537-33be94f3repos/cloud/toolforge/toolforge-deploy!177project_1317_bot_df3177307bed93c3f34e421e26c86e38bump_builds-buildermain
inject_buildpacks: ensure nodejs-only is the lastrepos/cloud/toolforge/builds-builder!30dcaroput_nodejs_the_lastmain
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:09 AM
bzimport set Reference to bz33520.
bzimport added a subscriber: Unknown Object (MLST).

I get the unexpected results (which I thought were intended) in 1.17 and 1.18 too. But not always.. It seems to depend on the order in which you create and edit(and maybe view?) the pages.

The following seems to be reproducable in 1.17 and 1.18:

Set wgMaxRedirects to high
Create page 3 with redirect to 4
Create page 2 with redirect to 3
Create page 1 with redirect to 2
Edit 3 to redirect to 9
Goto page 1: it shows ->2->4 instead of ->2->3->9
Create page 4 with redirect to 5
Goto page 1 again: now it takes you to page 4

Hmm, it looks like this has to do with redirects are stored in the redirect table.

So no longer thinking this is a regression in 1.19. Possibly caused by r69181.

See also comment one by Roan on bug 30359

(In reply to comment #4)

See also comment one by Roan on bug 30359

This is close enough to be a dupe to that bug.

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