About this board

Post your feedback about using the visual editor.

If you have never provided feedback before, you can learn how to do it effectively. If you are reporting a problem directly on this page, please include your web browser, computer operating system, and wiki skin (usually Vector, sometimes Monobook). The feedback tool within the visual editor will include your user agent details instead.

You can use this page to tell the Wikimedia developers your ideas and issues about using the visual editor: this is the only feedback page actively monitored by WMF staff. The Contributors team welcomes your feedback and ideas, especially on user interface decisions and the priorities for adding new features. All comments are read, in any language, but personal replies are not guaranteed: the team will try and go through reports here at least once a week. Need more attention? Report directly in Phabricator. Please note that the Wikimedia Foundation does not provide support for installing VisualEditor on third-party wikis. Please report bugs involving Parsoid at Talk:Parsoid instead.

You may also want to read a guide to optimize the visual editor's experience on your site, which details work necessary on the community side (such as translating or setting up citation systems).

View open developer tasks Report a new bug in Phabricator Join the IRC channel Test the visual editor! (no account required)

Error contacting the Parsoid/RESTBase server (HTTP 404)

Costas Athan (talkcontribs)

I just updated to MediaWiki 1.35.0 yesterday.

Whenever I try to edit a page using the visual editor a progress bar starts to load and near the middle of the process the progress bar stops to fill itself and I get the message:

"Error contacting the Parsoid/RESTBase server (HTTP 404)"

I'm on shared hosting and I'm not running a RESTBase server, but from what I get it's not mandatory ( I have set $wgVisualEditorAllowLossySwitching=false, by the way.

The wiki also has $wgGroupPermissions['*']['edit'] = false.

Any ideas?

Duhuh54 (talkcontribs)

If you set $wgGroupPermissions['*']['read'] = true, it might work.

I am in the same situation except that I want a to have $wgGroupPermissions['*']['read'] = false

2001:16B8:107E:2C00:D5D:F0B1:B7F0:FB51 (talkcontribs)

The documentation of VisualEditor sadly is still lacking. I am having the same problem, but there are no hints on how to fix this.

Costas Athan (talkcontribs)
Kachkaev (talkcontribs)
Costas Athan (talkcontribs) (talkcontribs)

I am having the same issue.

This post was hidden by Costas Athan (history)
Awatkins1966 (talkcontribs)

Having the same problem. It seems that the option to make it a private wiki (need to login, University Intranet) causes it to get the error and fail:

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

The fix at the moment is to check via IP address, but that isn't going to work for me. Is there anything which I can add to LocalSettings.php which checks for Logged In user? (talkcontribs)

When mediawiki 1.35 (from debian buster-backports) is behind reverse proxy, visualeditor does not work correctly because it does not use $wgInternalServer but uses $wgServer to make internal rest requests which is wrong (internal traffic should not travel to external). Please fix visualeditor logic to use $wgInternalServer for internal api calls.

Amglez (talkcontribs)

I am having the same isue. With a peculiarity. As I upgraded my wiki to 1.35, the old pages can be edited with VisualEditor, no problem, the new ones give me this 404 error (parsoid etc.).

Costas Athan (talkcontribs)
UGOBOSS777 (talkcontribs)

Any news on this?

I still can't save using VisualEditor, always getting that "Error contacting the Parsoid/RESTBase server (HTTP 404)".

My wiki is private and I need to keep it this way. Any workaround?

Hcadby (talkcontribs)

Having the same issue, using Mediawiki 1.35.1 on redhat. anyone got any solutions. (talkcontribs)

same. (talkcontribs)

Same, I've been searching for 20 hours now without a solid fix for this T_T

Robertgarrigos (talkcontribs)

I had this same problem. I fixed it by redirecting the default apache virtual site to my wiki directory. (talkcontribs)

Same problem. I'm using private MediaWiki 1.35.1 with Nginx on Ubuntu server. (talkcontribs)

Same, Ubuntu and Nginx. (talkcontribs)

I get this error strictly when editing a page whose name contains a slash or other problematic character.

Ruut (talkcontribs)

Me too, I use slashes because of the mediawiki's subpages feature. Pages which have a slash give the error. All other pages work fine.

EelcoJD (talkcontribs)
Awatkins1966 (talkcontribs)

I had hopes it would work, but no.

Clarify I have:

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

