On Gamepedia we use a vetting process before giving people administrator level access and we actively engage with the administrators in our IRC/Slack channels. However, an extension like this would be useful once the number of wikis/admins grow past what is reasonable to handle. As for taking over accounts we have our own AuthenticationProvider and SessionProvider that more or less mitigates those possibilities.(I won't say it is impossible though!)

I can confirm that our editors at Gamepedia are experiencing the same issue with *.gamepedia.com wikis. Our top wiki editors primarily use Firefox and they all began to experience this issue after upgrading to Firefox 50 in November 2016. Since there are many wikis they visit they regularly break that 150 cookie limit. I tested and checked this with an editor today observing that despite cookies being set on individual subdomains(example.gamepedia.com) Firefox is keeping a limit of 150 cookies for the whole of gamepedia.com.

I made a patch that fixes all of these instances.

This shows up as issue in the CargoTables special page as well.

In T135876#2314749, @matmarex wrote:

That doesn't explain anything. I still don't see why the small change in when the hook gets called broke your extension. The function is still called, and it's still called with the same parameters. So is the hook in Vector.

In T135876#2314743, @matmarex wrote:

That change was part of https://gerrit.wikimedia.org/r/#/c/273745/ by @Krinkle.

The setupSkinUserCss() method should still be called from OutputPage::buildCssLinks(). Is that not working for you for some reason?

Here is a very simple way to reproduce it tossing it into any page. $wgTidyConfig is the default of null and $wgUseTidy is the default of false. I have not figured out a fix yet.

The develop branch contains several untested fixes that should make it easier to run it outside the Hydra Wiki Platform.

• Switched to CentralIdLookup factory.
• Renamed $dsSiteKey to $wgSiteKey - This will have to be defined per site configuration.
• Database schema updates will run if the site being updated has $wgSiteKey set to 'master'.

Now open sourced:
https://github.com/HydraWiki/GlobalWatchlist

Yes, it is on my list to make open source. I am not entirely sure it will be usable in its current state due it being a memory hog. My 20% time is on Fridays so I will look at this tomorrow and sanitize any strings that might be considered proprietary before pushing it up to GitHub.

I ran php7mar against this and did not find any current instances PHP 7 breaking variable interpolation. I could not get phan to work as it just produces segmentation faults.

This patch was abandoned in Gerrit.

I believe this was the bug fixed by this pull request and was merged into 1.24+.
https://gerrit.wikimedia.org/r/#/c/59522/

I investigated the GraphicsMagick issue. At some point they merged in the "+set Thumb::URI" fix/feature, but I can not find it in their change logs. The recommendation I have is for people using it to make sure they are running the latest version.

The GlobalWatchlist extension that runs on Gamepedia is tied heavily into the Curse account system to be able to use a single user identifier. Exactly like the global_id used by Extension:CentralAuth. Releasing it in its current state would result in code that is unusable by anyone else. There are future plans for the team, one year or more, to rework the Curse account system so that extensions that rely on it can be easily decoupled.

This is fixed/improved in the 3.0.4 release.
https://github.com/Alexia/DynamicPageList/releases/tag/3.0.4

This is fixed in the develop branch on the Github repository. It will be packaged in the next release.
https://github.com/Alexia/DynamicPageList/commit/2ba36f01f0a417480c19c20bdeeee0a995aa86c3

I put this on our internal tracker to be worked on and I should get to it this week if not today.

This appears to fix the issue on my end.

It appears ConfirmEdit tries to initiate a WikiPage object with the NS_SPECIAL namespace.

Alright. Would there be any opposition to adding developer notes to the Extension:MobileFrontend page? I searched and looked around for a couple hours trying to find details and ended up here to report a bug figuring there was no way around it.

In T78678#1138642, @Aklapper wrote:

In T78678#853544, @Alexia wrote:

I am looking into this now. I'll copy the resolution here from Github when completed.

@Alexia: Any news?

I forgot about the patch uploader. I just sent one through with corrected logic.

I am looking into this now. I'll copy the resolution here from Github when completed.