I created a paste here with a patch (and also a new maintenance script)

I apologize for not providing clear and atomic patches, but there is no project where I can track this.

I'll reach out to the maintainer - it's not clear to me either, but I initially thought that there was a project here.

@TheDJ i understand and completely agree with the notion of small atomic commits.

Assuming this is merged, I'd be happy to submit a follow-up for the REL1_43 backport

The 302 redirect (and related tests) introduced to SvgHandler in this patch are still relevant for direct Thumb.php access. There are many instances in the wild where Thumb.php access is direct and this code catches those.

I had Claude explain it to me like I'm 5 and create a plan

Thanks @TheDJ , I just pushed another fix - this time improving the MockSvgHandler to mirror SvgHandler and fix the 9 regressions in the integration testing where `!! config
wgSVGNativeRendering=false` is set. (now composer phpunit -- --testsuite parsertests passes on the bugfix branch).

Note: I totally reworked the description of this issue since it was first filed, and also changed the code in the patch based on feedback from @TheDJ that the documentation was wrong, and that the code was intentionally setup to respect $wgSVGNativeRenderingSizeLimit even when $wgSVGNativeRendering was 'true'.

Hopefully these examples answer questions about where and how Thumb.php, Linker.php, ImagePage.php and parser output combine to create the user experience.

I apologize if it's bad form to rewrite a task, but this issue started out with incorrect assumptions. So, I just rewrote the task to make it much clearer.

In T423825#11895768, @TheDJ wrote:

Just an fyi, the file limit applies if you set it. It is not gated on partial (the very first patch did, but i changed that later to make the variable independent of wgSVGNativeRendering value)

It seems i did not correct the documentation for that. The reason for that is that very large SVGs are a ddos vector, so it has value even for people who want 'everything' to be rendered by the browser.

I updated the docs at https://www.mediawiki.org/wiki/Manual:$wgSVGNativeRenderingSizeLimit to clarify and make it consistent with the code if filesize >= limit.

w3c (standards org for SVG format) has many test files https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/

we could add more cases, and tests, for example handling animations like https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/video1.svg

A separate issue, or another commit on this issue? We should change mustRender() to always return false.

Yes, those are the settings I use:
img_auth.php
thumb.php

In REL1_43, uploading an SVG or using typical wiki syntax for displaying an image on a page can result in errors. I've updated examples on my wiki (running REL1_43) including the wiki config settings in LocalSettings.php. I'll be busy tomorrow, but will get examples on a REL1_45 instance.

