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
This has been soft-deprecated since MW 1.26; this hard-deprecation
sets the stage for future removal of this old cruft.
Bug: T198214
Depends-On: Idf246d05d116f63a73105b50a1929a7721fbe7b9
Change-Id: I2e7d990da1da378eb6e828d4b3c0f5a41791dd92
This adds getSecondaryDataUpdates and getDeletionUpdates
to ContentHandler, and updates WikiPage and DerivedPageDataUpdates
to handle DataUpdates from all slots.
Bug: T194038
Bug: T194037
Change-Id: I75c96318f58a5cdda48484f7040ae41e6f42392a
While having an overview of the overall design of MediaWiki in the
code repository is a good thing, having an outdated design overview
that has not been substantially updated in 15 years is not helpful.
This is a fun historical document though, so I have put it up at
<https://www.mediawiki.org/wiki/Architecture/design.txt>.
Change-Id: I85be15a68f4ab9ac77766112e6484f2007da4eec
Neither SpecialWatchlistFilters nor SpecialRecentChangesFilters are used in any
code known to Wikimedia code search. The related code to use these hooks was
only ever used within the MediaWiki repo.
Change-Id: Ib631d49d7b5835c665171dbad3e8a646b80827ef
Move logic for rendering a diff between two content objects out of
DifferenceEngine, into a new SlotDiffRenderer class. Make
DifferenceEngine use multiple SlotDiffRenderers, one per slot.
This separates the class tree for changing high-level diff properties
such as the header or the revision selection method (same as before:
subclass DifferenceEngine and override ContentHandler::getDiffEngineClass
or implement GetDifferenceEngine) and the one for changing the actual
diff rendering for a given content type (subclass SlotDiffRenderer and
override ContentHandler::getSlotDiffRenderer or implement
GetSlotDiffRenderer). To keep B/C, when SlotDiffRenderer is not overridden
for a given content type but DifferenceEngine is, that DifferenceEngine
will be used instead.
The weak point of the scheme is overriding the DifferenceEngine methods
passing control to the SlotDiffRenderers (the ones calling
getDifferenceEngines), without calling the parent. These are:
showDiffStyle, getDiffBody, getDiffBodyCacheKeyParams. Extensions doing
that will probably break in unpredictable ways (most likely, only
showing the main slot diff). Nothing in gerrit does it, at least.
A new GetSlotDiffRenderer hook is added to modify rendering for content
models not owned by the extension, much like how GetDifferenceEngine
works.
Also deprecates public access to mNewRev/mOldRev and creates public
getters instead. DifferenceEngine never supported external changes to
those properties, this just acknowledges it.
Bug: T194731
Change-Id: I2f8a9dbebd2290b7feafb20e2bb2a2693e18ba11
Depends-On: I04e885a33bfce5bccc807b9bcfe1eaa577a9fd47
Depends-On: I203d8895bf436b7fee53fe4718dede8a3b1768bc
This way the hook is able to consider what kind of DifferenceEngine
was created by default, or even wrap/decorate it.
Change-Id: Ibb6b1b087a2dda445be2b5e8c7518c7d169b5192
* Move $wgEnableProfileInfo to DefaultSettings.php
* The configuration variable to enable the entry point was added
together with the entry point itself in 9af3c09e5c (r9846).
* Change references to StartProfiler.php to refer to LocalSettings.php,
given the former is deprecated since 1.31 (I4e8dd9558132).
Change-Id: I7ca5f2deace8645f06bebd915630c1de05c84bc5
The use of global variables was deprecated in favour of
ResourceLoaderModule::getLessVars() on a per-module basis.
Also moved testLessFileCompilation case to the appropiate file as it
covers ResourceLoaderFileModule.php, not ResourceLoader.php.
Bug: T140804
Depends-On: Ib1b2808df2384473bfac47f53a5d25d7c9bbca2b
Depends-On: I96047f69d01c4736306df2719267e6347daf556f
Change-Id: If708087c85c80355c7e78f1768529b5f2e16ed07
I think it's reasonable for link "colours" to depend on the page on
which they are shown. It seems similar to how self-links are handled.
The $colours variable is not cached, so title-specific link colours
will not "leak" to other titles.
Used in ProofreadPage in Ic910c2c33a6f1f8a70d9a122fbd2128428f29bd5.
Bug: T199288
Change-Id: I7378102a3e06544e9e695b255982c9bb0cfbf3a2
This doesn't belong here and also doesn't make a lot of sense
with current browser support any more.
We shouldn't provide basic HTML documentation in 2018 as part of
core.
Change-Id: I1a3516e45902d16f0d9efbe97cb2dbd6efd566be
This allows AbuseFilter to add an extra link in the tool links section of
the subtitle on a history page
Co-authored-by: Matěj Suchánek
Bug: T28934
Change-Id: I2e0e9e92d3fc303135b0eb9acf06b5fd120178a5
Code from wikiHow codebase, where this hook is used by the following extensions:
* AlternateDomain -- used to remove certain links altogether and change the contents of other elements (e.g. <meta description="..." />)
* hooks (PageHooks) -- used to hide certain links for anons on noindexed pages to avoid leaking article info to Googlebot
* QADomain -- used to remove certain elements and correct <meta keywords="..." /> tags not to mention "wikiHow" if that string is present
* search (LSearch) -- used to remove canonical URL on Special:LSearch for SEO
Change-Id: I4a9ceb343bb5c0b4eb79e4589d36c3790938f8a9
wikiHow added a new hook called 'SpecialSearchPowerBoxOpts', which was passed only &$opts, so that the Finner extension can unset the $opts array. Enhancing the pre-existing hook is a better solution in this case.
Change-Id: I091cbdc78fc779144554d8420a95435b7048c407
* All Xml generation code has been removed.
* The LogEventsListGetExtraInputs hook now needs a form
descriptor array and not plain HTML.
See I37e0d3e81a46239750465b9299279fbbd7c7f87a.
* LogPager and LogEventList also take the $day parameter
for 'From date (and earlier)' and pass it to getDateCond
as well.
* Since FormOptions can't automatically extract the date
from the request this is being done manually in the
execute method of Special:Log using MWTimestamp.
Bug: T117737
Change-Id: Iba3c6aa5ac40dcdee0792c2d045b238b02d76521
Without these rules, validation will fail in any skin or
extension that tries to use it.
Follows-up 36252b7.
Bug: T198930
Change-Id: Iee77655d4868a7d921be8cc23776a7859d9acf0c
The $baseRevId in WikiPage::doEditContent is used only to indicate what
revision an edit reverted to. It is not used to indicate the actual base
revision of an edit in any sense. Specifically, EditPage never sets it.
So, this change renames the parameter to $originalRevId to match $undidRevId.
It also renames PageUpdater::setBaseRevisionId to setOriginalRevisionId.
Further, this introduces a paramter to PageUpdater::hasEditConflict():
Before this change, PageUpdater::hasEditConflict() was based on the
revision set via PageUpdater::setBaseRevisionId(), assuming the semantics
of "base revision" used by EditPage. However, this is NOT how the $baseRevId
parameter in WikiPage works.
Bug: T197685
Change-Id: Ib78257d4d6ee7c4ec093d5706904c599b02c73e0
Hooks [UploadForm:BeforeProcessing] and [UploadForm:initial] get SpecialUpload
object as their parameter (NOT the UploadForm object).
Also replaced obsolete note "use UploadVerification and UploadVerifyFile"
with modern "use UploadVerifyUpload".
Change-Id: I09ac5b238c8619c94978bdc771653127d3a6264d
This introduces PageUpdater to replace WikiPage::doEditContent,
and DerivedPageDataUpdater, to replace WikiPage::doEditUpdates
and WikiPage::prepareContentForEdit.
See docs/pageupdater.txt for a description of their
functionality.
MCR migration notes:
* The interface of PageUpdater is expected to
remain mostly stable after this patch. Code that has been using
WikiPage::doEditContent can be confidently migrated to using the
new mechanism for revision creation.
* This patch keeps the code inside PageUpdater largely aligned
with the old code in WikiPage, to make review easier to to avoid
mistakes. It is intended to be refactored further, moving
application logic into stateless services.
* DerivedPageDataUpdate is intended as a stepping stone for further
refactoring. Its behavior is designed to be compatible with
callback code that currently relies on
WikiPage::prepareContentForEdit. Much of the code that currently
lives in DerivedPageDataUpdate should be factored out into
services, all behavior relevant to calling code should be exposed
via narrow interfaces.
Bug: T174038
Bug: T196653
Change-Id: If610c68f4912e89af616cdcac1d35a1be3946afa
This file is a disaster, but now at least we actually wrap at 80 chars
for all the hooks, not just the ones where the developer felt like it.
Change-Id: I10d3d51412af29b135fd7e9a0393ff0b57eb25aa
Many of these are still soft-deprecated, so tracking down their age
and kicking off the full deprecation process is hard, let alone
actually removing them. Doing this makes that future work easier.
Change-Id: Ib096190accceabf9082f621ba96243f7dedb025d
This allows extensions to essentially reimplement Linker#makeImageLink
completely. Before this wasn't 100% possible as these three are needed for
that.
Inspired by wikiHow's core hacks to /includes/Linker.php, which can now be
moved to an ImageBeforeProduceHTML hook subscriber. wikiHow uses those
changes together with the WikihowArticle extension to heavily modify the
article DOM for various extensions and the default skin.
Change-Id: I8b5ab42d9cf021d66b90d15be68a0239643c10e3
This will be useful when an extension does something expensive and wants to
make sure users don't put too much pressure on the system.
Bug: T194950
Change-Id: I8a396d07c2d5764a680d0e5536cd1f99edbe141e
Remove mention of this deprecated global in favour of documenting
the backend configuration instead.
Also update the outdated docs for where the sidebar is cached,
which was changed a while ago to use WANObjectCache instead.
See Skin::buildSidebar().
Change-Id: I3d34a760cc05cab6fe7ddd8684257d6ec6b49309
In change 4633f4d46a it was changed
to an interface implemented by both PreferencesFormLegacy and
PreferencesFormOOUI so that existing typehints for some functions
parameter would accept them both. Replace those typehints to use
HTMLForm instead. There was really no guarantee in the past that
they would only be given PreferencesForm or its subclasses, either.
Because the typehint change affects some hooks, note it as a
deprecation in MW 1.31 and a breaking change in MW 1.32.
Also add @since tags and correct some typos in code comments.
Follow-up to 4633f4d46a.
Change-Id: I61749f1d864cf68afe90cd9e15ba2d7a74252501
The PSR-4 autoloader requires "AutoloadNamespaces" keys to have a
trailing \ (\\ in JSON), so add a validation check for that.
Unfortunately the validation error isn't great, since it checks to see
if the property matches patternProperties, and when it doesn't, it
claims the property isn't defined since additionalProperties is false.
But it's still better than not failing when they are missing.
Bug: T189136
Change-Id: If01bd06cdd767fb704a8ff85cdf1c143e53fa4ca
The primary goal here is a defense in depth measure to
stop an attacker who found a bug in the parser allowing
them to insert malicious attributes.
This wouldn't stop someone who could insert a full
script tag (since at current it can't distinguish between
malicious and legit user js). It also would not prevent
DOM-based or reflected XSS for anons, as the nonce value
is guessable for anons when receiving a response cached
by varnish. However, the limited protection of just stopping
stored XSS where the attacker only has control of attributes,
is still a big win in my opinion. (But it wouldn't prevent
someone who has that type of xss from abusing things like
data-ooui attribute).
This will likely break many gadgets. Its expected that any
sort of rollout on Wikimedia will be done very slowly, with
lots of testing and the report-only option to begin with.
This is behind feature flags that are off by default, so
merging this patch should not cause any change in default
behaviour.
This may break some extensions (The most obvious one
is charinsert (See fe648d41005), but will probably need
some testing in report-only mode to see if anything else breaks)
This uses the unsafe-eval option of CSP, in order to
support RL's local storage thingy. For better security,
we may want to remove some of the sillier uses of eval
(e.g. jquery.ui.datepicker.js).
For more info, see spec: https://www.w3.org/TR/CSP2/
Additionally see:
https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy
Bug: T135963
Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
Single-file modules to src/, the remaining as sub directories.
A few highlights:
* mediawiki.Upload.BookletLayout. (stylesheet: no image references)
* mediawiki.feedback - Also move the image to its own images/ subdir.
* mediawiki.searchSuggest. (stylesheet: no image references)
* mediawiki.toc. (stylesheet: no image references)
Also updated any other references to 'src/mediawiki/' that I could find
in core:
* Fixed references in docs/uidesign/*.html
* Remove redundant exclude from jsduck.json.
After this, there are 4 files remaining in src/mediawiki,
which are the 4 files used by the actual 'mediawiki' base module.
Bug: T193826
Change-Id: I8058652892a78b3f5976397bd850741dd5c92427
There has long been a hack for previewing edits to user JS/CSS, where
OutputPage would pass an 'excludepage' parameter to
ResourceLoaderUserModule to tell it not to load one particular page and
would instead embed that page statically. That's nice, but there are
other places where we could use the same thing.
This patch generalizes it:
* DerivativeResourceLoaderContext may now contain a callback for mapping
titles to replacement Content objects.
* ResourceLoaderWikiModule::getContent() uses the overrides, and
requests embedding when they're used. All subclasses in Gerrit should
pick it up automatically.
* OutputPage gains methods for callers to add to the override mapping,
which it passes on to RL. It loses a bunch of the special casing it
had for the 'user' and 'user.styles' modules.
* EditPage sets the overrides on OutputPage when doing the preview, as
does ApiParse for prop=headhtml. TemplateSandbox does too in I83fa0856.
* OutputPage::userCanPreview() gets less specific to editing user CSS
and JS, since RL now handles the embedding based on the actual
modules' dependencies and EditPage only requests it on preview.
ApiParse also gets a new hook to support TemplateSandbox's API
integration (used in I83fa0856).
Bug: T112474
Change-Id: Ib9d2ce42931c1de8372e231314a1f672d7e2ac0e
* Remove left-over mention of the .php5 entry points in docs.
* Remove dead logic in NoLocalSettings for php5 entry points.
* Remove dead match in WebRequest for php5 entry points (they'd
redirect since 1.25, and not seen by PHP).
Change-Id: Ia0ee8588591860b8fe34030c8503f38e9bce31f3
Deprecated since 1.30, only had one caller (MobileFrontend)
which has been fixed since.
Bug: T140804
Change-Id: I39b594e3082ebe321bae463780cfadbfb3de1d5c
PlatformSettings.php is a standardized and recommended way for
re-distributors and packagers of MediaWiki to be able to tune
DefaultSettings.php as appropriate.
If includes/PlatformSettings.php exists, the installer will
automatically include it as part of the generated LocalSettings.php.
The main advantage of this system is that if the distributor wants to
change the default settings, all users will benefit immediately. And if
people want a vanilla MediaWiki experience, they can just remove the
inclusion from their LocalSettings.php.
This RfC
(<https://www.mediawiki.org/wiki/Requests_for_comment/PlatformSettings.php>)
was approved by TechCom.
Bug: T182020
Change-Id: I34f9a4acbe86b9c5c80ac16451b317ce5f6640f9
This makes it possible for extensions to add to the WHERE clause
with which unknown preferences are deleted.
Bug: T188966
Change-Id: Ifb22ca42207956f2b07333da026ff0b215a83930
It was never super popular anyway, APC was always the best option.
The project has no plans to move to PHP7, so it's quickly reaching
its end of life. Oh, and Fedora dropped it from their repos 2 years
ago.
Change-Id: Ia3257e86a6323d8943f04a5c05c72c0bd4c4b0a9
So that more than just PHP code and MediaWiki core can use it, but
also JSON-based static extension registrations. :-)
Change-Id: If22fccbb43c5b05db2a666d61ae8864ee9815e7d
* Some of the license selection code (License & Licenses)
has seen some minor refactor to make it more open to
reuse/extension elsewhere.
Extension:3D will make use of these for patent selection in
Iafb1e7e5da4b67f4c5ae7dda511d130ae10f748c
* License/TemplateSelectorLine has been modified so the text
can be wikitext (as needed for patent labels)
* uploadLicense was renamed to uploadTemplatePreview and
altered so it can be reused elsewhere. And, like
window.wgUploadWarningObj, uploadTemplatePreview is now also
added to `window` so it can be re-used from elsewhere (to
preview patent templates)
Bug: T182683
Change-Id: I0c097442aa557dd90eb5825553ebf892f9af8a01
This is a re-submission of I4f24e7fbb68.
As a first major step towards Multi-Content-Revisions (MCR),
this patch turns the Revision class into a legacy proxy for
the new RevisionRecord and RevisionStore classes.
Backwards compatibility is maintained for all but some
rare edge cases, like constructing a completely empty
Revision object.
For more information on MCR, see
<https://www.mediawiki.org/wiki/Requests_for_comment/Multi-Content_Revisions>.
NOTE: once this is merged, verify create/delete/restore cycle on beta,
ideally with emulated replication lag.
Bug: T174025
Change-Id: Ia4c20a91e98df0b9b14b138eb4825c55e5200384
This reverts commit 9dcc56b3c9.
With this patch applied, newly created revisions are sometimes not found
just after submitting an edit, until replicas have caught up.
Our best theory is that it somehow interfere with ChronologyProtector,
but we don't have a good idea how.
Also, as legoktm mentioned, the commit message is terrible and needs fixing.
Change-Id: Idf3404f3fa8f8d08a7fb2ab8268726e2c1edecfe
This adds support for a PSR-4 (<http://www.php-fig.org/psr/psr-4/>)
autoloader, so instead of needing to manually list each class, just the
namespace prefix is needed.
Extensions can set a "AutoloadNamespaces" property in extension.json to
register PSR-4 compatible namespaces to be autoloaded.
The implementation is based off of the example implementation
(<http://www.php-fig.org/psr/psr-4/examples/>) with some modifications
for performance, notably cutting down on function calls, and only trying
to look up classes that are namespaced.
The generateLocalAutoload.php script will ignore any directory that is
registered as a PSR-4 namespace.
Bug: T99865
Bug: T173799
Change-Id: Id095dde37cbb40aa424fb628bd3c94e684ca2f65
Importing revisions in MediaWiki has long been weird: if the username on
the imported revision exists locally it's automatically attributed to
the local user, while if the name does not exist locally we wind up with
revision table rows with rev_user = 0 and rev_user_text being a valid
name that someone might later create. "Global" blocks too create rows
with ipb_by = 0 an ipb_by_text being a valid name.
The upcoming actor table change, as things currently stand, would
regularize that a bit by automatically attributing those imported
revisions to the newly-created user. But that's not necessarily what we
actually want to happen. And it would certainly confuse CentralAuth's
attempt to detect its own global blocks.
Thus, this patch introduces "interwiki" usernames that aren't valid for
local use, of the format "iw>Example".[1] Linker will interpret these
names and generate an appropriate interwiki link in history pages and
the like, as if from wikitext like `[[iw:User:Example]]`.
Imports for non-existant local users (and optionally for existing local
users too) will credit the edit to such an interwiki name. There is also
a new hook, 'ImportHandleUnknownUser', to allow extension such as
CentralAuth to create local users as their edits are imported.
Block will no longer accept usable-but-nonexistent names for 'byText' or
->setBlocker(). CentralAuth's global blocks will be submitted with an
interwiki username (see Ieae5d24f9).
Wikis that have imported edits or CentralAuth global blocks should run
the new maintenance/cleanupUsersWithNoId.php maintenance script. This
isn't done by update.php because (1) it needs an interwiki prefix to use
and (2) the updater can't know whether to pass the `--assign` flag.
[1]: '>' was used instead of the more usual ':' because WMF wikis have
many existing usernames containing colons.
Bug: T9240
Bug: T20209
Bug: T111605
Change-Id: I5401941c06102e8faa813910519d55482dff36cb
Depends-On: Ieae5d24f9098c1977447c50a8d4e2cab58a24d9f
This overwrites the generic marker from the wikidiff2 lib and adds
simple RTL aware arrows that indicate movement of the paragraphs.
Bug:T176486
Change-Id: I3554785772a091c3813e41071efcb7bb9a26a951
Several classes have a "selectFields()" static method to tell callers
which fields to select from the database. With the recent comment table
change and the upcoming actor table change, this pattern has become too
simplistic as a SELECT will need to join several tables to be able to
retrieve all the needed fields.
Thus, we deprecate the selectFields() methods in favor of getQueryInfo()
methods that return tables and join conditions in addition to the
fields.
Change-Id: Idcfd15568489d9f03a7ba4460e96610d33bc4089
This would allow extensions to define custom attributes on title link,
such as put information in "title", change attributes depending on
specific search hit, etc.
Now Wikidata does the same by overriding LinkBegin, but this applies
to all links, not specifically to search result link.
Since ShowSearchHitTitle is always used with the link, I think it makes
sense to enable this specific customization.
Change-Id: I19f64e0909d92e32ddf6271f74c014e8b65d5014
It seems that textareas have their own font-size set in Chrome (but not
Firefox and other browsers), making them unaffected by this behavior.
Change-Id: I811245ea26b4d90ad252fe8f6d2e096e27cb9073
Add the test entry point, because it contains documented hooks.
Filter out empty args, coming from trailing commas
Removed empty lines from hooks.txt, because a hook must be one block
without newlines between.
Change-Id: I71e0625da96cad03f5e38a000fa61d1d2bdac8ef
Change 950cf6016c took care of the most,
but a few remain, either outside of includes/ and maintenance/
directories (which that change was limited to), or in code introduced
afterwards.
Change-Id: I9c363d0219ea7e71cde520faba39406949a36d27
Add deprecation notice to $wgResourceLoaderLESSVars and
hook 'ResourceLoaderGetLessVars'. Warnings to be added in 1.31.
Users should migrate to exposing variables via the individual module's
getLessVars() method.
- Ensures better cache invalidation.
- Separates concerns for getting information and exposing information
as less variables. And allows an extension to, for example, use
a different variable name for something if needed.
The 'deviceWidthTablet' variable will need to be migrated to
either a regular configuration variable that individual modules
can expose in their getLessVars() method - or, alternatively, we
can deprecate it altogether in favour of exposing it through
a less import file instead (see T112747). That would mean, however,
that the value can only be changed in core, not by site config.
Bug: T140804
Change-Id: I61cff1d9652d88dc53c43075dd5053b7707809e6
Example implementation using this hook: wikiHow's ChineseVariantSelector
extension, installed on zh.wikihow.com, which uses cookies to store the
preferred language variant, allowing anonymous users to change the
language variant without registering/logging in.
Change-Id: I5295a26578b45a8d51f2b7550938088fec18404f
Adds RecentChangesPurgeRows hook which gets called in the same
transaction where old recentchanges rows are purged, and gets the
list of deleted rows. Extensions which store data for joining to
recentchanges can use this to purge their own data.
Bug: T159753
Change-Id: I03f1d485a1a3004412e0859d9d878b7895c95b40
Also update the hooks documentation. Now that it is using HTMLForm the
<fieldset> is closed before the submit button is added. The old code
was closing the <fieldset> after adding the submit button so the
documentatio made sense.
Bug: T111999
Change-Id: I109065100e40fef0c56a010c444de04a40950479
* UnitTestsAfterDatabaseSetup
* UnitTestsBeforeDatabaseTeardown
Bug T168802 necessitates that CentralAuth creates its tables
before any user tests are run, due to its extensive hooking
into everything. This change adds two hooks for that, called
after DB initialization is done and before teardown begins. The
corresponding CentralAuth change is
at I618840fafd22d9b6471eb470ef0414e354aa17f5
Bug: T168802
Change-Id: If7050513719833d4167a24283885d7c10a25856b
Changes:
- added one argument to PreferencesFormPreSave hook,
a $oldUserOptions array which contains set of all user
options before save
- updated documentation
Bug: T169365
Change-Id: I28003c5898d64031e1efb212cb0bec58ff44b958
We have several types of change lists (old RC/watchlist/related
changes, enhanced RC/watchlist, history) with slightly different
HTML, each with their own idiosyncracies. JavaScript code trying
to identify lines by log ID / revision ID has to jump through all
kinds of hoops to work with that.
To simplify the lives of frontend / gadget maintainers and provide
something approaching an API for these pages, we now expose the basic
attributes of each change line (revision ID for edits, log type/action
and ID for log events) as data attributes.
The OldChangesListRecentChangesLine, EnhancedChangesListModifyLineData,
EnhancedChangesListModifyBlockLineData, PageHistoryLine,
ContributionsLineEnding and DeletedContributionsLineEnding hooks
are updated accordingly. New hooks (LogEventsListLineEnding and
NewPagesLineEnding) are added for the change list pages which did
not yet have them.
Change-Id: I6dd006d0b1b0fd35c0020f0f9eea9113eca30b35
* ParserOptions is reorganized so it knows all the options and their
defaults, and can report whether the non-key options are at their
defaults.
* Definition of the "canonical" ParserOptions (which is unfortunately
different from the "default" ParserOptions) is moved from
ContentHandler to ParserOptions.
* WikiPage uses this to throw an exception if it's asked to cache
with options that aren't used in the cache key.
* ParserCache gets some temporary code to try to avoid a massive cache
stampede on upgrade.
Bug: T110269
Change-Id: I7fb9ffca96e6bd04db44d2d5f2509ec96ad9371f
Depends-On: I4070a8f51927121f690469716625db4a1064dea5
includes/resourceloader/ResourceLoaderOOUIModule.php
* New trait centralizing some logic for dealing with OOjs UI themes,
previously duplicated in OutputPage, ResourcesOOUI.php and
ResourceLoaderOOUIImageModule.
* Follow-up change I74362f0fc215b26f1f104ce7bdbbac1e106736ad uses this
as a base to allow skins/extensions to define new OOjs UI themes.
resources/Resources.php
resources/ResourcesOOUI.php
includes/resourceloader/ResourceLoader.php
* OOjs UI resource module definitions are moved back to their rightly
place in Resources.php. They are again (almost) normal and static.
* Theme-specific logic is now handled by the module code, definitions
only specify 'themeScripts'/'themeStyles'/'themeImages'.
* ResourcesOOUI.php is deleted and no longer loaded by ResourceLoader.
includes/resourceloader/ResourceLoaderOOUIFileModule.php
includes/resourceloader/ResourceLoaderOOUIImageModule.php
* Glue code previously existing in ResourcesOOUI.php now lives here.
* Use the ResourceLoaderOOUIModule trait to avoid code duplication.
Change-Id: I39cc2a735d9625c87bf4ede6f5fb0ec441d47dcc
This should work the same way as registering API modules via a factory callback.
Point in case: Ifb8611473a971 could avoid global state using this mechanism.
Change-Id: Ifbf29006141ce2a2dff42efa352f406502a06bc6
This moves attributes out of the top level, and namespaces them under
each extension. If the extension that it belongs to is not installed,
the attribute is not exported and dropped.
The full name of the attribute is the name of the extension plus the
name of the attribute key. This enforces the recommendation that the
attribute name start with the extension's name.
Add test coverage for attributes under manifest_version 1 and 2.
Bug: T133627
Depends-On: I5a148763f68989c8da313a4fb1d0213658ee4495
Depends-On: I5a148763f68989c8da313a4fb1d0213658ee4459
Change-Id: I8613a027c56e2c9d2c6a83ca14749eb1c8fc23be
$wgJobClasses can now specify a factory function for creating a job,
instead of a class to be instantiated directly. This makes it possible
to inject services in a job constructor, and register a factory function
that calls the constructor with default services.
This follows Ieb85493a7765 and Ia2107dc5af78, which introduced factory
functions for API modules and special pages.
Change-Id: I0461e59da2a8fa6681e3b1fcdfc38bfed7f3ac32
Callers to the EditPageBeforeEditToolbar hook can now return false to
signal that the toolbar is over-written, in which case this old code
won't be called (so no deprecation warnings for users of WikiEditor,
CodeEditor, etc.).
Bug: T30856
Depends-On: I5e755ef5dffb843368563511044d3123f14dc4bc
Change-Id: I3bed70a20e4b94fe3d04a00925b8012312202574
This patch introduces a new special page named AutoblockList.
Its design is reused from Special:BlockList.
Bug: T146414
Change-Id: I811d23c98be749d8df36700b07a295355691af77
Allows search engine to suggest deleted titles for undelete search.
Note that the titles are still verified against the archive table,
to ensure search engine is not out-of-date.
Bug: T109561
Change-Id: Id6099fe9fbf18481068a6f0a329bbde0d218135f
getCheckboxes() directly generated the HTML for the
"This is a minor edit" and "Watch this page" checkboxes,
and allowed extensions to add more HTML checkboxes (and
modify existing ones) using the 'EditPageBeforeEditChecks'
hook. This prevents us from ever changing the format of
the HTML (e.g. to use OOUI checkboxes).
Introduce new method getCheckboxesDefinition(), which
generates the checkboxes in a machine-readable format,
with a new hook 'EditPageGetCheckboxesDefinition'.
Rewrite getCheckboxes() in terms of that. The old hook
'EditPageBeforeEditChecks' is now deprecated.
Change-Id: I3dbe973dcac6cba0c3a1ac5d983cafcfb49d833c
Directly mention ChangesListBooleanFilterGroup and
ChangesListStringOptionsFilterGroup so people know what to construct.
Change-Id: I3c105d072889c1da26f94402326ba48635081833
Explicitly block two filters in the same group from having the same
name.
Before, it would be left to registerFilter, which would just cause
the second one to win.
Also, avoid a getFilter warning when the filter does not exist.
Do the same for getFilterGroup on ChangesListSpecialPage
Finally, a minor related doc fix.
Change-Id: I6b3880a5c7cc381c169bbd969cd4814559b49c91
This reverts commit 1525f6cd45.
This should be functionally equivilent to what was being done
before. When go is triggered but does not cause a redirect the
hook is called. Nothing is done with the result of the hook, same
as before.
Not going to bother deprecating, it doesn't particularly hurt the
architecture in any way, it was removed for being what appeared as dead
code due to a long removed feature. There are apparently a few usages of
this in extensions that may or may not work with recent releases of
mediawiki.
Bug: T160441
Change-Id: I368dec79431fbcc8d04f95afed8bbc7262a2e5de
Generate old RC, Related changes (it was already displayed and working
on 'Related changes' before this change), and Watchlist/etc. and data
for new UI from back-end.
This moves everything used for defining the old (unstructured) and new
(structured) filters into unified objects, ChangesListFilter and
ChangesListFilterGroup (and sub-classes).
This includes the query logic (see below) and logic for adding
CSS attribution classes.
This is a breaking change (for subclasses of ChangesListSpecialpage)
due to the signature (and name) change of buildMainQueryConds and
doMainQuery. An alternative that I don't think is a breaking change
would be to put the filter->DB logic in runMainQueryHook, but then it's
doing more than just running a hook.
This is because it used to only build $conds here, but it's clear from
filterOnUserExperienceLevel filters need more than this. I added all
the DB parameters from the hook, but this could be debated.
I have an checked and fixed the WMF-deployed extensions affected by
this.
Other than that, there should be full back-compat (including legacy
filters not using the new system).
* add hidepatrolled/hideunpatrolled to new UI.
* Move userExpLevel from RC to ChangesListSpecialPage. Although for
now the structured UI only displays on RC anyway, when it displays on
watchlist, it seems we'll want userExpLevel there.
Change this to make 'all' exclude unregistered users.
* Don't have front-end convert none-selected to 'all' on string_options.
* Needs the hideanons/hideliu special redirect to be done before this
is merged (T151873)
Bug: T152754
Bug: T152797
Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
In addition to the general (English) description key in a config
option in extension.json, developers now can provide a description message
key. This localized message will be used in user interfaces, such as
viewing configuration options on-wiki (see later changes).
Bug: T155157
Change-Id: I5c780b3347bd54a05694cfa6de93879656b4e921
This value is currently unused but will be used in later changes
for allowing to view configuration options on-wiki. It will require each
extension maintainer to whitelist the keys that can be published by marking
them as public.
Bug: T155156
Change-Id: I020c148157818ef8bfee0e79cb5a6f43181c5a8c
I was bored. What? Don't look at me that way.
I mostly targetted mixed tabs and spaces, but others were not spared.
Note that some of the whitespace changes are inside HTML output,
extended regexps or SQL snippets.
Change-Id: Ie206cc946459f6befcfc2d520e35ad3ea3c0f1e0
Use of &$this doesn't work in PHP 7.1. For callbacks to methods like
array_map() it's completely unnecessary, while for hooks we still need
to pass a reference and so we need to copy $this into a local variable.
Bug: T153505
Change-Id: I8bbb26e248cd6f213fd0e7460d6d6935a3f9e468
v2 of the schema allows extensions and skins to be definied under
"requires". This is also used by some extensions in extension.json for
v1.
It works, so allow the same properties in v1 as in v2.
Change-Id: I9b5f1986cadbd714d6f3460ac3e1db3bf7aae65d
VersionChecker is using a switch with a exception in the default path,
which makes it very unhappy to see additional properties.
Change-Id: Ief84497de6b2fa2d2715fc713088bee66c21fdc0
This patch adds an ug_expiry column to the user_groups table, a timestamp
giving a date when the user group expires. A new UserGroupMembership class,
based on the Block class, manages entries in this table.
When the expiry date passes, the row in user_groups is ignored, and will
eventually be purged from the DB when UserGroupMembership::insert is next
called. Old, expired user group memberships are not kept; instead, the log
entries are available to find the history of these memberships, similar
to the way it has always worked for blocks and protections.
Anyone getting user group info through the User object will get correct
information. However, code that reads the user_groups table directly will
now need to skip over rows with ug_expiry < wfTimestampNow(). See
UsersPager for an example of how to do this.
NULL is used to represent infinite (no) expiry, rather than a string
'infinity' or similar (except in the API). This allows existing user group
assignments and log entries, which are all infinite in duration, to be
treated the same as new, infinite-length memberships, without special
casing everything.
The whole thing is behind the temporary feature flag
$wgDisableUserGroupExpiry, in accordance with the WMF schema change policy.
The opportunity has been taken to refactor some static user-group-related
functions out of User into UserGroupMembership, and also to add a primary
key (ug_user, ug_group) to the user_groups table.
There are a few breaking changes:
- UserRightsProxy-like objects are now required to have a
getGroupMemberships() function.
- $user->mGroups (on a User object) is no longer present.
- Some protected functions in UsersPager are altered or removed.
- The UsersPagerDoBatchLookups hook (unused in any Wikimedia Git-hosted
extension) has a change of parameter.
Bug: T12493
Depends-On: Ia9616e1e35184fed9058d2d39afbe1038f56d7fa
Depends-On: I86eb1d5619347ce54a5f33a591417742ebe5d6f8
Change-Id: I93c955dc7a970f78e32aa503c01c67da30971d1a
Reasons:
* $text is vague. It's the label of the link. There is a function named
getTitleSnippet, which is what I'm reusing for the variable name.
* $page is vague. It's not the page of the search result, but the search
special page.
* $queryString is not a string but an array of strings.
I also updated https://www.mediawiki.org/wiki/Manual:Hooks/ShowSearchHitTitle
accordingly.
Change-Id: Ia18dbf5ccf7f9fcc8890ad01641d0b7ff3e6eee8
Changing hook signatures with no deprecation period is a no-no.
Fixes Ib527fc3a3c39eb2e56985e5d1e4905fc4562353c
Reverts I153a7d590faceb1e2c4fe7d95a5cb931cda0c301
Bug: T155625
Change-Id: I2b408691fc4435ef24fc62360bd7ad6114f385c7
In general, there's no reason to use by-ref on objects unless
the hook is supposed to replace them (this one isn't).
Change-Id: I153a7d590faceb1e2c4fe7d95a5cb931cda0c301
This was suggested at a Developer Summit session as a way to get people
to know about the mailing list.
This also adds a hook so ApiFeatureUsage can mention itself in
deprecation warnings too.
Bug: T148855
Change-Id: I04a7cf89e87e48f6504803dd173e779017a205d0
So that extensions like MessageCommons can try to use this (and
$wgLanguageCode) instead of $wgLang->getCode()/$wgContLang->getCode(), as
the latter ones cause fatals and recursion, at least with the Gadgets
extension also enabled at the same time.
Change-Id: If71fe1ded26c7a1c771128397783783ad5715b00
First step in refactoring the search results page. Pulls out widgets
to render our two styles of search result, Full and Simple.
Bug: T150390
Change-Id: If78cb0c29ae394f16e465c15a8e8246c1b56dcea
Currently, there is no hook that runs before a user's groups are changed. Adding a hook here will allow for action before the groups are changed.
Bug: T49338
Change-Id: I87dbb6a8eb897f4a40215d33d1a0b24af7efa871
Currently, there are two hooks ('BlockIP' and 'BlockIPComplete') that run when a user or IP is blocked in Special:Block, but no similar hooks when a user is unblocked in Special:Unblock. Adding these two hooks allows an extension to add and remove criteria about a user/IP unblock before it occurs and for possible action after an unblock is completed.
Bug: T50546
Change-Id: I9d9888dc5f1bb6a8bc62e90e6a423bf56b05173b
This will allow for checking passwords against the wiki's password
policy from the account creation and password change forms.
Bug: T111303
Change-Id: I0de281483bd83e47d80aa1ea37149d14f2ae5ebd
This passes the id of the revision that was undone to the
PageContentSaveComplete hook, since this hook is now inside a deferred
update so extensions can no longer rely on 'wpUndidRevision' being
present in the request.
Change-Id: I50dcb841cd0616acc2d69c3a685ba3cb339986c3
Instead of having the current version of the schema live at
extension.schema.json, always include a version number in it. This
simplifies both the code, and makes merging, cherry-picks, rebasing,
etc. easier when the current schema version changes.
Change-Id: I1b5ef4ced1eb34b8bdda7ba9b3f086b1997b704c
For mucking with the class member variable mNewContent and optionally
allowing the suppression of the "missing revision" message when revision
data is not found for a requested revision.
Originally implemented as the "GetUserMessagesDiffCurrent" hook (yes,
these three separate hooks in three separate places were essentially the
same) by Wikia for their SiteWideMessages extension.
Change-Id: Ie0c175af2af418d4ed3de28c94df918115312da3
There are some extensoins that depend upon another extension or skin,
usually in different ways:
* A constant that is added in the dependency extension, and the
existence of is checked for. This is problematic because it requires a
specific load order.
* Checking whether a specific class exists. This is problematic because
it is extremely fragile, and breaks whenever the class is renamed.
* Checking ExtensionRegistry::isLoaded(). This is mostly there, but it
only checks at runtime, and doesn't provide any machine readable data.
Furthermore, developers implement each one differently, with very little
standardization.
With this, extensions may now specify what other extensions they depend
on. This is for explicit *hard* dependencies that must be installed.
For example:
"requires": {
"MediaWiki": ">= 1.25.0",
"extensions": {
"FakeExtension": "*"
},
"skins": {
"FakeSkin": "*"
}
}
This would add a minimum requirement on MediaWiki 1.25.0+ (already
implemented), as well as the requirement that the FakeExtension extension
needs to be installed, as well as the FakeSkin skin. A wildcard (*) is
used instead of an explicit version requirement as many extensions do
not actually version themselves, and there is no consistent versioning
scheme yet.
Bug: T117277
Change-Id: If1cccee1a16a867a71bb0285691c400443d8a30a
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
