I suspect I broke this by fixing T219457 – if you had new wikitext editor enabled, such links would open the visual editor's HTML in the wikitext editor, which was crazy.

If the visual editor is expected to be available in the project namespace ("Wikipedia"), perhaps it would be better to just enable it there? It is enabled on other wikis, e.g. pl.wp.

Some wikis have talk pages in their project namespaces therefore is wouldn't be a good idea to enable the visual editor in the whole Wikipedia namespace.

Oh, yeah, there are thousands of talks; almost 5000 daily candidates for deletion, and village pumps and various help desks and some 10.000 archives of talks.

A bit sophisticated approach: Imagine current namespace is not permitting VE launching but page is linked to Wikidata Q3938 then skip namespace block. Naturally this goes for WMF farm only, but external customers are simply not connected. Tough config issue anyway.

Since talk archives are involved it does not help to check add section property to distinguish talk pages.

I would propose that a systemmessage in MediaWiki Namespace gets created, where admins can list pages, where users are allowed to use VE, even if the namespace is "blacklisted", so kind of VE whitelist. That would solve the problem, and create a flexible solution.

And if you impkement such a whitelist, we can also implement a blacklist to temporary list pages there where the editor breaks them for example.

Blacklisting pageids could be a hard job, since there are more than 10.000 pages in talk structure on German Wikipedia project namespace.

Whitelisting by individual decision per Wiki is better, but only a few dozens large Wikis will have sysops who are able to maintain that.

The suggested approach to configure an array of Wikidata item numbers [3938] is much easier in the long run, but requires some implemention efforts. If namespace does not grant and such array is set in installation config and a Wikidata ID is assigned to current page and that number is one of the elements is matching then VE is permitted. In addition to project:sandbox some other globally used test pages may be appended later. Even a small Wiki can benefit easily when anyone is assigning their sandbox on Wikidata.

In T221892#5138827, @matmarex wrote:

I suspect I broke this by fixing T219457 – if you had new wikitext editor enabled, such links would open the visual editor's HTML in the wikitext editor, which was crazy.

If the visual editor is expected to be available in the project namespace ("Wikipedia"), perhaps it would be better to just enable it there? It is enabled on other wikis, e.g. pl.wp.

In German-language Wikipedia, where this issue was brought up, there is one single page in project namespace where the visual editor used to be available, and it should remain restricted to that single page: "Wikipedia:Spielwiese". That's German Wikipedia's universal "sandbox" for all users to try out things. All other project namespace pages shouldn't have the VE enabled.

I don't want us to end up implementing a complex system of whitelists and blacklists, also because it would be a maintenance burden for us, but mostly because it would make on-wiki configuration of VE even harder to understand.

So the problem we're trying to solve, and that was previously solved by manually constructing a 'veaction' link, is to make the sandbox page editable in VE. I definitely agree that it should be possible.

I kind of like the idea of whitelisting Wikidata items… Seems like a practical solution and not too complex.

For the whitelist there is already T52883: VisualEditor: Provide some way of enabling VE on arbitrary pages for all users (e.g. non-ns0 sandboxes), a blacklist was previously declined in T54141: VisualEditor: Provide a mechanism to disable VisualEditor on a given page (to be used if it corrupts said page).
The "real" solution of course would be to enable Flow, use it for all pages in project namespace that have discussions on them, and then enable VE for everything else, (i.e. the same configuration as on mediawiki.org) but unfortunately that isn't going to happen.

We talked about this within the team during a planning meeting. We're reluctant, but not opposed :), to implementing that whitelist or allowing the parameter again.

But another idea was proposed – why not just move the sandbox page to a namespace where VE is enabled? The 'Help' namespace seemed like a good candidate to us. And from a quick review of https://www.wikidata.org/wiki/Q3938#sitelinks-wikipedia, it seems that the sandbox is already in the 'Help' namespace on French (fr) and Finnish (fi) Wikipedias, so it might be reasonable for English, German and other languages too.

Do you think that could be an option?

That isn't any help to the VEFriendly template which is specifically there to assist VE-only people edit pages on which the VE is not routinely available but that they need to edit. For example, the State Library of Queensland are very involved with 1Lib1Ref contributing over 1000 edits in the past couple of years (world leaders in both years). They are gearing up for their 2019 1Lib1Ref (which starts 15 May ) and discovered to their horror that they could no long edit their [[WP:SLQ]] pages (which have the VEFriendly template). Nor does it help them talk to me on-wiki as their support person as my User Talk page also uses VEFriendly template.

We have the VE for a reason to make it easier to attract and retain new contributors. I have used it successfully to attract and retain a library-full of people. Isn't this what we are supposed to be doing with GLAM partners? They run projects and need to use the Wikipedia name space.

Solving the Sandbox problem is irrelevant to them, they edit real articles in 1Lib1Ref.

In T221892#5168211, @matmarex wrote:

But another idea was proposed – why not just move the sandbox page to a namespace where VE is enabled? The 'Help' namespace seemed like a good candidate to us.
Do you think that could be an option?

Strong oppose on unauthorized behalf of German Wikipedia.

