aboutsummaryrefslogtreecommitdiffstats
path: root/includes/config-schema.php
Commit message (Collapse)AuthorAgeFilesLines
* Broaden type of DataAccess::preprocessWikitext()C. Scott Ananian2025-03-241-0/+5
| | | | | | | This prepares the way for a revision of this API in the follow-up patch Ie543457d5a2eba2ef1f1f4b7622531582c48c3e4. Change-Id: I29b843daeb614d1f48009e1ade93c16fe2f16736
* Namespace all remaining files in includes/jobqueueJames D. Forrester2025-03-201-17/+17
| | | | | Bug: T353458 Change-Id: I95690a312e356c45dbeed607d32fb0e4626690cf
* Namespace all remaining files in includes/recentchangesJames D. Forrester2025-03-201-1/+1
| | | | | Bug: T353458 Change-Id: I2ae4577de79832b082adca282ff73cfabc8f9392
* Namespace all remaining files in includes/loggingJames D. Forrester2025-03-191-41/+41
| | | | | Bug: T353458 Change-Id: Ibe1810f1c71316a9124e1dc6ae405097dafd5267
* Introduce thumbnail stepsAmir Sarabadani2025-03-021-0/+10
| | | | | | | | | | | | | | | | This would make it when the editor requests thumbnail with the width of 200px, and we have defined the steps as [...,150px,250px,...], the thumbnail with the size of 250px to be picked but still the width attribute in HTML will be set to force the requested size. This change will massively reduce the storage of thumbnails that have been causing issues for us recently and improves cache hit ratio in every layer (from client-side to CDN frontend and backend). Tested locally and it worked just fine. Bug: T360589 Change-Id: I9110d4ac9bcd421b07f13deeae5d863ef1ef9c31
* Merge "Remove $wgAllowAuthenticatedCrossOrigin flag"jenkins-bot2025-02-271-2/+0
|\
| * Remove $wgAllowAuthenticatedCrossOrigin flagLucas Werkmeister2025-02-181-2/+0
| | | | | | | | | | Bug: T322944 Change-Id: I4e142ec5eba2dc05afe947f138bea043e0667151
* | 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 "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-0/+1
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+3
| | | | | | | | | | | | | | | | | | 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-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+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/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+2
| | | | | | | | | | | | | | | | | | * 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/+1
|\ \
| * | Add ParserOutputFlags::{HAS_ASYNC_CONTENT,ASYNC_NOT_READY}C. Scott Ananian2025-01-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+2
|\ \
| * | categorylinks: Add support for write bothAmir Sarabadani2025-01-211-0/+2
| | | | | | | | | | | | | | | Bug: T299951 Change-Id: Ifd9876bcb452e412b7335741e74cfc4c820aa248
* | | For Parsoid calls, treat preprocessing as starting in SOL stateSubramanya Sastry2025-01-171-0/+2
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
* / Tag page creations of previously deleted pageKgraessle2025-01-141-0/+1
|/ | | | | | | | 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/+0
|\
| * DnsBlacklistUrls: Remove sorbs.netReedy2025-01-061-1/+0
| | | | | | | | | | | | | | 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/+2
|/ | | | | Bug: T368113 Change-Id: I8d98d187ba4f1342167820b5710f5382b2ac4831
* ParsoidFragmentMode: use special 'exttag' strip markerC. Scott Ananian2024-12-161-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-10/+5
| | | | | | | | | | | | | | | | | | | | 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-1/+1
|\
| * temp accounts: Break up temporary user names with hyphensThalia2024-12-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+4
|/ | | | | Bug: T371755 Change-Id: Ib5c523723e510621a5a278287856c4a0b0330dc9
* Merge "Merge Interwiki extension into core"jenkins-bot2024-12-051-0/+4
|\
| * Merge Interwiki extension into coreDringsim2024-12-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | ParserCache: Get rid of the temporary key schema ratio configAmir Sarabadani2024-12-031-2/+0
|/ | | | | | | | Now that production has been gradually migrated, we can simplify and remove the transitional code. Bug: T373037 Change-Id: Ic0a9f0c5df9aba61d0afac767c5aa091aa708db4
* installer: Make installer initial content be configurableTim Starling2024-11-191-0/+9
| | | | | | | | | | | | | | 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/+2
| | | | | | | | | | | | | | | | | | | | 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/+2
| | | | | | | | | | | | | 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-2/+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
* user: Allow excluding autopromotions into select groups from RCMáté Szabó2024-10-311-0/+3
| | | | | | | | | | | | | | | | | | | | | 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-1/+0
| | | | | Bug: T343492 Change-Id: I89a32eea3280f5c5ca809efa3fa661b2bf998e08
* Merge "Introduce minimal OTEL tracing library"jenkins-bot2024-10-101-0/+5
|\
| * Introduce minimal OTEL tracing libraryMáté Szabó2024-10-091-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In T340552, the official PHP OpenTelemetry client was effectively rejected for inclusion in MediaWiki due to its size. Implement a minimal tracing library instead that eschews conformance with the OTEL client specification in favor of simplicity, while remaining capable of emitting trace data in OTLP format and thus retaining compatibility with any ingestion endpoint capable of handling OTLP. In its current state, the library supports a basic feature set that should be sufficient for basic tracing integration: * Span creation, inclusive span activation and automatic parent span assignment, * Span attributes and span kinds, * Basic resource (process/request)-level metadata generation, * Data export over OTLP. Additional functionality, such as trace propagation, can then be incrementally added to the library. Bug: T340552 Change-Id: Ibc3910058cd7ed064cad293a3cdc091344e66b86
* | rdbms,objectcache: Replace wgChronologyProtectorStash with MicroStashTimo Tijhof2024-10-091-5/+0
|/ | | | | Bug: T336004 Change-Id: I2f769aa703ce98b15fa0fe98eda092ff19c27d0a
* Make revision-slots expiry configurableAlexander Vorwerk2024-09-301-0/+5
| | | | | Bug: T183490 Change-Id: I08e35ee64eab081de85ed8745361ebc4c9025d91
* Replace raw HTML copyright footer message with wikitext oneBartosz Dziewoński2024-09-261-0/+2
| | | | | | | | | | | | 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
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-22 18:32:29 +0000