r49330 MediaWiki - Code Review archive

This really needs some test cases and validation for safety.

See bugzilla:12998#c21 for test cases.

For your convenience, the test cases are:

Main Page
{{DISPLAYTITLE:<span style="text-decoration:underline">Main Page</span>}}
<title>Main Page</title>
<h1><span style="text-decoration:underline">Main Page</span></h1>

Main Page
{{DISPLAYTITLE:<i>Main Page}}
<title>Main Page</title>
<h1><i>Main Page</i></h1>

Main Page
{{DISPLAYTITLE:<a href="https://www.mediawiki.org/wiki/Main_Page">Main Page</a>}}
<title>Main Page</title>
<h1>Main Page</h1>

Main Page
{{DISPLAYTITLE:<script>Main Page</script>}}
<title>Main Page</title>
<h1>Main Page</h1>

Dweeb (band)
{{DISPLAYTITLE:[dweeb] (band)}}
<title>Dweeb (band)</title>
<h1>Dweeb (band)</h1>

Dweeb (band)
{{DISPLAYTITLE:dweeb (band)}}
<title>dweeb (band)</title>
<h1>dweeb (band)</h1>

E=MC2 (song)
{{DISPLAYTITLE:E=MC<sup>2</sup> (song)}}
<title>E=MC2 (song)</title>
<h1>E=MC<sup>2</sup> (song)</h1>

