@Anomie said

In general, we need the code doing the outputting to be able to know what it's getting back: output safe for HTML output (whether parsed or escaped) or output not safe for HTML output, which doesn't depend on the input format

In T226598#5331685, @tstarling wrote:

So I now propose that MessageFormatter::format() will correspond to Message::text(), which just does preprocessing. It would be up to the caller to interpret the result as either plain text or HTML.

In T191231#5328452, @HappyDog wrote:

That may be true of a general abstraction layer, but we're talking about a specific abstraction layer for MediaWiki. Therefore, by definition, it is the choice of the application.

This is done. Here is a link to the API:Sandbox for exporting a file description page with a mediainfo slot:

The merged patch, 522401, should address the critical problem. Should probably be backported and go on SWAT.

In T32211#5327950, @Urbanecm wrote:

Hmm, then the fact two users were moving on the same time might be just a coincidence.

meta:MediaWiki Stakeholders' Group is an interwiki redirect:

#REDIRECT [[mw:MediaWiki_Stakeholders%27_Group]]

In T191231#5327371, @HappyDog wrote:

This. A proper DB abstraction should not be about trying to define the lowest common denominator of, for example, an INT field (can't be signed, limited to 16 bits because we need to support FoobarDB, etc.). It should be about defining high-level data types (e.g. EMAIL, ARTICLE_TEXT, etc.) and allowing the individual abstraction layers to map them to the most appropriate type in the back-end system.

I agree with the plan Tim outlined above.

In T227700#5327028, @Krinkle wrote:

Such as:

• Request ID: XSfQLgpAMFsAAGu8hPkAAABM
• Request URL: http://meta.wikimedia.org/wiki/Special:MyLanguage/MediaWiki_Stakeholders%27_Group

Tagging CPT for review.

In T227776#5326455, @Anomie wrote:

At the moment we don't have a concept of "non-public REST API routes", unless I missed something when I was on vacation recently. The closest would be a public route that we document as internal and that requires some sort of shared secret to function.

In T227776#5326455, @Anomie wrote:

Kask,[1] accessed via RESTBagOStuff?

In T227776#5324601, @Anomie wrote:

Overall I like the idea, but I'd want to see more details as to how all the "in addition support" stuff is actually going to work at an interface level that doesn't wind up turning it into just another generic key-value store.

But if you are confident it will get fixed in the last 7 days, I don't see a reason to block the train today.

In T213505#5324809, @Tgr wrote:

The issue here is that the cached HTML would have to be updated at some later point, when the summary became available. At a glance, the proposed change to ParserCache does not make that easier (or harder).

@Anomie time to revive https://gerrit.wikimedia.org/r/c/mediawiki/core/+/514245?

Moved to the RFC backlog for improvement after discussion at the TechCom meeting. The proposed functionality seems sensible enough, but this ticket is lacking information about system design that is needed to make this viable as an RFC.

@Ladsgroup we discussed this at the TechCom meeting. This proposal seems sensible at the database level, but there are two aspects that are not really clear: need and cost.

Per the TechCom meeting on July 10, this goes on Last Call until July 24. If no relevant objections remain unaddressed by that time, this RFC will be approved as proposed.

In T227700#5324428, @Ladsgroup wrote:

The reason that it's UBN is because it's a train blocker and they all are UBN. Whether this should be considered as train blocker or not. I don't know. (Just case it's not clear why it's UBN)

We should thin about how the RESTbase storage component relates to the ideas outlined in T227776: Generalize ParserCache, create a service for storing data derived from a page's current content.

This is a potential use case for T227776: Generalize ParserCache, create a service for storing data derived from a page's current content

Might be a use case for T227776: Generalize ParserCache, create a service for storing data derived from a page's current content.

@Jdlrobson thanks for the clarification, Jon!

In T216165#5322823, @Jdforrester-WMF wrote:

Can you please go have an RfC on another task with Timo's proposal (which would also encompass T216166 ), rather than disrupt this task?

Thanks for the analysis, @Krinkle! Looks like the Title/NamespaceInfo refactoring is flushing out more places were we inadvertently use invalid titles or make unwarranted assumptions about titles.

This should be an RFC since it has wide ranging implications.

Before upgrade the wiki was 1.31.0, cache was filled with its data and everything worked after upgrade

In T223165#5318871, @JTannerWMF wrote:

It appears Core Platform Team is taking this on so the Growth-Team is moving this to external.

@hashar on a related note: T227600: Make graph-tool available on tool forge

In T227603#5318565, @hashar wrote:

@daniel I am not sure why networkx has to be used with python 2. It has been supporting python 3 for a while and even dropped python 2 support with v2.3.

Caching should not be the cause of any problems during upgrade. Unless the desired is found in the cache but isn't actually in the table, in which case it wouldn't get created in the table. But how would it get into the cache if it's not in the table? The cache is populated by loading from the database.

Pinging @Physikerwelt for the Mathoid use case.

In T226598#5315251, @Anomie wrote:

There will either need to be a factory class, or the formatting functions will need to have a language parameter.

That's a good question, and one that will also be relevant if/when I get around to the MessageSpecifier thing.

In T226598#5312973, @Tgr wrote:

Implementations ignoring the hint and just displaying the raw quantity and unit would still be usable, if a bit awkward.

In T184529#5310385, @Tgr wrote:

You did create T224020: Create a class to represent the identity of wikis on the same wiki farm based on that.

up for review per legoktm

In T193824#5316023, @Legoktm wrote:

I've been operating under the assumption that at some stage we're going to have some kind of containers with just some extensions installed, and we'll need to resolve those dependencies for testing or whatever.

@Absorbcium is there anything in the log about the PopulateContentTables script being run? Try running it manually if in doubt.

In other news, I'm investigating the possibility of making a codeception plugin for phester style tests. Seems quite doable, but I have only just started to poke around.

I found another tool that is relatively close to phester conceptually: htt the HTTP Test Tool (hosted on sourceforge - I didn't know that was still a thing). As far as I can tell, htt was created by the FSF in 2011 and as seen little activity between 2013 and 2019, but had version 2.4 release this year.

In T225585#5312967, @Urbanecm wrote:

@daniel i've backported this into wmf.11 to speed up the fixing. Can you (or somebody else) verify it's indeed fixed now please?

So, the concrete issue was fixed by moving the check, but we still don't know the root cause. Is that correct?

In T222100#5308491, @kostajh wrote:

Meanwhile you could have a look at https://github.com/deminy/behat-rest-testing

The relevant patches mentioned above are merged now.

This task is invalid as described, because the updater has always been running PopulateRevisionSha1 after PopulateContentTables. I changed PopulateContentTables to calculate the SHA1 (and the size) on the fly if needed and write it to the content table
(https://gerrit.wikimedia.org/r/520735), and Bill updated PopulateRevisionSha1 to make use of that information to populate rev_sha1 and ar_sha1 at the end of the update process (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/516730/).

This task is invalid as described, because the updater has always been running PopulateRevisionSha1 after PopulateContentTables. I changed PopulateContentTables to calculate the SHA1 (and the size) on the fly if needed and write it to the content table
(https://gerrit.wikimedia.org/r/520735), and Bill updated PopulateRevisionSha1 to make use of that information to populate rev_sha1 and ar_sha1 at the end of the update process (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/516730/).

In T200653#4499482, @MvGulik wrote:

Update: Seems the "populateRevisionSha1" maintenance script needed to be run with some "--force" option.
To make note of a personal point here ... I'm kinda disappointed that option was not mentioned here.

So I played with codeception a bit. Here's the basic CRUD tests: