It is not entirely meaningless. It might be an indicator that
the number of calls to a method is intentionally unlimited.
This is similar to e.g. an @inheritDoc PHPDoc comment that
marks a method as being "intentionally undocumented".
However, what's the meaning of being "intentionally
unconstrained"? Let's just not have any constraint then.
I feel all these ->expects( $this->any() ) bloat the test
code so much that it's never worth it.
Change-Id: I9925e7706bd03e1666f6eb0b284cb42b0dd3be23
It's the same and makes the test code much more readable, I
would like to argue.
Because of the was I split all the changes I made into smaller
patches this patch contains some other changes in the same
lines where I could not split them off. E.g. removal of
->any(), which is the default anyway and doesn't do anything.
Change-Id: Ib297b989d4aec33b31a4e33fe9d5032865b39be0
Ended up using
grep -Prl '\->setMethods\(' . | xargs sed -r -i 's/setMethods\(/onlyMethods\(/g'
special-casing setMethods( null ) -> onlyMethods( [] )
and then manual fix of failing test (from PS2 onwards).
Bug: T278010
Change-Id: I012dca7ae774bb430c1c44d50991ba0b633353f1
This parameter, mainly used during transition to CirrusSearch,
was no more effective because its value was read too late.
Also, added a test for this parameter.
Bug: T277045
Change-Id: I43af23bac983a5c88569c6cde1bab20039128389
if there has been a rewritten search term
then use that as the search term for subsesequent
page requests
Bug: T271103
Change-Id: I9964c5d9acde4ea74f93332b01ef5684b817a12b
This reverts commit 066e77735e.
Reason for revert: Objections brought up on ticket by Esanders are in alignmenet with own objections, that arose after initially providing this patch. We need clarification that is better addressed in new patch, reverting this.
Bug: T270796
Change-Id: Id873b3e3b7efb3003daa4986225b1fb3e7e218c8
On a multi–writing system wiki it may happen that Special:Search
show the create page link on a "blue link".
Rely on LanguageConverter::findVariantLink() to find such link.
Bug: T260957
Change-Id: Ic95188543a2aa88764882a7789e4c3a99fd5c3cc
This covers only directly used services by this special page and pager
Services used by the base class are not part of this patch set
Bug: T259960
Change-Id: Ic64c83d5496680cecf7c76bcad0802c330e0078c
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
Migrate all callers of Hooks::run() to use the new
HookContainer/HookRunner system.
General principles:
* Use DI if it is already used. We're not changing the way state is
managed in this patch.
* HookContainer is always injected, not HookRunner. HookContainer
is a service, it's a more generic interface, it is the only
thing that provides isRegistered() which is needed in some cases,
and a HookRunner can be efficiently constructed from it
(confirmed by benchmark). Because HookContainer is needed
for object construction, it is also needed by all factories.
* "Ask your friendly local base class". Big hierarchies like
SpecialPage and ApiBase have getHookContainer() and getHookRunner()
methods in the base class, and classes that extend that base class
are not expected to know or care where the base class gets its
HookContainer from.
* ProtectedHookAccessorTrait provides protected getHookContainer() and
getHookRunner() methods, getting them from the global service
container. The point of this is to ease migration to DI by ensuring
that call sites ask their local friendly base class rather than
getting a HookRunner from the service container directly.
* Private $this->hookRunner. In some smaller classes where accessor
methods did not seem warranted, there is a private HookRunner property
which is accessed directly. Very rarely (two cases), there is a
protected property, for consistency with code that conventionally
assumes protected=private, but in cases where the class might actually
be overridden, a protected accessor is preferred over a protected
property.
* The last resort: Hooks::runner(). Mostly for static, file-scope and
global code. In a few cases it was used for objects with broken
construction schemes, out of horror or laziness.
Constructors with new required arguments:
* AuthManager
* BadFileLookup
* BlockManager
* ClassicInterwikiLookup
* ContentHandlerFactory
* ContentSecurityPolicy
* DefaultOptionsManager
* DerivedPageDataUpdater
* FullSearchResultWidget
* HtmlCacheUpdater
* LanguageFactory
* LanguageNameUtils
* LinkRenderer
* LinkRendererFactory
* LocalisationCache
* MagicWordFactory
* MessageCache
* NamespaceInfo
* PageEditStash
* PageHandlerFactory
* PageUpdater
* ParserFactory
* PermissionManager
* RevisionStore
* RevisionStoreFactory
* SearchEngineConfig
* SearchEngineFactory
* SearchFormWidget
* SearchNearMatcher
* SessionBackend
* SpecialPageFactory
* UserNameUtils
* UserOptionsManager
* WatchedItemQueryService
* WatchedItemStore
Constructors with new optional arguments:
* DefaultPreferencesFactory
* Language
* LinkHolderArray
* MovePage
* Parser
* ParserCache
* PasswordReset
* Router
setHookContainer() now required after construction:
* AuthenticationProvider
* ResourceLoaderModule
* SearchEngine
Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
To avoid preference bloat, this preference is hidden unless the new
sysadmin config $wgSearchMatchRedirectPreference is set.
Bug: T235263
Change-Id: Ic16f53a4e6ddb6da071d63cd5da28d937d4692c8
Add public, protected or private to function missing a visibility
Enable the tests folder for the phpcs sniff
Change-Id: Ibefce76ea9984c47e08c94889ea2eafca7565e2c
Providing an invalid sort order to Special:Search could trigger an
exception from the search engine when trying to apply it. Validate the
sort order, much like API classes do, and let the user know that the
sort they requested could not be applied.
We also have a unreported error for invalid profile requested, so
added that warning to the display while here.
Bug: T228171
Change-Id: I79079eea8c03a90b5b65f1dad11c99e514de00e1
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
