Would it be possible to keep the | for the collapsed version? I feel it looks like the template name has been shortened without it.

Thanks, that makes sense and confirmed working.

I see another call to user.sessionId() in this file as part of the bootstrap process:
https://github.com/wikimedia/mediawiki-extensions-Popups/blob/a35e35e3b397d9e6bac6b4ebe0110441d0a91cca/src/actions.js#L83

I'm experiencing this on MediaWiki 1.39.2 with the latest REL1_39 version of the extension (0.1.11). The master version only has some dependencies that are different, the extension code itself is identical.

Many wikis aren't set up to use the licenses dropdown the same way as wikipedia.

I am having the same issue which I mentioned on the talk page. You can just delete the "composer/installers": "~2.1", line since I think it's required only if you want to install via composer.

I just did a test upgrade from 1.37.4 to 1.39.0-rc.1 (latest commits on REL1_39 for mediawiki core and the Echo extension) and had this issue as well.

I've updated the mediawiki version and expected behaviour.

I don't disagree with this.

In T300587#8244314, @adrelanos wrote:

In T300587#8236028, @Prod wrote:

T301588 seems to address this issue on REL1_38 and newer versions of Extension:PageImages

Then all images wiki wide would need to be added class=notpageimage. That would be a crazy amount of work. I don't think that this is a good solution.

This ticket is a feature request for a global configuration option.

What's your use case for PageImages apart from populating og:image?

T301588 seems to address this issue on REL1_38 and newer versions of Extension:PageImages

This seems to have corrected the issue for me.

The email mentioned An "MediaWiki Extensions Security Release Supplement" email will follow this one..

@Reedy Is there anything required from me to get this merged?

In T269517#6827289, @sbassett wrote:

For a bit more clarification on the comment above and per our security readiness review SOP, the Security-Team would be happy to re-triage this if a few more details can be provided regarding:

1. A more specific target deployment date.
2. An intended production support plan, including any potential Foundation team sponsorship.
3. A working test environment, be that in Mediawiki-Docker, a standalone docker, a cloud installation, patchdemo, perhaps even a beta deployment, etc. While we can in theory just manually install the extension against a local copy of mediawiki, it helps us quite a bit to have an existing development environment with potentially real data to test against.

Thanks.

Once this is merged, will it be backported to REL1_35?

It looks like this is fixed in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ReplaceText/+/631706

In T269516#6754417, @Krinkle wrote:

Would it be possible to get this backported to REL1_35? Or can I just drop the master branch includes/Pingback.php file into my 1.35 install?

This is not a bug fix and is non-trivial new code that I think should sit through the regular development cycle to ensure wide test coverage. In my opinion too risky to backport.

It is a workaround for a bug, not the bug fix itself. This and parent task are still being worked on by Aaron, which will address the underlying issues regardless of Pingback. If you'd like to resolve this sooner, you could write a minimal patch to REL1_35 for disabling Pingback. If that works for you and you can share it on Gerrit, I'd be happy to give it a review if it's sufficiently minimal and low-risk.

In T269516#6702989, @Krinkle wrote:

In T269516#6702070, @Prod wrote:

The pingback seems to be triggering identity mode for me, and I'm not sure how to disable that, short of commenting it out in core.

The Pingback feature can be turned off via wgPingback = false, at which point it does "nothing". However it does indeed still do a very light queue and pop through DeferredUpdates which is a pretty core feature to be broken.

But, indeed as much as DeferredUpdates working is critical to a working wiki, it generally does not get involved on simple read requests. Being able to turn even that off, as part of fault tolerance seems useful.

Fixed:

In T270540#6702987

Change 650643 had a related patch set uploaded (by Krinkle):
[mediawiki/core@master] Pingback: Don't instantiate service if disabled by configuration

https://gerrit.wikimedia.org/r/650643

Is there a MediaWiki Extensions Security Release Supplement for this release?

This issue is due to T258877: MediaWiki sets invalid Content-Encoding: none.

