a couple more things

if you're going to do site js/css then might as well do vector js/css as well.
and this may be going too far but some other things to consider:

• vector wasn't always the default so also js/css for earlier defaults
• past versions of wmf-config
• past mediawiki wmf deployment branches

and now force quit doesn't help. so maybe was a coincidence the first time.

got an edit conflict then waited 10+ mins, still was a conflict. (and I was still the only editor today)

@Dbrant what's another example of different phenotypes, same cause? is that policy written down somewhere? if someone just read T115035 and never saw this then they would be unlikely to know they need to also check here to see if it was also fixed when that's fixed.

@Dbrant may be the same cause/fix but clearly not a dupe.

my gut says this is a 5 minute fix for someone that already knows the right part of the codebase. seems there's more than one local cache in the app. a manual refresh immediately after edit updates the rendering but doesn't purge/update the cache used by the in-app editor.

In T268956#6663277, @schoenbaechler wrote:

Looks good to me, moving it to QA signoff.

@schoenbaechler it's from this page I linked in the task description https://commons.wikimedia.org/wiki/Template:Potd/2020-11-30_(en)

see also T268334: Cut off content within “In the news” card

I'm the only editor to that article in more than 48 hrs and following the instructions to refresh and try again doesn't help.

still broken 2.7.50334-beta-2020-11-02

to clarify none of this is on mdot. it's all desktop site just switching local user agent between default and desktop modes. not off the edge of the screen but off the edge of the citoid popup. I think partly maybe depends on the length of that bare URL.

what does standard libraries mean? SUL is for sure not directly possible, I was speculating about something like oauth against mediawiki.org prod.

xyz was sent using exactly the method you request. this has been a feature of our phabricator literally forever (since before it was a production service).

thanks for triaging.

well I don't mind rushing and no one else is bothering to triage at all.

for the record that latest test was [Edit=Require extended confirmed access] (indefinite) [Move=Require administrator access] (indefinite) since 2016-05-07

this is still an issue with Android App 2.1.144-beta-2016-05-09

Please leave this open until actually fixed.

WMF has several django apps already configured in puppet. (apparently graphite, sentry, and servermon. based on a simple grep. https://phabricator.wikimedia.org/diffusion/OPUP/browse/production/?grep=django )

jenkins merge failed so it probably needs a rebase.

In T85528#1964958, @jeremyb wrote:

why was this added to Wikipedia-iOS-App-Development?

why was this added to Wikipedia-iOS-App-Development?

I was able to edit without logging out/back in and it was attributed to me not IP. (the first preview showed IP but then was username after save and when I went back and made a second preview then ~~~~ showed username that time) Thanks!