Jump to: navigation, search

About this board

Previous discussion was archived at Talk:VisualEditor/Archive 1 on 2015-09-01.

Why isn't the VE running on talk pages anywhere?

Summary last edited by Sänger 21:00, 13 July 2016 1 year ago

There won't be any real answer at any time.

Sänger (talkcontribs)

Instead of the normal editing possibilities, on talk pages we are restricted to either only use the wikitext editor, or to this Flow environment, with its massive restrictions on next to everything. Why is the VE not enabled anywhere on talk pages?

Jdforrester (WMF) (talkcontribs)

Hi there. This question comes up a bunch, and has been answered at length a few times before, but I can't find any of those right now, sorry.

The short answer is that VE is a content editor, and is designed to make writing (long-form) content. In dozens of ways, we've optimised it around writing articles for Wikipedia, Wikivoyage and other wikis. The use cases of a semi-free-form-but-with-odd-rules discussion box are fundamentally incompatible. Providing VE for talk pages would mean making massive compromises both on being a good content editor and on being a good discussion editor. It's an anti-pattern, and it's not going to happen.

I know you have a personal animus with Flow, and that's unfortunate, but it's the option available if you think talk pages don't work well (with which I would agree).

Sänger (talkcontribs)

It's just about an editor, the difference between a plain text editor and a wysiwyg editor. There shouldn't be any big difference between editing a text on either the front or the back side of any page. A talk page is as well nothing much different to any other content page, only the content is a bit different.

It's like the difference between old fashioned WordPerfect and the wysiwyg version of the same program. Some prefer the classic mode, some the ve, but the resulting page is just the same.

Sänger (talkcontribs)

Why was this definitely not solved question closed? Your answer was just a straw man, not a real one. It's everything but closed.

Jdforrester (WMF) (talkcontribs)

Sorry, I didn't see a question in your response, just implicit accusations of bad faith and incompetence. :-) If you could re-write one that'd be great, otherwise there's nothing more to say.

Sänger (talkcontribs)

Why isn't the VE running on talk pages?

VE is a text editor, and thus should be fully capable of editing on any page, at least simple talk pages.

Jdforrester (WMF) (talkcontribs)
VE is a text editor,

As I explained, this is not true.

Sänger (talkcontribs)

To just quote the first sentence from the other side:
The VisualEditor project aims to create a reliable rich-text editor for MediaWiki.
So why do I have the impression, that either the other side is plain wrong or your "argument" is just a straw man?

Whatamidoing (WMF) (talkcontribs)

The visual editor cannot (abuse HTML definition list formatting to) fake the indentation of paragraphs. Therefore, you are likely to find using it in a talk-page discussion to be frustrating at this time.

Sänger (talkcontribs)

...yet. An editor that's capable of editing tables, using templates, setting references etc.pp. is incapable of abusing colons for indentation? Should I really believe this?

Why do I think of a nice idea to push the software pet project that's not as much liked by the community as by the WMFers?

Whatamidoing (WMF) (talkcontribs)

I think you may have to wait until phab:T6521 is resolved.

BTW, there are a few wikis that have the visual editor enabled in the Project: namespace, and which also have some discussions in that namespace (e.g., ), and we hear complaints about problems on those pages. I don't think that it would be a good idea to expand the use of the visual editor on such pages at this time.

Sänger (talkcontribs)

You insist without any real merit, that a wikipage is not the same as a wikipage. In principle all wikipages behave in absolutely the same manner, they were edited with exactly the same editor up to some time ago, when you a) tried to get so-called structured discussions, first with Liquid Threads, something that failed, now with a bit different layout system Flow, something that as well is stuck in limbo. But if you discount these, the article page uses the same syntax as the talk page, the user page uses exactly the same syntax as the talk page, with one of two available editors the can be edited in exactly the same way as everything else in the wikiverse. With the other one, the VE, you claim that these exactly same pages are magically somehow different, and one of them can't be edited in a wysiwyg-way.

