MW-1.32-notes || MW-1.34-notes
Tasks which have seen a code commit or fix merged into one of the unstable "1.33.0-wmf.xx" development branches. These development branches are included in the final stable MediaWiki 1.33 release.
This project is automatically added to tasks by @ReleaseTaggerBot.
Blockers to the final release of MediaWiki 1.33 should be tagged with MW-1.33-release, not with this tag.
Change 747225 abandoned by Krinkle:
[mediawiki/core@master] externalstore: Always use 'dbname' if set for an external cluster
Reason:
Change 747225 had a related patch set uploaded (by Krinkle; author: Krinkle):
[mediawiki/core@master] externalstore: Always use 'dbname' if set for an external cluster
Yesterday the zombie apocalypse hit me: T294796 ;)
For posterity:
Change 582205 abandoned by GeoffreyT2000:
[mediawiki/core@REL1_31] Update the tag_summary table too in rebuildrecentchanges.php
Reason:
No point in leaving this open since MediaWiki 1.31 will reach EOL soon.
Change 713613 merged by jenkins-bot:
[mediawiki/core@master] MW_VERSION also exists in 1.33.3 and 1.34.1
Change 713613 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):
[mediawiki/core@master] MW_VERSION exists since 1.34.1
See T288201: Re-enable var() in inline CSS for plans of re-enabling var().
Assuming this is resolved given patches merged
Change 675120 merged by jenkins-bot:
[mediawiki/core@master] Follow-up 335fabf5f: Don't misuse qc_value in DeadendPages
Change 675120 had a related patch set uploaded (by TK-999; author: TK-999):
[mediawiki/core@master] Follow-up I1ef297: Don't misuse qc_value in DeadendPages
Hmm. it appears that chrome already patched this
Multiple patches have been made in the meantime. Here are some I found in close proximity to the code we are talking about:
There is still code in FormatMetadata.php that assumes GPSAltitude is always a number. I see this error about 50 times in the past 30 days. I'm not going to make a patch for this as it is rare and what we are looking at here appears to be a rabbit hole: there are sooooo many code paths in this file that just assume what they get is an integer or float, when it is most likely a string, and possibly even an empty one. I don't know how to fix this without touching half of the file.
@tstarling is there anything more to do here? Or can this be resolved? The remaining open subtasks can be disconnected, since this has already shipped and at least T250859: Rename BeforeParserrenderImageGalleryHook to BeforeParserRenderImageGalleryHook isn't really directly related
Can someone test this in WMF prod/master?
Per comment
This issue of the redirect is affecting my Mediawiki instance. I have updated my instance to MW 1.34.2 hoping that the fix would be automatic, but my user's information is still available with the Special:Redirect/user/# hack. I have searched for how to suppress users, but have so far been unable to figure it out. No where on this issue page have I seen the steps to resolve the issue, only that fixes were made to Mediawiki to somehow prevent this. Can someone point me in the right direction? I've been given until Oct 5 to resolve this vulnerability. Thanks in advance.
This was reopened without further information. Does this happen on the same code? Or was it closed/opened on accident?
Change 597616 abandoned by DannyS712:
[mediawiki/core@master] Pingback: update SCHEMA_REV following deprecation of $wgVersion
Putting this into the text planning review column, for status assessment and planning of next steps.
Can this be closed? Should this still be in "doing" on the board?
Untagging, since there is nothing to review right now. Feel free to re-tag if there's a new patch.
We haven't seen a recurrence of this so I am optimistically resolving.