Jump to: navigation, search

About this board

Edit description

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

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL

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

VE is garbling wikilinks as an drive-by-accident

Sänger (talkcontribs)

In this change it seems, the VE has changed some correct wikilinks to something not readable in normal edit mode. The IP probably only wanted to update the table (and messed it up, despite VE is supposed to be better in working with tables), it would never have made those other changes intentionally. As I can't start a phab, I report it here.

The paragraph on deWP where this popped up was this one.

Grüße vom Sänger ♫(Reden) 16:39, 9 January 2017 (UTC)

Sänger (talkcontribs)

Another Post in deWP where it popped up. Is there already a phab for this? Grüße vom Sänger ♫(Reden) 09:34, 26 March 2017 (UTC)

Reply to "VE is garbling wikilinks as an drive-by-accident"
Blazyb (talkcontribs)

I have a page on 9738 words and 73074 characters.

VE loads to 100% (pretty quickly) and stops there and nothing happens.

When I trimmed it down to around 50k characters it worked.

Sounds like there is a limitation somewhere that restricts this?

Any ideas?

Blazyb (talkcontribs)

Problem identified: It was a thumbnail that VisualEditor cannot parse. Why is that?

Blazyb (talkcontribs)

Error msg:

Whatamidoing (WMF) (talkcontribs)

Hi @Blazyb. Is this on a private wiki? Is the image present on the local wiki, or pulled from somewhere else?

Blazyb (talkcontribs)

Yes, this is a private wiki. The image is present on the local wiki yes, it is uploaded through the "Upload file" page. And checking the images folder I can see the files there. (talkcontribs)

Hey Blazyb did you found a solution?

My VE is loading as well but stops at 100%.. But only in Pages with Images

Maalab (talkcontribs)

I got the same error. Anyone have a solution?


Maalab (talkcontribs)

I have discovered something. Our Wiki is in french. If i put this in my LocalSettings.php, it work : $wgLanguageCode = "en";

I have not find a solution to use it in french.

Whatamidoing (WMF) (talkcontribs)

Maalab, can you please tell me more about your config? Also, what version are you using for VisualEditor, Parsoid, and MediaWiki?

I've named you in the bug report at Phab:T155447. You can provide more information on this page or directly in the Phabricator task.

Maalab (talkcontribs)

Thanks Whatamidoing for your reply. I will reply to both place so people can follow this case.

Our wiki is run on Ubuntu 14.04.5 LTS server. Parsoid version is 0.6.1, Mediawiki version is 1.27.1 LTS and VisualEditor version is 0.1.0.

This is a private Wiki, but i have change it to a public Wiki and the problem is still there.

We have some extensions, but i will not list them (except if you need it), because when i disable them all, this does not solve the problem.

I don't think the problem is related to parsoid, because, when i troubleshoot parsoid and show the page in problem (http://servername:8142/localhost/v3/page/html/Test/), everithing seems to work fine and there is no error un parsoid log.

The only way i get VisualEditor to work with a page that have an image aligment, is when i put the Wiki in english. Our Wiki is in french.

When i inspect the code with Chrome Debugger, i get this error : Uncaught TypeError: Cannot read property 'constructor' of null at Object.oo.cloneObject.

I have also report this bug at

Let me know if i can test something to help troubleshoot.

TitusiMW (talkcontribs)

@Maalab: how do you change public wiki to private wiki? I can only think of two ways --- going through installation process all over again or changing tons of permission variables one-by-one? Even there, I did not find any complete/exhaustive lists of permission variables that need to be set to flip a private wiki to public wiki and vice-versa.

Maalab (talkcontribs)

Maybe i am wrong about what is a private wiki, but for me, a private wiki is a wiki that require authentication to see pages. What we do to make a private wiki is remove permission to read ans edit page to all user and give those permission to know user :

$wgGroupPermissions['*']['createaccount'] = false;

$wgGroupPermissions['*']['read']          = false;

$wgGroupPermissions['*']['edit']          = false;

$wgGroupPermissions['*']['createpage']    = false;

$wgGroupPermissions['*']['createtalk']    = false;

$wgGroupPermissions['*']['writeapi']      = false;

$wgGroupPermissions['user']['edit'] = true;