Signaling System 7
{{DISPLAYTITLE:Signaling System #7}}
<title>Signaling System 7</title>
<h1>Signaling System 7</h1>

And what happend to $wgRestrictDisplayTitle?

I removed it because it was complicating things and it seemed really confusing to allow the display title to be arbitrarily different from the actual title. For example, you might try to type the display title into the search box, and it could take you to a completely different page. Or you might try to link to the article, only to have the link not work or link to a completely different page. Is there really demand for this "feature"?

This is useful for the ones who want to be able to set any title without having to use JavaScript hacks. And according to Wikimedia's configuration (http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php) it's used on Chinese Wikipedia and Wikimania 2009 wiki.

If you really want to remove it, also remove it from DefaultSettings.php and add an entry in RELEASE-NOTES about that.

The reason why we supported to set the varible to false was the cache problem caused by using -{T|}- syntax. Before r45828, one who saved a article recently need to purges that page again, in order to display the converted title correctly. At that time, I called a request to disable $wgRestrictDisplayTitle, since we could use to set the title for different variants.

But after r45828, the problem has been solved. Actually, there is no need for Zh MediaWiki to use the anymore, because people can use -{T|}- instead of it completely.

Glad to hear that the bug has been fixed and the Chinese Wikipedia no longer needs $wgRestrictDisplayTitle! I've removed the setting properly in r49610.

Some non-Wikimedia parties are likely using $wgRestrictDisplayTitle = false. It's arguable whether it's really necessary to have the title be linkable; I agree with you that it's a good idea, but some people seem to prefer aesthetically superior or more correct titles. For instance, the lack of validation would permit display titles that include prohibited characters like <>[]| etc., which might be more correct for some pages (although you couldn't then copy-paste the title). I think this decision should be left up to local site admins for the time being unless there's a compelling reason to remove it.

99% of the time, the solution to an incorrect page title is to move the page to the correct title. Introducing a hack to make it look like the page is where it should be, but really it isn't, is confusing and problematic. If there are really wikis out there that you think need wanton DISPLAYTITLEs, please point me to them.

If we are going to support <>[]| etc. in page titles, we ought to add a way to escape page titles so that they can contain those characters without conflicting with those characters' special meanings. In fact, one syntax we could use is already in place: percent-encoding. For example, we might use [[Mac%7CLife|click here]] to link to an article titled "Mac|Life".

Here's one example: http://strategywiki.org/wiki/Pok%C3%A9mon_Trading_Card_Game/Imakuni -- Currently a js hack is used in lieu of DISPLAYTITLE, but basically we needed to add a "?" to the end of the title in order for the page name to be correct (in-game the name ends with a question mark, but the ? character is disallowed in titles).

I could forsee unrestricting DISPLAYTITLE useful in other cases as well, listed below:

1. Truncating the title to the last part (useful when using sub-pages to place pages in a hierarchy instead of using categories).
2. Allowing users to further customize their user pages by adding handles, etc. to the page title (moving the page won't work in this case)
3. Appending additional information to the page title, such as a product id (moving the page to include the product id would make linking difficult)
4. Probably others, but I can't really think of any more right now.

If you don't provide any definitive reason that the software shouldn't support this variable, then I'm going to add it back in a week from now. The reason being, even if you don't use it, why should you prevent others from being to use it as well if they want to?

Question marks are allowed in titles, see http://en.wikipedia.org/wiki/How_Long%3F for example. http://strategywiki.org/wiki/Pokémon_Trading_Card_Game/Imakuni could easily be moved to http://strategywiki.org/wiki/Pokémon_Trading_Card_Game/Imakuni%3F. This is a great example of why unrestricted DISPLAYTITLEs are a bad idea: instead of moving the page properly, the editors of that wiki have simply slapped on a hack and called it good.

The problematic characters []{}|#<> can be enabled by overriding $wgLegalTitleChars in LocalSettings.php. Just be warned that you will need to escape links to titles containing these characters and MediaWiki will not work perfectly with them. But even though there are some problems, it does work and should be reasonably reliable.

About your use cases:

1. Categorization and navigation boxes are a much better solution. Or if you're desperate, you could use {{DISPLAYTITLE:<span style="display:none">Really/Long/Page/</span>Title}}.
2. What is a "handle", and why is having it more important than being able to move the page?
3. Use redirects. Redirects are perfect for having short links to long titles.

The use case for unrestricted DISPLAYTITLEs is so narrow that it does not outweigh the confusion and inconsistency it creates, apart from making MediaWiki more complicated, more difficult to maintain, and a tiny bit slower because of the extra global variable check.

A "handle" is a nickname, aka another name you might be known by. You can't simply move the user page because the user page must correspond to the user's name. Yes, I know that it isn't necessary to add to the title, but having that avenue open to use is nice.

Also, mediawiki is actually faster if $wgRestrictDisplayTitle is false, so that claim is entirely unfounded (checking a boolean versus normalizing a title and checking it -- I wonder which takes more time).

In addition, if you want to make mediawiki less complicated, why don't you do something useful such as cleaning up all the code marked FIXME in the files? Surely that will help much more than removing a global variable THAT ACTUALLY HAS USES (and don't give me that "oh, you can simply move the page or set up a redirect." Workarounds are exactly that -- workarounds. They aren't solutions to issues, they only attempt to quickfix the issue until a more desirable solution is implemented).

Or, better yet, why don't I just use your arguments against you? We should just remove DISPLAYTITLE entirely. The use case for restricted DISPLAYTITLE is so narrow that it does not outweigh the confusion and inconsistency it creates (superscript isn't allowed in titles, so why should it be shown? That is just confusing). In addition, it makes MediaWiki much more complicated, more difficult to maintain, and a tiny bit slower because of the extra normalization checks. Because of that, we should just eliminate DISPLAYTITLE entirely even though wikis actually use it. Sounds like a great idea, no?

That's basically what you just said for the $wgRestrictDisplayTitle global.

And again I repeat: just because you don't use it doesn't mean others won't. The use cases I listed can be achieved via other means, yes, but that doesn't mean that the sitemasters WANT to do it that way. In addition, as you said yourself, allowing various characters is problematic and requires even MORE hacks to make them work properly than it does to simply change the title.

TL;DR version of this discussion: Don't remove things simply because you don't like them. If I was to follow your example, I'd kill off i18n because it takes up the vast majority of space and is way slower than hard-coded strings. Yet I don't. Why? Because i18n is useful to people that speak different languages and because I respect the community that uses it and wouldn't take it out without contacting them first. Did you contact anyone before removing $wgRestrictDisplayTitle? Judging by iAlex's comment, I'd say that the answer is no.

Also, I have yet to see a good reason for not putting it back. 0.0001 seconds of load time for those that have it set to true isn't a good reason. Forcing pages that already use it as unrestricted to do it "properly" isn't a good reason. Removing ONE if and ONE global statement from the codebase isn't a good reason.

Well, my nickname is "Dot". What if I wanted my user page to say "Dot" instead of "User:Remember the dot"? It would cause confusion because "Dot" could also refer to the punctuation mark or "User:Dot".

The default configuration would take a tiny performance hit from having to check $wgRestrictDisplayTitle over and over and then perform the title normalization anyway. This performance hit is not worth worrying about. The added complexity to the code is what concerns me, but what worries me much more is the confusion that unrestricted DISPLAYTITLEs would cause.

Moving pages to their proper titles is usually the solution. If "Pokémon Trading Card Game/Imakuni" should be "Pokémon Trading Card Game/Imakuni?" then move it there. Problem solved, cleanly, easily, and completely. Redirects are also a good, easy-to-understand solution in many cases.

Superscript and subscript should be allowed in page titles because they are simple formatting. No one is going to be confused if "E=MC²" turns into "E=MC2" in their watchlist. But if the page that says "E=MC²" is actually titled "Mass-energy equivalence relationship discovered by Einstein", confusion abounds.

Personally, I think adding more characters to the whitelist would work better than allowing unrestricted DISPLAYTITLEs. Try it, tell me if it works okay for you. The problems did not seem so severe to me. At the same time, I can see why others might disagree. If you can show me some wikis out there that would prefer unrestricted DISPLAYTITLEs, then I wouldn't mind adding the option back until we resolve the problems that adding characters to the whitelist creates.

I'm not against unrestricted DISPLAYTITLEs because I don't like them, I'm against them because they're almost always a bad idea. I'm not in favor of supporting poor ways to use the software. At bugzilla:12998#c27 I brought this up back in February and no one said a word.

The use case for unrestricted DISPLAYTITLEs is so narrow that it does not outweigh the confusion and inconsistency it creates

Which only appears on wikis whose administrators choose to enable it. So that's their problem.

apart from making MediaWiki more complicated

When in doubt between simplicity and flexibility for user-exposed features, simplicity has a strong case. But the complexity of administrative settings is not an issue. Admins who don't care can just ignore them.

more difficult to maintain

Negligibly. It touches what, two functions?

and a tiny bit slower because of the extra global variable check.

Completely trivial. Do not cite performance unless it would actually be measurable.

The basic point is that this is an existing feature that people are using. It is something that some people, for whatever reason, want to use, and have been happily using for years in some cases. Removing it would be a regression in functionality for several wikis of nontrivial size, and any such regression has to be justified by a serious argument. Simplifying two functions slightly is not a serious argument.

Originally we had only unrestricted display titles. This dates back to before my time in MediaWiki; I believe Magnus added the feature. A couple of years ago Rob Church changed it to only work when restricted, exactly as you propose. We received complaints about the regression in functionality, which eventually led to the current configuration setting. The setting was added due to administrator demand. We have already tried your way and found it was a bad idea. If you think using it is a bad idea, convince the wiki administrators who want it. MediaWiki is intended to permit administrators to do stupid things if they want to, up to and including things like $wgRawHtml.

Thanks for your reply, Simetrical. Again, I'm concerned foremost with the confusion it would cause to end users, secondly with the added complexity in MediaWiki's code, and trivially with the performance impact. The reasons you gave are good reasons to put the feature back in, ones that I was not aware of. Could you show me the sites that are actually using this, though?

Well, see bug 17307 for a Wikimedia site that's apparently using it. This wiki is apparently closed-edit and so unintuitive links aren't really an issue; it seems to serve the purpose of just "set the page title arbitrarily to look pretty", like a CMS might have. Brion specifically authorized that use, so I assume he'd prefer it if the feature didn't suddenly disappear.

As far as I can tell, even though the Wikimania 2009 site enabled the capability, they never used it (see link). A couple of problems with the "just set the page title arbitrarily to look pretty" approach are that the URL won't match and the search feature won't work right, which is perhaps why that wiki left unrestricted DISPLAYTITLEs by the wayside. Do you have any other examples?

http://wikimania2009.wikimedia.org/w/index.php?ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1&redirs=1&search=DISPLAYTITLE&title=Special%3ASearch&fulltext=Advanced+search&fulltext=Advanced+search

No, I don't remember them offhand. Some examples were provided earlier. You might argue that they're misusing the feature, but they're using it nonetheless, and their wikis will break on upgrade if it's removed.

There's not much point in discussing this further. If you think the feature should be removed, probably best to talk to Brion.

$wgRestrictDisplayTitle re-added in r49654 In addition, r49654 fixes some bugs with block-level tags being allowed in DISPLAYTITLE (such as , which normalizes to the correct title, but makes it look weird)

er... such as {{DISPLAYTITLE:</h1>This page}}

Problem #3: {{DISPLAYTITLE:<span style="display:none;">{{FULLPAGENAME}}</span>}}. style attributes need to be stripped here. I'd say all attributes should be stripped, possibly. There might be uses for class, but it could be easily abused. Just do class="mainLegend" or something to achieve the same "display: none" effect. So stripping all attributes seems most sensible ― that's the approach I took when I allowed sup and sub in the TOC.

If we didn't allow attributes, then how could editors add <span class="Unicode"> to improve display of titles that contain unusual characters?

I know that page titles can be vandalized, but really, it's no worse than what vandals can already do to the body of the article, not to mention pagemove vandalism which vandalizes the title everywhere and not just in the main view.

Interestingly, the English Wikipedia already technically permits the vandalism you're worried about via wikipedia:Template:Wrongtitle, and it hasn't caused much trouble.

I wasn't really worried about vandals. I was concerned that this might be done deliberately for some reason, breaking the linkability of the title. But since, as you point out, allowing (safe) attributes has legitimate uses and there's clearly demand for it, such that it's in fact already possible on enwiki, I retract my objection.