We should probably QA this unless there is another team doing this. @JTannerWMF can you advise?

Okay the refactor patches are up. I'm hoping this will be the last time we need to touch legacy Vector. I've tried to simplify the components legacy Vector needs so we can park its templates in its own folder (potentially includes/templates/legacy) and rely on Typescript to help us not break those contracts going forward. I'll switch gears to the header work while I await your reviews. Thanks in advance!

Do any of you have a strong preference for where you think this component should live? If so, it would be awesome to get an initial pulse of that on this ticket now.

I don't know if it's feasible, but I feel a strong leaning to have a dedicated repository that we publish to npm. In terms of integration I'd like to see us take the built and versioned output of that code and put it in either core or Vector.

@Tgr I've got a question about whether I can deprecate this now - would it be possible for you to give your perspective in this discussion? Thanks in advance.

(Sorry for the noise)

all this without discussion and consensus

@Volker_E feel free to add QA steps for beta cluster and move to QA if necessary.

Patch https://gerrit.wikimedia.org/r/586451 fails to do vertical centering. Absolute positioning with arbitrary browser font-size is unable to do that.
Please revert the patch to avoid the damage.

This patch moves a value into a variable. It doesn't change the status quo. Additionally it lets us make the changes to the header without touching any code that runs in the legacy version. It's not going to be reverted.

@Tgr https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/580881 and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/586469 should explain it

In T249565#6034709, @Bugreporter wrote:

In T249565#6034676, @Bugreporter wrote:

Note in Wikidata EmausBot is creating a lot of duplicated items: https://www.wikidata.org/wiki/Special:NewPages

And due to this, rebuilding wb_items_per_site may results in some errors (see https://www.wikidata.org/wiki/Wikidata:True_duplicates)

There have been no deploys in the last 5 hours. The issue is described here - https://logstash.wikimedia.org/goto/9f6a1d2eb60269b7d8ce0c8a767c7ce8 - and states "Table 'wikidatawiki.wb_items_per_site' doesn't exist"

This impacts cached HTML

Reopening because there is still a config change I need to SWAT to tick the acceptance criteria. Feel free to move this off the board if it's noise (I can track it in my user board)

Note the remaining code in MobileFrontend that makes use of this is never run in production and scheduled for removal this coming release. So I guess this is blocked on T240622 (not sure if you want to formalise this in Phabricator) xx?

@Krinkle I'm seeing "curl: (3) <url> malformed" which suggests those globals are not available (works fine locally). Are you sure they are available in npm test?

So I suppose we'd be checking variables are defined. It would mean we'd have to ensure certain template values were defined as null (and not undefined) as null is a perfectly valid template value.

For the things that can be done later, I think is important to somewhat plan ahead and reassure TechCom and others here that those things actually can be done later in a way that isn't a breaking change.

Thanks for the protip @Krinkle I hadn't realised those globals were available here.

From my perspective the code looks good and is delivering value. It is also behind a feature flag which defaults to false.

Also broken on desktop (https://en.wikipedia.beta.wmflabs.org/wiki/Extension:Graph/Demo#Using_RESTBase_API) so I think this is unrelated. Looks good to me.

I'll take care of the config flag on Monday.
No need to track this any more. Thanks for the review @polishdeveloper

(Thanks for the merge @polishdeveloper !)

@Izno @Jdforrester-WMF @Ciencia_Al_Poder this task is very very far in the future - sorry to give the impression it was pending. As @Izno says the template styles adoption is a big blocker which is going to take time.

Hey there is T248347 to capture that! Have added you as subscriber.

In T244444#6025946, @Demian wrote:

@Volker_E at which point of the caching infrastructure would these conflict before the 2 week TTL runs out?

Yeh there is code merged that will run in next train so we should be starting QA asap.

The migration has been completed.

Thanks for SWATing!

In T237230#6023387, @Edtadros wrote:

@Jdlrobson I'm wondering if I'm just not logged in with the right user or settings when I test these. If you look at AC5 in T237230#6023325 It behaved differently with a user with AMC on vs off.

Result of patch https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/585042/

I believe this is blocked on fundraising and the maintainer of the 3rd party (?) Theme extension.

Thanks @Edtadros
@Volker_E @alexhollender - it seems we are wrapping rather than truncating in some places. Is the QA/acceptance criteria wrong or is this acceptable?

TheDJ ah okay. IS the bug for the static image captured anywhere? As that seems more of a pressing issue to me.

Done ...?
QA ... ?

I've looked into this and it appears the lazy loading images is the problem here.

@TheDJ I dont' think this has anything to do with MobileFrontend.