$wgGroupPermissions['user']['createpage'] = true;

$wgGroupPermissions['user']['createtalk'] = true;

If i remove those line in my LocalSettings file, it is a public wiki and anyone can read or edit pages.

But like i said, maybe i am wrong about what is a private wiki.

Maalab (talkcontribs)

My problem have been solved. See

Reply to "VE not loading big pages"
Noé (talkcontribs)


Sorry if it is not the right place for this suggestion. During Wikimania 2016 we discussed about links between Wiktionary and Wikisource, and we reach a solution to tide them up. Well, in VisualEditor it is already possible to include media from Commons. So, may it be possible to include similarly Sentences from Wikiquote or Wikisource? I mean: you click on Insert citations put a word and tick languages and it request x project to give sentences that include the requested word.

It may be of some use for Wikipedia, but very useful for Wiktionary as definition came with attestation. If this tool can also format the references, it may permit to insert a sentence that contain a specific word in less than a second! Such an improvement!

I have no idea on how difficult it can be to develop that, but there is a need for it, and we can organize a vote to prove that if needed. I'll be happy to explain more precisely if my English is too cryptic, so feel free to react in any way.

Whatamidoing (WMF) (talkcontribs)

Noé, thanks for this note. I think I understand your goal. There may be more than one way to get example sentences.

I'm going to pass this idea along to User:Trizek (WMF). He knows more about Wiktionary than I do. I think he will also be interested in your idea. So, please feel free to post in French.

Trizek (WMF) (talkcontribs)

I know about Wiktionary thanks to Noé. :)

Insert Images is easy: you have one image and identified meta-data attached to (good job, dear Commonists).

If you want to pick a precise citation, that's not the case for Wiktionary or Wikisource. I think it will be much more complicated.

This said, please post your idea in details in French. Automated translation is pretty accurate.

Noé (talkcontribs)

L'idée en français alors. Actuellement, en cliquant sur "Insérer" dans l’Éditeur Visuel, il apparaît une liste d'options dont "Média" qui va rechercher sur Commons. La façon dont je vois les choses serait d'ajouter une option "Citations" qui ouvre une fenêtre de requête permettant d'interroger Wikisource et Wikinews, dans les versions linguistiques choisies. La requête sortirait des phrases contenant le mot cible, délimitées par des points (détectés automatiquement), et mettant en gras le mot clé. Il suffirait ensuite de cocher les citations adéquates puis de valider pour qu'elles s'insèrent avec la source bien formatée (modèle source sur le Wiktionnaire francophone). De cette manière, il serait plus simple de citer des projets libres que d'aller piocher sur Google Books...ce qui est la pratique actuelle. Je ne sais pas comment des développeurs pourraient faire ça, mais ça serait génial :)

Elitre (WMF) (talkcontribs)

Wow, I never thought about this, and yet it makes so much sense. I put it at, which can be improved if I misunderstood something. I think we should also ask the Search guys. Looks like a clever idea though.

Trizek (WMF) (talkcontribs)

Comme je disais en anglais, cela est facile à faire pour les images, car celles-ci sont uniques : une page = une image. Les méta-données qui y sont attachées sont facilement trouvables.

Pour des contenus textuels, c'est bien moins évident : ce sont des blocs de texte, dans lesquels il faut trouver telle ou telle phrase en fonction d'un contexte ou d'un auteur... C'est très difficile à mettre en place.

Je vais faire remonter l'idée. Aurais-tu quelques exemples concrets ?

Noé (talkcontribs)

Je réalise bien la différence, et entends que ça puisse être très difficile, mais parfois, il suffit de bien exprimer les problèmes les plus complexes pour que des solutions émergent. Et puis, il se trouvera peut-être quelqu'un qui piochera ce sujet lors d'un prochain hackathon, ça n'a pas forcément vocation a être développé par des employés de la Fondation. Il y a une fonction un peu comme ça dans Linguee, un outil en ligne que j'aime bien. Ça marche plus ou moins bien, mais ça fait le taf en général. Par exemple :

Sorry to write in French. Trizek wrote he considers this operation very complex and I assure I got it. I imagine describing properly a problem may help to solve it at some point. And maybe there will be someone that may like this challenge at the next Hackathon. As an example of this kind of feature, I can mention Linguee:

