The current default is false: https://gerrit.wikimedia.org/g/mediawiki/core/+/941744bd04db2e4eadbfec565592960df4f4bf59/docs/config-schema.yaml#5049
It has been set to true on Wikimedia wikis since 2025-06-10.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T404526 Remove $wgEnableMultiBlocks | |||
| Open | None | T404509 Set $wgEnableMultiBlocks to true by default |
Event Timeline
Comment Actions
Do most wikis need multiblocks? I'd say that keeping it off is possibly more useful for the majority of wikis (outside of Wikimedia sites). Although I don't have any reason to think that really!
Note that there's also T351508 which is related.
Comment Actions
I filed this task for the followibg reason:
- I suppose $wgEnableMultiBlocks is a temporary flag that should eventually be removed (similar to $wgEnablePartialBlocks which is already removed). So this is the first step. Maybe I am wrong, but see also the next item.
- When $wgEnableMultiBlocks is still an optional setting, A number of extensions (e.g. AbuseFilter) requires different behavior when it is true or false, which may cause technical debt. And also see recently filed T404508: Make $wgEnableMultiBlocks queryable which means 3rd party tools needs to deal with whether it is enabled or not.
Comment Actions
I agree with this task. Let's get the new and shiny in front of people.
Removal of this feature option should be blocked on re-adding support for Special:Block without Javascript. I've filed that as T404524: Codex Special:Block should support no-Javascript environments (rather than as a direct child of this task).
Comment Actions
$wgEnableMultiBlocks is a temporary flag
My memory is that we didn't mark it as such (unlike $wgUseCodexSpecialBlock) because it was intended to be permanent. But it definitely would be simpler to not have multiblocks be optional, so if it's seen as useful (or not terrible, I guess) for all 3rd party wikis then this makes sense.
Comment Actions
Indeed, $wgEnableMultiblocks was intended to be permanent. We felt multiblocks might impose unnecessary complexity particularly on smaller wikis that don't really need multiblocks, compared to the much simpler binary system of where a user is either blocked or not.
However, from what I can tell, reception of multiblocks and the new interface has been overwhelmingly positive – except for the lack of no-JS support. I also certainly agree we should avoid the tech debt, so it's sounding like making multiblocks permanent is the right decision.
Thanks to both Izno and Bugreporter for creating this and related tasks! In case it means anything, For the record, I highly doubt we'll have this, T404526 and its subtasks done by MW 1.45, if that means anything to anyone.