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
Changes:
* Add support for fragments.
* Use wgLegalTitleChars instead of the old clean() method
that stripped out characters instead of throwing an exception.
* Implemented various other parts of Title.php to make it more
strict like Title.php. It is still slightly looser, but it
now takes care of the following that Title.php did already:
- Directory patterns ("../" etc.)
- Extra initial colons
- Titles in NS_TALK that don't round-trip to NS_MAIN
- 3 or more consecutive tildes
- Limited title size (255 bytes)
* Extracted parsing logic into a private static #parse method
and introduced mw.Title.newFromText (a constructor that returns
null|Title instead of throwing an exception).
* Extended test suite to cover the added features and fixed bugs.
* Since the PHP test suite was lacking these, added them there
as well.
Bug fixes:
* Fragments are now excluded from the title instead of causing
the input to be invalid or malformed (e.g. "Foo#bar" was being
normalised to "Foo_bar").
* ".com" now parses and round-trips properly. The extension and
rest of title are still separated, but only at the very end
after all other processing, so though title cannot be empty,
since we only do a lazy split afterwards, it will split into
title="", ext="com" internally and join back together when
needed (bug 38081).
* "Example.js " (trailing space after extension) was previously
incorrectly parsed as title=Example.js,ext=null.
* "Foo bar" (multiple consecutive spaces) was transformed
into 1 space correctly, but "Foo___bar" was not. This has been
fixed to match the PHP implementation (it merges underscores
and whitespace of any kind).
Clean up:
* Removed various redundant private helper methods.
* Removed fixNsId as getNsIdByName uses wgNamespaceIds which
always yields a valid value. The fixNsId was verifying
something that was already valid.
* Yoda conditional in Title.php, got rid of.
* Use newFromText in jquery.byteLimit.test. It was previously
using a very basic invalid test (=== '') and no try-catch.
Since we're getting more strict, typing 'User:' results in
an invalid title, which should result in the same behaviour
as it previously did for the lazy === '' check.
Bug: 38081
Change-Id: Ief1c11dabadc2f822065c40be91e04d655933e4f
The upcoming rewrite of mw.Title needs to use wgLegalTitleChars,
but for that to work, it needs to be converted into something
that can work in javascript.
Signed-off-by: Timo Tijhof <krinklemail@gmail.com>
Signed-off-by: David Chan <david@sheetmusic.org.uk>
Change-Id: I163f3d7e3a680d52640a93f4bd195d8209669918
PHP Code Coverage uses the @cover comment statement to limit code
coverage to some specific function. The method reference lacked the
trailing 's' leading to an error when running coverage:
PHP_CodeCoverage_Exception: Trying to @cover not existing method
"Title::checkReadPermission".
Change-Id: Ie09e804039271ec8f0165c32dc7849ea4be8a3b9
This patch make it possible to whitelist pages which anonymous users may
see. It is similar to $wgWhitelistRead expect it uses regular
expressions, the list of regex are to be added in the new global array
$wgWhitelistReadRegexp.
This would be useful in a semi-public team wiki situation where the
admin would want to hide an entire namespace from everyone except those
in a particular group due to sensitive team specific information.
Added new unit test testUserCan in includes/TitleTest.php to
test this new functionality.
* adds $wgWhitelistReadRegexp to DefaultSettings.php
* updates RELEASE-NOTES-1.21 new features
* updates CREDITS
Signed-off-by: Antoine Musso <hashar@free.fr>
Change-Id: I83f6a614874c3d289ff4bd8d015f1d9c92e500b6
This test assumed wikitext in the main namespace. That is not always
the case. Now it expects wikitext in the Help namespace. Also not
guaranteed, that should pretty likely be currect.
Change-Id: Icf437b4396812131c501c4594ece2eff7604b6ba
This introduces the ContentHandler facility into MediaWiki,
see docs/contenthandler.txt.
For convenient review, a squashed version is available at
https://gerrit.wikimedia.org/r/27191
The ContentHandler facility is a major building block of the Wikidata project.
It has been discussed repeatedly on wikitech-l.
Change-Id: I3804e2d5f6f59e6a39db80744bdf61bfe8c14f98
This commit depends on the introduction of
MediaWikiTestCase::setMwGlobals in change Iccf6ea81f4.
Various tests already set their globals, but forgot to restore
them afterwards, or forgot to call the parent setUp, tearDown...
Either way they won't have to anymore with setMwGlobals.
Consistent use of function characteristics:
* protected function setUp
* protected function tearDown
* public static function (provide..)
(Matching the function signature with PHPUnit/Framework/TestCase.php)
Replaces:
* public function (setUp|tearDown)\(
* protected function $1(
* \tfunction (setUp|tearDown)\(
* \tprotected function $1(
* \tfunction (data|provide)\(
* \tpublic static function $1\(
Also renamed a few "data#", "provider#" and "provides#" functions
to "provide#" for consistency. This also removes confusion where
the /media tests had a few private methods called dataFile(),
which were sometimes expected to be data providers.
Fixes:
TimestampTest often failed due to a previous test setting a
different language (it tests "1 hour ago" so need to make sure
it is set to English).
MWNamespaceTest became a lot cleaner now that it executes with
a known context. Though the now-redundant code that was removed
didn't work anyway because wgContentNamespaces isn't keyed by
namespace id, it had them was values...
FileBackendTest:
* Fixed: "PHP Fatal: Using $this when not in object context"
HttpTest
* Added comment about:
"PHP Fatal: Call to protected MWHttpRequest::__construct()"
(too much unrelated code to fix in this commit)
ExternalStoreTest
* Add an assertTrue as well, without it the test is useless
because regardless of whether wgExternalStores is true or false
it only uses it if it is an array.
Change-Id: I9d2b148e57bada64afeb7d5a99bec0e58f8e1561
This patch adds new public accessor to the Title class. They are merely
returning the already existing conventions.
Added tests for the four new methods:
- Title::getBaseText()
- Title::getRootText()
- Title::getRootTitle()
- Title::getSubpageText()
The later does not test with $wgNamespacesWithSubpages variants.
Change-Id: I4f7230c1a5487b82d06c78a45c50436085df57be
This is basicly a merge of r84386 & r84491, see their commit messages for
more details.
r84386 makes wikilinks nicer by updating the URL forge implemented by r2621
r84491 fix an issue with the (un)?watch links. getParamValue should not be
used to guess 'title' or 'action'