Whatamidoing (WMF) (talkcontribs)

You do not need to apologize for writing in French here. is not an English-only project. You are welcome to post in French.

Trizek (WMF) (talkcontribs)

(Mes collègues ont accès aux outils de traduction automatique qui transcrivent très bien le français :))

Linguee est un sacré projet, que j'utilise tous les jours (je l'avoue). J'ai du mal à voir le lien entre Linguee et l'idée proposée : Linguee cherche des relations entre phrases ayant le même sens. Tu souhaites avoir un outil de citations qui va chercher des éléments suivant un conteste général. Or, il y a une différence entre chercher la traduction de « Napoléon est mort à Sainte-Hélène » et chercher les citations qui se rapportent à son décès.

Peux-tu préciser ton exemple ?

Elitre (WMF) (talkcontribs)

I think he's just trying to show how he imagines the feature to be like, a search bar + snippets of results that you can choose from. I believe this is eventually about interwiki search, which is directly related to Goal 2, Objective 2 for Discovery this year: .

Noé (talkcontribs)

En fait, ce qui intéresse le Wiktionnaire, c'est d'avoir des attestations avec une orthographe identique. Chaque variation orthographique a droit à son entrée, et la requête serait donc uniquement sur une chaîne de caractère, sans prise en compte de la sémantique. C'est à dire que l'on ne recherche pas la définition de "pomme" mais seulement des phrases dans lesquelles il y aurait le mot "pomme" (et nous n'aurions pas "pommier" car nous n'en voulons pas). Est-ce que tu voyais autre chose ?

Trizek (WMF) (talkcontribs)

Je ne voyais pas grand chose :)

Elitre has raised an interesting possibility to work on that, with the Discovery team. @CKoerner (WMF) may be interested by that idea of having a way to quote citations from somewhere (search occurencies of "apple" to illustrate the Wiktionary with examples of sentences where "apple" is used).

VIGNERON (talkcontribs)


Intéressé et concerné, je me permet de laisser un message.

Du point de vue technique, il me semble que cela se découpe ainsi :

  • recherche du mot dans Wikisource
  • découpage de la phrase (ou la partie de la phrase)
  • insertion dans le Wiktionnaire
  • insertion des données bibliographiques

Le premier point me semble trivial.

Le second est déjà un peu plus compliqué (comment savoir où couper ? quelle section de la phrase est pertinente et fait sens ?) mais cela ne me semble pas insurmontable (Linguee le fait bien : pas de problèmes pour les phrases courtes qui sont les plus courantes).

Le troisième point dépend de ce que l'on attend ; une solution simple serait de faire un copier-coller, non ? Une véritable transclusion serait bien trop compliqué (nécessiterait de faire comme des Labeled Section Transclusion) et ne correspond pas au besoin.

J'avoue mon ignorance sur la complexité technique précise du quatrième point ; lesdites informations bibliographiques sont en cours de migration vers Wikidata mais un chantier délicat et un peu complexe (difficile à complètement automatiser, on a passé 2 jours à réfléchir à la question pendant Wikimania ; en gros, on a conclu qu'il valait mieux le faire doucement mais surement).

Noé (talkcontribs)


Merci Vigneron, et d'accord avec toi dans l'ensemble. Copier-coller une phrase est suffisant, pas besoin de transclusion. Idéalement, le Wiktionnaire francophone met en italique toute la phrase et en gras le mot vedette, mais chaque langue a un choix de mise en forme différent et il faudrait envisager des aménagements locaux. Pour les sources, l'ordre est éventuellement différent selon les langues, et ce ne sera peut-être pas si trivial. Dans fr.wikt nous les mettons dans un modèle source.

Trizek (WMF) (talkcontribs)

Donc avoir un moyen de mettre en avant le mot (surbrillance) dans un ensemble de phrases serait l'idée ?

Noé (talkcontribs)

Oui. Je n'avais pas vu la question avant, désolé. En réfléchissant à cette idée à nouveau, j'ai réalisé qu'il s'agissait simplement d'interroger une base textuelle de la même manière qu'avec le moteur de recherche standard, avec les différences pointées par Vigneron. Je mentionnais Linguee pour l'aspect visuel, la mise en avant de ce que l'on recherche. Pour les sources, j'imagine que ça ne sera pas forcément évident de récupérer le numéro de page.

