This patch uses the recommended MW practice for injecting
settings into MW services. Instead of passing in the full
config object, pass in service options which MW service wiring
will use to lookup settings/options from config sources.
So in this patch, the various options have been identified
and put into `CONSTRUCTOR_OPTIONS` constant and inject via
service wiring.
Test plan
=========
Ensure that the special page: `Special:Search` still works
with this patch checkout on your local test wiki.
When you visit `Special:Search` on your local wiki, you should
see a search form view. Type in something like: "Main Page" and
then hit search. If everything works well, then local test passes.
NOTE
====
This patch also resolves a TODO which mentions the removal of
the `getConfig()` method from the SearchEngineConfig class.
Change-Id: Ib5dfc10f3f210c6c35247f4f30f9549dd60e0af7
There are a couple of user options related classes already,
and the T321527 work on dynamic defaults is going to add
even more. Let's move them into a separate namespace
to make core a bit more organized.
Old name is kept as an alias for compatibility purposes.
Bug: T321527
Bug: T352284
Change-Id: I9822eb1553870b876d0b8a927e4e86c27d83bd52
This takes us one step closer to deprecating Status,
so we can isolate StatusValue from presentation logic.
FormatterFactory is introduced as a mechanism for
getting instance of formatters that need access to the user interface
language and other request dependent information.
Usage is demonstrated in thumb.php, SpecialCreateAccount, and
SearchHandler. The examples indicates that there is no work do
be done around ErrorPageError and LocalizedHttpException.
Change-Id: I7fe5fee24cadf934e578c36856cc5d45fb9d0981
This class is used heavily basically everywhere, moving it to Utils
wouldn't make much sense. Also with this change, we can move
StatusValue to MediaWiki\Status as well.
Bug: T321882
Depends-On: I5f89ecf27ce1471a74f31c6018806461781213c3
Change-Id: I04c1dcf5129df437589149f0f3e284974d7c98fa
(quote): Not only is this intensive to compute (and could be an
attack vector). See also: T323125.
Bug: T323126
Change-Id: I404630ea9d580bce91d7c58f73391ce6b672178c
Just methods where adding "static" to the declaration was enough, I
didn't do anything with providers that used $this.
Initially by search and replace. There were many mistakes which I
found mostly by running the PHPStorm inspection which searches for
$this usage in a static method. Later I used the PHPStorm "make static"
action which avoids the more obvious mistakes.
Bug: T332865
Change-Id: I47ed6692945607dfa5c139d42edbd934fa4f3a36
What was previously a REST API-only feature (the thumbnails
hook allowing for thumbnails for non-file pages via the
PageImages extension) is now also being adopted in the main
search page.
That hook will now be called with NS_FILE result thumbnails
pre-filled, which was not the case previously. PageImages
essentially duplicated NS_FILE thumbnail logic that was
already present in Special:Search, so that can (and will
in a follow-up patch) then be removed there. Special:Search
will then simply take whatever is produced from the provider
(which will include both NS_FILE thumbs - which it handled
already - as well as whatever else it receives from the hook),
as will the REST API (which already received both)
Since thumbnails can now come in for multiple namespaces &
having some of those results with & others without a thumbnail
can be quite jarring, it was decided that we'd display
placeholder images (for certain namespaces). This is now
controlled by $wgThumbnailNamespaces.
I also split up a few things in FullSearchResultWidget::
generateFileHtml for more clarity.
Meanwhile also updated mediawiki.special.search.styles.less
to use variables for known colors.
Also implemented a 'transform' (required for testing this
change properly) and 'getDisplayWidthHeight' (it became
needed after implementing transform) callback function for
mock Files, and updated some existing tests in response to
these changes.
And some more Rest test files have been updated to allow
passing around a HookContainer instead of only an array of
hooks (from which a new HookContainer would then be created)
to allow the same container to be used across all relevant
objects, who may have it injected as dependency.
Bug: T306883
Change-Id: I2a679b51758020d3e822da01a1bde1ae632b0b0a
When creating ServiceOptions objects or fake HashConfigs use the
constant to refer the config name
Change-Id: I59a29f25b76e896c07e82156c6cc4494f98e64cc
Only check if "real" pages are redirects,
since our RedirectLookup::getRedirectTarget()
does not allow passing in a non-real (e.g.
special page) for redirect lookup.
Bug: T301346, T303352
Change-Id: Icd1fd980bb98f7271b26048b6901927b35549820
This adds full integration tests for extension registration, ensuring
that ExtensionProcessor and ExtensionRegistry work together as expected.
The existing tests for ExtensionProcessor and ExtensionRegistry are
converted to "pure" unit tests.
This change is intended to protect against bugs while refactoring
ExtensionProcessor and ExtensionRegistry to better integrate with the
new SettingsBuilder class.
Bug: T297166
Change-Id: I2d9cc373b8a4aa014aef93b0a8e8d83758851783
Add a field to the response object of the REST
endpoint /search/page to display the title of the page
that the given page is a redirect to, or null if
the page is not a redirect.
Bug: T296671
Change-Id: I6673d50e8eae822455972403c82ec33e6ffce5dd
Previously, when a user with correct permissions uses completion search on a
private wiki, the results are returned and cached. Since we are on a private wiki,
we don't want to cache results since the content is not accessible to all users.
Now, content that is not accessible to all users will not be cached.
This patch achieves this by setting the appropriate Cache-Control response headers
for the MW REST Search endpoint.
Bug: T292763
Change-Id: I693b4088df9c0520d5238c286312ec52ab273604
Most of these are found by the not yet released I10559d8.
I remove the type MockObject in some cases when the calling
code really does not need to know if he get's a mock or the
real thing. However, I do this only in places that are very
closely related to the fixes.
Change-Id: I26a4c3c5a8ae141bf56161b52b54bce7e68f2e30
The functionality of creating title mocks is generally useful
and this will also allow to make HandlerTestTrait more narrow.
Bug: T264058
Change-Id: I76eca48dfcff65a6203fccde5366912a2d66c495
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
By default, core adds those fields as null to each row.
provideThumbnail and provideDescription hooks are introduced.
Extension should subscribe on the hooks to provide a thumbnail and description respectively.
Bug: T250144
Change-Id: I42c6c8ff9d887a440174af2a21c7921573b06640
This allows indirection between the values in $wgSearchType and
$wgSearchTypeAlternatives where the underlying class name
doesn't match the actual class name that subclasses
SearchEngine.
Bug: T250977
Change-Id: Ib9634128f07d428276e80a6f2f492b850eef17e8
Completion search used for type-ahead should make use of http caches,
like ApiOpenSearch does.
Bug: T245675
Change-Id: Ia8366684203381b6c4dc55669a6877e53e9ffe40