BTW: Using colons to indent, instead of some software hack created by those many devs paid by content creators and talk page users, is frustrating as well, but you choose to ignore this for quite some time and preferred to create shiny new bling instead of boring maintenance. That's at the core of this, not the proclaimed, but not existing, differences between those pages. And the phab is just a strawman as well, if you mange to get templates programmed somehow, the indentation problem should be non-existing. Unles you deliberately choose not to do something about it, to keep this strawman alive.

MZMcBride (talkcontribs)

Hmmm. Does "support VisualEditor on talk pages" have an associated Phabricator Maniphest task?

I tend to agree with Sänger, though I'd perhaps phrase it this way: VisualEditor should work with all regular (non-Special) wiki pages. This includes user pages, talk pages, portal pages, pages in the MediaWiki namespace, etc. It's an extensible editor that we've already installed and committed to supporting. We've seen time and again that the arbitrary distinction put up between VisualEditor support by namespace is confusing and annoying to users.

I think there are talks about unifying the wikitext and VisualEditor editors. Eliminating or masking the difference between the two or more editors that we have may somewhat neatly resolve this issue.

Whatamidoing (WMF) (talkcontribs)

To see the result of these "talks", go to Special:Preferences#mw-prefsection-betafeatures and enable the "new wikitext mode" beta feature.

NB that it's not really about "unifying the [old] wikitext and VisualEditor editors". This will not merge the code for EditPage.php or Extension:WikiEditor with Extension:VisualEditor. The only thing that's being unified is the user experience, i.e., the user gets VisualEditor's black-and-white toolbar and VisualEditor's built-in tools (such as pasting a URL to a Wikipedia page and getting an internal wikilink instead of an external link) everywhere. There will still not be any visual mode on the talk pages.

Sänger (talkcontribs)

And there is still no believable reason given, why a wikipage is not a wikipage. It's just futile justification lyricism for not wanting to do anything against Flow.

Sänger (talkcontribs)

Short update:

In the current Community Tech survey the VE is used in discussions, so the whole "argument" with the non-suitability was proven as a straw-man by the WMF on one of its own pages, yet they still insist that a wikipage is not a wikipage.

See this archived proposal as an example (and as another attempt to stifle any discussion about VE on talkpages for pure political reasons). Grüße vom Sänger ♫(Reden) 12:26, 3 December 2017 (UTC)

Reply to "Why isn't the VE running on talk pages anywhere?"

Error saving data to server: Empty server response

5 (talkcontribs)

Error saving data to server: Empty server response


Please help! we have installed new visual editor and parsoid on our wiki, and all user have the problem with articel edititing. when articel have a external link, he cant be saved by users, but not by admins.

How we can enable editing with external links for all default users?


# The following permissions were set based on your choice in the installer
$wgGroupPermissions['*']['createaccount'] = false; // Registrierung verbieten
$wgGroupPermissions['*']['edit'] = false; // Bearbeitung verbieten
$wgGroupPermissions['*']['read'] = false; // Lesezugriff verbieten
$wgGroupPermissions['*']['createpage'] = false; // Schreibzugriff verbieten
$wgGroupPermissions['*']['upload'] = false; // Dateien hochladen verbieten
$wgGroupPermissions['*']['reupload-shared'] = false; // Ersetzen von bestehenden Dateien verbieten
$wgGroupPermissions['*']['upload_by_url'] =false; // Hochladen durch eingeben einer neuen URL verbieten
$wgGroupPermissions['*']['autocreateaccount'] = true;

