Jump to navigation Jump to search

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)

Sdkb (talkcontribs)

When making an edit at English Wikipedia with the source editor, the w:MediaWiki:Editpage-head-copy-warn notice appears at the top of the page, warning that "Content that violates any copyrights will be deleted. Encyclopedic content must be verifiable. Any work submitted to Wikipedia can be edited, used, and redistributed—by anyone—subject to certain terms and conditions." The last sentence is just a disclaimer, but the first two communicate really important information. However, this notice is entirely missing from VE. This is especially problematic given that newer editors, who most need to hear the warning, are also the ones most likely to use VE. Is there a space in the VisualEditor editing environment where we could add this notice or something similar?

Reply to "Sources and copyright notice"

Process for creating redirects with VE is burdensome

Sdkb (talkcontribs)

The current process for creating redirects with VE is quite burdensome and unintuitive. You have to go to the page options menu, choose page settings, check the "redirect this page" box, type out the name of the page, click apply changes, then go through the publish page dialogue. Redirecting is something that is most often done when creating a new blank page, so it might be nice if, when looking at a blank page in VE, a shortcut to creating a redirect appeared.

Jdforrester (WMF) (talkcontribs)

We wanted to make it more prominent, but as it was some experienced users complained that newbies were creating bad redirects. I think the current balance is probably fine.

Sdkb (talkcontribs)

@Jdforrester (WMF), do you know when that feedback was received? I believe we've only recently tightened up our patrolling of new redirects, so things may be better now than they were a few years ago. Courtesy pinging @Rosguill, who I believe is active in this area. In any case, two points: 1) the fact that beginners tend to make more mistakes than experienced editors seems like a bad reason to make workflows difficult for them and for everyone else on VE—the extreme endpoint of that line of thinking is that many VE edits are low-quality newcomer edits, so let's just disable VE. 2) If we ever want experienced users to start using VE, we need to make it work better with the kind of editing experienced editors do, which includes creating redirects.

Jdforrester (WMF) (talkcontribs)

@Jdforrester (WMF), do you know when that feedback was received? I believe we've only recently tightened up our patrolling of new redirects, so things may be better now than they were a few years ago. Courtesy pinging @Rosguill, who I believe is active in this area. In any case, two points:

Around 2013, I think. When you say "we" I assume you mean the English Wikipedia given you don't state otherwise? This software is written for hundreds of Wikimedia wikis and thousands of non-Wikimedia hosted wikis; we don't make decisions solely based on local sentiment. :-) I vaguely believe that the pressure was from the French or possibly Spanish Wikipedias.

1) the fact that beginners tend to make more mistakes than experienced editors seems like a bad reason to make workflows difficult for them and for everyone else on VE—the extreme endpoint of that line of thinking is that many VE edits are low-quality newcomer edits, so let's just disable VE.

Indeed, and such arguments are put forward every month in different communities.

2) If we ever want experienced users to start using VE, we need to make it work better with the kind of editing experienced editors do, which includes creating redirects.

Yes, I agree. I'm just giving some context.

Rosguill (talkcontribs)

Not sure I have much special insight to this aspect of redirects, but I agree with Sdkb that VE is more difficult than raw for redirect editing, despite otherwise preferring VE for articles.

Whatamidoing (WMF) (talkcontribs)

The goal wasn't to make redirect creation fast for people like us. The goal is to help the less-experienced editors (that's 99% of them, compared to the four of us in this thread) be successful (e.g., actually create a redirect, and have that redirect point to an extant page).

Sdkb (talkcontribs)
Whatamidoing (WMF) (talkcontribs)

Typing a code that you memorized isn't intuitive, either. What do you think would be intuitive?

Sdkb (talkcontribs)

What I suggested above—that when looking at a blank page in VE, a prominent button or similar provides users an option to create a redirect. The vast majority of the circumstances in which an editor would want to create a redirect occur when creating a new blank page, and many instances in which an editor is creating a new page are ones where they're creating a redirect, so it should make sense to provide a shortcut from that screen.

Reply to "Process for creating redirects with VE is burdensome"

Template with no parameter (suggestion)

Summary by Whatamidoing (WMF)
Curios7ty (talkcontribs)


I'm a French user on frwiki.

