Honestly this is so annoyingly trivial and I only spotted it because I was testing 1313987 on a mwcli instance that I spotted this 😆

In T414004#12228481, @Addshore wrote:

I just did sudo mw update --version v0.31.0 followed by sudo mw update --version v0.32.0 and it seemed to work fine for me?
On what setup were you trying this?

In T414004#11687511, @Addshore wrote:

In T414004#11686985, @ItamarWMDE wrote:

I can confirm this is still happening with updates from 0.29.2 to 0.30.0

Looking back at the commit, I believe it should be fixed with updates from v0.30.0 onwards

All four methods are now hard deprecated 🎉

We currently use Google's own consent integration directly from the AdSense panel, but rolling something more aligned with MediaWiki etc would be a bit better.

On the first point I made - as by it's nature, a lot of these tools are social and to do with multiple users interacting - once you've found a thing, you then need multiple test accounts to go and test things.

I know we're now... ten years on from this task being created but adding some two cents...

As far as I'm aware this is now resolved - though T425223 is the long term solution

I'm not sure if there's a pre-existing way to do this in MediaWiki/PHP/any of the libraries already - CLDR seems to provide a method to do this, but would create a hard requirement on that extension.

Some good progress has been made on this - there's certainly still more to do! Codesearch has a number of instances, though plenty of false positives too.

Sounds like a good first task to me - would probably just need to make sure it's logged to the correct wiki(s), the log code itself is pretty simple, but requires the introduction of some i18n messages etc.

Rebased and merged today :)

I know this bump is almost a year after this conversation started, but this extension is effectively without a maintainer. It would be great if someone (possibly @NicJansma ) could be granted rights to take up maintainership.

In T427214#11961367, @Pskyechology wrote:

In T427214#11961275, @lcawte wrote:

I don't know when exactly core changed its permissions to tie creation things to the 'edit' right, however, the ability to decouple the permissions of this feature from the main edit right is very much an intentional choice which is left in the hands of site operators to make.

I can't think of a single good reason to disallow editing and normal page creation, but allow the creation of pages via extension. This also places an unnecessary burden on operators to specifically account for the extension's design choice that misaligns with core to allow for a rather silly choice.

I don't know when exactly core changed its permissions to tie creation things to the 'edit' right, however, the ability to decouple the permissions of this feature from the main edit right is very much an intentional choice which is left in the hands of site operators to make.

Should now be patches for review against all WMF-deployed code & core per codesearch.

Currently, as there is no ETA on a fix, the solution looks like reimplementing PageInCat as a Lua module - 1.43+ introduces a relevant call which makes this possible.

It's been a minute or two since I last touched logging code - this seems like it'll be a reasonably easy fix for new entries - should just be able to log a (ns_id:)page_id and put a formatter in to change that into an article link.

Interesting - have you only experienced this via the API or is it also a frontend issue? I'll have to see if I can reproduce, feels like it could be a caching issue, but, equally it sounds like it might be an unhandled error somewhere that needs more handling.

Absolutely agree. ListByRatings? Not a difficult change to make, just need to name things which is hard.

According to codesearch, all the remaining instances hosted by the Wikimedia Foundation are in inactive extensions that are in the process of being archived.

According to @hashar (T70638#736434) we did used to have djvu packages installed in CI ?

In T425077#11880788, @TheDJ wrote:

Id3 is most definitely a production dependency. However, you need the entire media pipeline with ffmpeg and dedicated job runners if you want to run video encoding and processing. It’s not easy to set up

In T337185#8869442, @Catrope wrote:

Although a lot of CentralAuth's functionality was generalized in the SessionManager interface and its friends in MediaWiki core, this single-use authentication token functionality wasn't. It's CentralAuth-specific, and the code for generating the token is in an action API module, so it doesn't provide a real PHP-side interface for getting it.

We could generalize this interface, put it in MW core with an implementation that would work for a shared user table setup with a shared session store (or just within the same wiki), and have CentralAuth override it with its own code.

(TWN marked as done as never translated on TWN)

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.