The experiment was a success imho, so we need to actually do it now.

ParserCache has been expanded under a separate project. This ticket is obsolete.

From what I've seen, there is nothing in those plans that suggests a separate source of config per extension, nor a specific use case or need for it.

Yeah, finalize instead of unset. I'm already removing the unset in some of the other patches. $wgSettings is useful to have access to in tests.

Pages were added to the list for multiple reasons:

Yup, reverting the patch mentioned by @thiemowmde will certainly fix this. I'll re-do the patch slightly differently later on, reverting is the right move now.

Patch https://github.com/wikimedia/eslint-config-wikimedia/pull/426

In T296331#7525107, @Legoktm wrote:

We will need to upload packages of php-yaml to our php72 and php74 sections on apt.wm.o. When did you want to have this available in production by?

We've consulted with stakeholders identified in the Tech forum proposal and haven't seen too much opposition to the idea of YAML. It probably will not be the final destination, but it seems like an ok intermediate step in cleaning up the configs. I'm resolving this ticket.

In T296331#7524691, @Majavah wrote:

Will 3rd party MW installations require php-yaml in the future?

I don't think access logging in logstash would be very useful. It would be useful to send regular envoy logs to logstash, but filter on error level.

This worked :)

Note that LinkTarget knows nothing about page IDs. LinkTarget is a parsed full title string. Why exactly page IDs are involved is probably an optimization - Parser already resolved the page IDs for redlink rendering so we set them in ParserOutput to not waste good batch database result lookup.

Having fake RevisionRecord imho is not great - we are trying to all more and more invariants to it. Like we want RevisionRecord::getPage to return a PageIdentity, meaning that RevisionRecord can only exist for pages that potentially can exist. Doing that for example will break things like parsing in the context of the special page, which we do.

@Legoktm I've tried out converting our existing DefaultSettings into TOML. With introduction of config schemas the general structure for each key would be something like this in YAML:

So, the code that's asserting is

https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/5136 should fix the immediate issue on translatewiki.

I fail to see the connection to k8s to be honest. Care to elaborate?

Ok, from reading all the tickets posted by @Reedy it seems like SemanticMediawiki supports installing via composer (e.g. it's code is pulled via composer). It's not (should not) be enabled by default though, there's enableSemantics function for that.

What the path above did was to move composer autoloading before loading DefaultSettings.php. Which should not have mattered - composer dependencies shouldn't really depend on MediaWiki.

Yeah. ParserOptions still need a lot of love, but we can love them independently of this ticket.

ok. I guess I agree. let's squash them together.

Hm... Indeed you're right, it did remove it by making the content uncacheable. But it was a bad thing.
I still stand firm in my believe that it's a problem with tests, not with the patch :)

'disablelimitreport' is a different thing 'saved in parser cache' comment. These are 2 completely different comments from different systems. The reason 'saved in parser cache' started showing up is because we can not save more things in parser cache, and I guess one of your tests now has content that can be saved. There's never been a way to remove 'saved in parser cache' comment from the output.

But isn’t this something that should be avoided?

only happened once, perhaps during pulling of the change... if you look at the stack trace, HttpRequestFactory.php line 98 doesn't have a reference to Http:$httpEngine anymore.

Not on Friday unfortunately. No deployments on Fridays.

Ok, fixed all the stuck renames. Done.

Done.

This also affects simple page views: https://zh.wikipedia.org/wiki/Delon_Thamrin

Success! Thank you @dancy

Actually, different result, now it's UndefinedError instead of AttributeError..

@Legoktm just tried to deploy again, same result.

Currently initialization of MWServices is quite a mess.

If we look at the URLs in logstash we can see something like /w/index.php?contribs=user&limit=50&month=1&namespace=&tagfilter=&target=127.0.0.1&title=Special:Contributions&year=3cCnJTIY'%20OR%20486=(SELECT%20486%20FROM%20PG_SLEEP(12)) - the 'year' parameter is garbage, someone is trying to do a little SQL injection here.

The format of "problem statement first, solutions later" is very hard to follow, since I feel immediate urge jump to solutions, I'll try to stick to the problem.

yes this can be removed.