MWNamespace has three internal caches, only one of which can be cleared
(and that somewhat oddly by passing a boolean to
MWNamespace::getCanonicalNamespaces()).
This change introduces a MWNamespace::clearCaches() method to clear all
three caches. It also adds some resetting in tests that seemed to be
missing it.
Change-Id: I1dcfcd8713888b3ff8fc75e95329ba72bd95d0c9
Replaces \TestingAccessWrapper (defined in core) with
\Wikimedia\TestingAccessWrapper (defined in the composer package
wikimedia/testing-access-wrapper).
See https://gerrit.wikimedia.org/r/#/q/topic:librarize-testing-access-wrapper
for downstream patches.
The core version of the class is kept around for a while to avoid
circular dependency problems.
Bug: T163434
Change-Id: I52cc257e593da3d6c3b01a909e554a950225aec8
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
I thought there was just an issue with capitalization, but in fact the
code explicitly only searched one namespace anyway. Fixed that while
taking capitalization differences in namespaces into account.
This by extend also brings support for multiple namespaces to the
opensearch API.
Follows-up I3487bb69.
Bug: T67752
Bug: T32323
Change-Id: I4bec7b5548fc27ac51a1b4d4961c3bbc31eb7337
It was attempting to do this before, but it didn't handle special pages
registered by hook, and was not clearing the list properly (so it was
too late when wgSpecialPages was cleared).
This would cause the test to fail if certain extensions were
installed (e.g. AbuseFilter).
Change-Id: I9affac5ad00e97326ebf9961bbf709ac22aef498
This reduces the runtime of database-bound tests by about 40%
(on my system, from 4:55 to 2:47; results from Jenkins are
inconclusive).
The basic idea is to call addCoreDBData() only once, and have
a addDBDataOnce() that is called once per test class, not for
every test method lie addDBData() is. Most tests could be
trivially be changed to implement addDBDataOnce() instead of
addDBData(). The ones for which this did not work immediately
were left out for now. A closer look at the tests that still
implement addDBData() may reveal additional potential for
improvement.
TODO: Once this is merged, try to change addDBData() to
addDBDataOnce() where possible in extensions.
Change-Id: Iec4ed4c8419fb4ad87e6710de808863ede9998b7
* Fix errors spotted by new release
* Introduce "composer fix", which uses phpcbf to automatically fix some
errors spotted by phpcs.
* Drop $PHPCS_ARGS variable that didn't work on Windows, and add -s flag
* Remove rules from phpcs.xml that are now in MW-CS ruleset.
Change-Id: I13e2155695918c918b67497ac65b85a03897095e
these tests get skipped and so should adding these pages, since it
leads to a fatal error and inability to run tests on such a wiki.
Bug: T97416
Change-Id: Icc4e325ecbc5ed069d12bbad686812f6a45b47e7
Doesn't change the semantics much since run() calls addDBData()
right before setUp(), but these belong addDBData() per the
documentation of setUp().
Change-Id: I304a0aff1fc6b2f0541b3dc3c9e3527772c8f91c
- Added/removed spaces around parenthesis
- Added newline in empty blocks
- Added space after switch/foreach/function
- Use tabs at begin of line
- Add newline at end of file
Change-Id: I244cdb2c333489e1020931bf4ac5266a87439f0d
Prefix search attempts to find exact matches to the user's query that aren't
returned by plugins. In some cases, like when the exact match is a redirect
and the target of the redirect is also in the search results, it would result
in multiple results in prefix search going the same place. This looks really
silly when the top hit is "Barack obama" (a redirect) and the next one is
"Barack Obama" (the target of the redirect).
This handles a bunch of cases to do with redirects in the matches and when
the exact match is a redirect.
Bug: 736731
Change-Id: I49fe1ccec84bd5d1f44c6b91b260abf50f2cc3a1
The default search backend implements proper prefix search and
does this naturally. But extensions providing search backends
like Lucene and CirrusSearch actually fail to implement proper
prefix searching and instead use their search engine ranking for
prefix search as well. Thus often the exact match is not on top
or is not even in the first 10 results at all.
On en.wikipedia.org:
> Example
1. "Example (musician)"
2. "Example"
3. "Example.com"
> John ive
1. "John Ives"
2. "John Ivey"
3. "John Ive"
> Foo
1. "Football (soccer)"
2. "Football League Cup"
3. "Foot (length)"
"Foo" exists but is NOT among the returned results.
Bug: 70958
Change-Id: I78d419424baf43d38beeb6dabfc347f430fa45f6
