xref: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1296675/comments/ab472dda_c6f790fb

Acknowledged :) Retitled for clarity. Feel free to adjust if desired

(Just to clarify, is the scope of this task Product Safety and Integrity -stewarded extensions? Just asking as the tags currently present on this task seem to be PSI-stewarded exts AFAICS, w/ the exception of ConfirmEdit (CAPTCHA extension) [which is apparently stewarded by the Editing-team?])

Cross-referencing to user report: https://commons.wikimedia.org/wiki/special:gotocomment/h-Captcha_broken_when_adding_structured_data_on_a_File:_page-20260527134000

Seems like this may still be occurring within MediaSearch (or may have regressed, I wouldn't have the personal knowledge to know either way). For me, visiting https://commons.wikimedia.org/w/index.php?search=einstein&title=Special%3AMediaSearch&go=Go&type=image and scrolling down causes some missing thumbnails to be displayed. Spot-checking a few of the missing images' URLs, the reason they're not loading appears to be Use thumbnail sizes listed on https://w.wiki/GHai.

@Aklapper Just as you had asked for use-cases in this task earlier, I'm curious what you thought about what I wrote in T351289#11356736?

In T427324#11957553, @brennen wrote:

This might just coincide with heavy traffic to phabricator.wm.o resulting in a timeout.

In T427324#11957163, @brennen wrote:

This triggers a faint itching somewhere in my brain, so it's possible it's a duplicate.

In T427081#11955347, @Andrew wrote:

The site is back up; the VM that hosts it had run out of disk space.

@Xaosflux doesn't it? $wmgUseNewUserMessage is true for commonswiki AFAICS.

In T426972#11953512, @Aklapper wrote:

->setActingAsPHID('PHID-APPS-PhabricatorHeraldApplication') should hide the PHID of PhabBanBot and set Herald as the actor.

+        // We must have a transaction actor. Set PhabBanBot which is not
+        // involved but comes closest? This is not exposed in the UI anyway.

As of right now, for me at least, https://wikitech-static.wikimedia.org/ has permanently moved to... my localhost (ie., 127.0.0.1) :P

(xref T416518: Disable Composer 2.9 functionality to randomly block existing configurations from working; related task)

Still seems to be occasionally happening, FWIW: e.g. the emails I got about the @gerritbot actions at T419152#11927317 & T419152#11927318 both contained the following header...

X-Herald-Rules: <9>, <352>, <293>, <425>, <458>, <480>, <471>

...even though those actions don't seem like they should match the conditions of H480 (if it were enabled), and that rule's been disabled for 2months+ now. :P

In T426908#11945795, @Segsap wrote:

; Enable xdebug extension module
;zend_extension=xdebug.so (line commented here)

The application started working after commenting out the mentioned line.

Hey @MGChecker/others, just checking in regarding this task from a Wikimedia-Site-requests perspective -- is/was there any update on whether there was community consensus reached for this sort of change?

(boldly closing task as resolved; this is in the 'done' column of a now-archived sprint board, and appears to have passed QA [per @dom_walden's comment directly above]. feel free to reopen if there is anything I have missed :))

(tagging codebases for visibility)

(side-note: interesting how @phaultfinder works with the current alert-names -- this was originally a ticket for gerrit being down, but then turned into a ticket about contint being down :p)

(boldly closing as a duplicate instead, as IMO it is a bit confusing to have this task as 'resolved' when the retry policy patch hasn't actually yet been merged FWICS)

In T422559#11942353, @Dzahn wrote:

Or are we just supposed to use a different sender address? It's not like we care as long as the mail arrives.

Parser state cleared while parsing. Did you call Parser::parse recursively? Lock is held by: #0 /var/www/app/mediawiki/g2/includes/parser/Parser.php(924): MediaWiki\Parser\Parser->lock()

In T422559#11938383, @jhathaway wrote:

I can add a recipient map and add the test phabricator address?

In T426861#11941420, @Reedy wrote:

Does it really matter?

symfony/yaml security issues blocking vendor

(for the record, https://gerrit.wikimedia.org/r/c/mediawiki/core/+/471664 was merged on 2026-05-19. it seems like @gerritbot didn't comment about it here for some reason)

(for the record, I assume that this was marked as resolved due to https://gerrit.wikimedia.org/r/c/mediawiki/core/+/471664 being merged on 2026-05-19. it seems like @gerritbot didn't comment about it here for some reason)

(for the record, I assume that this was marked as resolved due to https://gerrit.wikimedia.org/r/c/mediawiki/core/+/471664 being merged on 2026-05-19. it seems like @gerritbot didn't comment about it here for some reason)

(xref T416518: Disable Composer 2.9 functionality to randomly block existing configurations from working)

(not being able to merge config patches feels bad)

For the record, the patch results in (e.g.) I747323b6c377a8ced42b02bd0b0d3a8b401a593b being auto-linked as I747323:

IIUC from this commit message, the code in this repo may have been extracted from the operations/deployment-charts Gerrit repo; in which case I guess the code may be licensed under GPLv3?
(To be clear, the repo should probably still have a LICENSE file, but just saying this in case it helps to clear up which license the code may already be released under)

Cross-referencing:

• T335407: Wikipedia Android app is not available on Codesearch
• T406500: The Wikipedia iOS app should be added to Codesearch

...as the tasks for which the 'Mobile Apps' section was introduced, IIUC.

(For the record, it seems like the Countdown application was re-installed on 2026-05-06?)

I believe this got deployed in https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1284014 on 2026-05-07. From checking just now, the issue reported in this task seems to be resolved :)

Given that the mentioned Phab projects do seem to be related to VisualEditor AFAICS (for three of them, due to them starting with the prefix VisualEditor-, & for two of them, due to their code appearing to be within the mediawiki/extensions/VisualEditor repo), I'm gonna boldly propose to answer my own question with 'yes' :p

Thank you @bd808 :)

(noting for the task record, @TheDJ emailed wikitech-l about this proposal at: https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/VN5PJWPWJR66FFE52LL6AE3DIY7TJXVB/)

I suppose I was more flagging up that it was a sort of PHP-thrown error, rather than something that was (more) gracefully validated on the server-side. I guess I also assume that this sort of thing would probably be flagged up as a Wikimedia-production-error in MediaWiki-land, and so probably thought I should raise it here for folks' information. But I don't have any explicit concerns per se - I just wanted to let y'all know in case you wanted to e.g. add some server-side validation for the name length to prevent this PHP exception from occuring :)

Depending on whether or not you think the SQL exception is fine as-is, this may be deemed okay; but just FYI that it's possible to trigger:

Fatal error: Uncaught mysqli_sql_exception: Data too long for column 'name' at row 1 in /var/www/html/includes.php:117 Stack trace: #0 /var/www/html/includes.php(117): mysqli_stmt->execute() #1 /var/www/html/public/create.php(92): insert_wiki_data() #2 {main} thrown in /var/www/html/includes.php on line 117

...by removing/modifying the client-side maxlength="32" property on the <input> element that takes the wiki-name (and then entering a name that's longer than 32 characters).

In T426137#11922867, @hnowlan wrote:

[...] but I think after an incident we should have to make a very good argument for keeping an incident task private.

(cross-referencing to T424443: Request creation of thelounge Cloud VPS project)

Confirming that uploading a file on a new patch demo wiki works for me now, thanks :)

(cross-referencing to T389664: Reconsider default incident visibility, where the default visibility of incident tasks was previously discussed FWICS)

In T426293#11921006, @jcrespo wrote:

I did a few manual purges, can you check if that helped?