In T407115#11276072, @jhsoby wrote:

The README in the MWStake repo says "If the skin is no longer supported and does not work with any supported version of MediaWiki, it should be removed. ". Since DarkVector's last update (at least according to it's MW skin page) was in November 2022, just before the release of 1.39 LTS (which is EOL this December), it presumably works with that version, but I'm not sure how to properly check for the newer supported versions.

At what point do we consider closing this task as done? The methods in the task description were removed from core in 1.32 (Jan 2019) according to the release notes.

• wfExpandUrl() - dropped in 1.46
• wfGetServerUrl - dropped in 1.45
  • wfAssembleUrl - dropped in 1.46
• wfRemoveDotSegments - dropped in 1.43
• wfUrlProtocols - dropped in 1.46
• wfUrlProtocolsWithoutProtRel - dropped in 1.46
• wfParseUrl - dropped in 1.46
• wfExpandIRI - dropped in 1.45
• wfMatchesDomainList - dropped in 1.46.

There's probably half a dozen other commits I should have tagged with this bug. Most of these functions have now been dropped from the core as they've been removed from WMF-hosted (and some other) code. Will aim to tidy up this task to reflect the current status.

In T42485#11763833, @Jdforrester-WMF wrote:

In T42485#11762811, @lcawte wrote:

Should we consider closing this task or using it as a parent tracking task? There are currently no hard deprecated functions in GlobalFunctions.php (although there are some that are definitely due it) and a few long standing soft deprecations that are tracked in other tasks.

I believe the ambition is to delete GlobalFunctions.php once all the functions are deprecated or moved (e.g. wfLoad… to somewhere in the setup code), so maybe we should keep this task open for that?

Should we consider closing this task or using it as a parent tracking task? There are currently no hard deprecated functions in GlobalFunctions.php (although there are some that are definitely due it) and a few long standing soft deprecations that are tracked in other tasks.

We've just run into this at ShoutWiki after upgrading to REL1_43. Did anyone ever work out what caused this, or if it is patchable? In my search for an existing fix, I ran into this thread where another third-party user caught this error.

What exactly are we looking at here? All those GitHub repos seem to be up to date to the latest commit in the branch?

In T391086#11623606, @Seb35 wrote:

I implemented Altcha for ConfirmEdit, I’ve not published the code for now but will do in the following days.

I used the official PHP library altcha-lib-php and integrated it in the ConfirmEdit framework; in this setup there is no external call (hence no external subcontractor with GDPR issues to be managed).

At the core of the Altcha protocol, the server randomly chooses a number between 1 and maxNumber (the parameter of the difficulty) and computes the hash of this number with a salt, and the client has to find this number by computing the hash of every number with the salt until finding the correct answer. The paid service Sentinel adds an adaptative maxNumber based on the reputation of the client, a dashboard, a spam filtering service, etc.

I'm tempted to WONTFIX this task as we've now fixed the offending premature access issue and thus got GlobalPreferences (& others) working again, however, I'm cautious that someone might still want to look at the error handling for this?

In T299951#11520426, @hashar wrote:

The BlogPage and MediaUploader extensions have not been migrated and fail on CI due to the drop of categorylinks.cl_to.

I'm going to merge the above into REL1_45 - while I can't guarantee any level of "official" support for non-LTS release branches, if you want to give it a try, it should hopefully work. I'm not sure I'm going to have time to get to VoteNY this week, but, it's on my radar.

(Sorry, had this open for ages and didn't see the project tag)

As the Special "page" is part of the notifications, this seems like the correct tag for this.

Ran into this mess of code in the process of cleaning up the now-removed cl_to field references. Mainly commenting so I can find it again later.

Apologies if I'm misunderstanding this task, but, as Tgr suggested in T359116#9731922 (and makes absolute sense) if we're talking user permission/rights groups, Extension:GlobalUserrights may well worth considering by migrating CentralAuth rights to and/or refactoring it to merge in any efficiencies etc.

In T243412#9834741, @Alex44019 wrote:

This task seems to have been superseded by T337185.

Working on this at Wikimedia-Hackathon-2025 - initially as an option for third party sites.

(See also: T314352)

Going to boldly claim this, I suspect this may be one on my list for Hackathon this year, though, if I'll (hopefully) remember to release this if I get distracted/take on side quests.

I will review these later today/over the weekend - please hold me to this!

Create a new special page called Special:BlockedExternalDomains, editable by anyone having "delete" right

Sounds like ext:LocalisationUpdate would have been a good option had it not been sunset? (T300498)

Updated backtrace from my dev stack. For testing purposes, I disabled every extension, skin and non-"core" hook call.

[681ce7ac7b4d7d4eb733cc15] /wiki/Main_Page TypeError from line 300 of /home/lcawte/webhost/quietwiki/w/extensions/GlobalPreferences/includes/Hooks.php: Return value of GlobalPreferences\Hooks::getPreferencesFactory() must be an instance of GlobalPreferences\GlobalPreferencesFactory, instance of MediaWiki\Preferences\DefaultPreferencesFactory returned

Is the cause likely to be similar to T285894 ?

Extension is not tracked/developed upstream. Should be fixed in current codebase.

Forgot about this one - yes, and in REL1_35.

Does ShoutWiki Ads not have a Phab project up here?

In T254803#6204208, @Legoktm wrote:

Maybe put out a call on mediawiki-l to see if anyone uses this functionality before we get deprecate it?

For alternative names, this basically enables hotlinking so $wgEnableImageHotlinking?

I'm pretty sure that SkinAfterContent with some CSS or AddFooterLink could be used to achieve the same effect.

In T254104#6180271, @Aklapper wrote:

Screenshot from mobile mode. It is unclear what the problem is.

In T101017#6134711, @sbassett wrote:

In T101017#6128275, @Dzahn wrote:

We are waiting for updates from the security team here. Let's ask them instead of the bug reporter.

This likely needs a re-triage then as I'm sure it's fallen off our radar at this point. While it would be nice to have some official process in place, if the user this task concerns (@lcawte) has been inactive and/or no longer requires such access, we should probably resolve this task.

In T199474#5003716, @GeoffreyT2000 wrote:

The part about rc_bot has already been fixed with https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/494619/. Perhaps
Jack Phoenix and Lewis Cawte could also make a similar patch that fixes the problem for rc_patrolled.

On my TODO list when I clear this week's coursework off my list... that's assuming no one gets to it first.

I think this got shelved from our director's meeting due to more pressing matters and never ended up back on the agenda. Given that I'm the sole director now, I'd sign this if this access is something that's still possible (although I'm guessing the NDA may have been updated since June 2015?)

I'll let you guys in on a little trick I don't like publicizing, we've got a tool so it can be done on wiki as well! It's called Special:RefreshSpecial. I'd suggest, particularly on Brickipedia, if you're going to run them all (and I'd suggest you not do it excessively either), run OrphanedPages separately. I've not run it on Brickipedia since, well, probably August, but one of the pages takes a long time to populate and I'm pretty sure it's that one.

Breaking runs of fairly big maintenance scripts like runJobs and refreshLinks isn't a great idea...

ShoutWiki has enough resources to support Semantic MediaWiki, since Brickimedia now lives there this task is invalid.

Brickimedia doesn't use CloudFlare anymore.

I missed a config line. Sorted.

Transferring the domain to me (as I said I'd foot the bill a few times) is probably the easiest in the long run.

Sure, we need access to the DNS before we can do anything (pretty much all the prep work is done)