And start indicating that hooks relying on this data might become
unreliable as this data is only populated by SearchDatabase search
engines.
This information was only populated by SearchDatabase implementations
and due to bad initial design of SearchResult[Set] (now fixed) it forced
users of these classes to carry this information for the sole purpose of
highlighting.
Because SearchEngine can now own their SearchResult[Set] implementations
nothing that is engine specific should be exposed outside of these
specific implementations.
If there are some logic that still requires access to such list of terms
they should be made engine specific by guarding their code against
instanceof SqlSearchResult.
Change-Id: I38b82c5e4c35309ee447edc3ded60ca6a18b247a
Depends-On: I53fe37c65c7940f696c1e184125e01e592a976e4
Add some of the basic REST API class hierarchies:
* EntryPoint
* Router
* Request
* Response
* Handler
The actual entry point file rest.php has been moved to a separate
commit, so this is just an unused library and service.
Bug: T221177
Change-Id: Ifca6bcb8a304e8e8b7f52b79c607bdcebf805cd1
Extensions can specify development dependencies in extension.json under
the "dev-requires" key. It's identical to the "requires" field.
Any requirement that is needed to pass tests, including but not limited
to, PHPUnit, QUnit, structure, phan, should be documented in this new
field. The main intention is that CI will ensure that all of these
dependencies are satisfied before running tests.
At standard runtime, the development requirements will be ignored by
MediaWiki, since it only checks for real requirements. Scripts can
manually check development requirements by calling
ExtensionRegistry::setCheckDevRequires( true ) before trying to load
things.
If both "requires" and "dev-requires" are present, MediaWiki will merge
the two together, so the environment will need to satisfy both before
proceeding.
Bug: T193824
Change-Id: I9b2936666ee3c96f5c976c7a17f11c437c2c7f48
1. FSFile::getPropsFromPath() is not used by any code any more.
https://codesearch.wmflabs.org/search/?q=FSFile%3A%3AgetPropsFromPath&i=1
The only remaining usage is in one test. We might as well remove the
function.
2. The $props array is passed to the hook for convenience, in case all
the file properties are already available. Fetching them from a file on
disc can be an expensive operation, and should be avoided if the
information is already available. But the caller does not guarantee this
is set. Other callees already know this can be a falsy value, notably
LocalFile::upload().
Change-Id: I43724d18467b6fb68a963b2206332cf553c81b2c
This is to avoid annoying fatal errors when someone annotated their
hook handler to only expect Language objects, but that expectation
is violated due to this code possibly passing StubUserLang to hooks,
some of which may also assign it to $pageLang.
Even with this in place, it is probably a good idea for hook handlers
to refrain from type hinting parameters that are passed by reference
because their types cannot be guaranteed.
Bug: T214358
Change-Id: I88405a8de4b13675eb5a9d11e9ddc87e20a85fb4
The generated links are now always known links.
All users of the hook 'SkinEditSectionLinks' in extensions set
'options' => [ 'noclasses', 'known' ]
5f48eb9acd/TinyMCE.hooks.php (291)857c1bd3d1/includes/VisualEditorHooks.php (617)
This change makes it easier to migrate to LinkRenderer in
Ifc170abc958add28a2fe08aa0c44af83c6f7cad8 without legacy options.
Change-Id: Ia5d151b81dabce9560045b45886f2c77abf975da
This patch adds the possibility for extensions and skins to require
certain environment abiltites that are not necessarily PHP extensions.
For now, the only ability introduced is the ability to shell out, but
the processing and testing is written in a more general way to allow
users to add more abilties later on by just changing getAbilities().
In theory, this allows using VersionChecker to check for random
abilities if they are specified in the constructor, as it is comletely
environment agnostic and not really bound to just be used for checking
extension compatibility.
Furthermore, it is possible to specify custom error messages for each of
these abilities in the constructor. Other parts of MediaWiki may use
these features to check for requirements while working with totally
different abilities.
Bug: T212472
Change-Id: Iff8512530b08ef509e7ac0b6ed8fe9578ef3e2a1
MWNamespace::clearCaches() has been removed entirely, along with the
$rebuild parameter to MWNamespace::getCanonicalNamespaces(). The rest of
MWNamespace is deprecated.
Diff best viewed with -C1 so git notices that NamespaceInfo is a copy of
MWNamespace.
Depends-On: Icb7a4a2a5d19fb1f2453b4b57a5271196b0e316d
Depends-On: Ib3c914fc99394e4876ac9fe27317a1eafa2ff69e
Change-Id: I1a03d4e146f5414ae73c7d1a5807c873323e8abc
This will allow the OAuth extension to subscribe to this hook and add an
“OAuth CID: $consumerId” tag to patrols made via OAuth.
Bug: T219655
Change-Id: Ie5e6f820bbf399ec639e715afd908f78bf5c8e9a
T110209 caused maintenance scripts to fail on unknown parameters,
which is normally desirable. However, some extensions (notably
SemanticMediaWiki) need to support additional params and had no
way to add them to the list of expected parameters. It will
now be possible them to update.php via a new hook:
MaintenanceUpdateAddParams.
Bug: T213893
Change-Id: Ia40949ccb2f32090f21e0f3f7e5b9c4aef322330
This introduces XML schema validation into the unit tests for
the backup dump scripts. This is intended to ensure that the
output keeps conforming to the schema when updating XmlDumpWriter
and friends to support newer schema versions.
Bug: T174031
Change-Id: Iafa8cb8ba5b3684a08172e92974edaf0482f19b7
This hook is required by extensions like MobileFrontend to tag
log entries when actions are performed on the mobile web.
There is a possibility to tag log entries by using
'RecentChange_save' hook, but that works only when the log entry
is published to 'rc' or 'rcandudp'. This means, that tagged log
will appear also on the Special:RecentChanges page which is something
what extensions like 'Thanks' wants to avoid.
In the future we should avoid using 'RecentChange_save' as an
indirect way to tag log entries, and use the
'ManualLogEntryBeforePublish' hook instead.
To cover ourselves in the future, instead of passing &$tags only,
we pass the $this (the log entry object) so extensions can perform
additional checks before using setTags().
Bug: T215675
Change-Id: I747eded4bc5406cd5d4676fc93b0bb55c99f9a4d
This seems to have been intended as optimization for SiteStore,
but was never used as far as I can tell. Instead, SiteStore is
already cached via LocalServerCache (APC).
Keep the FileBasedSiteLookup class for one release cycle in case
third parties not indexed by MediaWiki Codesearch are using it.
== History
* 2013: Report of high memcached usage by Wikibase via SiteStore.
* 2014: Lazy-load the data in Wikibase (d3f2e99cb6).
* 2014: Implement the file-based cache (via T47532 and 90f6efc360).
* 2015: Use local-server cache (APC), per T58602.
The file-based code was never used. The related task marked
invalid (T47532).
Change-Id: I8e2d9edcf3880149f824cc3de37793ca57435b49
Both calling fixUrlQueryArgs, which handle the array case
Also improve hooks docs for the similar functions getLinkUrl/getLocalUrl
Change-Id: I77df39711c7d6b2ee0a3709a6bdaf9cde6a616c6
Clarify that the type of second parameter that is being passed
to the hooks can be anything because one hook can change it and
then it is passed to another hook without the hook caller having
possibility to check or modify the value.
Clarify that hooks should only return Language objects.
Rename $wgLang to $userLang in the hook parameter documentation to
avoid false posivite matches for the global.
Fix some typos, use Title::inNamespace and add a test assertion.
Also, the $content parameter is unused by all implementations of
this method, and on quick look never passed by any caller. I kept
it for now, however.
Bug: T214358
Change-Id: Iae49d2998c2b762565d232c0337d84d43a4a900c
There is a full schema for ResourceModules when the
class: ResourceLoaderWikiModule is used. Except it doesn't actually work,
since it it fails validating against that schema, it will continue to check
the other anyOf schemas, find the arbitrary class one, and pass that one.
Blacklisting ResourceLoaderWikiModule from the arbitrary class schema means
that it has to pass the specified schema for it, or fail validation.
I verified that all extensions and skins in Gerrit pass validation with this
patch.
Change-Id: Icb862088c0ca1f89ed5a57a4286dd9049d213021
We want this regex to match on everything that is not the literal string
'ResourceFileModule' or 'ResourceImageModule' (actually
'ResourceLoaderWikiModule' should be in this too, but I'll fix that in a
follow-up). But the current regex would not match if one of those was in a
substring.
The new regex should match everything that is *not* those two strings.
Bug: T216861
Change-Id: I7d888adfdc67b2075028e49432710308aa0125af
