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 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
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
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 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
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
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
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 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
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 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
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 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
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
Deprecated since 1.30, only had one caller (MobileFrontend)
which has been fixed since.
Bug: T140804
Change-Id: I39b594e3082ebe321bae463780cfadbfb3de1d5c
This makes it possible for extensions to add to the WHERE clause
with which unknown preferences are deleted.
Bug: T188966
Change-Id: Ifb22ca42207956f2b07333da026ff0b215a83930
* 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
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
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
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
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
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
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
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
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
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
This was added in I56b6600 in an attempt to work around a bug in
CentralAuth, but the bug has since been fixed in a better way. No hook
functions in Gerrit use the parameter (or ever have, as far as I can
tell), and anything that was passing a value other than the default
'login' has since been removed. So let's just get rid of it instead of
keeping it around doing nothing.
Change-Id: Ie604e03d268706221161ac93eb866f477e466fb4
Added for use in the CategoryTree extension to show the category count
on the special page, see If3815586c2a280b4e8958c13010c9f7436b8723d
Change-Id: If195fb55dee1350a6de095892ce89e6565287cd9
Also updated on mw.org.
This array never has language keys (at least not
unless other extensions add them) but core will
always just have numerical keys.
Change-Id: Ie9c42ac2b4ff143e36d07642f57cca769e8c00e7
The hook was removed in Ia8e17008cb9d9b62ce5645e15a41a3b402f4026a
The mentioned file in the documenation was renamed:
parserTest.inc -> ParserTest.php -> ParserTestRunner.php
Change-Id: I8fcf8302b84254d1dc5a3b629f425616bd1f5d13
The hook was readded with Iad2646acde79b8a59710bb9fd5fbbfea5a39c341
The text is from I2783c46c6d80f828f9ecf5e71fc8f35910454582
Change-Id: I5e26e0c9bef06e0a6213fd219bda58a61da80665
The main interface already has javascript enhancement to use
the API and mw.notify. This patch affects permalinks without
tokens, and opening the link without javascript.
This will match the current behaviour of action=watch.
Bug: T130946
Change-Id: I6be2c07824c17b165e068fc4ac36ab192e12bc9d
In order for an extension to add data to ApiQueryWatchlist, we need to
provide a way to allow it to manipulate the database query made by
WatchedItemQueryService. We also need some hooks in ApiQueryWatchlist to
handle the marshalling of data to and from WatchedItemQueryService.
To better handle hooking, this also moves some of the continuation logic
from ApiQueryWatchlist to WatchedItemQueryService.
Bug: T147939
Change-Id: Ie45376980f92da964a579887b28175c00fd8f57e
This allows extension to consistently use their WikiPage subclasses.
Currently the only way a subclass would be used is if Article::newPage()
was called.
Change-Id: I74cce5f9627c4bc4b92502aff74beb2daeb78d17
This will allow extensions to inject into the query to implement
"xxshow" parameters, and to add additional properties to the output
data for "xxprop" parameters.
Also, call these new hooks from ApiQueryRevisions, ApiQueryAllRevisions,
ApiQueryUserContributions, and ApiQueryRecentChanges since I701e8e19 is
going to be wanting them.
Bug: T143614
Bug: T143616
Change-Id: Id6b42c7f2eb53a6f659d0d61383287f41d96ca00
This creates a hook triggered when updating change tags, so that
extensions can take actions when tags are updated.
When tagging accompanies the action, the recent change is passed
while when tagging is subsequent to the action, the user who
performs the tagging is passed.
Bug: T118698
Change-Id: Ifb0cdc43252c4185e4f216d23b8a21fb31595a37