$wgNamespacesWithSubpages was not set at all, but I added it "$wgNamespacesWithSubpages[NS_MAIN] = true;" but no difference.


<VirtualHost ....>

AllowEncodedSlashes NoDecode

Could it be related that wgNamespacesWithSubpages was not set?

Will have another play to double check. Has anyone else got it working?


Awatkins1966 (talkcontribs)

Well, I moved the wiki to another system and it does work so it looks like "AllowEncodedSlashes NoDecode" may solve the problem. Guess my real site has some other coding which is messing it up. I don't think it is in apache.conf files so will have a closer look at any .htaccess files which may be read...

Awatkins1966 (talkcontribs)

Not seeing anything which could be change the "AllowEncodedSlashes" option. Our web server is behind a load balancer is there any chance that may be it? Is there away of test if AllowEncodedSlashes is working?

Awatkins1966 (talkcontribs)

Got it working...

I decided to start fro scratch building a new website and after a waste of a day. I spotted the problem. Yes you need "AllowEncodedSlashes NoDecode" but you also need the php ""

Since I like to keep our external web server as secure I possible I disables curl a long time ago, which is fine except VisualEditor seems to require it..

Thanks for all your help...

Asphorm (talkcontribs)

[Solved in my case] For those who have still problems with the Parsoid:

I have recognized that the Visual Editor may have problems with short urls. If I set the variable "$wgArticlePath" properly, the Visual Editor didn't work. For this reason I have developed a concept to activate short urls for standard users (read-only) and to use full urls for users which may work with the Visual Editor.

Hope it helps somebody!

GianniFabbris (talkcontribs)

Thanks Asphorm .... ken you explay: "to activate short urls for standard users (read-only) and to use full urls for users which may work with the Visual Editor." ... How, please?

Pawel Niemczuk (talkcontribs)

Hi, @Asphorm:. That's exactly why I'm here now - short URL's and VE. Could you pls be as kind as to explain your solution more accurately? Thanx in advance! Pawel Niemczuk (talk) 02:40, 5 April 2021 (UTC)

Freibeuter10 (talkcontribs)

