see also: T166010: The Great Namespaceization Effort

@ashley Nice to see you too Jack Phoenix! :)

Okay that's fine, thank you anyways!

@sbassett Thanks for clearing that up. And yeah I'm not sure, it looks like I'm still not able to see the task unfortunately?

@sbassett Hi! Yes please, I tried looking but I don't see any UI button on my screen to make this task public. Thank you! I don't have access to T263810, but I'm guessing that it would be related to this task then?

Some examples (to hopefully help anyone who is more familiar with Doxygen) that are affected by this issue:

• wfEscapeShellArg() references MediaWiki\Shell\Shell::escape() method, but only MediaWiki namespace is linked
  • https://doc.wikimedia.org/mediawiki-core/master/php/GlobalFunctions_8php.html#a26befca24e1ad5915ae9a3676fe284ba
• wfShellExec() references MediaWiki\Shell\Shell class, only MediaWiki namespace is linked
  • https://doc.wikimedia.org/mediawiki-core/master/php/GlobalFunctions_8php.html#a561c499dc3c5bb930e32f23b6ab24012
• wfShellExecWithStderr() has the same issue as wfShellExec()
  • https://doc.wikimedia.org/mediawiki-core/master/php/GlobalFunctions_8php.html#a7b0d89414d5c87ce56fe16a597f7d5c9
• RE_IP_BYTE constant: References the Wikimedia\IPUtils::RE_IP_BYTE constant, but only Wikimedia namespace is linked
  • https://doc.wikimedia.org/mediawiki-core/master/php/IP_8php.html#a23f58100c1c7040e9069720eec5b4824

Not sure whether I should make this task as resolved and public, but it's done on our side now, so moving on the Cosmos workboard.

Patches rolled-out to master, REL1_35, and REL1_34:

• master: https://gerrit.wikimedia.org/r/c/mediawiki/skins/Cosmos/+/634749
• REL1_35: https://gerrit.wikimedia.org/r/c/mediawiki/skins/Cosmos/+/634752
• REL1_34: https://gerrit.wikimedia.org/r/c/mediawiki/skins/Cosmos/+/634751

UploadAvatar extends UploadFromFile, which extends UploadBase, which defines the performUpload() function. Since 1.35, it introduces the $watchlistExpiry parameter, so the method signatures don't match now; this causes a PHP exception to throw.

So this database column was dropped in master branch, but not in the REL1_34 branch, however last time I worked on SocialProfile, the master branch was the branch that users were expected to use and is expected to be stable with the latest stable version of MediaWiki.

Looks like this column was dropped in the SQL patch at https://github.com/wikimedia/mediawiki-extensions-SocialProfile/blob/master/UserGifts/sql/patches/actor/drop-gift_creator_user_id.sql but there's still code trying to access this SQL column

Not as high of a priority now, since most are done. (not all are done yet, just two left)

Adding @alistair3149 as a subscriber, as they recently joined the developer team for the Cosmos skin.

Hi everyone, I hope this is fine. It's not to rush anyone, its just this is a matter of being a security issue (albeit, not a repository that's deployed on Wikimedia). Does the patch above look OK? I received an OK from Universal Omega on Discord, and I would like to receive at least one more OK so I can push this to master branch and backport it to the other branches as well. Also CC'ing @DannyS712, since Urbanecm added them as a subscriber.

This is now stalled as this requires fixing MediaWiki.ControlStructures.AssignmentInControlStructures.AssignmentInControlStructures, which requires refactoring CosmosSocialProfile::getMostWantedPages()

@Universal_Omega See https://github.com/wikimedia/integration-config/blob/master/zuul/parameter_functions.py#L141 for how it currently works

Switching to ResourceLoaderImageModule would slightly change behavior as they would have to be applied as a background image via the CSS background-image property.

Before this is done, needs some reviewing of how we can make it work nicely with \ServiceOptions, eventually we'll want to convert some stuff into services

Just discussed, adding ManageWiki as a soft dependency will probably need a separate task as it requires more setup (since it was created for the Miraheze wiki platform). The rest should be fine.

@thiemowmde Thank you for your input! There's not really any issue besides being consistent with the coding conventions.

@Universal_Omega Do you want to work on this? I can help show you how to make a patch to integration-config.

(We also don't need to necessarily use OOUI icons and is actually more out of scope for this task, but could be something to consider in the future)

Ultimately the goal should be that we can just store plain SVG files under resources and load them through ResourceLoader. Currently the icon SVG data is stored in a nested associative array, but that's not very nice to have. See https://www.mediawiki.org/wiki/Manual:ResourceLoaderImageModule.php