The funky iteration here was at best annoying. Switch
it over to an iterator based approach with appropriate
BC code to simulate the old iteration style.
Depends-On: I19a8d6621a130811871dec9335038797627d9448
Change-Id: I9fccda15dd58a0dc35771d3b5cd7a6e8b02514a0
The used phpcs has a bug, so the version 0.9.0 could not be enforced at the moment.
Will be fixed in next version, see T167168
Changed:
- Remove duplicate newline at end of file
- Add space between function and ( for closures
- and -> &&, or -> ||
Change-Id: I4172fb08861729bccd55aecbd07e029e2638d311
SearchResult::newFromTitle involves database connnection,
thus better to avoid calling this in the data provider.
Change-Id: I891e97cf18ca1dd44abefe01731dfc5da51f1982
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
Not a big change, but makes it so there is only one path into
SpecialSearch::showResults(). Makes things a little easier to follow.
Also moves the code for checking if full text search is disabled into
execute(), makes sense to check before even trying to make a search
engine. Also moves some setup code out of execute and into the setupPage
function
Bug: T150393
Change-Id: Ib527fc3a3c39eb2e56985e5d1e4905fc4562353c
Test fails on wikis with $wgLanguageCode not = 'en', fix this by
setting the language on the context.
Change-Id: I3a89b347263e460f639ba0641f5dbc65e8bf258d
Special:Search recently gained query rewriting behavior when the
original query returned no results. We want to expose this query
rewriting behavior to both api and web requests. Additionally we
want to be able to test different configurations of the query
suggestions. This patch allows for both by moving the rewriting
from core into the search backend.
This defaults to enabled for Special:Search, and disabled for
ApiQuerySearch. Internal code that talks to the search backend
needs to specifically enable this feature.
Bug: T106888
Change-Id: I0a8f75759f9148f53358707369b8a7128215de86
If the user gets zero results, but gets a "Did you mean" result, just
run the query for the "Did you mean" result and inform the user that
this happened. Adds a new query param 'runsuggestion' which will, when
given a falsy value, prevent running the suggestion and give the result
to the original query.
Bug: T105202
Change-Id: I7ed79942c242b1957d46bdcad59985f37466fb83
This might work in specific cases, depending on the string we're
quoting, but is never correct. The instance in SpecialAllMessages.php
was resulting in incorrect behavior (and log spam, T103879).
Searched for this regex: preg_quote\((?:\([^)]+?\)|[^,()])+?\)
Change-Id: Icc88775970f4927ddf953e5ad7c5c19d59491573
Other backends might not mimic this behavior. Having CirrusSearch
enabled causes this test to fail.
Change-Id: I462446cd2e5eaf43d843c066cb5d7596394429d8
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
- Place commas correct
- Moved comments
- Add space after if/foreach/catch
- Reformat some conditions
- Removed trailing spaces/tabs
Change-Id: I40ccda72c418c4a33fcd675773cb08d971510cdb
Fix almost all occurences of the following sniffs:
Generic.CodeAnalysis.UselessOverridingMethod.Found
Generic.Formatting.NoSpaceAfterCast.SpaceFound
Generic.Functions.FunctionCallArgumentSpacing.SpaceBeforeComma
Generic.Functions.OpeningFunctionBraceKernighanRitchie.BraceOnNewLine
Generic.PHP.LowerCaseConstant.Found
PSR2.Classes.PropertyDeclaration.ScopeMissing
PSR2.Files.EndFileNewline.TooMany
PSR2.Methods.MethodDeclaration.StaticBeforeVisibility
Change-Id: I96aacef5bafe5a2bca659744fba1380999cfc37d
Ief0bdd10 / 9299bab "Stop expanding search term in <title> of the search
results page" had an issue comparing the site title that could be in
different language. I have converted the assertion to make sur we
always have the plain search term (aka: {{SITENAME}}) which will work
regardless of the language currently set.
Change-Id: Idbb778174978c17a75fa7671d4967851c2732c15
When entering a search term such as {{SITENAME}} on Special:Search,
the <title> was generated with template expansion.
This patch prevents transformation by using search term as rawParams
of the 'searchresults-title' and 'pagetitle' messages.
Change-Id: Ief0bdd10ad882ebfaeefd11bf4217e70dd922d9d
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
When Special:Search uses User preferences for search, make sure that no
unwanted namespaces have been used.
Change-Id: Ibcb23c812bf1e02a398ffbf3a276afc1b1f367cf
r106780 to fix bug 33270 introduced a new bug that prevented selected
namespaces for search to be applied. This patch fix the issue.
Credits to Brad Jorsch
