When transcluding special page like newpages/rc/etc if any edits tagged, strip markers exposed and page title overridden
Closed, ResolvedPublic

Description

Author: Daedalus969

Description:
Quite simply, at my userpage of [[Wikipedia:User:Daedalus969]], I have {{Special:NewPages/5}} transcluded in. It's been transcluded in for roughly a year now, with no problems what-so-ever... until recently.

Yesterday I logged in to find that the title of my userpage had been replaced with Special:NewPages/5

Please fix this.


Version: unspecified
Severity: minor

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz23293.
bzimport created this task.Via LegacyApr 23 2010, 6:36 AM
Bawolff added a comment.Via ConduitApr 23 2010, 6:44 AM

I think this is either related to, or possibly a dupe of Bug 16129 (note how there's strip markers all over the place on the given example)

Reedy added a comment.Via ConduitJun 16 2010, 10:12 PM
  • Bug 24005 has been marked as a duplicate of this bug. ***
HappyDog added a comment.Via ConduitJul 21 2010, 12:50 AM

As per bug 24005, this was broken on my user page too ([[mw:User:HappyDog]]). Recently (last week or so) my sub-page transclusions also broke on that page which is something I hadn't quite got round to logging yet.

However, I've just logged back in and it appears that both of these issues are now fixed - the page title is now back to what it should be, and the sub-page transclusions are working again.

bzimport added a comment.Via ConduitJul 22 2010, 1:40 AM

Daedalus969 wrote:

(In reply to comment #3)

As per bug 24005, this was broken on my user page too ([[mw:User:HappyDog]]).
Recently (last week or so) my sub-page transclusions also broke on that page
which is something I hadn't quite got round to logging yet.

However, I've just logged back in and it appears that both of these issues are
now fixed - the page title is now back to what it should be, and the sub-page
transclusions are working again.

I have no idea what the devs are doing.. it's like this issue is fixed, then it isn't, then it is again..

Now it isn't. I had hoped your comment meant it was over with.. only to log in today to find it wasn't.

bzimport added a comment.Via ConduitJul 22 2010, 1:59 AM

thor.malmjursson wrote:

I'm having an issue which I suspect may be related to this, at User:BarkingFish/OW1/WatchSectioned - I'm making multiple categorised watchlists using Special:RecentChangesLinked, and transcluding the results into the page.

The problem is not only is the page now rendering with the Special page title, I'm also getting QINU <coded garbage> UNIQ plastered in the page, and the Special page transclusions are not listing correctly.

I have absolutely no idea what this is about, or what's gone wrong, but a fix would be greatly appreciated.

(Using Windows XP, SP3 - Browser IE8 / Safari)

bzimport added a comment.Via ConduitJul 22 2010, 2:01 AM

thor.malmjursson wrote:

I'm having an issue which I suspect may be related to this, at User:BarkingFish/OW1/WatchSectioned - I'm making multiple categorised watchlists using Special:RecentChangesLinked, and transcluding the results into the page.

The problem is not only is the page now rendering with the Special page title, I'm also getting QINU <coded garbage> UNIQ plastered in the page, and the Special page transclusions are not listing correctly.

I have absolutely no idea what this is about, or what's gone wrong, but a fix would be greatly appreciated.

(Using Windows XP, SP3 - Browser IE8 / Safari)

Bawolff added a comment.Via ConduitJul 22 2010, 6:19 AM

I spent some time trying to narrow the problem down. It appears to be related to change tags, which is probably why it is intermittent (if you have special:newpages on your page, sometimes it will have tagged edits, sometimes it won't)

Specifically, in my tests, commenting out the wfMsgExt( "tag-$tag", 'parseinline') in ChangesTag::tagDescription (~line 31) made the issue go away, so I think thats the culprit. ( I assume this is bug 17329 ?).

One fix would be to just disable showing Change tags if the special page is being transcluded. I'm not sure if there is a better fix that would both fix the issue and allow showing change tags when transcluding the special page.

removing keyword testme and changing description to more fit the problem

Bawolff added a comment.Via ConduitJul 23 2010, 12:50 AM

Created attachment 7587
patch to disable change tags on special:newpages, rc, rclinked when its being transcluded.

Here's a potential patch that just disables it when transcluding. Seems a bit inelegant though, and like there should be a better solution.

also marking as depends on bug 16129 as thats the larger issue.

Attached: rcinclude.patch

Bawolff added a comment.Via ConduitJul 23 2010, 10:38 PM

fixed in r69820 by making change tags not be displayed when those special pages are transcluded into another page.

bzimport added a comment.Via ConduitOct 7 2010, 1:51 AM

Daedalus969 wrote:

(In reply to comment #9)

fixed in r69820 by making change tags not be displayed when those special pages
are transcluded into another page.

This is still broken. If one simply views my userpage on wikipedia, the title is still Special:NewPages/5.

I will supply a screen shot if necessary.

bzimport added a comment.Via ConduitOct 7 2010, 2:14 AM

bugs wrote:

(In reply to comment #10)

This is still broken. If one simply views my userpage on wikipedia, the title
is still Special:NewPages/5.

Have you tried purging your cache? I've seen this error in the past, but I'm not getting any errors on your userpage or the other pages mentioned here.

Bawolff added a comment.Via ConduitOct 7 2010, 2:18 PM

re-closing as fixed. Wikimedia sites are running a version of mediawiki before the version where this is fixed.

Have you tried purging your cache? I've seen this error in the past, but I'm
not getting any errors on your userpage or the other pages mentioned here.

The error depends on what the contents of special:newPages is, so sometimes it will be present, sometimes it won't depending on if any of the recent page creations have been tagged.

HappyDog added a comment.Via ConduitJan 17 2011, 10:32 PM

It's back!

Site: http://www.mediawiki.org/wiki/Special:Version
Version: MediaWiki 1.16wmf4 (r79563)
Example: http://www.mediawiki.org/wiki/User:HappyDog

Bawolff added a comment.Via ConduitJan 17 2011, 10:33 PM

re-closing.

1.16wmf4 < 1.17

fix is in 1.17

HappyDog added a comment.Via ConduitJan 18 2011, 7:40 AM

(In reply to comment #14)

re-closing.

1.16wmf4 < 1.17

fix is in 1.17

Fair enough - though that's not what was said here:

(In reply to comment #9)

fixed in r69820 by making change tags not be displayed when those special pages
are transcluded into another page.

Bawolff added a comment.Via ConduitJan 18 2011, 4:11 PM

when people say fixed in rWhatever, they're generally referring to that revision of trunk. Wikimedia servers are running a branch, so its running r79563 of 1.16wmf4, which is mostly r64689 of trunk, with the odd newer revision thrown in (like r79562 to pick a random example). So 1.16wmf4 more or less is the same as r64689 regardless of what special:version says.

HappyDog added a comment.Via ConduitJan 18 2011, 9:39 PM

OK. Thanks for the clarification. Is there any meaningful way to get this reflected in Special:Version, or is that impossible?

Bawolff added a comment.Via ConduitJan 19 2011, 2:57 AM

As far as I'm aware, its impossible. Its not just that the branch is older code, but its a mix of older and newer code, so if the older r number could be shown, that would also be inaccurate, as anything that was merged from trunk outside of a total version update would not be included. The least confusing course of action would be to disable showing such revision numbers on wikimedia wikis (but then again, the sysadmins might find those numbers useful perhaps, i don't know).

HappyDog added a comment.Via ConduitJan 19 2011, 10:38 AM

Fair enough. Thanks for explaining.

Krinkle added a comment.Via ConduitJan 19 2011, 12:18 PM

Aside from it being difficult if not impossible. I think the current situation is quite correct:

Installed software

MediaWiki 1.16wmf4 (r79563)
PHP 5.2.4-2ubuntu5.12wm1 (apache2handler)
MySQL 5.1.47-facebook-r3550-log

It clearly states the name of the branch ("1.16wmf4").

Anyway, another way would be to check then revision number, for example: since r69820 (the fix for this bug). Then check the Branch points [1] where you can read if there's a branch made after the revision. If there's any branch containing "wmf" or "wikimedia" you know that it either is or will be deployed very soon.

In our example we can see that there is a branch point after the rev (namely 1.17) but no wmf-branch yet, so it's not live yet and explains why the bug is still showing up.

The only exception to this is when the revision has been back ported into an older branch. In that case you would see a line on the revision page (r69820) saying "MFT: ....".

Krinkle

[1] http://www.mediawiki.org/wiki/Branch_points

Matanya added a comment.Via ConduitAug 12 2012, 12:11 AM

This patch might revert the fix here: https://gerrit.wikimedia.org/r/#/c/17669/

Bawolff added a comment.Via ConduitAug 13 2012, 12:43 PM

(In reply to comment #21)

This patch might revert the fix here: https://gerrit.wikimedia.org/r/#/c/17669/

Just for reference, The fix for this bug (which was really a hack) is no longer neccesary since the broader issue was fixed (aka bug 16129 )

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.