Title::getRootText() uses the text form (spaces) of the title, while
$wgRawHtmlMessages was specifying them in dbkey form (underscores).
And add tests while we're at it. Which spotted that the existing
code didn't work. Whoops. Fixed.
Change-Id: I05eea553c588e0f99f862e07ad15386507ed0728
This is part of the effort to remove the assumption that every page
can have a talk page. Before we can merge Icee208dc4 which makes
Title::getTalkPage() throw an exception of no corresponding talk
namespace is defined, all extensions that call getTalkPage() must
be changed to either check canHaveTalkPage() first, or to use
the conveniance function getTalkPageIfDefined() instead.
Bug: T165149
Bug: T172146
Change-Id: I6d2613d8f7105048022f8093186dc57f1f8173ab
This renames Title::canTalk to Title::canHaveTalkPage
and MWNamespace::canTalk to MWNamespace::hasTalkNamespace.
Bug: T165149
Change-Id: I342a273a497b31282388b13bf76dadfb1122dcbb
Without this patch, Title::getPrefixedText() would return ":Foo"
if the namespace was unknown, potentially creating a misleading
link to the main namespace. With this change, getPrefixedText()
will return something like "Special:Badtitle/NS12345:Foo".
Note that round trip behavior is broken either way.
Bug: T165149
Change-Id: I0d491a2b58ff45f207f83ee62ca6e7e6ffbf790a
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I46261416f7603558dceb76ebe695a5cac274e417
MediaWiki titles may not contain Unicode bidi control characters, e.g.
U+200E LEFT-TO-RIGHT MARK. They are silently stripped and such a
title is considered valid.
MediaWiki titles may not contain any whitespace other than a regular
space. Most of them are silently replaced with a regular space and
such a title is considered valid, but there are some (e.g. the tab
character) which make the title invalid. I'm not sure if this is an
intentional behavior, but I added a test case to verify it.
Bug: T143759
Change-Id: If8fad1f896027c5d93a62b0785923a39136c6a36
The createFragmentTarget function allows for switching the fragment on a
target in an easier way. TitleValue already had a now-renamed
createFragmentTitle function (no uses outside of tests), and an
implementation was added for Title.
This will also help with reducing the amount of public usage of
Title::setFragment(), which is deprecated.
Change-Id: I1e8ba2f85e748b1b4394fb2f2a1ccce69cf6e3c5
Removed redundant set up in these classes (same as their paren
class MediaWikiLangTestCase does already).
* BlockTest
* ExportTest
* MWTimestampTest
* TitlePermissionTest
Change-Id: I28d18cb797bb249981727b02dffce4f0d8682b02
Without this, you have to call:
getArticleID( Title::GAID_FOR_UPDATE )
then either use that directly (bypassing the TitleExists hook) or
call exists afterwards.
Change-Id: Ieec5579e4de2a289795364e7001028932535e435
includes/Title.php
* The private method Title::secureAndSplit() now throws a
MalformedTitleException instead of returning false on invalid
titles.
* Added Title::newFromTextThrow(), which behaves exactly like
Title::newFromText() but throws MalformedTitleException instead of
returning null on invalid titles.
includes/title/MediaWikiTitleCodec.php
* Provide more information with the thrown MalformedTitleExceptions.
includes/MediaWiki.php
* Use the new Title::newFromTextThrow() to get detailed error
information, display it.
Change-Id: I4da8ecb457a77473e32d745ba48ab8505b35e45f
These tests all involve database access in some way,
and thus need @group Database tags.
These failed when setting a bogus database password
and then running the tests.
Change-Id: I7f113a79ac44d09d88ec607f76b8ec22bc1ebcf1
Also added it to the MediaWikiTitleCodecTest.php (which seems not exists
at time of bug creation)
Bug: T67879
Change-Id: I8411d46320201b594ebaa56953dc355d863d0500
Follows-up b36d883.
By far most data providers are static (and PHPUnit expects them
to be static and calls them that way).
Most of these classes already had their data providers static
but additional commits sloppily introduced non-static ones.
* ResourceLoaderWikiModuleTest, 8968d8787f.
* TitleTest, 545f1d3a73.
Odd unused method 'dataTestIsValidMoveOperation' was introduced
in 550b878e63.
* GlobalVarConfigTest, a3e18c3670.
Change-Id: I5da99f7cd3da68c550ae507ffe1f725d31e7666f
testIsAlwaysKnown was invoked on an interwiki link. To have the test
pass, we used addDBData() to inject the interwiki in the database. This
end up being execute on each test when it is only needed for a single
assertion.
Instead of creating a Title, use Title::makeTitle() to populate the
interwiki, thus letting us avoid the database hits.
Random timing: 1.20s -> 150ms.
Change-Id: I63a4e7b9af5eacb7dc1de4b33b8e631e6c3f1fa6
In practice, this means the MediaWiki canonical way to uniquely and
humanly name translation pages on a multilingual wiki becomes
$source_page_title + '/' + $target_language_code, irrespective of
the enabling of the navigational subtitle and of the relative
titles (..) syntax for linking and transcluding, which are unrelated
and keep being controlled by $wgNamespacesWithSubpages.
This syntax has been prevalent on most wikis including mediawiki.org
since at least 2009, also thanks to #titleparts in ParserFunctions.
The part of the special page's functionality that made links to it red
when destination page wasn't present will be integrated with a follow-up
commit because they require more performance work.
I'm also including some Title tests that were written for testing the
redlinking functionality but are useful in general.
Bug: 66762
Change-Id: I520077c931431b5919e0208f75c20b5b25f3159d
Mostly to catch regressions. While this is an invalid title,
it is valid as syntax when creating a Title *object*, the actual
page title itself does not allow leading colons.
Change-Id: Idbe8a3bfe487926c5fc8bdcfa69a957fc9d0bc49
For example, [[en:]] on enwiki. These links were for some reason considered
invalid. However, to support use-cases such as cross-wiki transclusion and
the importing of templates across wikis, this type of link should be
allowed.
I can't see that this would break anything. If anything, it will "un-break"
some links.
Should MediaWikiTitleCodec depend on Title::newMainPage? Almost certainly
not, but I note that splitTitleString is earmarked for demolition, so I
expect that the confusing dependency-web will be cleaned up in the future.
I also note that MediaWikiTitleCode already uses various static methods of
the Title class.
Bug: 64167
Change-Id: I27495aa62e6059c7725387135ae0358d7e6fb35b
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: Ic8aaf0a93796b97d0fa4617c1f86ff59f4b36131
this was to be temporary, right? we need the tests in.
If there are issues with jenkins, this is not the *best*
way to fix them.
This reverts commit 44a1968531.
Change-Id: I5dd60a9818c28155d96a6642c588781667e682c3
This code was added by Brion back in 2004 as part of r6398.
According to Brion, links like [[en:wikt:foo]] on English Wikipedia are
"just crazy!", but I can't see any reason to disallow them.
Bug: 61357
Change-Id: If449e60a0ef95cfe3dd6f4b1809ac012be62a0ea
Although the tests themselves pass, their introduction to the codebase pushed
the total number of tests past some threshold at which Jenkins starts
segfaulting. So remove the tests as a temporary workaround, and revert this
patch once the bug with Wikimedia's Jenkins deployment (bug 43972) is resolved.
Change-Id: I5722faf0e4216e1c1f98ecc1f2dba744b240b7d3
TitleValue is intended to be a light weight alternative to the Title
class. Any operations on TitleValue are implemented in separate
service classes, like TitleFormatter and PageLinkRenderer. See
<https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue>
for more information.
This change updates SpecialCategories and SpecialLinkSearch to use
TitleValue instead of Title, to demonstrate how TitleValue would be
used, and how the necessary services can be injected and applied.
The intention is to improve testability and reusability; these
advantages will however only become apparent with further refactoring
of the respective special pages. This will be done in follow-up
changes.
More work will be needed to migrate essential functionality from
Title and Linker classes into the respective service classes,
MediaWikiTitleCodec and MediaWikiPageLinkRenderer.
Change-Id: I8eef5a165de4ffcacfbc4911fdacdb15d502fff4
This is akin to $wgSkipSkin/$wgSkipSkins. It is quite plausible for a wiki
to have more than one self prefix (e.g. enwiki has w: en: wikipedia: and
maybe others).
Some recent changes code seems to use $wgLocalInterwiki for quite unclear
purposes:
- I removed the line using $wgLocalInterwiki from the RecentChange
class, as the 'lang' field of $mExtra is not used anywhere in core code.
Extensions may use it, but it would seem more appropriate for them to
use something like $wgDBname (or indeed to consult $wgLocalInterwikis
directly) if they need to identify a particular wiki.
- In the IRC formatter, the first prefix in the array is used (if set).
Appropriate documentation is added to DefaultSettings.php.
Related to bug 954 comment 3.
Bug: 954
Bug: 955
Change-Id: I9dbb566385b464402c5e78510b95dd2ffb4d9489
Also test $wgLocalInterwiki.
The js part does not respect interwikis,
so there is no need to add tests for that.
Change-Id: I407355295b65bc67eb171da435c1505797569d3e
When secureAndSplit gets a single colon as input, the leading colon
is stripped and produces a title with a empty string. This change makes
that impossible by moving the empty string check to after the substring
removal of the colon.
Bug: 54044
Change-Id: I574168c9ed281c535901c36dea7c179a4e794d20