The submitted patch was developed and PHPUnit tested against master, but I originally found and developed it against REL1_43 (because I'm on LTS) - which is all to say that I'm confident this patch is good for both. Between REL1_43 and current master, the major bug (500 error) was fixed but still, the handling of "limit" mode is incorrect. these diagrams illustrate the execution flow for the 'limit' mode across 3 branches.

I looked at the WIP conflicting code and it seems like that should be folded into this, preserving the now working 'partial' mode. I have svg diagrams (example) that range from 16K to 395K that I wanted to show on my wiki, which is how I discovered the 'partial' mode bug.

Testing:

composer phpunit -- --filter 'ThumbnailEntryPoint'
or both classes:
composer phpunit -- --filter 'ThumbnailEntryPoint|SvgHandler'

I have a patch in progress

I wandered down this path when I wanted to enable larger SVGs (e.g. diagrams, not just UI elements) on my wiki to be rendered perfectly by letting the browser handle it instead of rasterizing them.

The point of this message is to say that I found some instances of nulls coming into the parser from an extension (SMW - fixed) and that it still could be a good idea to defensively null coalesce the $text parameter in public function preprocessToObj( $text, $flags = 0 ) { on about line 129 of ./includes/parser/Preprocessor_Hash.php like this:

This is still an issue
Product Version
MediaWiki 1.43.6 (b557aab)
2026-03-10T01:40:25
PHP 8.1.34 (fpm-fcgi)
ICU 74.2
MariaDB 10.3.39-MariaDB-log
Elasticsearch 7.10.2
Lua 5.1.5

TODO: on completion, update the wiki page https://www.mediawiki.org/wiki/Extension:WhosOnline

WhosOnline records ALL visitor traffic, including anonymous visitors (and therefor bots on a public website) which can lead to far too many records being created in the DB. The extension is therefore only recommended for private wikis without further modification. If the code were modified so that only authenticated users were recorded in the DB, then the extension could be useful to public wikis.

For me, I get no CommentStreams functionality... even without the configuration that is the subject of this issue. I originally did have $wgCommentStreamsAllowedNamespaces = -1;, but when I remove that configuration, I still get nothing. (using the REL1_43 branch)

In my 1.43 wiki, on a page with CommentStreams enabled, I get no errors, but also no output of the CommentStreams UI (button).

merged into master

I uploaded a patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageSchemas/+/1189916

While troubleshooting the same error message on my wiki (during an upgrade to 1.39), I found that I needed to restart the memcache daemon that my wiki uses so that new extracts would be generated rather than pulled from cache. In my case, I also needed to override $wgExtractsRemoveClasses with either $wgExtractsRemoveClasses = null; or $wgExtractsRemoveClasses = '';

acknowledged.
I wish I had time to devote to upgrading (rewriting) this extension, but the likelihood is somewhere around 5%

I'll try to add docs when I get to develop an implementation.

I've used it in the past, and was contemplating using it again. I do find it useful. I can't make any commitment because I don't see when I'll have time to work on a clean room implementation, but I'll check back in here if I do.

Or, IANAL, but Tim is just one contributor. If i understand correctly, wouldn't there need to be a contributor agreement signed by ALL contributors if I add a GNU GPL license file?

Can we just use a reply from @siebrand?

I think all MediaWiki extensions should have a valid composer.json. I tagged those projects I could identify as "affected". Not all extensions have a phabricator tag.

I'm going to re-open this ticket because I do think it is both valid, and separate from T250406

composer validate --no-check-publish

In Element chat I raised this same issue. (Sorry for forking the thread.)

We used to add name/description/license/etc. to composer.json with the intent of leaving them unpublished and then people went ahead and published them to packagist anyways, so we had to take them out.

I'm a 3rd-party (corporate) user of MediaWiki and we use Docker for local sandbox development while hosting official environments (DEV, QA, PROD) in AWS using their analog called ECS (Elastic Container Service).

Publishing is not required. In fact, you can't publish a package with an invalid composer.json file.
There is no reason why MediaWiki extensions should have invalid composer.json files.

By the looks of it, all patches related to this issue have been merged. I believe this task is complete.

I added the 'enablable - semantic markup' icon / status for the <details> <summary> tags because I believe this query on Code Search doesn't show any concerns. The follow-up would be https://phabricator.wikimedia.org/T31118#6989769 suggesting the use of <details> <summary> in place of using mw-collapsible.

Thanks anyway @Majavah , and for pointing to the docs. I wasn't sure if it was possible and didn't find the wikitech info previously.

I have two concerns:

Is the mode self-contained enough to be able to be contributed back to the CodeMirror project? I don't see MediaWiki in the supported modes for CodeMirror itself. I'm thinking that if CodeMirror itself supports MediaWiki as a mode, then at least any CodeMirror product (e.g. MediaWiki widget) would be capable of editing WikiText.

I believe that there was a GSOC 2020 project. I can see many references to OOUI in the extension source. Is there remaining work to be done?

I think the top two should be Confluence, and SharePoint / SharePoint Wiki

As much as I love FOSS, we shouldn't be left to our own devices if we choose not to use Emacs to contribute to MediaWiki code. I disagree with @Ricordisamoa's position. I believe a key requirement for fulfillment of this task is to pick one of the most popular IDE's available. The idea is to have the greatest impact.

I setup a default MediaWiki-Docker environment:

Product	Version
MediaWiki	1.37.0-alpha (d1219fa)
17:56, 2 June 2021
PHP	7.2.31-1+0~20200514.41+debian9~1.gbpe2a56b+wmf1 (fpm-fcgi)
SQLite	3.16.2
ICU	57.1

I'll try to reproduce this issue on a current MediaWiki and report back.

In T194901#5378291, @MarkAHershberger wrote:

Wikia said something on RIOT about having an extension for this that was published but probably not usable by others.

I'm OK with this being declined but I would expect it not to have a limit really. Shouldn't a search tool just page results? E.g. What if you wanted to search for every occurrence of 'wg'. I understand you can use other tools, but I figured this one would be at least as powerful.