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)

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

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.

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.

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)

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)

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

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:

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

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.

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.

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.

It's back!

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

re-closing.

1.16wmf4 < 1.17

fix is in 1.17

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

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.

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

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

Fair enough. Thanks for explaining.

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

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

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