Last modified: 2014-09-02 06:04:18 UTC
DISPLAYTITLE is not taken into account when first opening the page for editing, but it applied on previews. The culprit seems to be these two pieces of code in EditPage: # need to parse the preview early so that we know which templates are used, # otherwise users with "show preview after edit box" will get a blank list # we parse this near the beginning so that setHeaders can do the title # setting work instead of leaving it in getPreviewText $previewOutput = ''; if ( $this->formtype == 'preview' ) { $previewOutput = $this->getPreviewText(); } … # Use the title defined by DISPLAYTITLE magic word when present $displayTitle = isset( $this->mParserOutput ) ? $this->mParserOutput->getDisplayTitle() : false; if ( $displayTitle === false ) { $displayTitle = $contextTitle->getPrefixedText(); } $wgOut->setPageTitle( wfMessage( $msg, $displayTitle ) ); getPreviewText(), among other things, sets mParserOutput. It doesn't seem to be set by any other code paths, so later $displayTitle === false and the page title is used. We could add an 'else' and set mParserOutput to something these (but frankly, given how complex this stuff is, I have no idea how to get a "right" ParserOutput here), or just run getPreviewText() unconditionally (which might result in unnecessary parses and whatnot…).
I'm inclined to say this isn't actually a bug. We don't honor DISPLAYTITLE on history or diff pages either, or action=info. Why should we on the non-preview edit form? On the other hand, we *should* honor it on preview because there you probably want to preview the effects of the DISPLAYTITLE along with everything else.
(In reply to comment #1) > We don't honor DISPLAYTITLE on > history or diff pages either, or action=info. Hmm, I guess that's true. I'd call this a bug too (or a lack of an enhancement ;) ). Changing the title on preview only sounds like a silly thing to do, but I guess I won't be hurt or anything if this is WONTFIXed.