In LocalSettings.php, the only applicable setting is $wgDisableOutputCompression = true.

MediaWiki: 1.35.0
Ubuntu Server: 20.04
Apache: 2.4

I checked what was in DeferredUpdates::$postSendUpdates:

array(2) {
  [0]=>
  object(MWCallableUpdate)#246 (3) {
    ["callback":"MWCallableUpdate":private]=>
    object(Closure)#253 (0) {
    }
    ["fname":"MWCallableUpdate":private]=>
    string(26) "Pingback::schedulePingback"
    ["trxRoundRequirement":"MWCallableUpdate":private]=>
    int(2)
  }
  [1]=>
  object(ViewCountUpdate)#500 (1) {
    ["pageId":protected]=>
    int(107841)
  }
}

The second one is HitCounters, and the first seems to be checking if a pingback is required (disabled by default).

Just to confirm my understanding of what these hooks are providing:
From purgeThumbnails the hook would provide the URLs of the different sizes of thumbnails for the currently "active" file version. This would trigger for every new file upload, as well as moves/deletions.
For example, $urls for this file (https://commons.wikimedia.org/wiki/File:JPG_Test.jpg) would give the following:

• https://upload.wikimedia.org/wikipedia/commons/thumb/2/28/JPG_Test.jpg/191px-JPG_Test.jpg
• https://upload.wikimedia.org/wikipedia/commons/thumb/2/28/JPG_Test.jpg/382px-JPG_Test.jpg
• https://upload.wikimedia.org/wikipedia/commons/thumb/2/28/JPG_Test.jpg/477px-JPG_Test.jpg

In T269517#6673806, @sbassett wrote:

@Prod - just to clarify, is there a WMF sponsoring team for this (deployment + support) or a desired date for production deployment? Thanks.

I've requested a security review at T269517

In T120216#6613155, @gerritbot wrote:

Change 322495 abandoned by Thiemo Kreuz (WMDE):
[mediawiki/core@master] Don't drop the hitcounter table (and related DB fields) during update

Reason:
Duplicate of I9d8d188, which is merged.

https://gerrit.wikimedia.org/r/322495

Yes, that's exactly the sections I'm copying from those functions. I regenerate the $urls[] in my function.

For me, the specific use case is the URL.
onUploadComplete and onLocalFilePurgeThumbnails I get the specific URLs for the thumbnail that are now stale, and send them to my CDN (CloudFlare) with a purge_cache command. (wfExpandUrl( $url ))

@Aklapper I think it should be ready to start the review process. What do I need to do next? Can this ticket be converted into the central tracking ticket, or do I need to create a new one?

In T120216#6613155, @gerritbot wrote:

Change 322495 abandoned by Thiemo Kreuz (WMDE):
[mediawiki/core@master] Don't drop the hitcounter table (and related DB fields) during update

Reason:
Duplicate of I9d8d188, which is merged.

https://gerrit.wikimedia.org/r/322495

I believe the required styles are in MinervaNeue/skinStyles/mediawiki.ui.icon/mediawiki.ui.icon.less but I couldn't configure it to get it looking right.

I'm working on updating the code to match some of the newer features and functionality.

I am having this issue. I have a standalone mediawiki install (1.32.x) and it shows my wikiID. I'm not able to change the message as it ends in an underscore.

I'm having this issue on 1.32. Can it be backported?

In T196185#4284484, @Krinkle wrote:

In T196185#4270746, @Prod wrote:

I have this option set in my LocalSettings.php. How do I migrate away from it before the setting is removed?

Most likely, you will not have to do anything. The setting being removed by this task only affects the connection, not the schema. Thus no migration is required.

However, to be sure, let us know, what value do you have for $wgDBTableOptions?

I have this option set in my LocalSettings.php. How do I migrate away from it before the setting is removed?

Although ImageMagick offers a quality parameter, MediaWiki does not give us access to it.

I have updated the description with our MediaWiki version, imagemagick version, and some comments from some of the power users.