Special:RestSandbox presents a Swagger-UI interface for exploring REST APIs. The available APIs can be configured using RestSandboxSpecs.
For now, the default is to support no APIs, so the feature is disabled in production. In the future, it would make sense to expose the wiki's own REST API per default. The corresponding entry in $wgRestSandboxSpecs in LocalSettings.php would look like this:
'mw' => [
'url' => $wgScriptPath . '/rest.php/',
'name' => 'MediaWiki REST API',
]
Note that the spec URL may still change.
To also explore the endpoints exposed through RESTbase, we might add:
'wmf-restbase' => [
'url' => $wgServer . '/api/rest_v1/',
'name' => 'Wikimedia RESTbase API',
]
Similarly, we could expose a spec for endpoints on api.wikimedia.org, which could then be explored using the new special page.
NOTE: This adds a dependency on the swagger-ui npm library. See T325558 for the security review.
Bug: T362006
Change-Id: I1dd5ed82680a28f9c15136b446a2de0398525061
Legacy parser can now output headings using a more accessible markup,
which is also identical to the markup used by the Parsoid parser.
Changes to client-side JS and CSS necessary to support the new markup
have already been merged in earlier commits.
includes/skins/Skin.php
includes/ServiceWiring.php
* Define a new skin option, 'supportsMwHeading', which can be used
to toggle the new markup per-skin.
* Update the built-in fallback skin to enable it. This affects the
output in parser tests.
docs/config-schema.yaml
includes/config-schema.php
includes/config-vars.php
includes/MainConfigNames.php
includes/MainConfigSchema.php
* Add a new configuration setting, 'ParserEnableLegacyHeadingDOM',
which can be used to toggle the new markup per-site.
includes/OutputTransform/Stages/HandleSectionLinks.php
* Output new heading HTML for skins that enabled the option.
tests/*
* Duplicate parser tests that cover heading generation to cover both
new and old markup. Update other parser tests to use new markup.
* Add some unit and integration tests for the behavior of the skin
option and some parser tests for edge cases of the new markup.
Bug: T13555
Change-Id: I1180169a8e83af834c2984ba16089e6277f2a8dd
openssl provides the proper password hashing algorithm, so it is needed
in order to have safe and efficent password hashing.
Change-Id: I61498275c7f7cf19787f0aee50dc4884c57b82b2
Why:
- We don't want to allow unlimited acquisition of temp account names.
These should be rate limited in similar way to how we limit the
creation of temp accounts
What:
- Provide a TempAccountNameAcquisitionThrottle, and use it in the
acquireName() method
- Set a default that is 10 times the limit of
TempAccountNameCreationThrottle
Depends-On: If660aad1d0f04f366414084aff3f88484a19d416
Bug: T343101
Change-Id: I99d5973498a89ac227847de5837c0a8e895c28fb
With this change, when async uploads are enabled, upload-by-url
will spawn a job and a form with a button to check the status of the
process is shown to the user.
In the process, add processing of warnings in the remote jobs spawned by
the API or the Special page. This is done by adding checks to
UploadJobTrait::verifyUpload. In order to manage warnings serialized in
the job status, a method to unserialize the result of
UploadBase::makeWarningsSerializable.
Things that we might want to fix:
* The form's UI is abysmal, we should probably use Codex
* While it's not a huge deal, I'd like to figure out why I need to
purge the page cache if I want the file to show up. And more
interestingly, why this doesn't happen when uploading via the API
Bug: T295007
Bug: T118887
Change-Id: I49181d93901f064815808380285fc4abae755341
Described as "Evil hack for mobile :(", this config variable had been
overridden in the MobileFrontend extension for some time, but this has
been removed last year in Icb1711a0cef828dda0d99b8a7c7963bc409816c9.
Since it was introduced, most HTMLForms using the 'table' format have
been reworked to use 'ooui' (or 'codex', these days), so the hack is
no longer needed.
We recently removed $wgUseMediaWikiUIEverywhere for similar reasons
in aa7eeeeef9 / be135c0fc0.
Change-Id: Id507c0dc5a1c1cfb9737073bae97b14badc30a54
Add a temporary feature flag that is going to be covering the work
around implementing a logout confirmation.
Bug: T357484
Change-Id: I3ee8f52976cb956e24f32115c02903c5c4f358c3
Why:
- The pathway to creating a regular account is different from that of a
temporary account. It makes sense to rate limiting creation of these
two types of accounts at different rates.
What:
- Add a TempAccountCreationThrottle config with a restrictive default
that matches the existing production configuration of
AccountCreationThrottle (6 creations per day)
- Update resetAuthenticationThrottle.php to support resetting the temp
account creation throttle
- For now, not adding an equivalent hook for account creation throttle's
ExemptFromAccountCreationThrottle
Bug: T357777
Change-Id: Ibf36ac96f717107bace6f0a3326f79ed129a1dfe
The TranslationAliasesDirs configuration allows defining translatable
aliases in JSON files. The value should be a name or names of folders
that contains files that have localized aliases. Each language should
have a separate file.
Currently, it supports defining special page aliases but in the
future can be extended to support magic words and namespace aliases.
The patch adds a script: ConvertExtensionsMessagesToTranslationAlias
that can be used to convert existing ExtensionMessagesFiles to the new
format.
Bug: T89947
Change-Id: Ief16a48a8dc8742854f67301791aa2a0b0531116
Introduce a temporary feature flag that will be used to display
Special:Block UI in Codex.
Bug: T358153
Change-Id: I74bc90af986ac2f429a952a19b6edf4fb02c5618
After the deployment of the updated mediawiki.cookie module, the
configuration variable can be safely removed.
Bug: T344791
Change-Id: Idf3b3ef521ef2ac368c3f575f99bf4c6da7baa82
Not to be confused with $wgOpenSearchTemplates (plural)
Soft-deprecated since 1.25 and hard-deprecated since at least
I9776d11d4e2d184 (1.39).
Not set in production.
Change-Id: I6a95b9e0e2b74bb44d51c375a62886761ec9ea88
MediaWiki UI has never really made it out of beta before being
deprecated. Legacy code using plain HTML forms doesn't need it;
new code can be written using Codex.
Bug: T182050
Change-Id: Ib9966bc6a4a94f771cb99a5aa52fb6a1dc826ca5
Soft-deprecated since 1.26 and hard-deprecated since at least
I9776d11d4e2d184 (1.39).
Not set in production.
Change-Id: I55e4569c5a40f77a719bc7ab1924eaa706e0da53
Soft-deprecated since 1.35 and hard-deprecated since at least
I9776d11d4e2d184 (1.39).
Not set in production.
Change-Id: I68b68ffcdff22daafad34c186d1cc609dcecbf32
Soft-deprecated since 1.33 and hard-deprecated since at least
I9776d11d4e2d184 (1.39). It's already noop in the code.
Not set in production.
Change-Id: I5895bc4dae9620d53c37188662e21bf01ae7bd85
Soft-deprecated since 1.37 and hard-deprecated since at least
I9776d11d4e2d184 (1.39)
Not set in production.
Change-Id: I0b25e89d1652dfa697ab1176a1e2b6ca3163bdab
It has been deprecated since 1.35, hard deprecated since at least I9776d11d4e2d184
No grep result in wmf-config
Change-Id: I2c67bab3e3212f25a0cbce7301f5e32a082f76da
INSERT IGNORE when inserting NULL into a non-nullable field will succeed
with a warning on MySQL but fail on PostgreSQL. In any case, it's
probably harmful and unintended. But to check the error code of MySQL
warnings, you need to query the server with SHOW WARNINGS, so there is a
performance cost.
So, add a configuration variable which, when enabled, checks warnings
after INSERT to see if there were any null type constraint errors. Set
it to true in DevelopmentSettings.php and TestSetup.php.
Change-Id: I5e47e2d3cc7e0f804036e11b512b1e3b76804432
Why:
Sometimes, it is necessary to have different behavior
for newly registered and existing users. For example,
this happens in the Echo or GrowthExperiments extensions.
As of now, this behavior is implemented by inserting
user_properties rows in onLocalUserCreated.
Over time, this results in a singificant amount of rows
inserted, which contributes to the user_properties table bloat,
which is already overly large (cf. T54777). This patch makes it
possible to remove such rows by supporting conditional defaults
for user properties.
What:
Add support for conditional defaults of user properties. This can be
configured via `ConditionalUserOptions` config option.
Bug: T321527
Change-Id: I1549c3137e66801c85e03e46427e27da333d68e2
Following up Id9539a28f0f143539334002c3:
* Don't run the script twice.
* Wrap the decoded dump in an array with key "data".
* The default assignment for DJVU_DUMP and DJVU_TXT had the effect of
running the scripts anyway if the configuration variables are null.
Don't do that.
* If both $wgDjvuDump and $wgDjvuTxt are null, don't run the shellbox
script.
* Centralise shell location configuration.
* Factor out call to convertDumpToJSON().
* Instead of txt_exit_code, just use existence of the file to
communicate success. This avoids a deprecation warning if
txt_exit_code was not received, due to passing null to trim.
* Check for the existence of the result files instead of just trying to
use them.
* Check the exit status of the overall script.
* Confirm that the BoxedCommand branch is functional and works in CLI
mode by using it in DjvuTest.
* Change the service name from "media" to "djvu". Existing examples are
"pagedtiffhandler" and "pdfhandler", i.e. named after the extension,
there is no other core caller. I think it should be more fine-grained
than "media". The name was possibly a conflation with the
ProductionServices array key.
Also:
* Check the exit status of djvudump and don't use the output file if it
is non-zero.
* Check the return value of convertDumpToJSON().
* Don't use isset() unless error suppression is intended.
Bug: T352515
Change-Id: If41a2baada2e4e2462518c1f437af458feb29632
This change was first introduced in Ic4e3dff and then reverted because
of a regression on CLI. So for now forward-port the code from that patch
and put it under a feature flag we can remove once we've debugged
the current issue.
Bug: T289228
Bug: T352515
Change-Id: Id9539a28f0f143539334002c356026b0d185450b
Pages that are fast to render can be omitted from the parser cache
to preserve disk space and cache write operations.
The threshold is configurable per namespace, so the tradeoff can
be evaluated based on different access patterns. For example, pages
that are accessed rarely, like file description pages on commons,
may have a high threshold configured, while pages that are read
frequently, like wikipedia articles, may be configured to be always
cached, using a 0 threshold.
Filtering is based on a time profile recorded in the ParserOutput.
A generic mechanism for capturing the timing profile is implemented
in the ContentHandler base class. Subclasses may implement a more
rigorous capture mechanism.
Bug: T346765
Change-Id: I38a6f3ef064f98f3ad6a7c60856b0248a94fe9ac
mcrouter-primary-dc was added in 9c14bb5 (I9bc589ec57f4c6), follow
the reverts and reapply too for more context as a way to store tokens
across all servers that run the application, and later purged afterward.
This patch introduces a MediaWiki wrapper service for interfacing
with mcrouter-primary-dc instead of accessing the setting directly
via operations config. This service will be configured by a setting
through $wgMicroStashType.
Testing plan
============
We can begin to directly use this patch as a way to test core rate
limiter via WRStatsFactory. So if that works accurately with this
patch without breaking CI, then that's good news.
In this patch also, MainConfigNames::StatsCacheType setting has been
removed in favor of MicroStashType via a wrapper service. NOTE that
there is already a config patch to take care of the switch and the
former will be removed (on cleanup later).
Bug: T336004
Depends-On: I96f6f7c0240a46e43a785dbd3c0a5a524d4eabc3
Change-Id: I08ebea5e8a601f161fcd678068cecb77f8e15c7c
This config has been set to false in production since 2018 (Ie4ea1dc0d3927).
This doesn't provide much benefit and its impact yet to be proven and
it's blocking removal of ILoadBalancer::getAnyOpenConnection()
That removal makes $dbwSerial unconditionally false which turned the
whole method into a one-liner and since it was used only once,
we just replaced that.
Bug: T325389
Depends-On: I24f33a15d214d49bfb6c6013e7fd64c7d0eb0086
Change-Id: I19043e775fce9f7ddded128cb2c9395b46dd19a3
Add $wgEnableMultiBlocks and $wgBlockTargetMigrationStage vars that will
allow for multi-stage migration.
Bug: T346671
Change-Id: Id356445605870abf279f056490040cb2b5921d7a
In https://phabricator.wikimedia.org/rMW3617c982c9db793515818e1468fa827ae5880358,
the "cookie redirect check" was removed but the setting that controlled
this set was not removed alongside.
Also, double checking that this setting is not configured in production
via our prod configs and always defaults to false is the case today.
Bug: T349791
Change-Id: Ia2a57b57c4c0a9848798f469181738646e0f8dc8
Add a config var named `$wgEditRecoveryExpiry`
(default 2592000s, 30d) instead of hard coding 30d.
Bug: T348593
Change-Id: I67ca48ef9265a102665e0b89b09b0273d3e69a04
This creates a new language code, 'x-xss', which is enabled using the
setting $wgUseXssLanguage (similar to how $wgUsePigLatinVariant enables
the 'en-x-piglatin' language code, and likewise defaults to false; will
be enabled in development settings soon).
In this language code, all messages become “malicious”, trying to run
some alert() JavaScript; if any alert() actually fires in the browser,
the message was not escaped properly. ($wgRawHtmlMessages are exempt,
since they’re already known to be “unsafe” and require more rights to
edit on-wiki.) Messages that are not escaped properly are generally a
minor security issue; they effectively let a user with 'editinterface'
right (such as a sysop, on many wikis) run arbitrary JS, without needing
the 'editsitejs' right (normally restricted to interface admins).
Developers can use this language code to more easily check their code
for escaping issues / cross-site scripting vulnerabilities.
Bug: T340201
Change-Id: Ia9a1cf712b139fea5da72046e37035e6de39d8d5
ParserOutput::addOutputHook() has been deprecated since 1.38, and without
any calls to ::addOutputHook() the associated ::getOutputHooks() and
$wgParserOutputHooks configuration do nothing.
Bug: T292321
Bug: T305161
Change-Id: Ib770c680d5e0697980e7e36a323ec56ba1d806b8
Why:
Temporary accounts introduced as part of IP Masking are supposed
to expire 1 year after their registration. Accounts can have
multiple registration timestamps when in a wiki-farm setup,
depending on which wiki we consult.
To implement the account expiration logic, we need to know the global
(first) registration timestamp.
Similar to CentralIdLookup, a concept of a registration date
provider is introduced. Unlike IDs, users can have multiple
kinds of registration dates (Wikimedia recognizes local and global,
but third parties can have different needs). For that reason,
any number of registration providers can be registered at any
given time; caller determines which one is requested. The default
is `local`, which is the only provider that is guaranteed to exist.
What:
* Add UserRegistrationLookup
* Add UserRegistrationProviders config variable
Bug: T344694
Change-Id: If9fa12a392064dd504590a861a175e3604a34fab
In order to check all existing rate limits through Authority, the limit
keys must function as user rights. However, we do not want them to be
"normal" permissions, since they cannot sensibly be revoked, and they
should not clutter the user interface.
To solve this, we introduce the concept of "implicit rights", which are
always granted, but limitable.
Change-Id: I0ea6f29130da1d68d022d47d9221fe878bc9beae
This setting can be used to optimize externallinks queries for certain
domains that have many entries in the externallinks table, but also big
“gaps” where the table contains no entries for that domain. By putting
those gaps (whose el_id values would usually have been obtained on the
analytics databases) into the configuration, we can have MediaWiki tell
the database to skip those ranges of the table instead of scanning
through them. (This is only relevant for domains that have enough
entries that the database chooses to scan the table in primary key order
rather than using the el_to_domain_index_to_path index and filesorting.)
Bug: T341000
Change-Id: Iec4fe01aaa595fbaf3b427b7baa68a9d7209b117
This moves the core part of wfGetPrivilegedGroups() out of Wikimedia
config and makes it possible to move functionality built on it into
core.
Bug: T208477
Change-Id: I6536ef2909caeed047447e8b6a25831d6f00d827
Building blocks of CP don't really need to depend on LBF. Even the
config value for CP stash type is also different. But it's being passed
around along the rest of LB/LBF config and possibly down to the DB
object.
This is making the code much harder to understand, adds more coupling
than it needs to, and it's making pieces that don't need to rely on LFB
(like load.php) actually depend on LBF just to disable CP.
This clean up also helps improving DI of LB/LBF and building of DB
objects down the road.
Bug: T275713
Change-Id: Ic27269a1f1190ee7a03c6a422ada7ff293c3cab1
