Is the first one an unintended side effect of the Wednesday evening or Thursday / last night's SWAT patch deploys for T138425: wgMFSpecialCaseMainPage should be disabled on new wiki installs ? I suspect someone would have caught this prior to Thursday's / last night's SWAT patch, so I'm guessing the latter.

It would appear that had a secondary effect on mobile Wikipedias for the search bar. As you'll see at a group0 server response MediaWiki.org, for example, https://m.mediawiki.org/wiki/MediaWiki, the new search bar fixture is up and running as expected (group0 gets new code on Tuesdays). One would actually expect to see the new search bar fixture on place in Wikipedias via the deployment train yesterday (the bulk of Wikipedias get the updated code on Thursdays). But I'm guessing the code paths got crossed somehow. You'll notice that a page that has been cachebusted via an`action=purge` just several minutes ago, https://en.m.wikipedia.org/wiki/Tears , doesn't have any new search chrome as one would expect.

As an aside, as per {T134894#2341608} (expand section to see exchange between @Jdlrobson and @Nirzar) we expect a brief period of less than perfect search bar styling on stale pages while the search bar chrome propagates, but not this sort of thing, which appears to be a confluence of code.

we expect a brief period of less than perfect search bar styling

but i was seeing the new search bar on stable (non beta) last night. right after the deployment. and now i dont. on same browser. is that expected?

@Nirzar are you saying you checked the Main Page after @Jdlrobson's SWAT deployment last night? Or are you referring to checking something else after the train or something?

@Nirzar, not sure. Note also there are some styling issues appearing elsewhere on desktop wikis, so it's hard to say what's happening here exactly. @hashar just added this task as a potential blocker for the train deployment T136973: MW-1.28.0-wmf.7 deployment blockers. duploktm just requested to rollback the train because checkuserwiki has no styles. So I guess if a train rollback happens, we'll want to see if things "just work" again.

SWAT deployment last night? Or are you referring to checking something else after the train or something?

yes... after the task for search bar got resolved i checked wikipedia and it had the new searchbar.. now it doesn't :(

see also T138413 - styles missing on mobile special pages

Not related to T138586.

Just confirmed with the fix for the other wikis (checkuserwiki, nlwiktionary, etc.), the behavior still exists on a cachebusted page such as https://en.m.wikipedia.org/wiki/Main_Page?cb=1234234234 the symptoms exist.

https://gerrit.wikimedia.org/r/#/c/295926

@Anomie is cross-referencing full list.

From #wikimedia-operations Freenode IRC:

anomie>
dr0ptp4kt: On tin, /home/anomie/old-mobilemainpagelegacy.dblist has what I believe is the equivalent of the old list of wikis the setting was enabled on, and /home/anomie/mobilemainpagelegacy-removed.dblist is just the wikis that were removed from the list in that change.
...
dr0ptp4kt: I took git show 425cf560e8572d0e26f0a28e3d627324005c6a35:dblists/mobilemainpagelegacy.dblist and combined it with /usr/local/bin/expanddblist '%% all.dblist - wikidata.dblist - wikiquote.dblist - wiktionary.dblist', then sorted, uniqued, and compared to the current version.
dr0ptp4kt>
anomie: so if i understand correctly, the logical induction produced 461 (or is it 462? diff -rcs mobilemainpagelegacy.dblist old-mobilemainpagelegacy.dblist | grep -wc '+' yielded 461, but the -removed.dblist file shows 462 lines) entries that would have to be added back in...
...assuming
...total inaccuracy in the audit of the sites. i don't [sic. know] if that was done via a content analysis or something like that. anyway, clearly a number of wikipedias were operational using that wg

I'm not sure of the way the audited list of sites was generated for the preceding SWAT patches, but it would seem that deploying https://gerrit.wikimedia.org/r/#/c/295926/2/dblists/mobilemainpagelegacy.dblist now, and spending a little more time to verify the fuller insertion of those other 461-462 items from @Anomie's list (along the lines of @Krinkle recommendation of "The legacy dblist should contain all.dblist - [sic. minus] expansion of the previously false values (wikidata, wikiquote, wiktionary)" - I'm guessing there are nuances involved with the actual wikitext on sites - would be a fine approach.

Thanks!

Note the search bar is a different bug and probably not related. I suspect relating to caching since we rolled out the new design.

Change 295958 had a related patch set uploaded (by Jdlrobson):
English Wikipedia uses legacy main page formatting

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

So it turns out if you use id's which are prefixed with mp rather than mf although not documented this results in transformations sigh. So I'm rerunning the audit and the new config will take care of it. In the mean time this is a reminder of how many workarounds happen in MobileFrontend due to wiki content that is not mobile friendly. We need TemplateStyles !!

@greg-g any chance we can we could swat 295958 today given the impact?

Change 295958 merged by jenkins-bot:
Whitelist Wikis that use older mp- prefix

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