Andrew Sheedy (talkcontribs)

Ce que l'on voudrait, c'est de pouvoir chercher dans Wikidata et Wikisource les occurrences des mots qu'on veut trouver, et puis de selectionner les phrases pertinentes (qui contiennent le mot cible) pour les incorporer dans l'entrée sur Wiktionnaire/Wiktionary. Dans l'entrée, on aimerait que le mot vedette soit en gras et que les données bibliographiques soient incluses dans la bonne ordre. Si c'est possible, il serait encore mieux d'insérer toutes ces données ainsi que le texte exemplaire dans une modèle, mais il suffirait peut-être de les copier-coller à peu près comme l'exemple suivant :

date de publication=date

auteur=nom de famille, prénom


lien vers la source=lien

ISBN=ISBN (s'il y en a un)

(d'autres renseignements pertinents)

texte=texte avec le mot vedette en gras

Désolé d'avoir écrit en français même si ma langue maternelle est l'anglais, mais je n'ai que rarement l'opportunité de l'écrire et j'aime pratiquer quand je peux. :) J'espère que tout est compréhensible. Sinon, je peux m'expliquer en anglais....

Et Noé, c'est une idée fantastique, en passant. :)

Elitre (WMF) (talkcontribs)

m:User:CKoerner (WMF)/Interwiki Searches is relevant IMHO.

Billinghurst (talkcontribs)

To follow on from @ VIGNERON

The Wikisources currently utilise Extension:Labeled Section Transclusion to mark a printed page into sections, which then enables the sections to be transcluded internally within our wikis. I could see that the ability to mark a section of text is of interest to a wiktionary, and may have some conceptual interest for citations. Consider if we had the ability to easily markup text with a section, and apply a distinctive label that identifies that it is a citation, the word, the language, then probably to the wikidata equivalent or hardlink to the wiki/word

Then whether the section component could be either transcluded or bot-generated extraction. It is at least in a state to be useful.


  • the ability to xwiki transclude has been long mentioned (there may be ye olde phabricator tickets), and never gained priority, so I see that the proof of concept can be of importance and useful, if that is the avenue that may be worth exploring
  • adding multiple sections to Wikisource works would not be problematic as long as we design a schema for unique or non-clashing nomenclature
  • one advantage of our section markup is that it also allows for overlapping sections (uniquely label both start and end tags)
  • transcluded pages in the Wikisources have page numbering as anchors, and that with these works being (well getting there) in Wikidata, that there is good scope for good citation, with that improving over time as edition data improves.
  • I know that I have found numbers of words in our older texts that have not been within the English Wiktionary, and have added them, though often without citation as the learning curve is steep for an occasional user, so any tool that could make that easier would definitely be beneficial
  • there would be hundreds or thousands of existing uses of the wikt: interwiki within works that could be queried
Reply to "Insert citations"

VE can't load with http 500 error in Browser

1 (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


Reply to "VE can't load with http 500 error in Browser"
Dvorapa (talkcontribs)

Screenshots on this page look like some older version of topbar, could someone update them?

Whatamidoing (WMF) (talkcontribs)

I don't see any screenshots on this page (i.e., VisualEditor). Can you give me a link to the page that you're talking about?

Reply to "Screenshots"

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

Summary last edited by Sänger 21:00, 13 July 2016 10 months 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.

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


We have now got VE up and running (on Mediawiki 1.27) but have some complex InfoBoxes that just don't look too good in VE. There is no requirement for my users to change these in VE as we use SMW properties and forms to control all Infooxes. Is there any way I can exclude portions of text or even sections from VisualEditor on a given page when VE is launched via the Edit button.

Any help appreciated.

Jongfeli (talkcontribs)

Please read: (talkcontribs)

Thank you for the response. Looks like we are out of luck. The __NOVISUALEDITOR__ seemed like a really good idea for full page VE disablement. To be honest I was hoping for one better and was hoping there was going to be <novisualeditor> </novisualeditor> set of tags, similar to the tag in concept. I will mention to the SMW team to see if they have any ideas. Once again thanks.



Reply to "Excluding Sections / Text From VE"