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
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
In 8 years, this is the first time I see this directory exists
and that there is a Makefile that would write to it.
I don't know if anyone uses that, but PHPUnit auto-creates this
directory as needed. Hence, it need not exist ahead of time.
It seems most contributors generate code coverage by invoking
PHPUnit directory, which requires a path to be specified.
Per https://mediawiki.org/wiki/Manual:PHP_unit_testing/Code_coverage,
this tends to be docs/coverage, not docs/code-coverage.
Change the Makefile to write there as well, as better example,
and also add it to gitignore.
Change-Id: I0a4cf716ea9b7fae89c282945b160b0dc7b2d02f
It was still looking for wfRunHooks, which no longer exists
as of MediaWiki 1.32.
After this, it is now able to find one bad hook:
> Unclear hook calls:
> - Hooks::run( $action . 'ArticleComplete', [ .. ] ); # SpecialEditWatchlist
Also, remove the matching of wfRunHooks generally, given it no
longer exists. And also remove the historic notes from hooks.txt.
Change-Id: I4ac52ed75fb99d7775d4b4755e3f0871003d70a8
Authentication audit logs should indicate whether a login is via the
normal password or a bot password (and which one). For failed logins
it could be included in the error message, and it usually is, but
for successful ones there is no message, so we'll send the app ID as
a new AuthManagerLoginAuthenticateAudit parameter.
Bug: T194338
Change-Id: I8aab48177b81a8e80dae118e6476a8f6a32089f1
Depends-On: Id482d2e2205960a0facd334e456d3a23bcad0ece
So that using this hook it's possible to prevent the move, also
providing some more context.
Also, clean error message: instead of going with "you do not have
permission blah blah" for *every* kind of error, use it only when the
error is actually about permissions, and use a generic message
otherwise.
Bug: T208907
Change-Id: I4733724075b7514e9db59e7be772d9409aa9da87
AbortAutoAccount, AbortNewAccount, AbortLogin, LoginUserMigrated,
UserCreateForm, and UserLoginForm are all unused in Wikimedia
production and rare in other extensions.
This also scraps the FakeAuthTemplate and LoginForm classes and
the occasional remainig references thereto.
Bug: T193755
Change-Id: I24d6fa963f402d4311fa00fc11536a37ee3bd31e
The following deprecated methods, intended for overriding by extensions,
are no longer called and are hard deprecated.
* ApiBase::getDescription() (deprecated in 1.25)
* ApiBase::getParamDescription() (deprecated in 1.25)
* ApiBase::getExamples() (deprecated in 1.25)
* ApiBase::getDescriptionMessage() (deprecated in 1.30)
Also, the 'APIGetDescription' and 'APIGetParamDescription' hooks have
been removed, as their only use was to allow extensions to override
values returned by getDescription() and getParamDescription(),
respectively.
Change-Id: I486c4ccab4eca6a85cb17c30dbb2439876123ba1
The startup module varies by skin, so it should be possible for
consumers of the ResourceLoaderGetConfigVars hook to know what
skin it being requested.
Bug: T186062
Change-Id: I97d6b4bc245bc64ff148c3665b46116b8a6be409
With this change, MediaWiki will no longer have a 'JavaScript-powered'
wikitext toolbar, and instead sysadmins will be required to choose one
(or more) of the several extensions available for this purpose if they
need the functionality. For over half a decade MediaWiki's tarball has
included the 2010-era replacement for this feature, WikiEditor. We are
now working on replacing even that, with the 2013-era visual editor, a
mode of which is the forthcoming 2017-era wikitext editor, and several
more specialised editors like CodeEditor.
Beyond this, the core editor toolbar is ancient, un-loved, and is used
only exceptionally rarely, mostly by accident. It is unhelpful to give
implicitly this as the primary editor for MediaWiki just because we've
not removed it from core when it is not a very good experience for any
kind of user, and has not received the attention that users deserve to
be worth retaining in core.
The old core preference, which was intended to govern whether this old
toolbar should be shown, has since mutated into whether the to run the
EditPageBeforeEditToolbar hook. The hook is used by several extensions
to provide toolbars in lieu of the core one. This preference has been,
in practice, a very confusing preference for MediaWiki users, who have
to interact with quite similar preferences to toggle their real editor
which sit next to this one on the preferences page. Consequently, this
preference is also removed.
The code could be made into an extension for those (very few) users of
MediaWiki who might want to keep on using it. However, the author will
offer their services but not their encouragement in said undertaking.
Bug: T30856
Bug: T32795
Change-Id: I2b05f0ca25873ad8e0b33a5e4938bef52c4e9347
This change adds the possibility to specify ext-* keys under the 'platform'
key introduced in I6744cc0be2 to require given PHP extensions. Note that
it's impossible to add constraints different from '*', as there is no universal
way to retrieve PHP extension versions.
Bug: T197535
Change-Id: I510de1e6d80f5c1d92dc1d1665aaa6c25bf28bf7
This hook is created specifically for I379e17c.
The purpose of this hook is to override UserGetRights hook and ensure
that the removed rights will not be reinserted by the other callbacks.
Change-Id: Id31b1f25f2eda012bd811f4b96aac525bc3251c4
While MediaWiki Core already sets requirements for PHP versions, it should be
possible for extensions to tighten these requirements. This mirrors the PHP
parameter of extension infoboxes as well.
This change introduces a new 'platform' key (in addition to 'MediaWiki', 'skins'
and 'extensions', where non-MediaWiki software requirements will be listed
in the future, starting with a PHP version constraint. Further keys are
supposed to be added to allow setting constraints against php extensions
and other abilities of the platform.
Bug: T197535
Change-Id: I6744cc0be2363b603331af9dc860eb8603a1a89a
