Change Details

Currently, MW core requires a talk namespace to be defined for every subject namespace. However, in some cases, having associated talk pages is unnecessary or even unwanted, for instance for Flow's topic namespace. Extensions like flow try to work around this by not defining the talk namespace, and trying to hack around the fallout this causes in core code. Other extensions may define the unwanted namespace, but hide links and prevent editing. Both should not be necessary. == Current Situation == The assumption of having a talk namespace associated is manifest in the MWNamespace::getTalk() and Title::getTalkNsText() methods. More importantly, the assumption is spread throughout the code base by calls to Title::getTalkPage(), which is guaranteed to always return a Title. The requirement is also documented in <https://www.mediawiki.org/wiki/Manual:Using_custom_namespaces#Creating_a_custom_namespace>. The behavior of Title::getTalkPage() is scary in the case no talk namespace is defined: The Title object returned by Title::getTalkPage() will eventually rely on Title::prefix() to add the namespace prefix. Title::prefix() will take the return value of Title::getNsText() unseen, and prepend it to the title text. However, Title::getNsText() will return false if the namespace is undefined! So the resulting title has an empty namespace prefix, effectively causing it to refer to the main namespace, by virtue of the fact that turning the boolean //false// into a string in PHP results in an empty string. This behavior causes wrong links to be shown in the "talk" tab on top of the page, but surprisingly few other places, even though Title::getTalkPage is called a lot by core, and various extensions. Most such calls are for user talk pages. Some classes that use getTalkPage for all kinds of pages are SpecialEditWatchlist and code that constructs FeedItems. The $comments parameter of a FeedItem is typically set to the URL of the page's talk page. However, FeedItem comments are currently not used in Autom output (the respective line in AtomFeed::outItem is commented out), and RSS feeds are disabled on the live site. So it seems the fallout of ignoring the requirement of defining a talk namespace is currently limited, but only by sheer luck. It would be much better to drop the requirement from core. == Proposed Solution == The following methods should behave slightly differently when called on an undefined namespace: * MWNamespace::canTalk() should check whether the talk NS is actually defined. This would also change the behavior of Title::canTalk(). * Title::getTalkPage() should for now return a Title of a dummy page in case talk pages are not supported on the Title's namespace. ** later, getTalkPage() can be changed to return null or even throw an exception if no talk namespace is defined. This would however break a lot of currently existing code. ** The dummy page could be the main page (or the main page's talk page), or a special page that just shows a message. Perhaps we could have Special:ShowMessage/message-key-here. * Title::getTalkNSText() should declare that it may return false. This is already the case, but not documented. * Title::prefix() should check whether getNsText() returned false. In that case, some string derived from the namespace ID should be used as a "fake" namespace name. Perhaps NS1234:Foo would work. Code that calls Title::getTalkPage() can then be changed to check Title::canTalk() first.

Currently, MW core requires a talk namespace to be defined for every subject namespace. However, in some cases, having associated talk pages is unnecessary or even unwanted, for instance for Flow's topic namespace. Extensions like flow try to work around this by not defining the talk namespace, and trying to hack around the fallout this causes in core code. Other extensions may define the unwanted namespace, but hide links and prevent editing. Both should not be necessary. == Current Situation == The assumption of having a talk namespace associated is manifest in the MWNamespace::getTalk() and Title::getTalkNsText() methods. More importantly, the assumption is spread throughout the code base by calls to Title::getTalkPage(), which is guaranteed to always return a Title. The requirement is also documented in <https://www.mediawiki.org/wiki/Manual:Using_custom_namespaces#Creating_a_custom_namespace>. The behavior of Title::getTalkPage() is scary in the case no talk namespace is defined: The Title object returned by Title::getTalkPage() will eventually rely on Title::prefix() to add the namespace prefix. Title::prefix() will take the return value of Title::getNsText() unseen, and prepend it to the title text. However, Title::getNsText() will return false if the namespace is undefined! So the resulting title has an empty namespace prefix, effectively causing it to refer to the main namespace, by virtue of the fact that turning the boolean //false// into a string in PHP results in an empty string. This behavior causes wrong links to be shown in the "talk" tab on top of the page, but surprisingly few other places, even though Title::getTalkPage is called a lot by core, and various extensions. Most such calls are for user talk pages. Some classes that use getTalkPage for all kinds of pages are SpecialEditWatchlist and code that constructs FeedItems. The $comments parameter of a FeedItem is typically set to the URL of the page's talk page. However, FeedItem comments are currently not used in Autom output (the respective line in AtomFeed::outItem is commented out), and RSS feeds are disabled on the live site. So it seems the fallout of ignoring the requirement of defining a talk namespace is currently limited, but only by sheer luck. It would be much better to drop the requirement from core. == Proposed Solution == '''UPDATED''' after [[https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-06-07-21.03.html|discussion on IRC]] on June 7 2017. The following methods should behave slightly differently when called on an undefined namespace: * MWNamespace::canTalk() should check whether the talk NS is actually defined. This would also change the behavior of Title::canTalk(). ** Title::canTalk is a strange name. Perhaps introduce Title::hasTalkPage to replace it. * Title::getTalkPage() should throw an exception if Title::hasTalkPage returns false. ** Callers should check canTalk() first, unless the title is known to be on in a well known namespace with a guaranteed talk namespace associated, as is the case when calling getTalkPage on a user page title, for example. * Title::getTalkNSText() should declare that it may return false. This is already the case, but not documented. * Title::prefix() should check whether getNsText() returned false. In that case, it should prefix the title with `Special:BadTitle/NS<number>/<title>`. This behavior will be inherited by getPrefixedText() and friends. ** Note that using Special:BadTitle here doesn't allow for a successful round trip. But neither did the old behavior, which caused the text form to refer to the main namespace. * Title::makeTitle must continue to return Title objects when called with a bad namespace ID, so we can still render e.g. log entries about pages in namespaces that were removed. ** We could introduce a sensitive version, Title::makeTitleThrow, but Title::makeTitleSafe can already be used for this. Title::makeTitleThrow could behave just like Title::makeTitleSafe, except for throwing an exception instead of returning null for bad namespaces and malformed titles. * Introduce Title::isValid(), that applies the same checks as makeTitleSafe. ** Title::canExist() should probably check Title::isValid(). All code that calls Title::getTalkPage() must be changed to check Title::canTalk() first.

