We've discovered some new requirements.
Follow-up to 31f614f732.
The hook was not in a release yet, so we can rename it.
Bug: T371530
Change-Id: I82d8ae69c27a38c45eab5d19c063f0b9515b8ec8
Move deduplication of language links out of Parser.php and into the
ParserOutput in order to be compatible with alternate Parsers (Parsoid).
Clean up various inconsistencies: ensure deduplication also happens in
OutputPage when multiple ParserOutputs are merged into the final output,
and ensure that the deduplication in LinksUpdate is done in the same
order (first link prevails) as in Parser/ParserOutput/OutputPage.
Deprecate OutputPage::setLanguageLinks() (the matching
ParserOutput::setLanguageLinks() was deprecated in 1.42).
As a breaking change, return an array, not an array *reference*, from
ParserOutput::getLanguageLinks(). This allows us to safely modify the
internal representation of language links. As far as I can tell, no one
used the returned reference to sneakily modify the list of language
links, and there not a good way to have deprecated this before making
the breaking change.
While we're at it, we've added tests to ensure that language link
fragments are preserved.
Bug: T26502
Bug: T358950
Bug: T375005
Change-Id: I82a05a51d94782ebb9fa87ff889ca0f633b3e15c
Replaces 'copyright' with 'copyright-footer' and 'history_copyright'
with 'copyright-footer-history' (the original still takes precedence
if set). Adds SkinCopyrightFooterMessage hook which works the same
way as SkinCopyrightFooter for the new messages. Allows disabling
the old messages by setting $wgAllowRawHtmlCopyrightMessages = false.
Co-Authored-By: Gergő Tisza <tgr.huwiki@gmail.com>
Bug: T45646
Change-Id: I5fd5607f8d43b6e934c8d4d35097cec430c56043
Why:
* A hook is needed which is called when User::spreadAnyEditBlock
is called, so that extensions which provide alternative blocking
mechanisims (such as the GlobalBlocking extension) can spread
their blocks when local blocks are spread.
What:
* Add SpreadAnyEditBlockHook which is called from User
::spreadAnyEditBlock when it is called except when the user is
not registered.
** The hook is called even if the user is not locally blocked
* The return value of User::spreadAnyEditBlock is modified to
return true if either a local block or alternative blocking
mechanism spread blocks.
* Update UserTest to test this new behaviour.
Bug: T374857
Change-Id: Id302a6362d6177c89da9cdf4e677b3822ecb85f1
Move the checks for the existence of the user and the presence of
their email address before the 'SpecialPasswordResetOnSubmit' hook,
instead of after. This allows extensions to make their own decisions
about whether a user exists or has email.
This also means that extensions must now check the 'requireemail'
preference when only the username is provided. They already had to
check it when only the email was provided, so this seems more like a
bug fix. To allow them to check this logic, if both the username and
email were provided by the user, provide both of them to the hook.
Bug: T151012
Change-Id: I6baf2c5194f981803198729f59e1e83d5644383a
Improve maintainability of update-keys.sql by moving the list from an
SQL file to a PHP array in the same file as the updates it is disabling.
It was apparently an SQL file for the convenience of third parties
wishing to install MediaWiki by manually sourcing tables.sql. Support
this use case by adding an option to update.php which inserts the update
keys. Users should source tables-generated.sql and then run
update.php --initial
The array is the same for each DB type, but it's correct for it to have
the same scope as getCoreUpdateList(). Factoring out common parts of
getCoreUpdateList() and this new array is a separate project.
Bug: T167924
Change-Id: I404ee29aadcc2f3f24f78d1111090395129cd021
Depending on configuration, this returns either the interface language
code of the current user or the current page language.
Bug: T4085
Change-Id: Iab7fda272ec81af88c74612727ff6bed014d4a81
Session providers can provide a `canAlwaysAutocreate` flag which
indicates account creation is exempt from autocreate permission
checks. This is used, for example, for providers that provide
users for supporting applications in a wiki farm.
Pass that information along to pre-authentication providers so
they can respect the intent of the flag. We cannot simply skip
pre-authentication, it's used for non-permission-related things
like preventing CentralAuth username conflicts.
Bug: T373778
Change-Id: Ie3aeaf48e615e2fb85b2069203ab91ca0127ae05
It didn't have any use outside the core so went for the removal
instead of raising warning and hard deprecation.
Change-Id: I08dab348a89f1fe1adccfad4f003d9fb8b233f0d
wfGetServerUrl is deprecated since 1.39, let's remove the
only use and turn it into a hard deprecation.
Change-Id: I82be851fe411cd002c9c5847fe3924a6c0a4ba50
The hook OutputPageMakeCategoryLinks was only used by extension
CategoryTree:
https://codesearch.wmcloud.org/search/?q=OutputPageMakeCategoryLinks
CategoryTree switched to the new hook OutputPageRenderCategoryLink.
Depends-On: Ic86f210474cbc0e2dcebf664cf2309a4a4408f60
Change-Id: I8ea56f2d111aeccee158c40b8379383e92154d8a
WinCache is an APCu equivalent for use with Microsoft IIS, but in recent
years has been unmaintained and lacks support for PHP 8 and newer.[1]
So, remove support for it as MediaWiki will be raising the minimum
supported PHP version to 8.1.
[1] https://www.php.net/manual/en/install.windows.recommended.php
Bug: T365691
Change-Id: I4d2dc01a9119bb1f858132f0146b894750c1e86d
This allows to change the category link rendering by extension
CategoryTree without missing update of mCategoryData and mCategories
which leads to wgCategories = [] (T372155).
The new hook will be used in extension CategoryTree by
Ic86f210474cbc0e2dcebf664cf2309a4a4408f60.
Bug: T372155
Change-Id: Id82a77a57d1f12233d974ea4c1b093f50c5ab74f
wfUrlProtocols is deprecated since 1.39, let's remove the uses and turn it
into a hard deprecation.
Change-Id: Ic5f827f6e4563bab1b28f090da8f8613b124fcc5
For decades MediaWiki has allowed "extra" px modifiers in image size
specifications, for example `100pxpx`. It has been suggested since at least
2008 (T15500#174968) that this behavior should be deprecated. This is
not localized, so (for example) on eowiki we allow `100rapx` as well (!).
As one small step toward eventually removing this weird corner case behavior
add a tracking category whenever it is used on wiki.
In the process, emit deprecation warnings for
ImageGalleryBase::setWidths() or ::setHeights() if called without
ImageGalleryBase::setParser() having been set. The ::setParser() method
already includes in its documentation that "If you do not set this and
the output of this gallery ends up in parser cache, the javascript will
break!", so please set the parser appropriately.
Bug: T15436
Bug: T15500
Bug: T372935
Change-Id: If86d949189a7d105595404d21447477499873b03
Some wikis treat the category list from ParserOutput as a /set/, others
as an /ordered list/. For those who don't care about the order of
categories, provide the option for wikis to sort the categories
in OutputPage.
This can also be activated with a query parameter, `&sortcat=1`, which
is useful to the Parsoid team when doing visual diff testing to avoid
false positives caused by differences in category ordering.
Bug: T373480
Change-Id: Idd14650a1898c6a49c88441ef024ce3012903bbe
Update a few tests that relied on the feature flag to ignore
the 'requireemail' preference on "User1" to instead use "User2",
who doesn't have the preference set.
Bug: T242406
Change-Id: I996d3996272d704a071d1d2094c3568247b80f98
This method has a weird behavior where it resets the category *link* list
while not resetting the category *list*. It turns out that no one actually
needs that weird behavior; in fact no one needs this method at all, since
the only external user is the Translate extension, which could use the
OutputPage::addCategoryLinks() method instead, which has existed since
2014 (Id25041a7891f588ffa787fdd2c092342eecd30c8).
Deprecate this method with warnings.
Bug: T373480
Depends-On: Id25041a7891f588ffa787fdd2c092342eecd30c8
Change-Id: I7b07d761eb8cd5ad1e6da2dd836e969a0d492c2b
Add a new hook that can be used to prevent authentication just
before AuthManager takes the main action (writing the session
for login, creating the local user account for account creation).
The driving use case is a wiki which supports both a local and
a central (wiki-farm-level) login or signup flow - various
security options (such as 2FA) are needed during local login
but unnecessary during central login (which will have those
security features centrally), so we need to skip much of the
security when the user is taking the central route, and a bug
in how that's done could result in circumvention of security
features during local login. The hook makes it easy to inspect
and potentially interrupt login near the end, when we know for
sure what route it took. (Specifically, we know which primary
provider was used. The hook doesn't expose other details,
such as the list of preauth or secondary provders that were
invoked, because they were not needed for the immediate use
case, but they are easy to add in the future.)
The hook is called after the secondary providers for login
and before them for account creation, since secondaries can
interrupt login but cannot interrupt account creation.
A shortcoming is that since the hook is called after a primary
provider succeeded, it cannot prevent the primary provider from
doing work, ie. it cannot prevent creation of the remote account
during account creation (although it will prevent the creation
of the local account). This is not great but acceptable, since
creating a new account isn't very security-sensitive.
This also means the hook would not be useful during account
linking, as AuthManager does not do anything there, all the work
happens in the primary provider. This is even less great but
few authentication extensions implement account linking.
The hook is not called for authentication happening via
CreatedAccountAuthenticationRequest, which is a weird internal
hack hook handlers should not have to know about.
Also rename a confusingly named variable.
Change-Id: I835b2fe2f43e6e81f23348165cbb9c93832e6583
Allow disabling authentication providers. This allows for
extensions to replace core providers with their own.
This is using the $wgAuthManagerAutoConfig keys instead of
AuthenticationProvider::getUniqueId() as the keys to filter.
This makes it more useful for site administrators, and also
it's probably the better known of the two identifiers so
more intuitive.
No effort is made to prevent the hook from filtering
differently in different steps of the same authentication
process.
Bug: T369180
Change-Id: If5435b54a4fc08f685c04fc10eb44c6d72cd78fa
First export in commit 5c6b75659f
(Change-Id Ied5002d2ca82a05d69e55442561f254f610e0d5c ).
Language codes nan, nan-hani, nan-latn will be used for language
converter codes.
Bug: T354937
Bug: T369899
Change-Id: If68512a24cac67daa033a634b1fb57d872d0039c
Introduced in 2013 by I939551bd228 (fdef79d9f2), and originally used
for PostgreSqlLockManager. This was removed again in Ia8f802b2c68
(2fa8eb2c80).
Change-Id: I7ae15703f919c9ff890056648aad8e86bccf34ab
Follow-up to 298ec8382b, which replaced
`public $errors` with `public $status`, causing T372181.
* Add a deprecated fallback getter/setter for $errors
* Make $permission private and add a deprecated getter/setter
* Make $status private
Bug: T372181
Change-Id: If44b2256289d6bde9e9abb901d9dc145555c971f
It is difficult to distinguish this method from OutputPage::addJsConfigVars()
in code search:
https://codesearch.wmcloud.org/search/?q=%5BOo%5Dut%28put%29%3F%28%5C%28%5C%29%29%3F-%3EaddJsConfigVars%5C%28
We generally try to replace $output with $parserOutput or $pOutput
as we touch code, to improve the ability of codesearch to dig up
deprecated ParserOutput methods.
A future project will unify those parts of OutputPage which duplicate
ParserOutput: T301020.
Bug: T300307
Bug: T305161
Depends-On: I39ae7d7a40190eedaa024097a6442cd02b6a02e7
Depends-On: I2c660972b289bbad730ceee1325d70d5ba75d27e
Change-Id: I53c28ee7c80b889c893c1d00f37678e716e55783
This new key name should better signal to developers that this key
will be used as-is without escaping
Bug: T356971
Change-Id: I98849b2e45cc4555eca7674875b9bed89f128310
== Motivation ==
* Reduce amount of configuration switches relating to MW Stats component,
to reduce noise for MW sysadmins and devs.
* Reduce amount of code in the legacy Statsd implementation.
== Background ==
* commit e56f7b6c63 (2015, MW 1.26): Add statsd sampling.
Refers to T106457 under T106450 ("hook usage counts"), which used it
in https://gerrit.wikimedia.org/r/226640 which was reverted shortly
after in https://gerrit.wikimedia.org/r/233045 due to too high
overhead of stats code for something as hot as hooks, regardless
of actual sampling/stats sending.
* commit b203ec5fcd (2016, MW 1.29): Make statsd sampling configurable.
Use case unknown, but it is not used today in wmf-config, and
appears to have never been set in the past either:
```
operations-mediawiki-config (master)
$ git log -p wmf-config/ | grep wgStatsdSamplingRates
24s ec=1$
```
Looking for unmerged patches, I do find an abandoned patch for
the Wikibase extension that attempted to use to instrument database
load in 2020. It was abandoned in favour of dedicated DB tooling
to inspect database queries, which offer more detail as well.
https://gerrit.wikimedia.org/r/q/message:wgStatsdSamplingRateshttps://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/593335
== Future ==
In 10 years, we've not needed sampling anywhere even at our scale.
StatsD absorbs high traffic very well, with controlled flushing to
Graphite as backend. Prometheus exporters are similarly buffered
close to the producer with controlled scraping intervals. This
should make sampling unlikely to be needed.
We did have one experiment where sampling was attempted, which led
to the developments this commit removes. That instrumentation was
removed because the code was far too frequently called and hot that
it posed a latency problem, even before we factor in whether it
sends the metric. The overhead of the stats code itself added too
much overhead to Hook::run / HookContainer.
The new StatsFactory service class does feature per-metric sampling,
although this is similarly without use case at the moment:
https://codesearch.wmcloud.org/search/?q=%3EsetSampleRate&excludeFiles=test
New instrumentations should use StatsFactory, and if sampling were
needed in the future, it could be experimented by calling setSampleRate
on Metric objects (as part of the instrumentation, rather than in
site config, unless the feature in question makes it configurable).
That seems enough upfront investment for a theoretical future need.
Change-Id: I5f68e48d6d2c880a43f83915234d3c9f32a2d1ef
This reverts commit 36d5b83b31.
Reason for revert: This was merged without a breaking change announcement under the assumption that nothing was checking this flag, but unfortunately it turns out this assumption was incorrect. Let’s restore the flag for now, and potentially remove it again later once the removal has been announced and mwclient has been updated.
Bug: T115414
Bug: T294397
Bug: T371977
Change-Id: I70128ab30210213141cbd413e2e51f741c0c5a22
Since 106155e0a4, hooks are now run
run from ContributionsPager instead of DeletedContribsPager, so
update the release notes to descibe these changes.
Bug: T370438
Change-Id: I54e24fddc4577c997775012dc7733f9c0d548e63
Why:
* Special:DeletedContributions is built entirely separately
from Special:Contributions and lacks many of the features
that Special:Contributions has, such as search form filters.
* As part of the temporary accounts project, a special page
showing deleted contributions for temporary accounts was
added via the CheckUser extension (T363362), which has
feature parity with Special:Contributions. This was achieved
by factoring out abstract base classes for contributions
pages.
* SpecialDeletedContributions should be updated to make use of
this shared functionality, to avoid confusion for users
switching between these various pages.
What:
* Update SpecialDeletedContributions to extend
ContributionsSpecialPage.
* Update ContributionsSpecialPage::getUserLinks to be a
protected instance method instead of a public static method.
This can just be done, since it was only made public to be
called from SpecialDeletedContributions, and there are no
other callers.
* Build a link to Special:Contributions instead of
Special:DeletedContributions from SpecialDeletedContributions
by overriding ::getUserLinks.
Bug: T370438
Change-Id: Ica817be5c5e078b88c9b3157b54d0dbf997e8893
These were soft deprecated in 1.38, it's time to emit deprecation warnings
so we can complete their removal from the public API.
Change-Id: I437ab7dc8af4eb5d336e8074a42a0a54b4c00a4b
This hook is no longer used anywhere. It was deprecated in
ded922c21d and all of its users have
migrated to the new MessageCacheFetchOverrides hook.
Bug: T328183
Change-Id: I5f08849b57a33f0853e176a7452b6b3e6d601add
Remove the 'writeapi' field from the response of the query+siteinfo
API module. It had no purpose since MediaWiki 1.32 when
$wgEnableWriteAPI was removed.
Follows up I54ff9428b247ba203d67aba079149393f323d5a9.
Bug: T115414
Bug: T294397
Change-Id: Icedba7f9c7ff58a5ac690cf25e449ba9e2337bd9
Make QueryPage::getQueryInfo abstract as this was the replacement and
every subclass already implements the function
Bug: T244138
Change-Id: I3aca311674e9bf2fa2c5ae7ea10a78b578346fca
Now that PermissionManager can produce a PermissionStatus (1fbe8b761),
we need a way to display it without going through legacy error arrays.
Test plan:
* While logged out, access a page that all logged in users can access,
that uses the PermissionsError class (e.g. Special:Upload)
* While not an administrator, access a page that only administrators
can access, that uses the PermissionsError class (e.g. Special:Block)
Verify that you see the same error messages before and after this
change.
Change-Id: If21200ea1dd66f6443b03625d6a5b8ea416b2922
In change I625a48a6ecd3fad5c2ed76b23343a0fef91e1b83 I am planning to
make Wikimedia\Message\MessageValue use it, and we try to pretend that
it is a library separate from MediaWiki, so it makes sense to move
MessageSpecifier to the same namespace under Wikimedia\.
Bug: T353458
Change-Id: I9ff4ff7beb098b60c92f564591937c7d789c6684
This contains a minor bugfix to the ALLOW_OBJECT hint.
Depends-On: Ied49bd4e03d4ae816dc9ddd6791d92355be6304e
Change-Id: Ibcedd6c0c9809ccae04bfcb7c5892466b48b56ce