• We do not want to ask newcomers to modify in the Help: namespace.
• Many pages in the Help: namespace needed to be protected already, partially editing possible only by senior users (reviewers), since by accident new users edit, replace, move manual pages. Actually we want to grant experienced IP access to such pages, fixing typos or improving readability, but most frequented help pages already need protection.
• Search results in Help: shall not get polluted by temporary experiments. We are still working to move out non-manual pages from a decade ago.

It is confusing to have one sandbox as for 15 years in project namespace for source code editing, and another one for VE trials in another one.

• There are almost 10.000 subject pages in project namespace, and search results will show for every keyword a match on a 5 years old debate on page deletion or village pump. Search results of whatever do no harm.

The sandbox page is mainly targetting to new and unexperienced users. Sometimes an old school author might use it for a test of new syntax, but those often use their own user page or do not publish the test edit. For new users it is most dangerous to mislead them and permit to edit in namespaces they are not supposed to touch, just as a hack to overcome a recent regression in VE start procedure. Especially new users need clear advice and clear statements. Project namespace does contain help desks and village pump, help namespace is for manual pages only. I do not occupy Manual: or API: on mw: project as playground for first beginners.

WRT to the remark to open the entire project namespace for VE: There are archived discussions in talk page format for 15 years, on deleting pages, help desks and various village pumps, and those >10.000 pages will not be converted into Flow.

Thank you for the replies.

@Kerry_Raymond I was not aware that editors relied on this behavior on other pages than the sandbox, nor that there is a deadline on this task.

@PerfektesChaos Thanks, these are a few good points. (Regarding your last point: As far as I know nothing bad would happen if you were to edit an archived discussion page using VE. It lacks tools for e.g. indentation so it is poor for actually leaving messages on discussion pages, but it will not break existing content.)

I guess we should just bring back veaction=edit as a supported way to open VE on pages which it can edit (e.g. not .js pages), but where it is not shown in the navigation tabs.

Change 509144 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@master] ve.init.mw.DesktopArticleTarget.init: Allow veaction=edit to override namespace settings

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

QA notes:

• veaction=edit must not open VE if the user disabled it in their preferences, and it must not open VE on non-wikitext pages (e.g. .js pages)
• veaction=editsource must not open NWE if the user did not enable it in their preferences, and it must not open NWE on non-wikitext pages (e.g. .js pages)
• Issues described on T219457 must not reappear

The previous behavior was nice, and was actually used for editing Project namespace, as the reasons not to do it in some projects are the exception and not the rule. For example in elwiki there is only a handful of Project: pages that are actually used as talk pages. Article related discussions are done in Talk: subpages (always connected to the related article). Sandbox was already moved to Help: namespace so that newbies could press the actual tab that see in every article to open VE and not a made up button. So, some wikis would only need a blacklist to disable VE in some noticeboards etc. The majority of Project: pages (guidelines etc) have no problem to be edited by VE. I was doing it and like Kerry reports above we had hinted one of our glam fellows to use VE for everything and suddenly had to use to code.

I count 88 pages in elwiki:Help: (including 14 redirects), but 900 pages (including many redirects) just as top pages in dewiki:Help: which indicates that there is an intensive usage in one project and a more relaxed in another wiki, and there might be projects with almost no helpful page in Help: namespace.

The software is identical for all projects, and a solution needs to satisfy all requirements.
What might me feasible for one wiki does not necessarily work in others.

Like enwiki, dewiki has about 100 very actively used talk mode pages in project namespace, e.g. at least recent 7 days of nomination for deletion or 30 specific help desks on particular issues and 20 request pages on several business cases and a pile of project debates. Those have been introduced a decade before VE.

There might be wikis with no pages yet in Help: namespace and only a few project pages and no village pump nor help desks, at least not in project namespace. Those wikis are not affected by this suggestion nor by any namespace problem.

Change 509144 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] DesktopArticleTarget.init: Allow veaction=edit to override namespace settings

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

Change 510218 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@wmf/1.34.0-wmf.4] DesktopArticleTarget.init: Allow veaction=edit to override namespace settings

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

I'm taking @Kerry_Raymond's comment as a request to get this working again before 1Lib1Ref, and so I scheduled the patch to be deployed during the window tomorrow at 11:00 UTC: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20190515T1100. That's the soonest deployment window where I can be available.

(Note that ReleaseTaggerBot is wrong, and according to Gerrit, this change has actually made it into wmf.5, not just wmf.6. Thus we only need to backport to wmf.4.)

Change 510218 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@wmf/1.34.0-wmf.4] DesktopArticleTarget.init: Allow veaction=edit to override namespace settings

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

Mentioned in SAL (#wikimedia-operations) [2019-05-15T12:20:55Z] <lucaswerkmeister-wmde@deploy1001> Synchronized php-1.34.0-wmf.4/extensions/VisualEditor/: SWAT: [[gerrit:510217|VisualEditorHooks: Use isVisualAvailable() when changing tabs/editsections]] + [[gerrit:510218|DesktopArticleTarget.init: Allow veaction=edit to override namespace settings (T221892)]] (duration: 01m 15s)

Patches have been deployed after a small unplanned delay. veaction=edit should be working now again on Wikipedias and other projects.

Thank you!