@Esanders I vaguely recall a series of older DT tasks about the problems with DT using wgExtraSignatureNamespaces in this way to make a seemingly final decision that a page is a talk page when there are numerous indicators to the contrary, and/or requesting for ways to create a way to either opt-in or opt-out from that decision.

To RelEng: The way we usually structure these tasks is to link to the previous one for the same purpose (Fresh) and track "Create image" as the subtask.

Actually, it seems the above patch did not fix the issue.

We have also:

July 2023:

rdbms: Introduce InsertQueryBuilder
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/935747

FYI: Periodic updates about this topic appear to be posted to https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_update#Current_status, including several updates since the filing of this task, and the last one was a few days ago.

Nice to see that upstream now recommends the same! I've been supporting this for a while with similar changes and similar reasoning in these commits:

In T175146#9712693, @daniel wrote:

Why do you think that endpoint should be removed first? I thin the order doesn't matter...

I'll take this one with Hannah to look at next week.

Maybe. You raised a good point, though, about avoiding reading from MultiWriteBag and ReplicatedBag by design does not (completely) avoid that. Maybe an optional "read" option in MultiWriteBag would be more useful to us.

Fandom hotpatch related to this:
https://github.com/Wikia/mediawiki/commit/026bf08a8f8d75a4051360833cbae75fedec7f45

As does ResourceLoader, for its resource bundles.

@daniel Is the REST API safe to remove from the EventBus extension? We may want to do that first.

Notes from meeting:

@daniel Are you thinking about IP subnets as protection mechanism because you prefer it, or because you think it's what we use today? Of the 5 job runners in the task description, number 4 used this mechanism. However that one (runJobs.php) has not been in use for several years. I've updated the task description to clarify this.

@valerio.bozzolan The SQL statements and comments appear in contradiction. For every comment that says "Skipped bug X - state was REOPENED" there is in fact a real update statement that does exactly what the comment says it doesn't. Is this intentional?

In T341319#9015034, @gerritbot wrote:

Change 938220 had a related patch set uploaded (by TK-999; author: TK-999):

[mediawiki/core@master] PermissionManager: Avoid restrictions lookup for unsupported actions

https://gerrit.wikimedia.org/r/938220

One option would be to use ReplicatedBagOStuff combined with MultiWriteBagOStuff. Write to both. Read from one. This would, however, mean that, the resulting stack is four levels of bagostuffs, given that SessionBackend wraps it as well:

@Sophivorus I'm curious about what benefit you expect in this case. Can you describe (or e.g. draw on a devtools network screenshot) what activities you expect would move or shrink in the timeline?

@Urbanecm_WMF From the code documentation, I understand IConfigurationProvider to be the main entrypoint. However, I could not find an example of this in the extensions tests. Could you add a high-level integration test to demonstrate how it would be used? That would make it easier to check which parts will become used in the critical path, and which not.

I understand the redirect is limited to mediawiki.org, but by redirecting, the URL that ends up in circulation will become inevitably the destination, which then promotes the generic URL that can easily be mistaken for that on another wiki, or even be attempted as "correct" as users try to help themselves by using the "right" one (with questions about which one to use in a cross-wiki context).

@dancy Are you proposing a redirect in general, or only for appservers? (Is this easier than a rewrite?)

It appears to me that the immediate failure here is that the session directory at /var/lib/php/sessions is not writable (ie it doesn't exist and the "nobody" user in CI isn't allowed to create it).

I've tested this locally on codesearch8 by using iptables-save and iptables-restore and adding

Thank you @cmooney, that's amazing. That rule is very specific to just port 3002. That explains a few other things I was struggling with.

@cmooney suggested I run these commamds for some detail:

• iptables -L -v --line -n
• iptables -L -v --line -n -t nat
• ip netns list

@lmata Code review for the main patch.

In T361577#9681166, @daniel wrote:

In T361577#9680375, @ssastry wrote:

Looks like new breakage from https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1012690 that exposed the unitialized field ... and seems like Ammarpad's fix should do it. Added @BPirkle and @daniel as reviewers.

Huh, I wonder why this issue didn't show up in CI.

@Tgr BagOStuff will indeed not throw an exception when writes fail, but it does support error detection and error handling. E.g. SqlBagOStuff->set() willl return false if the database write failed for any reason, including if it was read-only.

This is relevant to an issue we discussed at the offsite last month around offering teams the option to migrate legacy Node.js services to e.g. the new MediaWiki REST API (extension) and/or a standalone PHP service (if indeed it qualifies to be its own service, under latest SRE guideance at https://www.mediawiki.org/wiki/Wikimedia_services_policy and T239856).

Assigning to @Tgr per comment at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/OAuth/+/910803.

Given that php-xdebug, by definition, cannot be used to debug this problem, time to sprint some print, wfBacktrace, and var_dump:

One feature I particularly like in PHPUnit 10, is the ability to pass multiple directories or files to phpunit. I've considered it a bug not to have this, in particular because the command is completely silent about the subsequent arguments, e.g. you can run phpunit tests/includes/ResourceLoader/* today and it would "succeed" with a bunch of meaningless dots, having actually only executed the first file that bash expanded the star to.

@Od1n Is there a functional problem here in terms of what a gadget is able to do or observe?

I applied these two mistakes locally in my MediaWiki checkout, to observe the behaviour as of today:

<pre> is indeed processed in wikitext similar to many Markdown implementations, with "nowiki"-like treatment applied.