Currently, MW core requires a talk namespace to be defined for every subject namespace. However, in some cases, having associated talk pages is unnecessary or even unwanted, for instance for Flow's topic namespace. Extensions like flow try to work around this by not defining the talk namespace, and trying to hack around the fallout this causes in core code. Other extensions may define the unwanted namespace, but hide links and prevent editing. Both should not be necessary. == Current Situation == The assumption of having a talk namespace associated is manifest in the MWNamespace::getTalk() and Title::getTalkNsText() methods. More importantly, the assumption is spread throughout the code base by calls to Title::getTalkPage(), which is guaranteed to always return a Title. The requirement is also documented in <https://www.mediawiki.org/wiki/Manual:Using_custom_namespaces#Creating_a_custom_namespace>. The behavior of Title::getTalkPage() is scary in the case no talk namespace is defined: The Title object returned by Title::getTalkPage() will eventually rely on Title::prefix() to add the namespace prefix. Title::prefix() will take the return value of Title::getNsText() unseen, and prepend it to the title text. However, Title::getNsText() will return false if the namespace is undefined! So the resulting title has an empty namespace prefix, effectively causing it to refer to the main namespace, by virtue of the fact that turning the boolean //false// into a string in PHP results in an empty string. This behavior causes wrong links to be shown in the "talk" tab on top of the page, but surprisingly few other places, even though Title::getTalkPage is called a lot by core, and various extensions. Most such calls are for user talk pages. Some classes that use getTalkPage for all kinds of pages are SpecialEditWatchlist and code that constructs FeedItems. The $comments parameter of a FeedItem is typically set to the URL of the page's talk page. However, FeedItem comments are currently not used in Autom output (the respective line in AtomFeed::outItem is commented out), and RSS feeds are disabled on the live site. So it seems the fallout of ignoring the requirement of defining a talk namespace is currently limited, but only by sheer luck. It would be much better to drop the requirement from core. == Proposed Solution == '''UPDATED''' after [[https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-06-07-21.03.html|discussion on IRC]] on June 7 2017. The following methods should behave slightly differently when called on an undefined namespace: * MWNamespace::canTalk() should check whether the talk NS is actually defined. This would also change the behavior of Title::canTalk(). * Title::getTalkPage() should for now return a Title of a dummy page in case talk pages are not supported on the Title's namespace. ** later,* Title::canTalk is a strange name. getTalkPage() can be changedPerhaps introduce Title::hasTalkPage to return null or eveneplace it. * Title::getTalkPage() should throw an exception if no talk namespace is defined. This would however break a lot of currently existing codeTitle::hasTalkPage returns false. ** The dummy page could be the main page (or the main page's talk page)Callers should check canTalk() first, unless the title is known to be on in a well known namespace with a guaranteed talk namespace associated, or a special page that just shows a message.as is the case when calling getTalkPage on a user page title, Perhaps we could have Special:ShowMessage/message-key-herefor example. * Title::getTalkNSText() should declare that it may return false. This is already the case, but not documented. * Title::prefix() should check whether getNsText() returned false. In that case, some string derived from the namespace ID should be used as a "fake" namespace name.it should prefix the title with `Special:BadTitle/NS<number>/<title>`. This behavior will be inherited by getPrefixedText() and friends. ** Note that using Special:BadTitle here doesn't allow for a successful round trip. But neither did the old behavior, which caused the text form to refer to the main namespace. * Title::makeTitle must continue to return Title objects when called with a bad namespace ID, so we can still render e.g. log entries about pages in namespaces that were removed. ** We could introduce a sensitive version, Title::makeTitleThrow, but Title::makeTitleSafe can already be used for this. Title::makeTitleThrow could behave just like Title::makeTitleSafe, except for throwing an exception instead of returning null for bad namespaces and malformed titles. * Introduce Title::isValid(), Perhaps NS1234:Foo wthat applies the same checks as makeTitleSafe. ** Title::canExist() should workprobably check Title::isValid(). CAll code that calls Title::getTalkPage() can thenmust be changed to check Title::canTalk() first.