When inserting a template without parameter (for instance {{,}} which displays a "," in superscript often between references), i would find it glad that it automatically skip the second step when asking for parameter/fields/inputs. It really only concerns template with no parameters (i don't mind for templates which have implicit parameters and can be specified or not).

Because what's more is that I can't even skip the 2nd step fast, because i can't use "Enter" to insert the template (the mouse is in the field case, and i would need to roll up "Maj"+"Tab" 4 times to get to the "Insert" and then insert the model. So i usually use mouse which is far slowlier.

> So my suggestion would be:

* automatically insert a template with no parameter (without the 2nd step asking for field input)

* or at least make the cursor field focus be on the "Insert" button, directly in 2nd step so an "enter" will make it almost automatic.

Thanks in advance for your feedback.

Whatamidoing (WMF) (talkcontribs)

Thank you for posting this suggestion. I don't expect this change to be made soon. In between now and then, you might want to learn the keyboard shortcuts. I don't see this one listed at VisualEditor/Keyboard shortcuts, but if you use a Mac, the keyboard shortcut for clicking the "Insert" button is usually Command+ Enter. (This works on almost all of the dialogs inside the visual editor.) On a Windows or Linux system, the equivalent might be Control+Return or maybe Control+ Shift+Return.

Reply to "Template with no parameter (suggestion)"

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!

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

Reply to "Error contacting the Parsoid/RESTBase server (HTTP 404)"
Perle Chn (talkcontribs)
Reply to "Brouillon"

Unable to add nsbp character in specific situation

Somerandomuser (talkcontribs)

In an edit on Wikipedia, I replaced nbsp templates with nbsp characters using the Nbsp button from the Special character menu. VisualEditor was unable to add the last instance of the nbsp character despite showing the gray box of the nbsp character. I needed to edit the source and manually add the nbsp character without using VisualEdit (see this diff). I'm using the Vector wiki skin from a Chromium-based web browser on macOS.

Whatamidoing (WMF) (talkcontribs)

How strange. Is this the only time that's happened to you?

Reply to "Unable to add nsbp character in specific situation"
Aleqc (talkcontribs)
Reply to "Problemes à sourcer"

Visual editor on Dagbani Wikipedia

Summary by Whatamidoing (WMF)
Masssly (talkcontribs)

Hello! I tried to enable visual editor and citoid on Dagbani Wikipedia and failed. How can I get some help around that? Thanks! -Masssly (talk) 20:04, 5 September 2021 (UTC)

AKlapper (WMF) (talkcontribs)
Whatamidoing (WMF) (talkcontribs)

@Masssly, this is a pretty difficult task. @Jadnapac and I were talking about the problems last month. I'll ask @Mvolz (WMF) to put you on her list.

Ultimately, though, what we need is to build up the technical skills in the African Wikipedias. @SSethi (WMF), is importing templates something that your m:Small wiki toolkits program could support?

Masssly (talkcontribs)

@AKlapper (WMF) and Whatamidoing (WMF): Thanks both for your feedback. 100% agree with building technical capacity in the African language communities. I started to discuss some ideas around that with folks from the Small wiki toolkits in the past year, but then I got busy with other things.

@Andre, here is where I got to phab:T290952. I guess we could merge with this other ticket: phab:T291004.


SSethi (WMF) (talkcontribs)

@Masssly In a day or so, there will be a blogpost released on the diff and tech blogs for a call for smaller language wikis to join the technical capacity program as part of the small wiki toolkits initiative. If your community wants to join, you could follow the steps / process in there.

Masssly (talkcontribs)
Reply to "Visual editor on Dagbani Wikipedia"
Tom Gdyk (talkcontribs)
Aplikacja klienta: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36 OPR/65.0.3467.62


Block when trying to insert a new photo. Blockade of no passage. The system informs you that the photo is harmful. The photo shows a model of an aircraft for tunnel testing and is in no way harmful.

Whatamidoing (WMF) (talkcontribs)
Reply to "foto upload lock !"

Copy paste in article in mobile gives only plain plaintext

Ugog-public (talkcontribs)

I've just did a volley of edits on VE mobile and noticed copy pasting didn't include all the markup like it does on regular desktop. I only got plaintext and was forced to use source editing. A known issue? I'm on Android+Chrome.

Whatamidoing (WMF) (talkcontribs)

I don't know if this is a problem with the copying (which I don't think VE can affect) or with the pasting (which it might be able to). If you copy similar content to another app, is the formatting retained by the other app?

Ugog-public (talkcontribs)

Thanks for you response as usual :)

Well no, it does show up as plain text in other apps, I just tried. Isn't that how it's on desktop too? Only copy-paste within VE pastes the wikitext properly, elsewhere, it's just plaintext even on desktop.

Whatamidoing (WMF) (talkcontribs)

It depends on the app. If I paste from a website into Google Docs, I get rich-text formatting (e.g., copying a portion of this discussion thread copies bold face text and links, not just the words). If I paste into an e-mail message, I get plain text or rich text, depending on whether the e-mail message is set to plain text or rich text.

Reply to "Copy paste in article in mobile gives only plain plaintext"