What if my web host service only runs Apache2 2.4 which has no NoDecode option (see 2.4/mod/core.html#AllowEncodedSlashes).

Arunzzz (talkcontribs)

I had the same error. And I have noticed the error occurs only when the $wgScriptPath variable have a value

Anthrazit68 (talkcontribs)

I've an issue with a specific page where this error occured.

The reason was that there was a forward slash (/) in the name of the page, the visual editor didn't like that. After changing the name of the page, the page could be edited again. (talkcontribs)

Witam, po instalacji wiki na serwerze również wyświetla mi komunikat przy próbie edycji danej strony, tj: Error contacting the Parsoid/RESTBase server (HTTP 404), przy tworzeniu nowej strony na wstępie edytor działa. (talkcontribs)

The error occurs after including a template once. means if the page uses or has used a template (doesn't matter how I included: subst:, template:), I can't switch to the VE anymore.

Not using templates no error

Ciencia Al Poder (talkcontribs)

Your issue with templates may be caused by mod_security, in case it detects template syntax as something sneaky.

See errors and symptoms. (talkcontribs)

Gracias, good advice, i will try

Rp (talkcontribs)

I'm not sure whether this is the same issue, but we've had to exempt Parsoid from access restrictions in LocalSettings.php. In our case, it looks like this:

function client_is_parsoid() {
  return ($_SERVER['REMOTE_ADDR'] ?? '') === \gethostbyname('parsoid');


$wgGroupPermissions['*']['read'] = [...] || client_is_parsoid());

Your criterion for identifying Parsoid may differ, but this is the basic idea. (talkcontribs)

Hey idk if this is still being monitered or if anyone will reply to this but when ever I try to save my changes on the Creepypasta Wiki, it gives me this 404 error: Error contacting the Parsoid/RESTBase server (HTTP 404), idk if anyone knows how to fix this, but if anyone has any ideas, it would be greatly appreciated!!

Rp (talkcontribs)

That looks like a wiki configuration error rather than a MediaWiki software bug, so you need to report it to the wiki's maintainers or, if you're referring to the wiki at, perhaps to the maintainers.

Reply to "Error contacting the Parsoid/RESTBase server (HTTP 404)"

Suggestion: more explicit output for shortened references

Afernand74 (talkcontribs)


I have been using more and more VE during the last months, only reverting to source editor to switch (reference) templates (cite web to cite book for ex). Keep on the good work!

I would find useful to see a preview of a shortened reference by hovering over its footnote marker, when editing, instead of the standard Template message. If you have several refs next to each other, you need to click all of them until you find the one you want, considering that they disappear from the reference list in VE mode.

Today when clicking on the footnote marker, VE shows the following message "Template / Generated from: sfn" or "Template / Generated from: harvnb". A preview would be more useful imho. For ex:

- code: {sfn|Doe|2021|p=101}

- VE message now: Template / Generated from: sfn (+ edit button)

- Proposed output: Doe 2021, p. 101 (+ edit button)


Reply to "Suggestion: more explicit output for shortened references"

חסרות דמויות וזה לא נותן לי לכתוב אותן

1 (talkcontribs)
Reply to "חסרות דמויות וזה לא נותן לי לכתוב אותן"

VisualEditor still messing up citation templates

JPxG (talkcontribs)

Check out this diff. It is still doing it: for no apparent reason, Visual Editor destroys citation templates. In this case, {{Citation needed}} was replaced with <sup>[''[[Wikipedia:Citation needed|citation needed]]'']</sup>. I don't know why it is doing this, but it creates massive amounts of work. Can it please be fixed? JPxG (talk) 20:22, 17 July 2022 (UTC)

JPxG (talkcontribs)

oh, cool, the feedback form for when VE is broken forces you to write your comments using VE.

JPxG (talkcontribs)

I have a massive regex in my AWB settings that can pretty easily detect when VE vandalizes a page -- another red flag is when it peppers nowiki tags throughout a paragraph, seemingly at random. Is there a way that we can get VE to pop up a warning or a confirmation box when someone attempts to save an edit that's adding a bunch of nowiki tags all over the page's source? It seems like there are very few situations in which this is what the editor actually intends to happen.

JPxG (talkcontribs)

Some other examples of this happening: here, here, here. This edit is an example of the "nowiki blizzard" where the tag is added at random points throughout an entire paragraph, in addition to the broken CN templates. This has been going on for months, and necessitates large AWB runs on a regular basis. Is there any way to fix it?

JPxG (talkcontribs)
JPxG (talkcontribs)

I asked one editor about this, Sakrb3791zi, who said: "I think I edited this article by going back and forth between mobile and visual editing. It most likely happened in the process of changing text editing to visual variants or vice versa. It was behaving a bit strangely, if I recall correctly. The device used is a Google Pixel 5."

JPxG (talkcontribs)

Here is a pretty egregious example, where it made an article basically unreadable by random addition of nowiki tags (in addition to messing up citation needed templates).

JPxG (talkcontribs)
TheDJ (talkcontribs)

Based on the pattern, the most likely reason is copying something from a preview or the original article, or even another article in another tab, and pasting it into the editor, preserving HTML. How is a person to know, that copying [citation needed] from somewhere is not going to insert the citation needed template? And how can the visual editor know that a piece of html is supposed to be generated as a template?

The problem here is that it looks about the same to the end user. They don't realize something is going wrong. If they did it with a big template like an infobox, it's much easier to spot that the paste result is problematic.

Here you have some more examples of a similar problem with inline reference numbers like [1] being copy pasted by users (not a VE problem anymore). When copied into VE, these no longer cause nowiki, as those copy pastes don't have wiki'able syntax. They also don't cause link syntax, as the VE likely can recognize them as ref links, due to the anchor. But do the same using a notepad app or whatever and you get this bare [1]. But VE can't really distinguish one wiki link in text from another (which citation needed actually is, just a link to a wiki page), so it's just gonna add it as what it is. A valid link, with potentially unbalanced link bracket syntax around it, which it then escapes. You could argue it could test if they are balanced or not, and don't contain an external link, but that seems like a pretty hard test....

But this isn't really new. From that list, I took this case, where an editor was doing the same in 2005, but its less noticeable. I repaired it today. Editors just aren't as aware of these as they don't contain the most evil 'nowiki' keyword.

Reply to "VisualEditor still messing up citation templates"

Difficultés téléversement

1 (talkcontribs)
Reply to "Difficultés téléversement"
Mx. Granger (talkcontribs)
Mx. Granger (talkcontribs)

See also this diff – looks like possibly a similar problem. Based on context, it looks like the editor tried to copy the ref named ":0", but VisualEditor added a "2" to create the ref name ":02".

Mx. Granger (talkcontribs)

Here too - it looks like the refs named ":62", ":622", ":623", and ":624" are all intended to be the same reference.

Matma Rex (talkcontribs)

Thank you for the report with examples, they are very helpful. I will have a look next week.

Matma Rex (talkcontribs)

I haven't gotten around to this, but I filed it as T312050 so that it doesn't get lost.

Mx. Granger (talkcontribs)

Not sure if this edit is the same issue, but it also introduced a bunch of undefined references by adding "2" to ref names:

FeRDNYC (talkcontribs)

@Mx. Granger: I suspect the issue there is that the references changed were previously "upside down": The named ref was invoked before it was defined. The first use of e.g. the "GadCast" ref was <ref name="GadCast"/>, and then it was defined in full the second time it was used.

So, when the V.E. saw a <ref name="GadCast"/> in the edited section, it saw it as a new, not-previously-defined reference (because there was no definition for it, up to that point), and noticed that the name conflicted with the definition of <ref name="GadCast" …> that appeared later in the article, so it applied automated corrections to the name.

Invoking references before defining them does work in MediaWiki, though it's definitely atypical page structure and I'm not sure where it falls in terms of "officially supported" syntax. But seems like, either VE needs to learn to support that ordering without freaking out, or invoking a reference before defining it needs to be flagged as a syntax error and tracked so that the (possibly many) articles where it's currently done can be corrected. Perhaps by an industrious bot. (Though I suppose a bot could correct those without them being made an error, really.)

Mx. Granger (talkcontribs)

@FeRDNYC: Thanks for the sleuthing on this. Many en.wikipedia articles invoke references before defining them, and in some cases this is the only feasible solution I know of to make a transclusion work correctly (specifically, this structure is needed when one page transcludes a section of another page that includes a reference also used earlier in the second page). I think VE needs to be fixed to support this ordering.

Matma Rex (talkcontribs)

Using a reference before it is defined is definitely 100% officially supported, and VE supports editing those references as well. It's not impossible that there are bugs, but I just tried some simple things and they work just fine, .

My best guess (I wrote it down on Phabricator: T312050#8082365 – I didn't think to copy it back to here, sorry) is that this happens because users copy-paste the wikitext for reusing a reference (<ref name="x" />) into VE, after editing the article in their sandbox, or from another article.

Mx. Granger (talkcontribs)

@Matma Rex Thanks for the update. That explanation makes sense, and I can see the problem would be tricky to prevent. (I'll try to remember to check for updates on Phabricator next time.)

Matma Rex (talkcontribs)

I had a closer look at the latest example ().

In this diff, the user was just trying to remove the {{Cast listing|…}} template wrapper, in addition to the other changes. The only way to do it is to copy-paste the wikitext out of the template. When I do this, I get the same diff with changed ref names that they got: (screencast).

I think that confirms my theory, but it also suggests that my proposed fix (just removing the broken refs) is not a good idea. I guess we should try to match the names to the existing ones, rather than filter them out. But this can lead to conflicts when refs are copy-pasted between articles… (particularly with the useless names like :1 generated by the visual editor itself). Maybe that is the lesser evil?

Mx. Granger (talkcontribs)

I'm genuinely not sure which is the lesser evil. As you pointed out, with the generic ref names generated by Visual Editor, trying to match the names could cause a very unfortunate conflict where a reference can end up attached to text that it has nothing to do with (if someone copies a <ref name=":1"/> invocation from one article to another article that already has an unrelated <ref name=":1">...</ref> definition). To be fair, this problem also happens when people copy and paste wikitext in the traditional editor.

A side question: is there any chance the Visual Editor could be changed to generate less generic ref names? I spend a lot of time fixing ref errors on en.wikipedia, and when the errors involve ref names like :1 and :2 that are so widely used across different pages, it can be much harder to untangle what has gone wrong.

Whatamidoing (WMF) (talkcontribs)

Decent automatic names is phab:T92432. This is difficult, because it must be language-agnostic. My favorite proposal so far is extracting some characters from the ref's contents.

A simpler first step could be phab:T52568.

Mx. Granger (talkcontribs)

I'm glad this is being worked on. Extracting characters from the ref's contents sounds reasonable. Nearly anything, even a randomly generated UUID or a hash code, would be better than the current setup, as there wouldn't be so many collisions when copying refs between articles.

Whatamidoing (WMF) (talkcontribs)

Well, it'd probably be more accurate to say that it's being "talked about occasionally". I don't have any real hope of this work getting done this calendar year.

Mx. Granger (talkcontribs)

After thinking about it some more, I think the current behavior may be the least bad option. With this behavior, an error is generated (putting the article into wikipedia:Category:Pages with broken reference names) and no information is lost, so as long as editors understand the issue, they can resolve it.

In contrast, if we try to match the ref names, we're vulnerable to the serious, silent problem with colliding ref names as mentioned above. If we remove the refs, information is lost so that it's not obvious the text was ever sourced. But I don't know, maybe there's some other solution that would avoid all of these problems.

In the case of the cast listing template – what if Visual Editor adds some kind of invisible control characters identifying the article when copying wikitext from a template within Visual Editor? Then when pasting the text into Visual Editor, it could check the control characters to see whether the text comes from the same article, then try to match the refs if it's the same article, and do the current behavior (adding a 2 to the ref name) if it's not the same article.

Reply to "Another reference error"

extra <div class="mw-parser-output"> right after each publish

Wint7 (talkcontribs)

When I publish a change by the editor, it replaces the content of the (opening) page with my edit (without reloading). This in-place replacement should be an expected behavior.

However, this replacing behavior is not exactly altering the <div class="mw-parser-output"> tag; but instead, it replaces the entire content within the <div class="mw-parser-output"> tag. This change results the nested tag -- <div class="mw-parser-output"><div class="mw-parser-output"></div></div>. The nest is a bit troublesome since it may break CSS stylings. It will not persist and disappear after reload (i.e. not saved as content), so it's not severe.

Is this nest an expected behavior?

Reply to "extra <div class="mw-parser-output"> right after each publish"

Visual editor no longer available

Chrisguise (talkcontribs)

Although I have VE enabled in my preferences, the 'Edit' tab no longer appears when I edit individual pages but it still appears on transcluded pages. I use Firefox but have checked Edge and get the same result.

Wladek92 (talkcontribs)
Please give Example of 'individual page'. Is that a question of page protection? or of user rights ?

Christian 🇫🇷 FR (talk) 15:39, 27 July 2022 (UTC)

Chrisguise (talkcontribs)
Wladek92 (talkcontribs)

you must first create the page before you can edit it. Drafts are created as user sub pages. Namespace Page: seems strange for me.

Christian 🇫🇷 FR (talk) 10:38, 28 July 2022 (UTC)

Reply to "Visual editor no longer available"

items disappeared when source holds [[ ]] motifs

Wladek92 (talkcontribs)

Hi all, 1.when writing I open it with source editor to enter last line with "bureau ." 2.I switch to visual editor using the pencil has been splitted into 3 lines


4. I make it smaller ; tags smaller relplace pre 5.I switch back to source editor 6.the brackets have disappeared together with user value and the text is now truncated "bureau ."

Christian 🇫🇷 FR (talk) 15:34, 27 July 2022 (UTC)

Reply to "items disappeared when source holds [[ ]] motifs"


Daredemodaisuki 114514 (talkcontribs)

When user using Chinese use VE and type in Chinese words and add source for it (such us [1]), if they continue to type the next word, the words they typed in would be deleted unexpectedly. It will only happen on the first word after the source, and won't happen every time.

For example, we have typed in:


and we will type the next character or word (e.g.内, nei),

first we type n:

这是一个例子[1]n 【n>1.你 2.呢 3.那 4.您 5.年】←the Chinese input program

and then we type e:

这是一个例子 【ne>1.呢 2.讷 3.那 4.呐 5.哪】

and then we type i:

这是一个 【nei>1.内 2.馁 3.那 4.哪 5.娞】

and we finally press 1 to choose "内", it will be:


If we continue to type more, it will be deleted more...

Normally it should be:


这是一个例子[1]n 【n>1.你 2.呢 3.那 4.您 5.年】

这是一个例子[1]ne 【ne>1.呢 2.讷 3.那 4.呐 5.哪】

这是一个例子[1]nei 【nei>1.内 2.馁 3.那 4.哪 5.娞】


Reply to "在可视化编辑器输入中文,引文脚注后使用输入法输入内容时概率出现吞噬文字现象"