$wgVirtualRestConfig['modules']['parsoid'] = array(
  // URL to the Parsoid instance
  // Use port 8142 if you use the Debian package
  'url' => '',
  // Parsoid "domain", see below (optional)
'domain' => '',
  // Parsoid "prefix", see below (optional)
// 'prefix' => 'localhost'

require_once "$IP/extensions/VisualEditor/VisualEditor.php";
$wgDefaultUserOptions['visualeditor-enable'] = 1;
$wgHiddenPrefs[] = 'visualeditor-enable';
$wgDefaultUserOptions['visualeditor-enable-experimental'] = 1;
$wgDefaultUserOptions['visualeditor-editor'] = "visualeditor";
$wgSessionsInObjectCache = true;
$wgVirtualRestConfig['modules']['parsoid']['forwardCookies'] = true;

Best regards, Vadim

Whatamidoing (WMF) (talkcontribs)

I'm sorry, I can't really help you. But I saw that error message the other day, when my internet connection dropped for a few minutes.

Can your regular editors save a page (with a URL) when they use other editing tools? (talkcontribs)

Hi! Yes, standard mediawiki editor can save a page with a URL (talkcontribs)


following settings in Localsettings.php have fixed the problem:

$wgGroupPermissions['emailconfirmed']['skipcaptcha'] = true;

$ceAllowConfirmedEmail = true;

hopefully, it will not bring any new problems now

Whatamidoing (WMF) (talkcontribs)

Thanks for posting the solution! I hope that it helps someone else.

Reply to "Error saving data to server: Empty server response"

Unable to stop the editor from loading while offline

Summary by
Kaartic (talkcontribs)

Once when I loaded a page while I'm online an went offline to read the page, I accidentally hit the 'Edit' button. This started the progress bar for the editor and obviously it got stuck after sometime as it was unable to connect to the network. It was frustrating for me as I couldn't cancel the page load and thus couldn't read the article that I loaded until I got the error dialog.

It would be nice if there was a way to stop the editor from loading while it's being loaded. This would help the readers to proceed with what they were reading quickly when they accidentally hit the 'Edit' button instead of waiting for the editor to load and then cancel the edit operation.

Note: This a copy of a similar topic at the Visual Wikitext editor.

Elitre (WMF) (talkcontribs)

Isn't "Back" (or its equivalent on mobile) that button? Doesn't the requested article stay in cache, so you don't need to reconnect to read it?

Kaartic (talkcontribs)

I'm not sure what you mean by a "Back" button but I don't see any while the visual editor is loading. Here's a screen shot,

Screen shot of visual editor; loading

In case you are referring to the browser's back button, it had no effect on the loading of the visual editor (possibly due to the caching!). IOW, hitting the "Back" button on the browser and hitting "Forward" button didn't cancel the loading of the visual editor. (talkcontribs)

If you're online pressing ESC (or the equivalent in your operating system /platform) will cancel the loading. If you're offline, allowing it to pseudo-load, then pressing retry and then ESC multiple times seems to also cancel the loading.

Also this isn't specific to visualeditor. All other editors behave in a similar fashion, in fact they show the offline message even faster. One problem is that VisualEditor re-uses the same page, so after it loads if one tries to go back, they hit the same "page" or editor again.

Detecting offline mode is a very tricky thing. There might be temporary network lapses or someone might be using a local proxy that contains a cache of the page, or one of a million other possibilities when it comes to networks.

Chrome had (or has?) to have a more aggressive caching configuration option that could be activated and would store such older pages. Generally speaking though, if one wants to see stuff offline, then saving the page is the best option, even if offline it can retrieve it from the cache and create a copy.

Reply to "Unable to stop the editor from loading while offline"

VE can't load with http 500 error in Browser

2 (talkcontribs)

mediawiki version: 1.28.0

nodejs version : v0.10.25

parsoid version i don't know, i have install it with Parsoid/Setup help. and it's work. I can access the http://myhost:8142 and get the right page in Browser.

The question is when i add "wfLoadExtension( 'VisualEditor' );" in LocalSettings.php, i will receive the http 500 error when i access my wiki in browser. when i comment "wfLoadExtension( 'VisualEditor' );" in LocalSettings.php, i can access my wiki normally.

I don't know where configuration is wrong, i'm following the step with Extension:VisualEditor.

I'm sure i have input "git submodule update --init" after clone VE.

Below is LocalSettings.php additional configuration:

# End of automatically generated settings.

# Add more configuration options below.

wfLoadExtension( 'VisualEditor' );

// Enable by default for everybody

$wgDefaultUserOptions['visualeditor-enable'] = 1;

// Optional: Set VisualEditor as the default for anonymous users

// otherwise they will have to switch to VE

// $wgDefaultUserOptions['visualeditor-editor'] = "visualeditor";

// Don't allow users to disable it

$wgHiddenPrefs[] = 'visualeditor-enable';

// OPTIONAL: Enable VisualEditor's experimental code features

#$wgDefaultUserOptions['visualeditor-enable-experimental'] = 1;

$wgVisualEditorAvailableNamespaces = [

"0" => true,

"2" => true,

"102" => true,

"_merge_strategy" => "array_plus"


$wgVirtualRestConfig['modules']['parsoid'] = array(

// URL to the Parsoid instance

// Use port 8142 if you use the Debian package

'url' => 'http://localhost:8142',

// Parsoid "domain", see below (optional)

'domain' => 'localhost'

// Parsoid "prefix", see below (optional)

#'prefix' => 'localhost'


Below is parsoid partial configuration:(i'm using config.yaml as configuration file)


- module: ../src/lib/index.js

entrypoint: apiServiceWorker


# For backwards compatibility, and to continue to support non-static

# configs for the time being, optionally provide a path to a

# localsettings.js file.  See localsettings.example.js

#localsettings: ./localsettings.js

# Set your own user-agent string

# Otherwise, defaults to:

#   'Parsoid/<current-version-defined-in-package.json>'

#userAgent: 'My-User-Agent-String'

# Configure Parsoid to point to your MediaWiki instances.


- # This is the only required parameter,

# the URL of you MediaWiki API endpoint.

uri: 'http://localhost/wiki/api.php'

# The "domain" is used for communication with Visual Editor

# and RESTBase.  It defaults to the hostname portion of

# the `uri` property below, but you can manually set it

# to an arbitrary string.

domain: 'localhost'  # optional

# To specify a proxy (or proxy headers) specific to this prefix

# (which overrides defaultAPIProxyURI). Alternatively, set `proxy`

# to `null` to override and force no proxying when a default proxy

# has been set.


#    uri: 'http://my.proxy:1234/'

#    headers:  # optional

thanks. (talkcontribs)

Do you install Restbase service

Reply to "VE can't load with http 500 error in Browser"

Display name function does not show any effect

Lanthanis (talkcontribs)

MW 1.27

VE 0.1.0

Hi @Whatamidoing (WMF)

if I want to set a display name for an article or a category it does not show any effect. Furthermore I didn't find any references of this function in the manual.

I think the function should display "VisualEditor" instead of the standard "Category:VisualEditor" for example, right ?

Whatamidoing (WMF) (talkcontribs)

Are you talking about {{DISPLAYTITLE}}? It's used to change the formatting of page titles, such as adding italics to the title of the book at

Lanthanis (talkcontribs)

I'm talking about this function "Anzeigetitel"

Whatamidoing (WMF) (talkcontribs)

The current version is 1.30.0-wmf.10 (cf8ce2d) for MediaWiki and 0.1.0 (c2dab36) for VisualEditor. It looks like you're running an older version. I believe that this problem will be solved if you upgrade to any newer version (anything in the last six months).

Reply to "Display name function does not show any effect" (talkcontribs)

Hi all,

When I open Media settings (Insert -> Media) and type in "L" it says nothing found. If I type in "L3" it shows the correct PDF file. Is there a way to convince the wiki to list all the media starting with letter [a-z] or show all the available media? Because not every user knows exactly what he has to search for.

If I test with other Picture Database ($wgUseInstantCommons = true;) it works with only typing in one letter.

MediaWiki Version: 1.28.0

Whatamidoing (WMF) (talkcontribs)

Well, that works on this wiki (after a delay). What happens in the regular Special:Search box, if you type in File:L? Does it list the files that you expect?

Lanthanis (talkcontribs)

If you are not using CirrusSearch or another fulltext search engine, you have to use search parameter like "L3" or ~L

Reply to "Media settings search is incomplete" (talkcontribs)

Hi, we have one very huge Page in one of our customers mediawiki. Editing this page will cause an alert windows after about 30 seconds witch says: "http". Not more. The Parsoid log says: ...started parsing... and then ...completed parsing in 37661 ms... so im guessing on a timeout problem. All other Pages load fast and fine. Is there a way to increase timeout? Thank you for every help and hint :-)

Reply to "Timeout in VisualEditor"

Parsoid crashes when processing articles with codeblocks

Summary by SSastry (WMF)
Satttarov (talkcontribs)

Hello, folks! When I create an article in our private wiki with more then four codeblocks, save it and try to edit later, those codeblocks aren't appear in editor. And when I close the editor, page freezes for about a minute then pass. But if I try to launch editor on this page again it crashes with error "HTTP 0" on parsoid logs I see this:

[warning][testwiki/Тестовая_страница] non-200 response: 504 <html>
<head><title>504 Gateway Time-out</title></head>
<body bgcolor="white">
<center><h1>504 Gateway Time-out</h1></center>
[error][testwiki/Тестовая_страница] Batch request failure for "f1c423e85011b3500256b9b5e736d7a0": 504
Error: Batch request failure for "f1c423e85011b3500256b9b5e736d7a0": 504
at BatchRequest.ApiRequest._requestCB (/usr/lib/parsoid/src/lib/mw/ApiRequest.js:421:11)
at Request.self.callback (/usr/lib/parsoid/node_modules/request/request.js:198:22)
at Request.emit (events.js:98:17)
at Request.<anonymous> (/usr/lib/parsoid/node_modules/request/request.js:1063:14)
at Request.emit (events.js:117:20)
at IncomingMessage.<anonymous> (/usr/lib/parsoid/node_modules/request/request.js:1009:12)
at IncomingMessage.emit (events.js:117:20)
at _stream_readable.js:929:16
at process._tickCallback (node.js:419:13)
[warning][testwiki/Тестовая_страница] non-200 response: 504 <html>
<head><title>504 Gateway Time-out</title></head>
<body bgcolor="white">
<center><h1>504 Gateway Time-out</h1></center>

Somebody encountered the same problem? Please help, this error completely defeats the purpose of our wiki.

Whatamidoing (WMF) (talkcontribs)

@SSastry (WMF), have you seen anything like this before?

SSastry (WMF) (talkcontribs)

I haven't seen this before ... but, can you paste the contents of that page for us to inspect? Looks like mediawiki is not able to provide information back to Parsoid ... either it is taking too long and timing out, or there is some other error that is causing this on the mediawiki end.

Satttarov (talkcontribs)

For the sake of testing I'm using these blocks. It doesn't matter what those blocks contain, if there is more than four blocks, Parsoid hangs as I described before.

<syntaxhighlight lang="bash">



Thanks in advance.

Arlolra (talkcontribs)

At first glance, that looks like a deadlock.

Do things get worse when you remove batching?

parsoidConfig.useBatchAPI = false;

Is this specific to the syntaxhighlight extension? What if you tried with <source>?

Arlolra (talkcontribs)

Sorry, <source> wasn't a good test case. I wanted an extension tag not provided by the same extension. Try <gallery>.

Arlolra (talkcontribs)

This is being fixed in

Jeblad (talkcontribs)

There should be a VisualEditor/Recipes where some common problems and solutions are described step by step. The page as it is now is just an example, with a single entry. Feel free to move the page if it is better suited on other locations.

Some additional background on Import of preformatted templates into an article.

Reply to "Receipes"

Images (edit-mode) not shown with https-wiki

Summary by Waanders
Waanders (talkcontribs)

Hi all,

We've a problem when using the Visual Editor with a https-protected wiki (MW version 1.27.1): images in a wikipage aren't displayed when editing a page where this does happen in Read mode.

View source of the page contains:

<a href="/wiki/index.php/File:MyImage.jpg" class="image"><img alt="MyImage.jpg" src="/images/5/5a/MyImage.jpg" width="208" height="199" />

Console of the browser gives this error message: "GET https://localhost/images/5/5a/MyImage.jpg net::ERR_CONNECTION_REFUSED".

How can I fix this problem?

Regards, Jethro