aboutsummaryrefslogtreecommitdiffstats
path: root/includes/MainConfigSchema.php
Commit message (Collapse)AuthorAgeFilesLines
* Merge "Enable $wgAllowAuthenticatedCrossOrigin by default"developmentjenkins-bot2025-02-251-1/+1
|\
| * Enable $wgAllowAuthenticatedCrossOrigin by defaultLucas Werkmeister2025-02-181-1/+1
| | | | | | | | | | Bug: T322944 Change-Id: I6de31143e67e14d14aeaf7df04f1cbe257cf56bb
* | Merge "Declare $wgAllowAuthenticatedCrossOrigin non-experimental"jenkins-bot2025-02-241-4/+0
|\|
| * Declare $wgAllowAuthenticatedCrossOrigin non-experimentalLucas Werkmeister2025-02-181-4/+0
| | | | | | | | | | | | | | | | The feature is enabled and working in Wikimedia production – I think that’s good enough to call it properly supported. Bug: T322944 Change-Id: I8fc310d4ab4fc3e17cbeaadfc8eadb4d2120ebda
* | Merge "Add 'lang=en' to 'Powered by MediaWiki' footer icon"jenkins-bot2025-02-221-0/+1
|\ \
| * | Add 'lang=en' to 'Powered by MediaWiki' footer iconReedy2025-01-111-0/+1
| | | | | | | | | | | | | | | Bug: T383501 Change-Id: I9fb473c0ebbc7b002aff513b0630d18d9cbd68d3
* | | user: Implement batch user registration lookupsMáté Szabó2025-02-191-1/+2
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Why: - The TSP team would like to change the way expired temporary account user links are displayed, which requires an efficient way to fetch their registration timestamps. - On WMF wikis, which use CentralAuth, this requires fetching the first (i.e. global) registration timestamp of the account, rather than the naïve approach of using the registration timestamp from the local user table. - MediaWiki provides the UserRegistrationLookup facade to transparently fetch the earliest registration timestamp for a single user, but offers no batch interface to do the same. - Since user links are often rendered in large pagers, a batch interface is needed. What: - Add IUserRegistrationProvider::fetchRegistrationBatch(), which takes an iterable of UserIdentities and returns a map of their registration timestamps (or null if not available), keyed by user ID. Although this interface is marked as stable to implement, its sole non-core implementor according to codesearch is CentralAuth. - Add UserRegistrationLookup::getFirstRegistrationBatch(), which delegates to fetchRegistrationBatch() on configured registration providers and returns the earliest registration timestamp for each user in the batch. - To avoid potential interface incompatibility in WMF production, this depends on CentralAuth implementing the new IUserRegistrationProvider method first. Bug: T358469 Depends-On: Ibe28163e962161567d486607e36d999a36a1e604 Change-Id: I1f6af2693a8f0c5c854b8a6b04edd1eb21934007
* | block: Add $wgAutoblockExemptionsTaavi Väänänen2025-02-181-0/+6
| | | | | | | | | | | | | | | | | | Add a new option to exempt users from autoblocks in the configuration, instead of editing a MediaWiki space page on every wiki. The use case for this is WMCS ranges (see T386689). Bug: T240542 Change-Id: I704b34b81214e7a1ac819fefa7ad3c2c87305647
* | Merge "Set correct merge strategy for $wgAddGroups and $wgRemoveGroups"jenkins-bot2025-02-141-0/+2
|\ \
| * | Set correct merge strategy for $wgAddGroups and $wgRemoveGroupsDaimona Eaytoy2025-02-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | These are 2D lists, so the default array_merge will overwrite values instead of merging. Bug: T386210 Change-Id: Id001462b17ff43964af4f627ca40f07cb198eab2
* | | logging: Use LinkTarget in LogFormatter::getPreloadTitles overridesUmherirrender2025-02-131-13/+83
|/ / | | | | | | | | | | | | Also avoid null as array item, as that is not allowed according to the return type Change-Id: I4083c55a69d6186448a13f35f18d96bfe9ffd23c
* | RenameUser: Introduce RenameUserJob to run rename jobxtex2025-02-111-2/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RenameUserJob is moved to Job/RenameUserTableJob because there are two kinds of jobs now. The newly added RenameUserDerivedJob is used for performing user-renames across a wiki family using virtual domains or shared tables. Most code are moved from SpecialRenameUser and maintenance/renameUser. The new service, RenameUserFactory is added for constructing RenameUser easier. When a global rename happen, the central wiki will enqueue RenameUserDerivedJobs for other wikis in the same family. The derived jobs will check if the central wiki has the same user table as local, and perform updates to local tables. A new user-right 'renameuser-global' is also added because wiki families may want global users to be renamed only by a limit set of users or on a certain global wiki. Bug: T104830 Change-Id: Ic4120cbd9a4850dfe22d009daa171199fe7c5e39
* | Remove temporary $wgParsoidNewTemplateExpansionMode configurationC. Scott Ananian2025-02-031-16/+0
| | | | | | | | | | | | | | | | | | This was used to test an experimental parsoid feature before deployment, but the testing was successful. Bug: T382464 Follows-Up: I194a9550500bf7ece215791c51d6feb78a80b1a8 Change-Id: Ib91a17868352722dc3570b07856423733f1b2368
* | Allow non-anonymous CORS for some session providersLucas Werkmeister2025-01-311-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a session provider is safe against CSRF (e.g. OAuth), we can allow cross-origin requests to be non-anonymous. This makes it possible to have fully client-side web applications that authenticate users via an OAuth 2.0 client (necessarily a non-confidential client) and then make authorized requests against wikis using the Authorization header. To opt into this new mode of CORS requests, we use a new boolean parameter called "crossorigin". (An earlier version of this change reused the existing "origin=*" parameter for this, but the change to its previous “always anonymous” behavior was not welcomed during code review.) The parameter is disabled by default via a config setting, which is currently declared experimental; if this works out in practice, we’ll presumably want to at least change it to non-experimental, though I don’t know if we want to enable the feature by default (or even unconditionally) or keep the setting as it is. Note that the preflight request doesn’t send the real Authorization header (it just includes its name in Access-Control-Request-Headers), so the session provider in the preflight request is still the normal cookie provider (which is why handleCORS() has to bypass the safeAgainstCsrf() check in that case). This shouldn’t be an issue, because executeActionWithErrorHandling() returns quite early if the request is an OPTIONS request (immediately after handleCORS()), but to be sure that the unsafe session isn’t used during the preflight request, I added a "crossorigin" check to lacksSameOriginSecurity(). (That method is called by the constructor before the param validator has been set up, so $this->getParameter() is not available – hence the call to $request->getCheck() instead, just as for the 'callback' parameter.) Bug: T322944 Change-Id: I41200852ee5d22a36429ffadb049ec3076804c78
* | Introduce ParsoidExperimentalParserFunctionOutput config flagSubramanya Sastry2025-01-301-0/+19
| | | | | | | | | | | | | | | | | | * Plumb this value into Parsoid's SiteConfig so that the Parsoid library code can access this. Bug: T373253 Bug: T385129 Change-Id: If119ff94e65325fc446ca068e0b2d2434c070a2e
* | Merge "Add ParserOutputFlags::{HAS_ASYNC_CONTENT,ASYNC_NOT_READY}"jenkins-bot2025-01-291-0/+13
|\ \
| * | Add ParserOutputFlags::{HAS_ASYNC_CONTENT,ASYNC_NOT_READY}C. Scott Ananian2025-01-291-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows Parsoid to mark parses which contain async content which is "not ready yet". At the moment this output is cached with a reduced TTL, although in the future it might still be treated as uncacheable, cached until evicted, or some other option. The HAS_ASYNC_CONTENT flag along with ParserOutput::hasReducedExpiry() ensures that RefreshLinksJob is opportunistically reinvoked whenever the page is reparsed, since the asynchronous content may change the metadata for the page when it becomes ready. As describe in T373256, ::hasReducedExpiry() is misnamed now, and a follow-up patch will probably rename it to ::hasDynamicContent() or something like that. What it really means is "RefreshLinksJob must be re-run on every parse, because the content may change on each parse". In the past we would *also* reduce the cache time for pages like this. But for asynchronous content, "the content may change on each parse" only *until* the asynchronous content is "ready". Once it is ready the contents will no longer change, and the cache lifetime can be raised again -- but ::hasDynamicContent() still needs to be set, which in the future will mean "you need to check that RefreshLinksJob has last run" not "you must always run RefreshLinksJob". Asynchronous content will always set HAS_ASYNC_CONTENT, even after the content is "ready", but will only set ASYNC_NOT_READY if it needed to use placeholder content in this render. Bug: T373256 Change-Id: I71e10f8a9133c16ebd9120c23c965b9ff20dabd2
* | | Remove Google search fallback for external searchSam Wilson2025-01-291-1/+0
|/ / | | | | | | | | | | | | | | | | Remove the 'googlesearch' and 'search-external' messages, so that there is no fallback search form if $wgDisableTextSearch=true and $wgSearchForwardUrl=false. Bug: T384678 Change-Id: I20a3fe8484424427de5dcc55098a09114fedaf66
* | Change default value of wgParsoidNewTemplateExpansionMode to trueSubramanya Sastry2025-01-271-1/+1
| | | | | | | | | | | | | | * This has to ride the train with Parsoid's changes Bug: T382464 Change-Id: I92a81d41d284a9b272d3f0d6cbdc5b022d051f57
* | Merge "categorylinks: Add support for write both"jenkins-bot2025-01-231-0/+16
|\ \
| * | categorylinks: Add support for write bothAmir Sarabadani2025-01-211-0/+16
| | | | | | | | | | | | | | | Bug: T299951 Change-Id: Ifd9876bcb452e412b7335741e74cfc4c820aa248
* | | Merge "For Parsoid calls, treat preprocessing as starting in SOL state"jenkins-bot2025-01-231-0/+15
|\ \ \
| * | | For Parsoid calls, treat preprocessing as starting in SOL stateSubramanya Sastry2025-01-171-0/+15
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * If Parsoid calls the preprocessor, initialize lineStart to true. Track this through: - parser function calls that return expandable template messages int: parser function is an example in core Extensions seem to define a number of other such parser functions - template-arg substitions So {{templatename|mytemplate}} with text {{{{{1}}}}} which is effectively a call to {{mytemplate}} continues to set sol-state to true across the expansion. See test "Preprocessor precedence 5: tplarg takes precedence over template" in preprocessor.txt which exercises this use case. - However, note that this is a best-faith effort because this flag is set while building the preprocessor DOM tree before templates are expanded. So, this is mostly a source syntax flag and constructs that expand to empty strings can blind the preprocessor to the true value of SOL state in the expanded string. This is true for both the legacy parser and Parsoid, and as such T2529 behavior is a hack with a set of associated edge cases. * Parsoid models templates as independent documents as always starting in start-of-line state (and does some patch up for b/c reasons where this assumption fails). So, there is no reason to add newlines for some set of wikitext characters (per T2529) when Parsoid is involved. * This lets us eliminate some hacks in Parsoid to strip these added newlines when Parsoid was already in SOL state but which then introduces edge cases. See discussion in T382464 where Parsoid currently cannot distinguish between a couple of test cases. * But, with this change, where Parsoid no longer gets a newline added, Parsoid doesn't have to heuristically remove the newline (and incorrectly as in the edge case in the bug report) which eliminates the edge case from the bug report. * This change has to be backed by a change in Parsoid to undo the T2529 newline removal hack in TokenStreamPatcher to ensure Parsoid CI doesn't break with this change. * To let us safely test this in Parsoid's round-trip testing and safely (and conservatively) roll this out to production, this change is backed by a new config flag (ParsoidTemplateExpansionMode) which defaults to false. We unconditionally set this to true in the ParserTestRunner for all parser tests. This flag will be removed once we roll out this change and the Parsoid change to production. Bug: T382464 Change-Id: I194a9550500bf7ece215791c51d6feb78a80b1a8
* / / resourceloader: Minor documentation correctionsBartosz Dziewoński2025-01-201-6/+8
|/ / | | | | | | | | | | | | | | Issues spotted while working on I03a9a6945ab27e9888ea21b03985ed713f0a9b50. Some code style improvements too. Change-Id: I409d0a1805aa7430cc86e53633f4f85ef8a76dcf
* | Remove trivial 1-line PHPDocs that just repeat the codethiemowmde2025-01-161-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | I assume these are all either auto-generated by an IDE or the language-level type declarations have been added later. In any case the comments don't add any new information to what the code already says. This is just extra clutter that makes the code harder to read, I would argue. There are many, many more comments like this. In this patch I intentionally focus on the most trivial 1-line comments. Change-Id: Ia294bf4ce0d8a77036842fe25884bc175c2b0e7d
* | Tag page creations of previously deleted pageKgraessle2025-01-141-0/+2
|/ | | | | | | | adds a new tag in core titled mw-recreated to note when a new page is a recreation Bug: T56145 Co-Authored-by: Rockingpenny4 <rockingpenny4@gmail.com> Change-Id: Ib8ffe3fba73d0464f3fd353138456b07e7afc7d7
* Merge "DnsBlacklistUrls: Remove sorbs.net"jenkins-bot2025-01-061-1/+1
|\
| * DnsBlacklistUrls: Remove sorbs.netReedy2025-01-061-1/+1
| | | | | | | | | | | | | | Service is no longer running, so it's a default that doesn't do anything Bug: T382987 Change-Id: I3a21c12ba689928d38e410cbe2547ab7e616ac8a
* | file: Basic support for writing to the new file tablesAmir Sarabadani2025-01-061-0/+16
|/ | | | | Bug: T368113 Change-Id: I8d98d187ba4f1342167820b5710f5382b2ac4831
* ParsoidFragmentMode: use special 'exttag' strip markerC. Scott Ananian2024-12-161-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When Parsoid is expanding wikitext using the preprocessor using fragment mode, we want extension tags to remain unexpanded so that Parsoid can perform the expansion itself. However, this causes discrepancies in the expansion size limits, since the extension tags would be counted as their full length, whereas before they were only counted as the length of their strip marker. This causes certain large pages to fail to parse in Parsoid with fragment mode on (T380758). We will probably need to more carefully reconcile expansion size accounting between Parsoid and core (T254523, T286355, etc) but for the moment address the discrepancy by adding a new strip marker helps ensure that Parsoid fragment mode leaves Parsoid's template expansion size accounting unchanged. Recursive parses involving extension tags inside parser function expansions may leave strip markers behind which are then stripped (T382287). This is slightly better than the previous behavior, where those extension tags would be left in the HTML unparsed, but should be fixed properly; likely via a native Parsoid parser function API (T373255). Bug: T380758 Bug: T254523 Bug: T382287 Change-Id: I17ab278e04e99e1b011cf5d9bb2f596a242f218e
* Setup: Remove unused $wgBaseDirectory in favour of MW_INSTALL_PATHTimo Tijhof2024-12-141-27/+10
| | | | | | | | | | | | | | | | | | | | In commit I7142af16d6 (cf581bb2ca), $IP was replaced with two things: a constant MW_INSTALL_PATH, and a mutable $wgBaseDirectory. It offered both on the very reasonable assumption that, given $IP is overwritten in several places in tests, it can't be migrated to a constant. Over the years, this turned out not the case: 1. Resources.php, switched to constant in I56c28d36e (e446a71f86). 2. GitInfo, switched to constant in Ib2c89461ed (268c2a5b5a). 3. DatabaseUpdater, switched to constant in I502bdb652e. 4. transformResourcePath(), switched to constant in If3b7942d25. There is no other use left, and afaik it was never adopted anywhere, other than in these 4 places in MediaWiki core as part of the initial $IP deprecation above. As such, remove without deprecation. Change-Id: Ia273414d77743e5c59bded793de6fdc6667fd8b8
* Merge "temp accounts: Break up temporary user names with hyphens"jenkins-bot2024-12-121-2/+4
|\
| * temp accounts: Break up temporary user names with hyphensThalia2024-12-121-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Why: * Temporary user names contain a generated part. The method for generating this part is configurable, and uses different implementations of SerialMapping. * The PlainNumericSerialMapping is used by default, but can be difficut to read if the number that is generated is long. What: * Add ReadableNumericSerialMapping, similar to the plain numeric mapping, but with hyphens after every group of 5 digits, for readability. * Make ReadableNumericSerialMapping the default in the config $wgAutoCreateTempUser['serialMapping']['type']. Bug: T381845 Change-Id: I262f1de38370c9e228f2fe804e95d9d43c49ca86
* | Enable new heading HTML by defaultBartosz Dziewoński2024-12-111-1/+3
|/ | | | | Bug: T371755 Change-Id: Ib5c523723e510621a5a278287856c4a0b0330dc9
* Merge "Merge Interwiki extension into core"jenkins-bot2024-12-051-0/+5
|\
| * Merge Interwiki extension into coreDringsim2024-12-051-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merge Interwiki extension into core, with some changes: * Always register 'interwiki' user right and 'interwiki' log type, and remove $wgInterwikiViewOnly * Remove nonstandard 'intro' and 'body' CSS classes on Special:Interwiki * Make interlanguage special cases be conditional on $wgInterwikiMagic * Other cleanups * Add SpecialInterwikiTest * Add a constant MW_HAS_SPECIAL_INTERWIKI which can be used in config to suppress loading of the extension. After merging Interwiki extension into core we can remove InterwikiLoadPrefix hook, which is incompatible with Parsoid. Bug: T33951 Bug: T270444 Bug: T312425 Bug: T315759 Bug: T357247 Depends-On: I0d02d93f49c746a7ce86b72b456f13c4af9b6c34 Change-Id: I05049e7c2e056928977245367583d027b80ef613
* | Merge "ParserCache: Get rid of the temporary key schema ratio config"jenkins-bot2024-12-051-15/+0
|\ \ | |/ |/|
| * ParserCache: Get rid of the temporary key schema ratio configAmir Sarabadani2024-12-031-15/+0
| | | | | | | | | | | | | | | | Now that production has been gradually migrated, we can simplify and remove the transitional code. Bug: T373037 Change-Id: Ic0a9f0c5df9aba61d0afac767c5aa091aa708db4
* | Merge "http: Update LocalHTTPProxy documentation"jenkins-bot2024-12-041-16/+3
|\ \
| * | http: Update LocalHTTPProxy documentationTim Starling2024-12-041-16/+3
| |/ | | | | | | | | | | | | | | | | | | | | * Update the documentation of LocalVirtualHosts for the fix to the linked bug. * Remove rambling in LocalHTTPProxy -- the effects on ports and cookies are the same as for HTTPProxy. From the client's point of view, it is not a reverse proxy, it's a regular forward proxy. Bug: T381251 Change-Id: I933f7194f10d860928bde642ff26a07c0a245425
* | Merge "Stats: Move StatsFactory flush into emitBufferedStats"jenkins-bot2024-12-031-1/+1
|\ \ | |/ |/|
| * Stats: Move StatsFactory flush into emitBufferedStatsCole White2024-12-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This centralizes the action of emitting stats to a single static function to be used by web and maintenance jobs alike. * Rename emitBufferedStatsdData to emitBufferedStats * Move StatsFactory->flush() call into emitBufferedStats * Update call signature where used Bug: T380609 Change-Id: I63e8832a170bfaa0e14e977f0852c4ef49f232bb
* | Show user a human readable message when $wgLocaltimezone is set to an ↵Aditya Kumar2024-11-271-1/+14
|/ | | | | | | invalid timezone Bug: T380423 Change-Id: Ie2001796442ee6ba973fdb4b7b1dc7312f802e8d
* installer: Make installer initial content be configurableTim Starling2024-11-191-0/+27
| | | | | | | | | | | | | | With the new installPreConfigured.php, it's possible to customise the installer using configuration. Add a configuration variable allowing the user to customise the initial page content. Add {{InstallerOption:}} and {{InstallerConfig:}} fake parser functions, for feature parity with addWiki.php. Production needs a message like "This subdomain is reserved for the creation of a $site in $lang". These variables can be provided to InitialContentTask as installer options. Bug: T352113 Change-Id: I6f72505cd6d5cb31b4d0105aeea31e1e2f1997de
* Parsoid DataAccess: support strip state in parser function resultsC. Scott Ananian2024-11-181-0/+12
| | | | | | | | | | | | | | | | | | | | When a parser function returns raw HTML in the strip state, this patch ensures it will be properly tunnelled through Parsoid as part of Parsoid's PFragment type. The Parser::OT_PREPROCESS mode claims that it processes "templates but not extension tags" but in fact it does process extension tags and turns them into general strip state items. Add a new parameter to Parser::replaceVariables() which leaves extension tags untouched (so that they can later be expanded by Parsoid). Bug: T279094 Bug: T257606 Bug: T374661 Depends-On: I0d8e85b01435f37b8bccab3431c9807d46989ae6 Depends-On: Ia201767111872158149ad805f415fe1fbe9fa70e Depends-On: I14f81b478ab7bfea98f825d619c492adce4f7a30 Change-Id: I52ed681d06c133574b57c97b0f5040199468597b
* ParserCache: Allow for gradual roll out of the new key schemeAmir Sarabadani2024-11-111-0/+15
| | | | | | | | | | | | | This makes sure all entries for the same page end up in the same database table in the same cluster so depool/crash of a parsercache host wouldn't have out of proportion effects on the cache overall. But if we just change the key scheme, every key will be displaced and everything will go down. So we need to introduce a temporary config variable to gradually roll out the change. Bug: T373037 Change-Id: Iae9b8dd5dd65c6d7c8d3b6f786a110d72f0b959e
* Remove CryptHKDF and MWCryptHKDFKevin Israel2024-11-111-26/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MWCryptHKDF was added ten years ago (in af66c04d39ad96a0), and as far as I can tell, it was never used anywhere. It seems unlikely that CryptHKDF will be used in the future, at least in its current form, for several reasons: * PHP 7.1.2+ has hash_hkdf(), so HKDF() would not be needed. * At the time MWCryptHKDF was created, access to a CSPRNG was dependent on server configuration: operating system, enabled PHP extensions, open_basedir, etc. The "clock drift" RNG used as a last resort was not considered to be secure or fast enough for generating large amounts of output.[1] random_bytes(), added in PHP 7, changed the situation. * Depleting the input pool of Linux's RNG is no longer a concern; there is no more blocking output pool for /dev/random.[2][3] In 2022, this change and others, including some that improved performance,[4] were backported to stable kernels as old as 4.9.[5] * $wgAuthenticationTokenVersion obviated the primary use case of quickly resetting the user_token field for all users, assuming all the existing tokens are unique. * CryptHKDF seems to perform much slower than random_bytes(), at least on Linux, making it pointless to use given that the other reasons for its existence no longer apply. [1]: https://bots.wmflabs.org/logs/%23mediawiki-core/20161004.txt [2]: https://lwn.net/Articles/808575/ [3]: https://lore.kernel.org/all/cover.1577088521.git.luto@kernel.org/ [4]: https://www.zx2c4.com/projects/linux-rng-5.17-5.18/ [5]: https://lore.kernel.org/all/Yo3pmh9hiUFtQz77@zx2c4.com/T/ Change-Id: I29136fad826341d21728671aa30285d5551f1162
* recentchanges: Make CategoryMembershipChange constructor args requiredMáté Szabó2024-11-011-1/+1
| | | | | | | | | | | | | | | | | | Why: - The `revision` and `forImport` constructor parameters of CategoryMembershipChange are marked as optional, but the only non-test usage of this constructor provides them both.[1] What: - Make both parameters required and remove tests related to instantiating a CategoryMembershipChange without a RevisionRecord. [1] https://codesearch.wmcloud.org/search/?q=CategoryMembershipChange%5C%28&files=&excludeFiles=&repos= Bug: T373318 Change-Id: Ic240edea0bb9a27cdfa2d810284644c1eef51895
* user: Allow excluding autopromotions into select groups from RCMáté Szabó2024-10-311-0/+12
| | | | | | | | | | | | | | | | | | | | | Why: - The config variable $wgAutopromoteOnceLogInRC controls whether autopromotions show up in recent changes, but offers no granular controls beyond that. - In T377829, stewards have expressed interest in excluding certain spammy autopromote groups from recent changes. What: - Introduce and use a new config variable $wgAutopromoteOnceRCExcludedGroups that can be used to define a denylist of groups. Autopromotions into these groups will never result in an RC entry, as long as they were the only new groups the user was autopromoted into. Bug: T377829 Change-Id: Ia4942b09a5162749f24c8f674429fbf3f0459a0b
* ResourceLoader: Remove ResourceLoaderUseObjectCacheForDepsHannah Okwelum2024-10-241-10/+0
| | | | | Bug: T343492 Change-Id: I89a32eea3280f5c5ca809efa3fa661b2bf998e08
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-28 16:34:00 +0000