In support of T191231: RFC: Abstract schemas and schema changes, and to action T244899: CentralAuth should work with postgres, CentralAuth should be migrated to Abstract Schema
Description
Description
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T33279 Installer: extensions improvements: descriptions, alternatives, multiselection, configuration (tracking) | |||
Open | None | T178349 Expand the set of bundled extensions and skins to achieve a default MediaWiki experience that's comparable to Wikimedia sites | |||
Open | None | T246381 Expand the set of bundled extensions and skins in MediaWiki 1.36 | |||
Open | None | T191739 Bundle Thanks extension with MediaWiki | |||
Open | None | T191746 Bundle LoginNotify extension with MediaWiki | |||
Stalled | None | T191738 Bundle Echo extension with MediaWiki | |||
Stalled | None | T244898 Notifications ('Echo') should work with postgres | |||
Stalled | None | T244899 CentralAuth should work with postgres | |||
Resolved | Legoktm | T31134 installer breaks when extensions depend on each other | |||
Open | None | T191231 RFC: Abstract schemas and schema changes | |||
Open | None | T259374 Convert extensions to using abstract schema | |||
Open | None | T261912 Convert WMF Deployed Extensions to Abstract Schema | |||
Open | None | T259376 Migrate CentralAuth to Abstract Schema |
Event Timeline
Comment Actions
CentralAuth is usually installed into a separate database that is shared between multiple wikis... I guess this needs some special trickery to support that?
Comment Actions
Not really, you can mostly ignore that.
For these centralised extensions, magic table creation can cause problems. If there’s the hook already, just wire in the other dbms files too in conditionals