Nope, it's actually missing from most of the underlying databases.

This is listed as a fullview in maintain-replicas config. I guess we just need to run the script to recreate it and mysql will see the new field... @chasemp?

In T154334#2908309, @Schnark wrote:

This works when you first press the TAB key 3 times.

Duplicate of T154217: Page blanked when editing a section after an edit conflict?

The current production deployment schedule can be found at https://www.mediawiki.org/wiki/MediaWiki_1.29/Roadmap
I think 1.29.0-wmf.7 on cswiki will likely be scheduled for January 4th, when it would receive code up to date as of January 2nd

When you say you weren't able to reproduce it, was that just due to not being able to arrange for an edit conflict? Or were the same steps taken without such an error/bug occurring?

in any case, I believe these are created by user (e.g., MediaWiki:Common.js) rather than MW code, so there's likely not much we can do on this side (VE isn't actually magic, it can't force everything else to become compatible)

However merely fixing that is probably sub-par. In the normal editor the page notice is part of the page. The tools in the page notice remain visible and easily accessible. In the New Wikitext Editor the page notice is displayed in a popup. [...]

If you want diff pages to redirect to mobile diffs when viewed on mobile devices, that doesn't seem to have much to do with VE. The VE behaviour here is expected. VE has no control over what is shown to readers after the edit is saved.

the production wikis use older code, I'm concerned with whether it's working on master (what beta runs)

The section header here appears to be a separate input rather than a surface. Maybe we can reuse some tricks from the ProofreadPage integration?

I just tested this on beta and with:

This doesn't make much sense, ultimately the link created and shown to users wouldn't change like that.

See also: T153959: The keyboard shortcut for previewing a page (ctrl-option-p) doesn't do anything on some browsers, T153958: In Firefox: using the keyboard shortcut to open the preview breaks, T153937: LOST WORK BUG: If you use the shortcut keyboard command to preview, you lose all your changes. - which seem to imply we have a shortcut for this already

What about reproducibility? Do you know the set of circumstances in which VE will get stuck like this?

That's a screenshot taken in the process of VE loading over the top of OWE. It didn't get stuck there, did it? If it did get stuck there, what was in the console?

Duplicate of T153367: Support "Preview page with this template" (TemplateSandbox) in the new wikitext editor?

I dug into this a bit, it looks like ve.ce.Surface.prototype.handleDataTransferItems always collapses to end. @Esanders?

Duplicate of T154020: Selected text is not replaced in new wikitext editor when a paste gets transformed?

Reproducible when you have VE configured to connect to RB directly from the client and it's not running. https://gerrit.wikimedia.org/r/#/c/327721/ seems to fix

This sounds like a dupe of T153445: 2017WE doesn't allow accessing the Translate extension by clicking on Edit source?

I still see modules/standard/templates/mail/exim4.minimal.labtest.erb and modules/puppetmaster/files/labtest.hiera.yaml in the puppet repository

For the toolbar button, maybe. It might make less sense for the keyboard detection of ~~~~ to prepend --

This would be due to https://gerrit.wikimedia.org/r/#/c/325949/7/modules/role/files/labs/db/views/maintain-meta_p.py where the matches = re.match("^(.*)(wik[it].*)", db) and lang = matches.group(1) were changed to lang = db[:2]

It looks like this gets disabled whenever VE decides what the Subject part is going to be, presumably so the user can't change it? Can you shed some light on this behaviour @Esanders?

I thought we already had this?

can we have more details for this please?

We have the v3 API enabled and have done for a while now. Do we need to move everything to using it, or is this done?

