In T245850#5912492, @sbassett wrote:

Whoops, I think this task was being edited as the Security-Team was reviewing it :) Did the above commit get deployed to any relevant wikis (I know ext:Widget isn't part of WMF production)? That should probably happen soon since the patch for master is public. We should also try to backport this to supported release branches.

This has been merged.

I am closing this as invalid. There is a context issue with the DynamicSettings FarmInstaller that is causing this maintenance script to run against the wrong database. We will fix that on our end.

I deleted the updatelog entry and ran it manually. This time around it actually did the task. This is consistent behavior across every wiki that is being upgraded. It fails during update.php with a successful message, is logged as completed, but did not actually do anything. I am going to do tests against the MW 1.31 version of the database with debugging to see what is happening.

The maintenance script did run though:

Running maintenance/populateChangeTagDef.php...
done.
Adding index change_tag_rc_tag_id to table change_tag ...done.
Adding ipb_sitewide field to table ipblocks ...done.
Creating ipblocks_restrictions table ...done.
Merging image_comment_temp into the image table
Merging image_comment_temp into the image table...
Completed merge of image_comment_temp into the image table, 0 image rows updated, 0 image_comment_temp rows deleted.
done.
Dropping table image_comment_temp ...done.
Table change_tag contains ct_tag field. Dropping ...General exception while running update: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? 
Query: ALTER TABLE `change_tag` MODIFY ct_tag_id int unsigned NOT NULL

Locally on Gamepedia we are removing this patch due to it negativity affecting many of our wikis breaking styling and layout. This issue only affects Chrome the worst, does not crash Safari(though never finishes loading), and loads fine in Firefox. It should be fixed by the browser vendors as needed.

In T211233#5250018, @Jdforrester-WMF wrote:

Sounds like this is a known bug in the bots, then?

In T211233#5228363, @Jdforrester-WMF wrote:

The cookie expires after 20 minutes, and should be removed immediately on successful edit by the JS anyway. Is this not happening in the client?

Looks good to me!

The $wgThumbLimits setting is default/stock in the Gamepedia stack.

In T212013#4865266, @thiemowmde wrote:

@Alexia, please check the local $wgPageImagesScores setting you are using in your wiki (farm). It seems it contains strings, but should only contain integers.

I goofed and submitted a buggy patch. See the new patch set.

Understood. I changed our local CSS to embed the output of the Google Font URL call directly.(Which is not recommended, but not the worst thing.) We only use it in two places.

This is MediaWiki making many cookies. See EditPage::setPostEditCookie() where it creates the cookie key: $postEditKey = self::POST_EDIT_COOKIE_KEY_PREFIX . $revisionId;

I wrote a function to hoist @import up to the top of files, but unfortunately in my digging it seems that resource loader is hell bent on keeping every single file separate until the very last moment. I can not find a good place to put this in.

In T204816#4597618, @Esanders wrote:

less.php hasn't been touched in two years and has 88 open issues: https://github.com/oyejorge/less.php :/

@ashley: You might be interested in this one since you were working on it recently.

The "MediaWiki-extensions-DeleteBatch" tag does not exist so I can not add it.

In T207223#4703891, @aaron wrote:

In T207223#4703802, @Alexia wrote:

The recommend fix does work for our extension. I apparently had configured Echo properly in the past so it was working properly. For AbuseFilter I had to patch it to use the same pattern since it only specifies the database and not the cluster to use.

What is the patch diff? There shouldn't be any need to change AbuseFilter itself (at least not git master).

The recommend fix does work for our extension. I apparently had configured Echo properly in the past so it was working properly. For AbuseFilter I had to patch it to use the same pattern since it only specifies the database and not the cluster to use.

Extension:GlobalBlock(No 'ing) is an internal extension that works with Gamepedia/Twitch authentication servers. That code example is based on a previous version of Echo.

We applied this patch as a temporary work around for our MW 1.31 testing.

Previously with MW 1.29 in LoadBalancer::reallyOpenConnection( array $server, $dbNameOverride = false ) $server['dbname'] would only be overwritten if an override was passed. An override was never passed though since LoadBalancer::openConnection() was always passing false for that parameter.

The issue was that when I submitted this patch 1.5 years ago that it broke several extensions that relied on it and had not been updated yet.(Such as ConfirmEdit.) Looking at my current local code base all of those extensions have been updated and no longer rely on it. This can be abandoned.

I will fix this patch this week.

I will add that task to Hydra's internal Jira to move to extending the Module set of classes for this.

I updated the test to match the new conditions.

In T191652#4117908, @Krinkle wrote:

@Alexia I believe you misunderstood my example. I've altered the second example below, in hope to provide clarity. If needed, I can also elaborate on the JavaScript example, but let us focus on the styles issue first.

Situation s1:

• addModuleStyles( [ 'foo' ] )
• Dependencies supported (e.g. with your patch).
• foo depends on bar.

Outputs:

/wiki/Example

<link rel=stylesheet href="load.php... foo, bar">

This HTML may be cached. For example, by user web browsers, or by own File Cache, by own cache proxies, or by company cache proxies (office, WiFi, ISP). This cache is public, typically expires after some days, and is validated based on contents and/or timestamp of the wiki page revision.

Situation s2:

• foo no longer depends on bar, but now depends on quux.
• foo.css is changed to assume and override styles from quux. Its logic for "bar" is removed.

Expected outcome:

• Either the page looks the same as before (bar with v1 of "foo", unchanged), or the page looks like the new situation s2.

Actual outcome:

• Users will view "Example" (still cached) with a request for modules=foo,bar (cache expired, result will be fresh).
• The response will not contain "quux".
• The response will contain "bar" and the new version of "foo".

In T191652#4117820, @Nirmos wrote:

We also fixed several other context bugs that caused ResourceLoader to rapidly evict the cache due to it not handling cache keys correctly.(Thus causing slow downs due to having to recache constantly.)

Is this referring to T188076?

(I am trying to follow along, but poorly.) If you remove "quux" from the repository then Javascript would not be able to load it either. It is missing. Though if you mean removing "quux" as a dependency and just hoping it gets included somewhere that would be an odd choice to make. I just deployed this ResourceLoader change out to live Gamepedia/Hydra if you wish to see it live. We have a test wiki available: https://meeseeks.gamepedia.com/Meeseeks_Wiki

I put in a work around for this on the Hydra Wiki Platform that removes FOUC and puts all the CSS into one minified file.

I just got notification of this. Patched on Gamepedia/Hydra wikis. However, our version of MySQL is patched already for the table of death issue.

Many years ago there were several third party extensions that had a habit of opening new database transactions, but never closing them. So as a work around in several of Hydra's own extensions we put $db->commit() in place to fix them breaking transactions.

This was the entire change. Basically it had not been updated for MediaWiki's newer API for atomic database transactions.

I found the issue. Another extension was throwing an exception for logged out users that was causing this issue for Cargo. However, due to an exception handling change in MediaWiki 1.29 those kind of exceptions were quietly being dropped and MediaWiki would go on pretending everything was fine.

Morning update: I have found that the hook "PageContentSaveComplete" is not being ran or being interrupted somehow. The onPageContentSaveComplete function in Cargo never gets called.

Regular page edits through the standard source editor are what cause this behavior.

@Reception123 DPL3 is meant to replace all previous iterations of DPL.

You should not be running both of these extensions at the same time. Intersection is a legacy extension and fork/branch of the previous iterations of DPL.

It probably will! I will get this fix deployed on the Gamepedia stack today.

A similar error on line 244 of drilldown/CargoFilter.php. Path of Exile has weapons with range so that conflicts with the MySQL reserved word.

I think I know why this happened then. Our development machines are OS X case-insensitive. So most likely at some point it was capitalized way in the past, but future file copies went fine since OS X will not rename/ignore the difference. I will mark this as closed.