I think this was done by my previous puppet patch (https://gerrit.wikimedia.org/r/#/c/309008/). I think we should re-purpose it as 'remove reliance on ldap from shinkengen' and close it when my new puppet patch (https://gerrit.wikimedia.org/r/#/c/328611/) is done. @Andrew?

I'm doing it in https://gerrit.wikimedia.org/r/#/c/328611/ - the roles thing is not exactly an OpenStack API, but it is an API that lets you query puppet roles for a given instance. And you can now use the OpenStack APIs to get lists of projects and instances.

Basic API HTTP code check added in T42022

Basic check added in T42022. My question above should be pretty easy though.

I think I've fixed it - https://no.wikipedia.org/wiki/Spesial:Bidrag/Alex_Monk_(WMF)

(I've accidentally linked to this task in a few unrelated revisions - if you're here from no.wikipedia.org please see T153579 instead)

This'll be the same old broken editnotice code, I'll fix it when I'm not traveling. Do not delete it

This appears to happen when you:

• have VE set to remember last editor, and you used visual mode last time,
• try to action=edit,
• try to edit only a section
• try to edit a page that does not have visual mode enabled

Of course, the surface must be read-only, and all tools should be disabled, except perhaps the Find tool (which should only have the replace option disabled).

Randomly?

This is in console:
Uncaught Error: Incomplete trigger
ve.ui.TriggerRegistry.register @ ve.ui.TriggerRegistry.js?c7b3f:59
(anonymous function) @ ve.ui.MWSaveDialogAction.js?81b5a:94
(anonymous function) @ ve.ui.MWSaveDialogAction.js?81b5a:103

In T153472#2881530, @Jdforrester-WMF wrote:

Need to add uselang/useskin to the whitelist of params we don't freak out about?

can you provide the full steps you went through for #2?

What kind of things?

It looks like the behaviour that Chrome & FF exhibit when you disable cookies/localStorage will break this code (though I'm not sure what exactly causes "The operation is insecure" here), so let's assume that's the problem.

Sounds like T78550 to me

yeah but virt-libvirt-driver doesn't use strtime, does it? this file (nova/contex.py) would come from the nova package

So this file has a lot of /usr/lib/python2.7/dist-packages/nova/context.py:181: DeprecationWarning: Using function/method 'oslo_utils.timeutils.strtime()' is deprecated in version '1.6' and will be removed in a future version: use either datetime.datetime.isoformat() or datetime.datetime.strftime() instead self, 'timestamp') else None, spam
Does the same occur on labnet1001?

https://en.wikipedia.beta.wmflabs.org/api/rest_v1/page/html/User%3ARYasmeen_(WMF)/349201?redirect=false returns the HTTP 500

I think it's close, it just needs the tag field to always include WMF-NDA and I think the only way to do that right now is to lock it.

It's actually the Cite extension (not the Citoid one) detecting a reference, then trying to render it using VE code that seems to have an issue.

Not all NDA statuses are stored in Phabricator (though it would be good if Phabricator actually knew about all Phab-based and historical NDA signatures)

Yes. Let's open a separate task (maybe a subtask of T142815) for that?

@Andrew, what other things should be checked?

And yeah, we don't get notifications when you add tokens.

There's no regression, we resolved T55441 with a configuration variable that allows VE to load on action=edit in some cases, depending on a bunch of factors such as user preferences.

So, when you have a title+section link in the text box, and the suggestions show the page name that's currently in there, an extra suggestion should be added for the full title+current section? I think anything more than that would be T52881

Also I'd be careful about trying to invent such a field (to store whether a given revision was a revert). While you could do it for rollbacks, when you press the undo link you can still change the text to whatever you want. Other humans probably usually identify a revision as a revert by looking for the auto-generated (but entirely customisable) revision summary and trusting the user who made it. To find a simple single-revision revert you can compare the text/hash of your revision to the parent of the parent's text/hash, but beyond that things could get complicated.

IIRC we can detect them in Echo because we hook functions running outside the scope of a revision, but that sort of context is lost as soon as the request has finished being handled. There's no good (quick + trustworthy) way to guess whether a given revision ID was a revert, we don't store the information.

yep. specifically when you get a valid result back. caused by https://gerrit.wikimedia.org/r/#/c/324531/