Extension talk:VisualEditor/2020

Please note that the Wikimedia Foundation does not provide support for installing VisualEditor on third-party wikis. However, if you have a question we may try to help.

Templates and Visual Editor

It appears that all of my templates are a "puzzle piece" in VisualEditor. Is there a way to show them before saving the page? 128.0.133.149 (talk) 16:06, 4 January 2020 (UTC)

References are not clickable when copied from MS Word

I have just installed VE and it is working great. The only problem I am facing is that when I copy paste article from MS Word file VE does not properly format the references. Moreover, references are not clickable either. Any solution to that? 39.53.109.151 (talk) 03:03, 14 January 2020 (UTC)

Pages with slashes (/) in title result in 404 error

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

It appears visual editor does not work with pages that have slashes in their titles. When trying to save edits to these pages, or create a new page with a slash in the title, it results in an "apierror-visualeditor-docserver-http: HTTP 404" error. Watching the parsoid logs, you can see that the request never even makes it to parsoid if this is the case.

I recently updated a wiki which already has a bunch of pages with slashes in the titles which have not posed an issue until now. Is there a workaround or a planned fix for this? Dstoeltz (talk) 17:37, 14 January 2020 (UTC)

I've just solved this for my wiki. The request isn't even getting as far as Restbase, let alone Parsoid. To fix it you need to have:

AllowEncodedSlashes NoDecode

in your Apache configuration. Without that, Apache rejects any urls with encoded slashes. Also, you need to add the nocanon directive on the end of the ProxyPass line. Prh47bridge (talk) 17:43, 27 April 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

the edit section redirect to the index.php page

you can see it in the link kookipedia.com/index.php?title=%D7%A2%D7%9E%D7%95%D7%93_%D7%A8%D7%90%D7%A9%D7%99&veaction=edit Yedidyarashi (talk) 16:17, 18 January 2020 (UTC)

pls help!!!!! Yedidyarashi (talk) 21:13, 18 January 2020 (UTC)

help with installing

I need help pls help me with this. Yedidyarashi (talk) 21:23, 18 January 2020 (UTC)

Hello, what you exactly need? Kizule (talk) 18:50, 8 February 2020 (UTC)

VisualEditor/Parsoid compatibility

Parsoid/JS v0.11.0 has been released but no documentation explain the compatibility with VisualEditor.

For ex. in MW1.31.6(LTS) VisualEditor 0.1.0 is not compatible with Parsoid 0.11.0:

HTTPError 406 Not acceptable profile=\"https://www.mediawiki.org/wiki/Specs/HTML/2.1.0\"

It would be helpful to update the compatibility matrix: Extension:VisualEditor#Set up a Parsoid service S0ring (talk) 13:27, 24 January 2020 (UTC)

Please read Parsoid/Releases. Jdforrester (WMF) (talk) 17:37, 24 January 2020 (UTC)

Thank you for pointing me to the right documentation, I assume Parsoid 0.11.0 is compatible for MediaWiki 1.33 or greater, although it will be end-of-life in June 2021 at the same date with MediaWiki 1.31 LTS (and with Node10).

In MW1.31 VE0.1.0 + Parsoid 0.10.0 are working fine (which includes an important fix for external links https://phabricator.wikimedia.org/T198511), but when RESTBase (for other services like Extension:ElectronPdfService or Extension:Math/Restbase) will be installed, then it will fail similar due to Parsoid HTML version incompatibility:

HTTPError 406 Not acceptable "requested_version":"1.6.0","existing_version":"2.0.0"

Parsoid 0.10.0 is breaking the current MediaWiki 1.31 LTS with RESTBase installed locally (master branch), is there any workaround to avoid it? S0ring (talk) 08:26, 27 January 2020 (UTC)

Yes, the content version compatibility checks are done by RESTBase, so you don't notice the breakage until it's installed. You shouldn't use such a new version of Parsoid, but instead the one that emits version 1.6.0 of the DOM, which is the content type that VisualEditor for 1.31 supports; apparently this is Parsoid 0.9.0 according to those notes, sorry. Jdforrester (WMF) (talk) 18:27, 28 January 2020 (UTC)

How to use {{#related:SITE}} or {{#description2:thats a description}}

Hi!

is there any way to use these kind of "templates". if I try to type, the template dialog opens, but they aren't templates. is there a way to use

{{#related:SITE}} tag or any of these tags?

cheers

Andreas

37.209.65.246 (talk) 20:47, 26 January 2020 (UTC)

Please list "exactly matching versions (VisualEditor, Parsoid, and MediaWiki)"

What defines "exactly matching versions" for Parsoid? It's not the version number, so what signifies the match? WhitWye (talk) 15:32, 28 January 2020 (UTC)

File that deals with formatting

Hey, could anyone please tell me the name of the file that contains the rules for formatting the text? For example, Visual Editor keeps adding spaces after * and |, and inserts a free line under headers, plus adds underscores to the name of files. Where exactly can I modify this behavior? 79.119.106.13 (talk) 14:49, 29 January 2020 (UTC)

That is done by Parsoid. VisualEditor doesn't know anything about wikitext, really. Jdforrester (WMF) (talk) 17:55, 30 January 2020 (UTC)

Thanks for the reply. So, in this case, how can I configure Parsoid's behavior in this regard? Is there a file? 79.119.106.13 (talk) 10:31, 1 February 2020 (UTC)

You can't. It's tens of thousands of lines of carefully engineered code. I'd very strongly discourage hacking around in it. Jdforrester (WMF) (talk) 18:12, 4 February 2020 (UTC)

Security issue for private wikis

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The current instructions suggest a workaround for forwarding cookies:

if ( !isset( $_SERVER['REMOTE_ADDR'] ) OR $_SERVER['REMOTE_ADDR'] == '127.0.0.1'	) {
	$wgGroupPermissions['*']['read'] = true;
	$wgGroupPermissions['*']['edit'] = true;
}

It seems like this solution is worse than the problem it is solving, as this will allow private wikis to be readable over the Parsoid port. When the browser visits that port, it will query the MediaWiki API with $_SERVER['REMOTE_ADDR'] set to 127.0.0.1. Of course, the Parsoid port could be closed to outside traffic. But it still seems like a bad idea and definitely should be noted in the instructions. Any thoughts? Ike Hecht 19:06, 3 February 2020 (UTC)

Indeed, I've moved around the warnings about this. How's this? Jdforrester (WMF) (talk) 19:40, 3 February 2020 (UTC)

Thanks so much! Definitely much better now. Just regarding this line:

All current options have significant, serious security implications.

Does forwarding cookies over HTTPS solve all security issues? If so, maybe that line should push users to that solution as the one safe option. Ike Hecht 22:43, 3 February 2020 (UTC)

I'm not sure; it's certainly the least-bad option. Sorry I can't be more specific. Jdforrester (WMF) (talk) 23:55, 3 February 2020 (UTC)

Thanks for your help with this. For now I added a note for users to use HTTPS. Ike Hecht 00:47, 14 February 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Compatibility MW/Parsoid

Dear all,

I don't understand the Extension:VisualEditor#Set up a Parsoid service table.

If I have the MW 1.33.1 installed, which Parsoid should i have? 0.10? Is it stable? Or should i go back to MW 1.31?

Thank you for your answer,

Frchdel4 (talk) 10:15, 11 February 2020 (UTC)

Error after install. Human error or computer error?

Hi, I recently installed MediaWiki on an Ubuntu virtual system with the apache2, php7.2, and mysql-server packages installed. The normal installation. All is well until I tried installing the VisualEditor. I first downloaded the package and moved it to the correct directory, then enabled it in the LocalSettings.php file. I took a break for a few days for personal things, then returned to my project to find that Parsoid needed to be installed. I did the installation instructions for Parsoid on a Debian/Ubuntu installation, and changed the uri variable in the config.yaml file of Parsoid to localhost, since that is where the api.php file is. I left the domain variable the same and returned to the VisualEditor page to do a full check of the instructions so that I knew I was done. I saw that I needed to change a few settings so that users would have a smoother experience, and I needed to link Parsoid to the VisualEditor. I did all that and reloaded the Parsoid service and the apache2 server. Finally, I returned top the localhost page in my browser to find that when I tried to switch to VisualEditor, it gave me the error "Error loading data from server: apierror-visualeditor-docserver-http-error: http-request-error." I checked a bit of the docs but coudn't find anything. Anybody know how to help? If you need anything just ask and I can tell you.

Thanks for reaching out,

Foxler2010 Foxler2010 (talk) 04:56, 13 February 2020 (UTC)

Hello, please provide the relevant parts of your configuration (parsoid/config.yaml, LocalSettings.php), also the versions of MediaWiki and Parsoid. Thus we can say what should be changed, otherwise someone must reproduce all the documentation for you. Spas.Z.Spasov (talk) 13:07, 13 February 2020 (UTC)

Allow Signatures in All Pages?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I have a private wiki where users do sign in article namespaces, but by default VisualEditor won't allow it. Is there any way to enable it? 104.194.203.111 (talk) 05:20, 19 February 2020 (UTC)

Do you want to allow Visual Editor on a certain NameSpace, named Article? Spas.Z.Spasov (talk) 16:13, 19 February 2020 (UTC)

VisualEditor is already enabled on the main namespace, but "your signature" in "insert" tab is greyed out, and users cannot insert ~~~~ signatures. I just want to enable it. 104.194.203.94 (talk) 01:44, 20 February 2020 (UTC)

In the article Help:VisualEditor/User guide is written that:

The "Your signature" item allows you to insert a signature that you use on the project. It will be greyed out (not selectable) when you are editing a type of page (a "namespace"), such as an article, where signatures should not be inserted.

There is a configuration variable, named $wgExtraSignatureNamespaces, that should allow you to add namespaces available for signature, but on my wiki this variable doesn't provide any result. Spas.Z.Spasov (talk) 08:05, 20 February 2020 (UTC)

This is exactly what I'm looking for! Thanks 104.194.203.111 (talk) 23:47, 20 February 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Adding new styles

Newbie question. Is it possible and easy to add new styles in the bar dropdown (where the headers, preformatc...) ? Dimassc (talk) 15:35, 24 February 2020 (UTC)

Setting up parsoid-php

There's been a lot of questions on Support_desk about how to setup the php port of parsoid (instead of using the parsoid node.js service). There seems to be no instructions for how to do so. It would be great if someone could document that. Bawolff (talk) 14:02, 26 February 2020 (UTC)

As said before, this won't be ready for many months. Jdforrester (WMF) (talk) 01:14, 27 February 2020 (UTC)

Its pretty ambigious all around. Parsoid/Releases certain seems to be implying the node.js version is deprecated and new installs should be moving to the php version. Bawolff (talk) 02:39, 27 February 2020 (UTC)

It is. They should wait for MW 1.35 to actually ship. Jdforrester (WMF) (talk) 21:28, 27 February 2020 (UTC)

VisualEditor failed to load

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

My VisualEditor stopped working after an upgrade to Mediawiki 1.34.

When "Edit" is clicked on, I can see the shadow of VisualEditor and Loading Bar showing up and then quickly disappeared (forced close).

Unlike most situations, there is no error message, and the browser just stuck at the page I intended to edit.

This is my setup:

• macOS Catalina (v 10.15.3)
• MAMP (version 5.5)
• MediaWiki 1.34
• VisualEditor (REL1_34)
• Parsoid 0.10.0 (set up from a virtual machine)
• Google Chrome Version 80.0.3987.122 (also tried Safari Version 13.0.5 and Firefox 73.0.1)

Parsoid seems to work fine from the port 8142, and I never got to the point of actually loading from Parsoid, so I don't think this is the issue but feel free to let me know otherwise. Also, I have tried ``REL1_34``, ``REL1_33``,``REL1_32``,``REL1_31`` versions of the extension, neither worked.

The only error messages I can pull out are those from the Google Chrome Console, so I will leave them here in case there is some helpful information.

DevTools failed to parse SourceMap: chrome-extension://cfhdojbkjhnklbpkdaibdccddilifddb/include.postload.js.map

VisualEditor failed to load: Error: Unknown module: mediawiki.api.messages

load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:51 jQuery.Deferred exception: Cannot set property 'section' of undefined TypeError: Cannot set property 'section' of undefined

load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:51 jQuery.Deferred exception: Cannot read property 'on' of undefined TypeError: Cannot read property 'on' of undefined

load.php?lang=en&modules=jquery&skin=vector&version=1xgm5:51 jQuery.Deferred exception: Cannot read property 'on' of undefined TypeError: Cannot read property 'on' of undefined

Regards, 108.89.25.45 (talk) 00:23, 2 March 2020 (UTC)

Your version of VisualEditor is incompatbile with your version of MediaWiki. The mediawiki.api.messages module was provided by MediaWiki until MW 1.33. You should upgrade VisualEditor (and all your other extensions) to the 1.34-compatible versions. Jdforrester (WMF) (talk) 19:52, 2 March 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

VisualEditor does not refresh page after saving changes

I have a rather weird issue. After saving changes with VE (2017 WE), instead of redirecting to https://wiki.com/w/Page, it stayed at https://wiki.com/w/Page?action=edit. Any idea why? The redirect issue happens when visiting https://wiki.com/index.php?title=Page&action=edit as well.

This is my setup:

Product	Version
MediaWiki	1.31.6
PHP	7.2.24-0ubuntu0.18.04.3 (fpm-fcgi)
MySQL	5.7.29-0ubuntu0.18.04.1
VisualEditor	0.1.0 (c3c9140)
Parsoid	0.10.0

No RESTBase is installed on the wiki. Alistair3149 (talk) 22:34, 15 March 2020 (UTC)

Viewing templates in the visual editor

I created a template using a table etc.the template views the icon of the puzzle piece and the table name In my visual editor.

Templates that use Wikipedia tables are viewing tables.

https://ja.wikipedia.org/wiki/%E3%83%AD%E3%83%8A%E3%82%A6%E3%82%B8%E3%83%BC%E3%83%8B%E3%83%A7

Can you tell me that I need to set up a visual editor or it's a different version? PonPon 14:11, 28 March 2020 (UTC)

VisualEditor is not compatible with the current MediaWiki core (version 1.34.0), it requires: >= 1.35.0PHP Fatal error: Uncaught ExtensionDependencyError: VisualEditor is not compatible with the current MediaWiki core (version 1.34.0), it requires: >= 1.35.0

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

PHP Fatal error:  Uncaught ExtensionDependencyError: VisualEditor is not compatible with the current MediaWiki core (version 1.34.0), it requires: >= 1.35.0 109.230.45.242 (talk) 13:26, 9 April 2020 (UTC)

Yes, master of extensions generally requires master of MediaWiki. See Manual:Extensions#Installing an extension. Jdforrester (WMF) (talk) 18:02, 9 April 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

curl_multi_init() has been disabled for security reasons

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Our hosting provider has disabled this function. We them asked to enable it but they refused. Creating new pages is fine but when i try to edit pages i get:

internal_api_error_Exception: Exception caught: PHP cURL function curl_multi_init missing.

Is there any workaround for this problem? Lostact (talk) 14:29, 15 April 2020 (UTC)

Since REL1_32 (for T139169), there's been a fallback to a non-parallel system that doesn't use curl if it's unavailable, but that was written assuming curl was intact. :-)

I've written this patch to also sniff for curl_multi_init and fallback; if that's merged, it'll ship with MediaWiki 1.35 unless we back-port it. Sorry that that's not an immediate fix. Jdforrester (WMF) (talk) 19:37, 15 April 2020 (UTC)

I applied this fix and my problem is solved. Thank you! Lostact (talk) 15:38, 16 April 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Can able to configure Visual Editors

I can't able to edit from visual edit it shows VirtualRESTService is defined how can I define that Iankush raj (talk) 00:15, 28 April 2020 (UTC)

Extension:VisualEditor#RESTBase setup for switching TiltedCerebellum (talk) 05:04, 22 June 2020 (UTC)

fail to switch to VisualEditor

hello! I loaded the extension in LocalSettings.php file, when I clicked edit, Visual Editor's interface popped for one second, and asked if I will switch to VisualEditor, but I missed it and clicked on something else..I am stuck with the plain editing interface.

I tried to remove the VisualEditor from /var/lib/extensions/ and re-upload again and load LocalSettings.php again, but the notification never pops up..

any clues? Onebigear (talk) 11:20, 20 May 2020 (UTC)

Display permissions messages in VisualEditor

On my wiki I've got it set up that VisualEditor is the default editor, for the ease of use of the members. The problem is, with $wgEmailConfirmToEdit set, the VisualEditor doesn't alert users that they need to confirm their email before editing.

Users will go to edit a page without confirming their email, and the VisualEditor just loads with everything grayed out and no explanation as to why. If you switch to the "edit source" tab with the built-in wikitext editor, it displays "You must confirm your email address before editing pages". This also extends to any other permissions messages that are normally displayed in the built-in wikitext editor.

Is there a way to add those permissions alerts to the VisualEditor, similar to how the alert about editing from an IP address displays? My current workaround is using a site wide dismissable notification telling users to confirm email before editing since VisualEditor doesn't display anything. Saxlover98 (talk) 17:47, 21 May 2020 (UTC)

Customize template output in VisualEditor only

I have a template which works fine but generates broken output with raw HTML in VisualEditor.

How to configure my template to have managed output in the VisualEditor? Is there some magic word, function, or wikitext syntax like noinclude, includeonly, etc. ? Czech.Fox (talk) 15:13, 25 May 2020 (UTC)

Help:VisualEditor/User guide#Editing templates TiltedCerebellum (talk) 05:02, 22 June 2020 (UTC)

data typing for tables

It would be so useful to restrict edits of wiki table to a data type ie. boolean or date. So sorting would become a lot more reliable and not mucked up by am incorrect entry. 49.198.223.203 (talk) 10:05, 28 May 2020 (UTC)

Hide categories from suggestions in VisualEditor

Is it possible to prevent certain categories from being suggested by the VisualEditor in the categories menu? For example, categories that are supposed to be added by templates, not manually? Garuda3 (talk) 10:04, 29 May 2020 (UTC)

Fundamental problem with this page

*The git submodule update --init command is vital, as MediaWiki-VisualEditor needs the core VisualEditor submodule to work. If you do not use this command, VisualEditor will fail to work.

Right so you are on shared hosting and this is a requirement. You come to this page looking for a solution on a shared host but then are left right back with a requirement to run a command line. Shouldn't this just say "it is not possible to get visual editing on shared hosting"? WayneGlenton (talk) 10:00, 31 May 2020 (UTC)

The link: VisualEditor/Installation on a shared host is under the heading:

Extension:VisualEditor#Setting VisualEditor up on shared hosting TiltedCerebellum (talk) 05:00, 22 June 2020 (UTC)

VisualEditor linked with (Parsoid over HTTPS) fails with HTML 500

Thank you all for your assistance in this issue. Our Current Configuration is:

Component	Version
Mediawiki	1.34.0
Parsoid	11
VisualEditor	0.1.1 (74116a7) 18:02, 23 December 2019
PHP	7.2.31 (apache2handler)
MariaDB	5.5.65-MariaDB

We installed VisualEditor with Parsoid over HTTPS using Stunnel. We have tested Parsoid over HTTPS through Stunnel using CURL. The correct response was received. We have also tested the VisualEditor using CURL. Also, a correct response is received.

Errors:

Our error is: Error loading data from server: apierror-visualeditor-docserver-http: HTTP 500. Would you like to retry?
& in the mediawiki debug log.

[VisualEditor] ApiVisualEditor::requestRestbase: Received HTTP 500 from RESTBase (We do not have RESTBase installed. We are a private wiki)
Our current config for Stunnel, Parsoid and LocalSettings is below:

Stunnel:

cert = /etc/httpd/ssl/<domaincert.cer>
key = /etc/httpd/ssl/<domaincert.key>
CAfile = /etc/httpd/ssl/<CACert.cer

;Allow only TLS, thus avoiding SSL
sslVersion = TLSv1.2
chroot = /var/run/stunnel
setuid = nobody
setgid = nobody
pid = /stunnel.pid
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1

[parsoid]
accept = 8143
connect = 8000
;TIMEOUTclose = 0


Parsoid:

mwApis
  - uri: 'https://<hostname.xxxx.xxx/api.php',
    domain: 'xxxx.xxx'

LocalSettings.php:

$wgDefaultUserOptions["visualeditor-enable"] = 1;
$wgHiddenPrefs[] = "visualeditor-enable";
$wgVirtualRestConfig["modules"]["parsoid"] = array(
  "url" => "https://<hostname.xxxx.xxx:8143",
 "domain" => "xxxx.xxx",
);

Thank you for your assistance in advance. Renegade04 (talk) 15:09, 1 June 2020 (UTC)

The indentation menu not active

Can anyone check this? Thanks...  Ę-oиė  >>>  ™ 14:15, 18 June 2020 (UTC)

How to change the size of the popup window in VisualEditor Extension

[x] I am using the VisualEditor extension to edit the wikimedia pages

[x] On typing " [[ " the popup shows to add internal and external links to the wikimedia page. This pop has a dynamic height depending on which page it is opened, varying from 80px to 208px.

[x] I searched the php files, but I couldn’t find the related code for the popup window. I also tried to specify the height in CSS files, but it is not doing anything

[x] Any idea how to change height? Yousaf13 (talk) 08:31, 23 June 2020 (UTC)

HTTP 500 "Error loading data from server"

After way too long troubleshooting VE-Parsoid-LDAP I thought I'd post what finally worked.

We have a private wiki (1.21 on Windows/Apache) that we wanted to upgrade to Ubuntu 20/Apache. I went through the normal migration steps. Relevant version info:

• Apache: 2.4.41
• MySQL: 8.0.20
• PHP: 7.4.3 (php-curl 7.68.0)
• MediaWiki: 1.31
• VisualEditor REL1_31
• Parsoid 0.9.0all (according to the compat matrix VE extension these should work together)

I Installed extension Auth_remoteuser (version REL1_31)

I setup Apache conf for a virtual host with LDAP authentication to our AD and then the relevant line in the <Location> section

Require valid-user

This seemed to break the handoff between VE and Parsoid. Edit source worked fine while invoking VE via Edit threw up this message each time:

"Error loading data from server: apierror-visualeditor-docserver-http: HTTP 500"

[Retry|Cancel]

I tried pretty much every suggestion on the internet, including suggestions about the 500 error on this page, but nothing worked. Debugging with curl statements worked with authentication and -u and without (and no -u). With authentication and the -u option I could see my username getting passed along inside MediaWiki variables.

None of the changes to LocalSettings.php mentioned on the extension page (forwarding cookies) worked. (I didn't try installing NetworkAuth and mapping 127.0.0.1 to the parsoid user. That was probably next.)

Looking at the Parsoid and Apache logs I could see that the request just wanted getting authenticated.

What ended up working for me was to whitelist localhost by adding the line

Require ip 127.0.0.1

just after require valid-user in the Apache conf. After an Apache restart everything came up fine and VE stopped getting a 500 internal error.

NOTE: I'd already tried an "Allow from 127.0.0.1" along with "Satisfy any" but this didn't work for either LDAP authentication or for Parsoid.

Since this was a bit of a frustrating exercise I thought I'd post the solution that worked for me. Any comments about what's going on here would be greatly appreciated. Dmccarty2 (talk) 18:09, 9 July 2020 (UTC)

Visual Editor not showing

I can't get the VisualEditor to work on our MediaWiki. Whenever you click 'Edit' you can "see" the progress bar for fractions of a second and then it disappears.

I went through all of the troubleshooting tips of both VisualEditor and Parsoid but nothing has helped so far.

These are my versions:

MediaWiki: 1.34.1

VisualEditor: 0.1.1 (74116a7), downloaded via ExtensionDistributor for MediaWiki 1.34

Parsoid: 0.11.0

Parsoid appears to be working. (For the private wiki I used the workaround to allow read and edit for all users where REMOTE_ADDR is 127.0.0.1).

The browser console has the following output:

jQuery.Deferred exception: target is undefined activateTarget/<@URL/w/load.php?lang=de&modules=ext.visualEditor.desktopArticleTarget.init%7Cext.visualEditor.progressBarWidget%2CsupportCheck%2CtargetLoader%2CtempWikitextEditorWidget%2Ctrack%2Cve&skin=vector&version=8zjxi:8:174

mightThrow@URL/w/load.php?lang=de&modules=jquery%2Csite%7Cjquery.client%2Ccookie%2CgetAttrs%2ChighlightText%2Csuggestions%2CtabIndex%2CtextSelection%7Cmediawiki.String%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2Cnotify%2CsearchSuggest%2Cstorage%2Ctemplate%2Ctoc%2Cuser%2Cutil%7Cmediawiki.editfont.styles%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%2Cstartup%7Cmediawiki.page.watch.ajax%7Cmediawiki.template.regexp%7Cskins.vector.js%7Cuser.defaults&skin=vector&version=t4vy4:48:916

resolve/</process<@URL/w/load.php?lang=de&modules=jquery%2Csite%7Cjquery.client%2Ccookie%2CgetAttrs%2ChighlightText%2Csuggestions%2CtabIndex%2CtextSelection%7Cmediawiki.String%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2Cnotify%2CsearchSuggest%2Cstorage%2Ctemplate%2Ctoc%2Cuser%2Cutil%7Cmediawiki.editfont.styles%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%2Cstartup%7Cmediawiki.page.watch.ajax%7Cmediawiki.template.regexp%7Cskins.vector.js%7Cuser.defaults&skin=vector&version=t4vy4:49:589

undefined

Any ideas? Flohoh (talk) 14:45, 10 July 2020 (UTC)

Since you didn't mention it

tail /var/log/parsoid/parsoid.log

tail /var/log/apache2/error.log

Do you see anything there?

Also, do you get any output on the command line if you do something like this: curl "http://localhost/api.php?action=visualeditor&format=json&paction=parse&page=Main_Page&uselang=en" Dmccarty2 (talk) 16:44, 10 July 2020 (UTC)

parsoid.log (for a click on 'Edit'):

{"name":"parsoid","hostname":"divis-web","pid":11121,"level":30,"logType":"info","wiki":"wiki$0","title":"Hardware","oldId":null,"reqId":null,"userAgent":"VisualEditor-MediaWiki/1.34.1","msg":"started wt2html","longMsg":"started wt2html","levelPath":"info","time":"2020-07-13T06:47:37.813Z","v":0}
{"name":"parsoid","hostname":"divis-web","pid":11121,"level":30,"logType":"info","wiki":"wiki$0","title":"Hardware","oldId":3785,"reqId":null,"userAgent":"VisualEditor-MediaWiki/1.34.1","msg":"completed wt2html in 82.2188150882721ms","longMsg":"completed wt2html in 82.2188150882721ms","levelPath":"info","time":"2020-07-13T06:47:37.885Z","v":0}

The only relevant error in error.log is

[Mon Jul 13 08:38:50.822221 2020] [php7:error] [pid 5488] [client ::1:34172] script '/var/www/html/api.php' not found or unable to stat

But this is probably because I copied your link without adapting it to my setup (...localhost/w/api.php...)

The output of curl http://localhost/w/api.php?action=visualeditor&format=json&page=Hauptseite&paction=parse contains an error that page parameter is not set which is weird because it is set. The same request worked in the API sandbox:

<!DOCTYPE html>
<html class="client-nojs" lang="de" dir="ltr">
<head>
<meta charset="UTF-8"/>
<title>MediaWiki-API-Ergebnis – DIVIS Wiki</title>
<nowiki><script>document.documentElement.className="client-js";RLCONF={"wgCanonicalNamespace":"Special","wgCanonicalSpecialPageName":"ApiHelp","wgNamespaceNumber":-1,"wgPageName":"Spezial:API-Hilfe","wgTitle":"API-Hilfe","wgCurRevisionId":0,"wgRevisionId":0,"wgArticleId":0,"wgIsArticle":!1,"wgIsRedirect":!1,"wgAction":"view","wgUserName":null,"wgUserGroups":["*"],"wgCategories":[],"wgBreakFrames":!1,"wgPageContentLanguage":"de","wgPageContentModel":"wikitext","wgSeparatorTransformTable":[",\t.",".\t,"],"wgDigitTransformTable":["",""],"wgDefaultDateFormat":"dmy","wgMonthNames":["","Januar","Februar","März","April","Mai","Juni","Juli","August","September","Oktober","November","Dezember"],"wgMonthNamesShort":["","Jan.","Feb.","Mär.","Apr.","Mai","Jun.","Jul.","Aug.","Sep.","Okt.","Nov.","Dez."],"wgRelevantPageName":"Spezial:API-Hilfe","wgRelevantArticleId":0,"wgRequestId":"fcdd936fb40936c611d5a78c","wgCSPNonce":!1,"wgIsProbablyEditable":!1,"wgRelevantPageIsProbablyEditable":!1,</nowiki>
"wgVisualEditor":{"pageLanguageCode":"de","pageLanguageDir":"ltr","pageVariantFallbacks":"de"},"wgEditSubmitButtonLabelPublish":!1};RLSTATE={"site.styles":"ready","noscript":"ready","user.styles":"ready","user":"ready","user.options":"loading","user.tokens":"loading","mediawiki.apipretty":"ready","mediawiki.legacy.shared":"ready","mediawiki.legacy.commonPrint":"ready","mediawiki.skinning.interface":"ready","ext.visualEditor.desktopArticleTarget.noscript":"ready"};RLPAGEMODULES=["site","mediawiki.page.startup","mediawiki.page.ready","ext.visualEditor.desktopArticleTarget.init","ext.visualEditor.targetLoader"];</script>
<script>(RLQ=window.RLQ||[]).push(function(){mw.loader.implement("user.options@1wzrr",function($,jQuery,require,module){/*@nomin*/mw.user.options.set({"variant":"de"});
});mw.loader.implement("user.tokens@tffin",function($,jQuery,require,module){/*@nomin*/mw.user.tokens.set({"editToken":"+\\","patrolToken":"+\\","watchToken":"+\\","csrfToken":"+\\"});
});});</script>
<link rel="stylesheet" href="/w/load.php?lang=de&amp;amp;amp;amp;amp;amp;modules=ext.visualEditor.desktopArticleTarget.noscript%7Cmediawiki.apipretty%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.skinning.interface&amp;amp;amp;amp;amp;amp;only=styles&amp;amp;amp;amp;amp;amp;skin=apioutput"/>
<script async="" src="/w/load.php?lang=de&amp;amp;amp;amp;amp;amp;modules=startup&amp;amp;amp;amp;amp;amp;only=scripts&amp;amp;amp;amp;amp;amp;raw=1&amp;amp;amp;amp;amp;amp;skin=apioutput"></script>
<meta name="generator" content="MediaWiki 1.34.1"/>
<meta name="robots" content="noindex,nofollow"/>
<link rel="shortcut icon" href="/favicon.ico"/>
<link rel="search" type="application/opensearchdescription+xml" href="/w/opensearch_desc.php" title="DIVIS Wiki (de)"/>
<link rel="EditURI" type="application/rsd+xml" href="https://cloud.divis.eu/w/api.php?action=rsd"/>
<link rel="alternate" type="application/atom+xml" title="Atom-Feed für „DIVIS Wiki“" href="/w/index.php?title=Spezial:Letzte_%C3%84nderungen&amp;amp;amp;amp;amp;amp;feed=atom"/>
<!--[if lt IE 9]><script src="/w/resources/lib/html5shiv/html5shiv.js"></script><![endif]-->
</head>
<body class="mediawiki ltr sitedir-ltr capitalize-all-nouns mw-hide-empty-elt ns--1 ns-special mw-special-ApiHelp page-Spezial_API-Hilfe rootpage-Spezial_API-Hilfe skin-apioutput action-view">
                <div class="mw-body" role="main">
                        <h1 class="firstHeading">MediaWiki-API-Ergebnis</h1>
                        <div class="mw-body-content">
                                <div><div class="api-pretty-header"><p>This is the HTML representation of the JSON format. HTML is good for debugging, but is unsuitable for application use.
</p><p>Specify the <var>format</var> parameter to change the output format. To see the non-HTML representation of the JSON format, set <a rel="nofollow" class="external text" href="https://cloud.divis.eu/w/api.php?action=visualeditor&amp;amp;amp;amp;amp;amp;format=json"><kbd>format=json</kbd></a>.
</p><p>See the <a href="https://www.mediawiki.org/wiki/API" class="extiw" title="mw:API">complete documentation</a>, or the <a href="/wiki/Spezial:API-Hilfe/main" title="Spezial:API-Hilfe/main">API help</a> for more information.
</p></div><pre class="api-pretty-content">{
    "error": {
        "code": "nopage",
        "info": "The \"page\" parameter must be set.",
        "*": "See https://cloud.divis.eu/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at &lt;https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce&gt; for notice of API deprecations and breaking changes."
    }
}

<script>(RLQ=window.RLQ||[]).push(function(){mw.config.set({"wgBackendResponseTime":55});});</script> </body></html>

Flohoh (talk) 07:11, 13 July 2020 (UTC)

I am having this exact same issue. I upgraded to 1.35 (since the Visual-editor documentation seems to have already been migrated towards it) and am getting a super cryptic error that directs me to the mailinglist.

Whenever the browser sends this:

{"Query string":{"action":"visualeditor","format":"json","paction":"parse", "page":"Special_rules_for_bases","uselang":"en","formatversion":"2","oldid":"67"}}

The server replies with a

{"error":{"code":"apierror-visualeditor-docserver-http","info":"HTTP 404","docref":"See https://wiki.commishes.com/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce&gt; for notice of API deprecations and breaking changes."}}

I'd love to know if anyone has any insight on what I'm doing wrong 89.27.154.138 (talk) 09:33, 25 August 2020 (UTC)

Templates not searchable - Title Key extension bug causes this

For users that have issue with VE template insertion and templates not being searchable, make sure you are not using the Title Key extension, at least until the bug in that extension is fixed (if it gets fixed). It will cause prefixsearch via Special:ApiSandbox to stop recognizing templates, files etc which can cause issues with other extensions like VE and Template Wizard:

Extension talk:TitleKey/Archive 2/Flow export#h-Breaks_VisualEditor_autocompletion_for_templates-2018-05-04T15:51:00.000Z TiltedCerebellum (talk) 06:03, 13 July 2020 (UTC)

Visual Editor don't show create page tab

I got Visual Editor, parsoid and mathoid to work, al last.

When you edit a page it works all right.

But when you try to create a page the create tab of Visual Editor does not show. You can create the page with wikieditor or source or whatever, save it and edit it in Visual Editor, but when you are creating the page, the create tab won't show.

Can anybody help, please. Amglez (talk) 10:11, 31 July 2020 (UTC)

1.35 RC Private Wiki

I constantly get 403 errors on a private wiki set up using the release candidate 1. If I allow anonymous read access then it works correctly. How do I give parsoid read access now that it's bundled in the PHP itself? 2001:8004:2768:D37:701D:2BB7:E895:5BD8 (talk) 07:15, 1 August 2020 (UTC)

Not showing text on page

I've got Visual Editor and Template Data installed on my wiki but I'm having an issue with them. I'm not sure which one is causing it.

The template uses a page field. The template fields load, but when searching it's intermittently showing blank text instead of the text of the page. Desbrina1 (talk) 19:51, 4 August 2020 (UTC)

Error contacting the Parsoid/RESTBase server (HTTP 404)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Installed Mediawiki 1.35 rc2, so new Visual Editor Parsoid PHP.

When I modify an page in the Main namespace, Visual Editor works fine.

But when creating or modifying a page in the User namespace, or when creating a page in the Main namespace, I get the following error: Error contacting the Parsoid/RESTBase server (HTTP 404).

Now reading the extension instructions it doesn't seem that I need to setup a RESTBase server, unless I want to avoid problems when switching between wikitext and Visual Editor.

Does anyone know what the problem could be?

Thank you for your help 185.69.145.64 (talk) 16:48, 26 August 2020 (UTC)

Been doing some further testing after reinstalling Mediawiki 1.35 rc2, and now the Main namespace works for modifying and creating pages, but the User namespace still doesn't work for either creating or modifying pages with Visual Editor. 185.69.145.64 (talk) 09:32, 27 August 2020 (UTC)

I had a hard time also to configure VE on MW 1.35.0-rc.2, with the error you mentionned when trying to edit a existing page in the main namespace. It turns out that the following line must be in LocalSettings.php:

wfLoadExtension( 'Parsoid', 'vendor/wikimedia/parsoid/extension.json' );

And the domain in $wgVirtualRestConfig['modules']['parsoid']['domain'] must be the same as the one in $wgServer (but $wgVirtualRestConfig is auto-configured, so this applies only if you explicitely changed it). ~ Seb35 [^_^] 16:15, 2 September 2020 (UTC)

Seb35, thank you very much for the suggestion!

Unfortunately it doesn't solve the issue I am having. I did try downloading the latest git version of Parsoid and adding that version via `wfLoadExtension( 'Parsoid', "$PARSOID_INSTALL_DIR/extension.json" );` though, as explained here: Parsoid/PHP, but didn't help either. 148.252.133.18 (talk) 17:12, 2 September 2020 (UTC)

I did pinpoint that the error is coming from file ApiParsoidTrait.php line 160:

// error null, code not 200

$this->getLogger()->warning(

__METHOD__ . ": Received HTTP {code} from RESTBase",

[

'code' => $response['code'],

'trace' => ( new Exception )->getTraceAsString(),

'response' => $response['body'],

'requestPath' => $path,

'requestIfMatch' => $reqheaders['If-Match'] ?? '',

]

);

$this->dieWithError(

[ 'apierror-visualeditor-docserver-http', $response['code'] ],

'apierror-visualeditor-docserver-http'

);

Does anyone know how I can access those warning logs? 148.252.133.18 (talk) 17:18, 2 September 2020 (UTC)

Debugging the PHP directly I get:

'code':

404

'trace':

#0 /var/www/html/w/extensions/VisualEditor/includes/ApiVisualEditor.php(67): ApiVisualEditor->requestRestbase(Object(Title), 'POST', 'transform/wikit...', Array)

#1 /var/www/html/w/extensions/VisualEditor/includes/ApiVisualEditor.php(251): ApiVisualEditor->parseWikitextFragment(Object(Title), 'testtext', false, NULL, true)

#2 /var/www/html/w/includes/api/ApiMain.php(1593): ApiVisualEditor->execute()

#3 /var/www/html/w/includes/api/ApiMain.php(529): ApiMain->executeAction()

#4 /var/www/html/w/includes/api/ApiMain.php(500): ApiMain->executeActionWithErrorHandling()

#5 /var/www/html/w/api.php(90): ApiMain->execute()

#6 /var/www/html/w/api.php(45): wfApiMain()

#7 {main}

'response':

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL was not found on this server.</p> <hr> <address>Apache/2.4.38 (Debian) Server at localhost Port 80</address> </body></html>

'requestPath':

transform/wikitext/to/html/User%3AJohn%2Ftestpage 148.252.133.18 (talk) 17:59, 2 September 2020 (UTC)

After further testing, i can't create any subpage in the Main namespace either...

So it will only allow me to create or modify pages but no subpages at all 148.252.133.18 (talk) 19:59, 2 September 2020 (UTC)

ok so this is definitely a bug.

If I remove urlencode from lines 230 & 250 in file ApiParsoidTrait.php it works.

requestPath above was sanitizing : and / to %3A and %2F, and that seems to be the problem. 148.252.133.18 (talk) 20:24, 2 September 2020 (UTC)

The page Parsoid/PHP is a bit old given it evolves quickly around this topic with the release of 1.35 (see phabricator:T248186 and linked tasks). In my case I used the tarball, and it seems my issue was different than yours.

Probably you can report it on Phabricator (an account will be needed), I quickly searched on Parsoid issues but I didn’t find opened tasks about encoding (well, there are some with "encod" but not really what you described). ~ Seb35 [^_^] 23:26, 2 September 2020 (UTC)

Thank you Seb35, I will report it on Phabricator. 148.252.133.18 (talk) 07:11, 3 September 2020 (UTC)

Created the following Phabricator report: https://phabricator.wikimedia.org/T261921

I can't close this issue here, I assume its because I'm not logged in. If someone else could I would appreciate. 148.252.133.18 (talk) 07:38, 3 September 2020 (UTC)

Thanks! I close this discussion. ~ Seb35 [^_^] 09:23, 3 September 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Math extension showing <math> tag in editing.

In page view, <math> is rendered well.

But in editing and 'formula' dialog, <math> tag is not rendered.

Any clue will be appreciated. Lajabs (talk) 05:51, 16 September 2020 (UTC)

Error loading data

How to solve problem?

Error loading data from server: no_vrs: The VirtualRESTService for the document server is not defined; see https://www.mediawiki.org/wiki/Extension:VisualEditor. Would you like to retry? Ss.sss16 (talk) 08:21, 16 September 2020 (UTC)

Moving from node.js to PHP with upcoming MW v1.35 upgrade

I'm currently doing prep for an upgrade to the upcoming v1.35 on a private enterprise wiki. For those of us currently using the node.js version of Parsoid, are there any actions we should be taking once we upgrade to cleanup the node.js setup? Removing the $wgVirtualRestConfig['modules']['parsoid']... from localsettings.php seems logical, as that would seem to be covered by the default setup now. Beyond that, is there anything I should be updating, removing, disabling, etc.?

Thanks! DHillBCA (talk) 15:16, 17 September 2020 (UTC)

You may need to do some tweaking on your URL Rewrite if you are using nice short urls.

VisualEditor/PHP will contact wiki/rest.php or w/rest.php when you go into visual editing.

If you are already using rewrites to make nice short URLs, you may find that - your rewrite rule will make the call to rest.php redirect to index.php, which gives a 404.

If you just ignore redirecting call to rest.php, your visual editor will work but cannot load page contents - it is accessing rest.php/yourdomain.name/v3/.... to load the page content, which cannot be ignored by checking rest.php.

The solution is, check the HTTP_USER_AGENT - VisualEditor make its access with UA: VisualEditor-MediaWiki/1.35.0. Add the bold line to every rewrite rules you defined for mediawiki (I'm assuming you are using apache2, tweak this accordingly if you are using other service):

RewriteCond %{REQUEST_URI} !^(static)

RewriteCond %{HTTP_USER_AGENT} !^(VisualEditor)

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d

RewriteRule ^(.*)$ %{DOCUMENT_ROOT}/wiki/index.php [L]

This will not make any rewrite to calls from VisualEditor/PHP and make it successfully access page contents and load it without affect other short URLs.

No other modifications in LocalSettings.php, just remove those restbase settings related to parsoid/JS and you can shut parsoid/JS down.

My env: Ubuntu 18.04 + PHP7.4 + Apache2 LapisLazuli33 (talk) 10:04, 3 October 2020 (UTC)

We are indeed using Apache2 (RHEL7, PHP 7.2.9 - will be upgrading as part of the process), but are not doing any short URLs. Glad to hear I can shut down the JS! Thank you for reaching out! DHillBCA (talk) 18:57, 8 October 2020 (UTC)

error visualeditor

no_vrs: The VirtualRESTService for the document server is not defined; see Extension:VisualEditor.

¡HELP! 200.73.241.79 (talk) 03:37, 21 September 2020 (UTC)

Nginx configuration

Is there a specific nginx configuration you need to do to get this working on 1.35?

When looking into the logs I've noticed it tries to access

`https://domainname.com/rest.php/domainname.com/v3/page/html/PageName/23526?redirect=false&stash=true`

but this returns a 404 on my server. Is the above URL the correct call url for VisualEditor and if so, how would I be able to tell nginx to not try and go to that location but pass those parameters to rest.php? 000Tom0000 (talk) 21:45, 25 September 2020 (UTC)

I also get a 404 error (Error contacting the Parsoid/RESTBase server (HTTP 404)): https://www.mediawiki.org/wiki/VisualEditor/Feedback/Archive/2020#h-Error_contacting_the_Parsoid/RESTBase_server_%28HTTP_404%29-2020-09-26T06%3A56%3A00.000Z

I'm on a shared hosting which uses LiteSpeed web server. Costas Athan (talk) 07:44, 26 September 2020 (UTC)

I've fixed it on NGINX by adding following to my configuration

location /rest.php {

try_files $uri $uri/ /rest.php?$args;

}

000Tom0000 (talk) 08:09, 26 September 2020 (UTC)

The server's configuration or the LocalSettings.php file? Costas Athan (talk) 08:28, 26 September 2020 (UTC)

Servers configuration. The error seemed to be that my pretty url rewrite wrongly send it to index.php instead of rest.php. 000Tom0000 (talk) 21:13, 26 September 2020 (UTC)

Oh my gah!! I can't thank you enough. I just copied and pasted and voilà, it work pretty straight and flawlessly!! Morikurayami (talk) 16:01, 16 December 2021 (UTC)

I got the same issue and the nginx configuration Tom mentioned does not help either. D3nnis3n (talk) 16:43, 26 September 2020 (UTC)

Because it's possible that there are multiple causes for the 404 error. Costas Athan (talk) 17:43, 26 September 2020 (UTC)

So, i found out that VisualEditor does show and work when trying to create a page that does not yet exist - but it fails when trying to edit a page that exists. D3nnis3n (talk) 17:37, 26 September 2020 (UTC)

You are right! It's the same for me. Costas Athan (talk) 17:46, 26 September 2020 (UTC)

I tried around for hours, but couldn't find a solution. Hopefully someone that has one will read this and help us out.

Maybe reporting a bug on their bugtracker would be useful, but it needs a registration, which i don't really want to do. D3nnis3n (talk) 19:46, 26 September 2020 (UTC)

I have also posted about it here: VisualEditor/Feedback/Archive/2020#h-Error_contacting_the_Parsoid/RESTBase_server_(HTTP_404)-2020-09-26T06:56:00.000Z

I think there is already an entry about this issue on Phabricator: https://phabricator.wikimedia.org/T255963 Costas Athan (talk) 19:54, 26 September 2020 (UTC)

Thats a different issue, though. They got the issue on saving. We don't even get that far out-of-the-box. Also looks like an issue for an older beta version and being on hold as well. D3nnis3n (talk) 00:16, 27 September 2020 (UTC)

Did you ever find a solution, 10 months later? Having the same problem on 1.36.1. Lostraven (talk) 18:20, 29 July 2021 (UTC)

I can replicate that VisualEditor does show and work when trying to create a page that does not yet exist - but it fails when trying to edit a page that exists. 110.33.200.115 (talk) 02:22, 8 November 2020 (UTC)

I'm able to reproduce the same error on a new installation. Perhaps there's something with the php version of parsoid that needs to be configured? Scripcat (talk) 20:41, 26 September 2020 (UTC)

Manually configuring

    $wgVisualEditorRestbaseURL = "https://example.com/api/rest_v1/page/html/";

    $wgVisualEditorFullRestbaseURL = "https://example.com/api/rest_";

for the main wiki and all the other wikis of the wiki family (we're using them in subfolders /en, /de, etc.) made the Visual Editor actually open without that error.

But it still doesn't show the pages content and is loading infinitely. D3nnis3n (talk) 02:46, 27 September 2020 (UTC)

Does RESTbase come with MediaWiki 1.35 or should it be installed following these directions: RESTBase/Installation? Costas Athan (talk) 07:12, 27 September 2020 (UTC)

I did not install a RestBASE Installation, i just changed these URLs.

The Visual Editor is supposed to work out-of-the-box and i can't find instructions for specific installs required. D3nnis3n (talk) 12:50, 27 September 2020 (UTC)

I don't think that RESTBase is a requirement, but it is mentioned in the page of the extension: Extension:VisualEditor#Switching between Wikitext Editing and VisualEditor

Anyway, you set those 2 variables. Where do these URLs point? Costas Athan (talk) 13:11, 27 September 2020 (UTC)

Based on this RESTBase/Installation#Configuration:

For MediaWiki 1.35 and later, YOUR_WIKI_REST_ENDPOINT is the location of your wiki's rest.php. For example, MediaWiki's REST endpoint is mediawiki.org/w/rest.php. See REST API.

I set $wgVisualEditorFullRestbaseURL = "https://example.com/rest.php";

The VisualEditor loads without a 404 error, but also empty without the page's contents. Costas Athan (talk) 06:55, 28 September 2020 (UTC)

VisualEditor/PHP will contact wiki/rest.php or w/rest.php when you go into visual editing. If you are already using rewrites to make nice short URLs, you may find that - your rewrite rule will make the call to rest.php redirect to index.php, which gives a 404.

If you just ignore redirecting call to rest.php, your visual editor will work but cannot load page contents - it is accessing rest.php/yourdomain.name/v3/.... to load the page content, which cannot be ignored by checking rest.php.

The solution is, check the HTTP_USER_AGENT - VisualEditor make its access with UA: VisualEditor-MediaWiki/1.35.0. Add the bold line to every rewrite rules you defined for mediawiki (I'm assuming using apache2, tweak this accordingly if you are using other service):

RewriteCond %{REQUEST_URI} !^(static)

RewriteCond %{HTTP_USER_AGENT} !^(VisualEditor)

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d

RewriteRule ^(.*)$ %{DOCUMENT_ROOT}/wiki/index.php [L]

This will not make any rewrite to calls from VisualEditor and make it successfully access page contents and load it without affect other short URLs.

No other modification in LocalSettings.php, My env: Ubuntu 18.04 + PHP7.4 + Apache2 LapisLazuli33 (talk) 10:01, 3 October 2020 (UTC)

You provide a great explanation but what do I do if I'm using NGINX. Junebug12851 (talk) 19:17, 20 October 2020 (UTC)

@Junebug12851 if you're using nginx, something like this works:

    location @rewrite {

        if ($http_user_agent !~* "^VisualEditor$") {

            rewrite ^/(.*)$ /index.php?title=$1&$args;

        }

    } Nnyby (talk) 18:17, 1 September 2022 (UTC)

I have the same issues and Tom's solution doesn't works for me as well. 154.17.24.21 (talk) 03:30, 27 September 2020 (UTC)

I opened a bug report here: https://phabricator.wikimedia.org/T263928

Feel free to participate in helping them out to find the possible cause of this :) D3nnis3n (talk) 03:48, 27 September 2020 (UTC)

I adding this gets me somewhere:

// Parsoid Setting

$wgEnableRestAPI = true;

$wgParsoidSettings = [

'useSelser' => true,

'rtTestMode' => false,

'linting' => true,

];

// Restbase server Setting

$wgVirtualRestConfig['modules']['restbase'] = [

'url' => 'localhost:/rest.php',

'domain' => 'localhost'

];

$wgVisualEditorRestbaseURL = "HTTPS://YOUR_DOMAIN/api/rest_v1/page/html/";

$wgVisualEditorFullRestbaseURL = "HTTPS://YOUR_DOMAIN/api/rest_";

// Parsoid Setting

$wgParsoidSettings = [

'linting' => true,

'_merge_strategy' => 'array_plus',

];

wfLoadExtension( 'Parsoid', "$IP/vendor/wikimedia/parsoid/extension.json" );

wfLoadExtension( 'VisualEditor' );

Scripcat (talk) 21:38, 27 September 2020 (UTC)

So this works for you? D3nnis3n (talk) 22:29, 27 September 2020 (UTC)

No. I got too excited. It loads without an error message and it looks fine until you realize it hasn't loaded the actual page's contents. Trying to save any edits will then result in cURL 28 error. Scripcat (talk) 01:22, 28 September 2020 (UTC)

VisualEditor/PHP will contact wiki/rest.php or w/rest.php when you go into visual editing. If you are already using rewrites to make nice short URLs, you may find that - your rewrite rule will make the call to rest.php redirect to index.php, which gives a 404.

If you just ignore redirecting call to rest.php, your visual editor will work but cannot load page contents - it is accessing rest.php/yourdomain.name/v3/.... to load the page content, which cannot be ignored by checking rest.php.

The solution is, check the HTTP_USER_AGENT - VisualEditor make its access with UA: VisualEditor-MediaWiki/1.35.0. Add the bold line to every rewrite rules you defined for mediawiki (I'm assuming you are using apache2, tweak this accordingly if you are using other service):

RewriteCond %{REQUEST_URI} !^(static)

RewriteCond %{HTTP_USER_AGENT} !^(VisualEditor)

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d

RewriteRule ^(.*)$ %{DOCUMENT_ROOT}/wiki/index.php [L]

This will not make any rewrite to calls from VisualEditor and make it successfully access page contents and load it without affect other short URLs.

No other modification in LocalSettings.php, My env: Ubuntu 18.04 + PHP7.4 + Apache2 LapisLazuli33 (talk) 10:02, 3 October 2020 (UTC)

The same problem appears without short URLs: https://phabricator.wikimedia.org/T263928#6496623

Anyway, I personally use short URLs. I added the line you suggested in my .htaccess and now I get "Error contacting the Parsoid/RESTBase server (HTTP 403)", instead of "Error contacting the Parsoid/RESTBase server (HTTP 404)" I was getting without it. Costas Athan (talk) 14:17, 3 October 2020 (UTC)

The user agent conditional was the correct answer for me here. Thanks! Dloewenherz2 (talk) 01:17, 13 July 2021 (UTC)

I was getting the same error message (403, not 404) with a standard, out-of-the-box MW 1.35, I'm not using any redirects/rewrite rules that I am aware of. Setting $wgVisualEditorFullRestbaseURL makes VE load, but with no content...

Since we are using a webhosting service, we are not able to edit the nginx or Apache base configuration. 95.222.50.200 (talk) 20:54, 4 October 2020 (UTC)

So, if I set

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

   'url' =>  .../rest.php',

   'domain' => '...',

];

I get a 404 error instead of the 403 error. 95.222.50.200 (talk) 21:10, 4 October 2020 (UTC)

location /rest.php/ {
    try_files $uri $uri/ /rest.php?$query_string;
}

worked for me, as it is written here : Parsoid Antoine.rozenknop (talk) 14:18, 11 October 2020 (UTC)

This worked for me too Morikurayami (talk) 15:59, 16 December 2021 (UTC)

This didn't work for me, same 404 message. Junebug12851 (talk) 19:25, 20 October 2020 (UTC)

On WM 1.35.0, with an nginx reverse proxy, having a similar issue with error "Error contacting the Parsoid/RESTBase server: http-request-error" when attempting to save VE documents, however I am not even getting a 404 and there is no activity in the NGINX error logs. Source code edits and saves are working without issue. An access to https://debian-guest.lan/rest.php suggests the redirection is correct (i.e., I receive what appears to be a response from the rest service); however https://debian-guest.lan/rest.php/v1/page/Main_Page/html (which I assume is the correct path) results in

• messageTranslations: {
  • en: "Unable to fetch Parsoid HTML" },
• httpCode: 500,
• httpReason: "Internal Server Error"

One other datapoint: when I create a new page, for the first time, the entire process succeeds using VE through saving and everything. I immediately encounter problems as described above when I attempt to edit the existing page via VE.

One final datapoint: interestingly, when I disable https, everything works exactly as it should with rewrite rules otherwise untouched. Final update, this was due to not setting up the RootCA in the test VM; once that was done everything (finally) works in HTTPS. Leaving this here for future reference by others in case they need minimally working server/LocalSetting configuration.

full (this is a test VM) nginx and LocalSettings.php configs are available at the Pastebin links. Same behavior with with/out the trailing slash in "location /rest.php/" and with "rest.php?$query_string" instead of "rest.php?$args" Bjsdaiyu (talk) 16:15, 25 October 2020 (UTC)

If anyone still struggles with VE 404 error on fresh install (1.36-alpha in my case):

`wfLoadExtension( 'Parsoid', 'vendor/wikimedia/parsoid/extension.json' );`

in LocalSettings.php solved it. Wouldn't call this zero config.

Should be noted that for a brief time period (a few weeks - 2 months) this worked without configuration in 1.35-alpha and broke later. —Aron Man.🍂 edits🌾 23:44, 31 October 2020 (UTC)

I was able to get my VisualEditor 404s to go away by following a config similar to what 000Tom0000 posted earlier (and is also given on Parsoid#Development ). My setup: I'm using Nginx, MediaWiki 1.35, and I was receiving HTTP 404s on rest.php/* only on https and not http only.

Since my wiki was using a $wgScriptPath (e.g. site), my Nginx config was:

location /site/rest.php/ {

    try_files $uri $uri/ /site/rest.php?$query_string;

} Jahoti (talk) 00:02, 3 February 2021 (UTC)

Same here

Additional conf in nginx resolved the problem

location /rest.php {

try_files $uri $uri/ /rest.php?$args;

} 109.9.182.128 (talk) 20:06, 17 April 2021 (UTC)

Edit .

with

try_files $uri $uri/ /rest.php?$args;

I can load visual editor, but not the content of the page

with

try_files $uri $uri/ /site/rest.php?$query_string;

I have no 404 error, but 400 instead 109.9.182.128 (talk) 20:11, 17 April 2021 (UTC)

In the end nothing mentionned here resolved the problem 109.9.182.128 (talk) 21:11, 17 April 2021 (UTC)

I solved by adding the following configuration:

location ~ /rest.php {

try_files $uri $uri/ /rest.php?$args;

} 171.97.48.45 (talk) 13:49, 12 June 2021 (UTC)

Running Ubuntu Server 20.04, MediaWiki 1.36.1, fresh install VisualEditor error, struggled with problem for couple weeks. Seems MediaWiki out-of-the-box install tends to work better with Apache2 vs nginx. Eventually VisualEditor worked, without errors, by installing additional php components as follows:

sudo apt install php7.4-mbstring php7.4-xml php7.4-fpm php7.4-json php7.4-mysql php7.4-curl php7.4-intl php7.4-gd php7.4-mbstring texlive imagemagick 68.145.238.178 (talk) 19:23, 19 September 2021 (UTC)

I installed all of the modules in this list I was missing and it didn't resolve the issue on my implementation... really a shame, can't deploy this server without a working visual editor. 71.235.161.204 (talk) 19:03, 8 November 2021 (UTC)

I use mw 1.37.1 container image and behind the nginx. My visual editor always got

Error contacting the Parsoid/RESTBase server: (curl error: 6) Couldn't resolve host name 207.23.128.10 (talk) 03:53, 21 March 2022 (UTC)

Error: Parsoid/RESTBase server (HTTP 500) when useing Ä,Ü,Ö in Page Title

I am using MediaWiki 1.35 specifically because I am new to all this. 89.26.47.65 (talk) 09:42, 30 September 2020 (UTC)

And Visual Editor is supposed to work out of the box.

But whenever I try to edit or create a page with an Umlaut in the title. I get Error 500 when saveing.

is this a known problem, or can somebody help me out?

Thanks in advance 89.26.47.65 (talk) 09:44, 30 September 2020 (UTC)

Visual Editor seems quite broken currently, there is a hell lot of people for which it does not work out of the box or not at all. Hope they will be looking at that soon. D3nnis3n (talk) 19:19, 30 September 2020 (UTC)

Error contacting the Parsoid/RESTBase server (HTTP 415)

{{{text}}}

just installed 1.35 on a brand new server, I am getting:

"Something went wrong

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

Haven't seen any troubleshooting regarding an HTTP 415 error, does anyone have any pointers where I could look or try?

Thank you 85.255.235.204 (talk) 16:30, 1 October 2020 (UTC)

This is the response I get

{"message":"A Content-Type header must be supplied with a request payload.","error":"no-content-type","httpCode":415,"httpReason":"Unsupported Media Type"}

and the trace

#0 /var/www/html/w/extensions/VisualEditor/includes/ApiParsoidTrait.php(279): ApiVisualEditorEdit->requestRestbase(Object(Title), 'POST', 'transform/html/...', Array, Array)

#1 /var/www/html/w/extensions/VisualEditor/includes/ApiParsoidTrait.php(296): ApiVisualEditorEdit->postData('transform/html/...', Object(Title), Array, Array, NULL)

#2 /var/www/html/w/extensions/VisualEditor/includes/ApiVisualEditorEdit.php(189): ApiVisualEditorEdit->postHTML(Object(Title), '<!doctype html>...', Array, NULL)

#3 /var/www/html/w/extensions/VisualEditor/includes/ApiVisualEditorEdit.php(163): ApiVisualEditorEdit->getWikitextNoCache(Object(Title), Array, Array)

#4 /var/www/html/w/extensions/VisualEditor/includes/ApiVisualEditorEdit.php(349): ApiVisualEditorEdit->getWikitext(Object(Title), Array, Array)

#5 /var/www/html/w/includes/api/ApiMain.php(1593): ApiVisualEditorEdit->execute()

#6 /var/www/html/w/includes/api/ApiMain.php(529): ApiMain->executeAction()

#7 /var/www/html/w/includes/api/ApiMain.php(500): ApiMain->executeActionWithErrorHandling()

#8 /var/www/html/w/api.php(90): ApiMain->execute()

#9 /var/www/html/w/api.php(45): wfApiMain()

#10 {main} 85.255.235.204 (talk) 17:53, 1 October 2020 (UTC)

and this is the request

[method] => POST [url] => /restbase/local/v1/transform/html/to/wikitext/TestingPage [body] => ([html] => <!doctype html><html><head><base href="https://en.wikipedia.org/w/"><base href="https://en.wikipedia.org/w/"></head><body><p>Test Text for Test PAGE</p></body></html> [scrub_wikitext] => 1 ) [headers] => ([If-Match] => [Accept] => text/html; charset=utf-8; profile="https://www.mediawiki.org/wiki/Specs/HTML/2.0.0" [Accept-Language] => en [User-Agent] => VisualEditor-MediaWiki/1.35.0-rc.3 [Api-User-Agent] => VisualEditor-MediaWiki/1.35.0-rc.3 ) Edmond Media (talk) 20:15, 1 October 2020 (UTC)

on the previous message it should say myWebsite instead of en.wikipedia.org (the spam filter was blocking it when I had my website there) Edmond Media (talk) 20:16, 1 October 2020 (UTC)

The exact same setup works on my local machine when running with localhost. Same OS, Debian 10.6. Same packages. The only difference is that this error is when deploying on the AWS cloud.

Could it have anything to do with the base ref having to be localhost on the POST message?

Could it be that it should be http and not https, my EC2 instances only have port 80 open, I believe the load balancer forwards http to the EC2 instances? Edmond Media (talk) 20:40, 1 October 2020 (UTC)

This appears to be related to HTTPS. When I use http I can save using VisualEditor. I get the error only when using SSL. Tstout21 (talk) 21:23, 1 October 2020 (UTC)

Thanks Tstout21

I tied hacking the file /var/www/html/w/extensions/VisualEditor/includes/ApiParsoidTrait.php with the following:

$request['body']['html'] = '<!doctype html><html><head><base href="localhost/w/"><base href="localhost/w/"></head><body><p>Test Text for Test PAGE</p></body></html>';

also tried using http + localhost and http + mywebsite but none worked... 85.255.235.204 (talk) 22:25, 1 October 2020 (UTC)

I reinstalled MediaWiki and it works now.... Edmond Media (talk) 15:32, 4 October 2020 (UTC)

Same issue on 1.36.1 of mediawiki. Tried reinstalling it and it does not work. Corruptedxcomics (talk) 01:10, 22 August 2021 (UTC)

For me the problem was in the LocalSettings.php file. The URL path of the installation was there without http. I changed it to https. Now it works. 138.188.55.41 (talk) 16:29, 22 November 2021 (UTC)

Thank you!!! After chasing a bunch of different suggestions, this seems to have actually fixed it! OurOakland (talk) 23:36, 8 July 2022 (UTC)

After a new install, I got HTTP 5xx errors. Based on other suggestions, I added an SSL certificate, but then I got HTTP 415 errors instead. I tried other suggestions, but this seems to have actually worked. OurOakland (talk) 23:40, 8 July 2022 (UTC)

For those who stumble upon this, specifically I changed the URL in $wgServer from http: to https:

## The protocol and server name to use in fully-qualified URLs

$wgServer = ... OurOakland (talk) 23:43, 8 July 2022 (UTC)

Sigh. Not sure what else changed (I've been trying different map extensions), but I'm back to HTTP 500 errors from the Visual Editor. OurOakland (talk) 21:30, 11 July 2022 (UTC)

Narrowed this down to pages that I've added a map to for display by Extension:Maps. For example, if I add {{#display_map:145 Athol Avenue, Oakland, CA|zoom=15}} to a test page using edit source, then I get HTTP 500 errors after that when using the Visual Editor. OurOakland (talk) 22:48, 11 July 2022 (UTC)

I have fixed the error by changing http: to https: in the LocalSetting.php file.

Thanks to 138.188.55.41 ! Perohanych (talk) 08:40, 13 June 2022 (UTC)

Thanks for the update, I had the same problem and this is what solved it for me 77.127.209.224 (talk) 12:16, 22 November 2023 (UTC)

Error contacting the Parsoid/RESTBase server: http-bad-status

The problem

This issue seems to occur on private wikis:

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

because VisualEditor accesses your pages as an Anonymous user (and thus can't see the page at all).

The workaround

Add the following to your LocalSettings.php after all of your $wgGroupPermissions configurations (ideally at the very, very end):

if ( $_SERVER['REMOTE_ADDR'] == 'YOUR_SERVER_IP' ) {
  $wgGroupPermissions['*']['read'] = true;
  $wgGroupPermissions['*']['edit'] = true;
  $wgGroupPermissions['*']['writeapi'] = true;
}

...while replacing YOUR_SERVER_IP with the server's IP address. You can get this using curl, for example:

curl ifconfig.me

Maybe they'll fix it

There is an open ticket for this issue where you can express your opinion on this.

I've just finished upgrading from MW 1.33 to 1.35. I have the following VisualEditor-relevant options in my LocalSettings.php file:

// Enable by default for everybody
$wgDefaultUserOptions['visualeditor-enable'] = 1;
// Set VisualEditor as the default
$wgDefaultUserOptions['visualeditor-editor'] = "visualeditor";

When I try to edit a page, VisualEditor tries to load, but then spits out the following error:

Error contacting the Parsoid/RESTBase server: http-bad-status

Looking in the console, this is error code apierror-visualeditor-docserver-http-error.

I'm not sure what this means but it sounds like not only is something wrong but the error handler is receiving an unsupported status code? Any help appreciated. Chitinlink (talk) 19:05, 2 October 2020 (UTC)

VisualEditor/PHP will contact wiki/rest.php or w/rest.php when you go into visual editing. If you are already using rewrites to make nice short URLs, you may find that - your rewrite rule will make the call to rest.php redirect to index.php, which gives a 404.

If you just ignore redirecting call to rest.php, your visual editor will work but cannot load page contents - it is accessing rest.php/yourdomain.name/v3/.... to load the page content, which cannot be ignored by checking rest.php.

The solution is, check the HTTP_USER_AGENT - VisualEditor make its access with UA: VisualEditor-MediaWiki/1.35.0. Add the bold line to every rewrite rules you defined for mediawiki (I'm assuming you are using apache2, tweak this accordingly if you are using other service):

RewriteCond %{REQUEST_URI} !^(static)

RewriteCond %{HTTP_USER_AGENT} !^(VisualEditor)

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d

RewriteRule ^(.*)$ %{DOCUMENT_ROOT}/wiki/index.php [L]

This will not make any rewrite to calls from VisualEditor and make it successfully access page contents and load it without affect other short URLs. LapisLazuli33 (talk) 09:59, 3 October 2020 (UTC)

My wiki is not set up to have a short URL. My URLs look like this: https://wiki.whatever/index.php/PageTitle

This is a private wiki, also. https://phabricator.wikimedia.org/T88016 Chitinlink (talk) 22:22, 3 October 2020 (UTC)

So to reiterate, my wiki is private. (maybe has something to do with this?)

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

I have the following VisualEditor related options set:

wfLoadExtension( 'Parsoid', 'vendor/wikimedia/parsoid/extension.json' );
$wgGroupPermissions['user']['writeapi'] = true;
// Enable by default for everybody
$wgDefaultUserOptions['visualeditor-enable'] = 1;
// Set VisualEditor as the default
$wgDefaultUserOptions['visualeditor-editor'] = "visualeditor";

The Extension:VisualEditor page as of right now has a banner at the top that says "This extension comes with MediaWiki 1.35 and above. Thus you do not have to download it again. However, you still need to follow the other instructions provided.". The other instructions I need to follow are not exactly clear, honestly...

Further down the page on a section I didn't follow, there's a warning, saying that RESTBase should not be installed on private wikis. Is RESTBase installed on my wiki just by virtue of VisualEditor being bundled with 1.35? Again, I'm getting a RESTBase error when I try to edit pages. Chitinlink (talk) 14:45, 5 October 2020 (UTC)

Your configuration will not be working.

Please remove the line

wfLoadExtension( 'Parsoid', 'vendor/wikimedia/parsoid/extension.json' );

from your config.

Also make sure that you are not setting anything in

$wgVirtualRestConfig['modules']['parsoid']. If you set anything there, Parsoid will no longer be found automatically. Jörgi123 (talk) 19:45, 8 October 2020 (UTC)

I've removed the line you mentioned, and confirmed my LocalSettings.php doesn't touch $wgVirtualRestConfig.

As before, I continue to have the same issue: VE loads when creating a new page, but when editing an existing one, throws: "Error contacting the Parsoid/RESTBase server: http-bad-status" Chitinlink (talk) 04:52, 20 October 2020 (UTC)

Jörgi123's advice looks correct to me. cscott (talk) 21:13, 15 October 2020 (UTC)

The "VE can't contact Parsoid/RESTBase" error is rather generic and it mentions two possible causes (choose the one that applies to you). This doesn't mean you have RESTBase installed, and you probably don't. Ciencia Al Poder (talk) 20:21, 5 October 2020 (UTC)

As Technoabyss, I find the description rather confusing. Could you please tell, Ciencia Al Poder, is an additional RestBase installation needed for a 1.35 or not? For me, i am getting an Error contacting the Parsoid/RESTBase server: http-request-error with my 1.35 installation. Actually, this directly points to a missing RestBase but my assumption was that the VisualEditor works out of the box. Aschroet (talk) 18:45, 8 October 2020 (UTC)

An additional Restbase installation is not needed. It is optional, you do not need it. Jörgi123 (talk) 19:28, 8 October 2020 (UTC)

...however, if you happen to configure something related to $wgVirtualRestConfig in your LocalSettings (which may be set for other extensions, like math), then MediaWiki will connect only to RESTBase Ciencia Al Poder (talk) 15:34, 9 October 2020 (UTC)

@Technoabyss, were you able to resolve your issue? I too don't have Short URLs enabled, and VE does not work out-of-the-box (i.e. fresh install). Rehman 12:56, 11 October 2020 (UTC)

Sorry for not following up on this. I will be trying everyone's suggestions in a moment

Edit: As before, nothing about my situation has changed... I've gone ahead and done as @Jörgi123 recommended, but the issue remains. Chitinlink (talk) 04:45, 20 October 2020 (UTC)

Screenshots of the request as shown in the dev console when I open the page for visual editing:

Chitinlink (talk) 08:23, 20 October 2020 (UTC)

I just solved similar issue by removing extensions/VisualEditor and installing it again. Spas.Z.Spasov (talk) 18:57, 29 October 2020 (UTC)

Same exact error for me. That response code , somewhat useless as it is (state what url/port/anything really has failed to be reached, we're clearly getting to api.php, but what is being tried from there?), sounds more like it's trying to reach something at an old location. Have you managed to get any further here? 50.204.98.114 (talk) 21:07, 2 November 2020 (UTC)

No, though I haven't really tried much since my last post. Do you happen to also have a private wiki? Chitinlink (talk) 21:21, 2 November 2020 (UTC)

I do, my upgrade has been from 1.15 to 1.35, so more prone to issues I'd believe. I'm running the new wiki on fresh 20.04 and fwiw the visual editor worked for saving new pages and editing before I restored and updated the database (without errors).

Being that the error is so vague I want to believe there's something stale or failed in there causing this issue, but mediawiki's debug log doesn't throw any obvious errors. I suppose for now I'm waiting for someone else to figure this out or 1.36. Unless there's someone here who happens to know if update.php doesn't run something needed for the new visualeditor config to work.

If I had any other insight to add, I do get a different error (There is no revision with ID 0.) by editing source on an existing page and moving back to the visual editor, then hitting try again when failed to load. 50.204.98.114 (talk) 21:43, 2 November 2020 (UTC)

Well I got it. For me at least. I had $wgGroupPermissions['*']['read'] = false; set in my LocalSettings.php which appears to cause this. Does this mean the visualeditor is actually a user? If so, what group/user can I allow read permissions to fix this but still keep read limited to groups of my choosing? 50.204.98.114 (talk) 17:39, 3 November 2020 (UTC)

I've made a bug report. Chitinlink (talk) 20:38, 19 November 2020 (UTC)

I solved this for my private wiki by following these steps linked here under 401 error.

I found I also had the same issue if I restricted the site using .htaccess and .htpasswd, instead of making it private.

The only issue I have now is that Visual Editor does not show recently uploaded files when you insert media. Sidnaught (talk) 22:11, 26 November 2020 (UTC)

I have this error and I don't have a private wiki. It only shows up for a particularly large page. Most pages are able to be edited properly. Metalliqaz (talk) 20:10, 29 November 2020 (UTC)

I've solved too, like Sidnaught, by adding following lines into LocalSettings.php

if ( $_SERVER['REMOTE_ADDR'] == '<THE_IP_ADDRESS_OF_SERVER_WHERE_YOUR_MEDIAWIKI_1.35_WITH_BUNDLED_VE_IS_RUNNING>' ) {
        $wgGroupPermissions['*']['read'] = true;
        $wgGroupPermissions['*']['edit'] = true;
}

note: use the actual ip address (not local host or 127.0.0.1) too if parsoid is actually running on the same server. 89.251.251.99 (talk) 15:40, 30 November 2020 (UTC)

Well, I fixed it following the same instructions. We've also got some attention on the issue I opened, so maybe at some point this workaround will no longer be necessary. Chitinlink (talk) 17:12, 1 December 2020 (UTC)

Keep in mind that the fix needs to be at the very end of your configuration, after you've set your other $wgGroupPermissions variables. Otherwise, it'll just get overridden. Jeffrey Wang 08:02, 20 April 2021 (UTC)

Hi @Woozle, I saw your recent edit to the summary. I've changed it back to the previous version because specifying the client's browser IP address is incorrect. The reason we use the server's IP is because the server is making cURL requests to itself. Logically, specifying the client's IP doesn't really make any sense either—it stands to reason that if they are editing with VisualEditor, they already have edit permissions. Jeffrey Wang 20:21, 11 July 2021 (UTC)

I think perhaps some more explanation is needed, then, because this is inconsistent with the workaround code given:

if ( $_SERVER['REMOTE_ADDR'] == 'YOUR_SERVER_IP' ) {
  $wgGroupPermissions['*']['read'] = true;
  $wgGroupPermissions['*']['edit'] = true;
}

According to the PHP docs for $_SERVER:

• $_SERVER['REMOTE_ADDR'], which this example uses, is "The IP address from which the user is viewing the current page." i.e. the browser/client
• $_SERVER['SERVER_ADDR'] is "The IP address of the server under which the current script is executing."

...so if this works as you say, wouldn't you want to use the latter?

I also verified that Apache is in fact being accessed from my client machine, and not from the machine serving it, by inserting some code into LocalSettings which logs the value of $_SERVER['REMOTE_ADDR']. When I attempted to save a page through VisualEditor, all the IP addresses logged were in fact my client IP, not the server's IP. Woozle (talk) 20:56, 11 July 2021 (UTC)

What I've said is perfectly consistent with the workaround code given, so you'll want to use the former.

• When the browser makes requests to MediaWiki, it's authorized to edit using the user's permissions. In this case, it's simple: the browser is the client and the server is the server.
• When PHP Parsoid needs to communicate with MediaWiki, it needs to access the MediaWiki API to either read, write, or both. (Not sure how this is exactly done yet in PHP Parsoid, which is why I guess the prevailing solution is to go ahead and grant both permissions.) In this case, Parsoid is the client making the requests to MediaWiki's API, and Parsoid now runs from the same server as MediaWiki. Therefore, in this case, the server is its own client. Apparently, when they released PHP Parsoid, they neglected to test how Parsoid is supposed to access the MediaWiki API if the wiki doesn't allow anonymous read/edit. This is the problem that this code snippet attempts to resolve. Since Parsoid doesn't have a "username" or some sort of API key that gives it special powers to do stuff, I guess this is the workaround that is required for now.

Why does Parsoid need to do internal talking to MediaWiki? Well, there's a lot of stuff that can't be done from the client side. They will need to do their own communication behind closed doors, and the browser is not privy to these communications.

This fix doesn't attempt to provide to fix an access issue for the end user, but rather for Parsoid accessing the MediaWiki API. Nothing is wrong with the browser-web server relationship, but something is wrong with the Parsoid-MW API interface. That's why we don't even consider the browser in this case. Hope that makes sense.

In response to: "When I attempted to save a page through VisualEditor, all the IP addresses logged were in fact my client IP, not the server's IP."

I'm assuming this is the Apache access log. What endpoint is logged as being accessed?

I would like to note that using the server IP, not the client IP, has worked for the rest of the commenters and the hundreds of wikis at MyWikis using VisualEditor. Please elaborate on how it would be possible to allow all client IPs to edit without allowing IPs not yet logged into MediaWiki. Jeffrey Wang 00:14, 12 July 2021 (UTC)

Okay, I think I understand what you're getting at: when dealing with Parsoid internal API requests, the server acts as the client.

I think I was confused because this doesn't match the behavior I'm seeing -- but it's possible there are other reasons for that: from what I can tell, the rest.php entry-point is (for some reason) rejecting requests from my browser (returning a 404 or 405 in its JSON response, depending on what is sent), so possibly the code never gets to the point where Parsoid makes its internal request, and therefore I don't see those requests in my logs.

I'm abandoning this issue for now as being non-critical-path, but I may get back to it at some point if it's not fixed upstream soonish.

Thanks for your explanation, and sorry for confusion on my part. Woozle (talk) 12:26, 12 July 2021 (UTC)

After everything in this thread failed. I was able to fix this by fixing my nginx config to allow path arguments to the rest.php script (wiki/rest.php/path/arguments)

location ~ \.php$ { to location ~ \.php(/|$) { and adding fastcgi_split_path_info ^(.+\.php)(/.+)$; MrStonedOne (talk) 00:58, 2 November 2021 (UTC)

Hello,

Here's the relevant content of my LocalSettings.php

wfLoadExtension( 'VisualEditor' );

wfLoadExtension( 'Parsoid', 'vendor/wikimedia/parsoid/extension.json' );

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

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

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

$wgVirtualRestConfig['modules']['parsoid']['forwardCookies'] = true;

if ( $_SERVER['REMOTE_ADDR'] == 'XXX' ) {

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

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

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

}

Where XXX is my server IP address.

This didn't fix it for me... any idea what I did wrong?? UGOBOSS777 (talk) 00:21, 24 December 2021 (UTC)

Note that XXX must be the server address as seen when it creates outgoing requests to itself. It may be 127.0.0.1 and not a public IP, depending on how it's configured Ciencia Al Poder (talk) 08:48, 24 December 2021 (UTC)

I tried with 127.0.0.1... It didn't work for me UGOBOSS777 (talk) 04:28, 2 January 2022 (UTC)

@UGOBOSS777 Try replacing the if condition with: $_SERVER['REMOTE_ADDR'] === $_SERVER['SERVER_ADDR'] Jeffrey Wang 06:01, 25 December 2021 (UTC)

I changed the condition, still doesn't work UGOBOSS777 (talk) 04:29, 2 January 2022 (UTC)

This is the at-the-end-of-LocalSettings.php workaround that worked for me:

# To be added at the very bottom of /opt/meza/src/roles/mediawiki/templates/LocalSettings.php.j2 to allow VE to work in 35.x when meza_auth_type is "viewer-read" and apache is 100% localhost behind an SSL terminator/load-balancer/proxy front-end (like haproxy)
# Define and calculate "remote_ip_test" based on hierarchy of what we know about the requestor's origin from the request header
# Result: "remote_ip_test" is 127.0.0.1 if-and-only-if it is truly an internal server-side request
if     (!empty($_SERVER['HTTP_CLIENT_IP']))       { $remote_ip_test = $_SERVER['HTTP_CLIENT_IP']; }
elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) { $remote_ip_test = $_SERVER['HTTP_X_FORWARDED_FOR']; }
elseif (isset($_SERVER['REMOTE_ADDR'] ) )         { $remote_ip_test = $_SERVER['REMOTE_ADDR']; }
# If the request is truly an internal server-side request, then open the wiki up for full access
if (isset($remote_ip_test) && $remote_ip_test == '127.0.0.1') {
  $wgGroupPermissions['*']['read'] = true;
  $wgGroupPermissions['*']['edit'] = true;
  $wgGroupPermissions['*']['writeapi'] = true;
}

Revansx (talk) 04:44, 27 December 2021 (UTC)

Hi all,

I've tried everything on this page that I could and so far nothing is working for existing pages. The visual editor loads for new pages but dies with the error on existing pages. This is after a new install and XML import of a previous wiki.

I have my wiki behind a pfSense box, so it has a public ip on 1:1 NAT to a private IP. I've obviously tried the code at the top of this page with public, private, and local loopback 127.0.0.1 addresses, but to no effect. I've also tried Revansx's code as well. I'm running Ubuntu 20.04 and apache2.

curl ifconfig.me shows my public IP, while ip a shows my private and local loopback IPs.

Any other ideas on what could be preventing this from working for me?

Thanks,

-Seth 206.123.222.162 (talk) 20:33, 29 December 2021 (UTC)

If you are experiencing this problem only on existing pages, but are able to create a new page and add a heading/paragraph and save it again, the problem may be a glitch in the wiki formatting itself.

In my case after switching from the basic code-only editor to VisualEditor, any page that included a preformatted textblock that itself also contained URLs seemed to throw this error. I removed the offending block(s) and replaced them with INSERT → MORE → CODE BLOCK and the problem went away.

I did not have to alter any other permissions or options even with a private wiki, it was just an odd parsing/content issue with some preformatted blocks. I have nothing special in LocalSettings.php, the following works fine (for private):

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

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

$wgGroupPermissions['*']['read'] = false; MattPilz (talk) 01:33, 10 January 2022 (UTC)

Well drat. The visual editor loads when I create a new page, but when I go to save the page I get the error:

Error contacting the Parsoid/RESTBase server: (curl error: 7) Couldn't connect to server

...so I can't even save a new page created w/ the visual editor.

Back to the drawing board.

-Seth 206.123.222.162 (talk) 16:36, 12 January 2022 (UTC)

My private wiki (v1.35) runs in an AWS VPC and is exposed by an ALB (Application Load Balancer). The only way I could get this to work was to use the ALBs private IP addresses rather than the servers IP address. This is obviously a problem. Since all traffic is coming from the load balancer every request is made to the server with these IPs. Is there a way for me to configure the host that Parsoid uses to make its requests?

Regardless of whether or not the wiki is private it seems ridiculous that I can't use a loopback to avoid network overhead, these requests should not have to leave my network if they are being made against my server.

I am having a hard time finding any substantial documentation for configuring Parsoid. The "Installation" section of the main page says "No configuration necessary if used on a single server.", but then doesn't provide any information about what configuration would be necessary if in a multi-server environment. Most of the information on that page seems to be targeted towards people developing Parsoid, not people using it.

What am I missing?

I found the following but I haven't been able to get it to work for me. I would rather not go down the path of creating a separate Parsoid server.

$wgVirtualRestConfig['modules']['parsoid'] = array(
    // URL to the Parsoid instance.
    // You should change $wgServer to match the non-local host running Parsoid
    'url' => $wgServer . $wgScriptPath . '/rest.php',
    // Parsoid "domain", see below (optional, rarely needed)
    // 'domain' => 'localhost',
);

I tried using this to get Parsoid to stay within the server but no luck so far. It says "non-local host" but I am hoping I can trick it into calling itself locally using the loopback. I will probably have to dig into the code to figure how this actually works and if what I am trying to do is possible. Ajmichels (talk) 20:20, 10 March 2022 (UTC)

I had a problem with mediawiki (v.138) in private wiki in AWS with an ALB.

The configuration of apache was only listening in 80 port. LoadBalancer end TLS connection and send conection to port 80 in Apache

When I try to open Visual Editor I was obtein "Parsoid/RESTBase server: http-bad-status"

I put the configuration in LocalSettings.php

if ( $_SERVER['REMOTE_ADDR'] == '127.0.0.1' ) {
  $wgGroupPermissions['*']['read'] = true;
  $wgGroupPermissions['*']['edit'] = true;
}

I modify /etc/host with

127.0.0.1 url_my_wiki

The problem is that connection to Visual Editor is trying to use https connection and don't find 443 port in apache.

The solution is enable https in apache and put a let's encrypt certificate in 443 apache port.

If you use certbot to install certificate, you have to modify http virtualhost to disable redirection that certbot have installed. You have comment

#RewriteCond %{SERVER_NAME} =url_my_wiki
#RewriteRule ^ h t t p s://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

CapNida (talk) 12:15, 17 November 2022 (UTC)

I had the same problem using the Wiki Visual Editor in my microsoft edge browser.

also using the other wiki editor produced the same problem.

Solution - problem solved by good workaround:

When I copied my improved draft version to the same draft URL page, but on my Chrome browser, everything there went ok. No more such error.

This was found just by trial and error. I cannot give a technical explanation. DJ7BA (talk) 12:23, 3 April 2022 (UTC)

I only get the "Error contacting the Parsoid/RESTBase server: http-bad-status", if I am using "nested" or structured pages.

It works for pages like TestPage, VideoCut, BestPractices (so "level 1") but not for pages like TestPage/Test1, TestPage/Hugo (so "level2").

When looking at the webserver (e.g. apache2) log files, it seams the rest.php URL is not build correctly.

In the good case the build rest.php send the following POST request:

POST /wiki/rest.php/localhost/v3/transform/html/to/wikitext/TestPage/12 HTTP/1.1" 200 521 "-" "VisualEditor-MediaWiki/1.38.2"

In the bad case the request looks like:

POST /wiki/rest.php/localhost/v3/transform/html/to/wikitext/TestPage%2FTest1 HTTP/1.1" 404 981 "-" "VisualEditor-MediaWiki/1.38.2"

It ends-up in a 404 instead of a successful 200. The problem seams to be the coded %2F (/) inside the Page-Path (TestPage/Test1 -> TestPage%2FTest1). Fmherschel (talk) 08:43, 16 July 2022 (UTC)

Your web server is (incorrectly) URL-encoding the page portion of the URL, as if it were a URL parameter instead of a full path. Take a look at your rewrite rules or whatever configuration you have to handle /wiki/rest.php requests and configure it to not encode them. Ciencia Al Poder (talk) 10:08, 16 July 2022 (UTC)

I am a bit confused, because I did not activated any re-write of URLs, because I did read in this forum already that this is not a good idea or at least needs to be configured in a proper way.

During my research I found that mod_rewrite is doing URL rewrites for apache2. I tried the following scenarios:

1. Still have de-activated mod_rewrite (-> still get the error)
2. Activating mod_rewrite but having 'RewriteEngine off' in the wiki root directory (.htaccess) (-> still get the error)

Then I again deactivated the mod_rewrite module. Now I need to find out what triggers apache2 to rewrite or encode the URL. Fmherschel (talk) 10:04, 24 July 2022 (UTC)

The solution on my system is to add the directive

AllowEncodedSlashes NoDecode

to the apache2 configuration.

Just wanted to share that here, please take my pardon, if I missed that to already documented. Fmherschel (talk) 10:09, 24 July 2022 (UTC)

Sorry it me again ;-)

And even better is to set

AllowEncodedSlashes On

because then the path-logs in /var/log/apache2/access.log gets readable again. Fmherschel (talk) 10:15, 24 July 2022 (UTC)

Looks like that solution was already provided in the Troubleshooting section of the page. Ciencia Al Poder (talk) 20:35, 24 July 2022 (UTC)

This is related to editing SubPages with VisualEditor, running on a Bitnami Wamp Stack on Windows 10. When you try to edit a page which title has a subpage like MyPage/MySubpage, than the error "Error contacting the Parsoid/RESTBase server (HTTP 404)" starts to happen if using VisualEditor, but don't happen when using Source Editor.

Update:

After checking possible solutions at StackOverflow (), I added a parameter to Apache conf. Specifically on the Bitnami installation folder:

File: [BitnamiWampStackRoot]\apache2\conf\bitnami\bitnami.conf

<VirtualHost _default_:[YOUR_PORT]>

AllowEncodedSlashes NoDecode <<- add this line

</VirtualHost>

Update 2:

Since the Parsoid access internally (by default) http://127.0.0.1, the setting AllowEncodedSlashes NoDecode also need to be added inside the :80 conf of your virtual host settings. WilliamKnak (talk) 11:23, 9 August 2022 (UTC)

In 1.35 I have run into error 400 only when editing. Adding a new record allowed Parsoid Visual Editor but editing threw the error.

Adding the specific domain to my /etc/hosts file on the Linux server solved my issue.

parsoid service threw error 400 on editing and failed.

adding to hosts file fixed it until the solution is known

127.0.0.1 yourwikidomain.com Compumatter (talk) 17:55, 23 August 2022 (UTC)

I have the solution. I switched on every conceivable debugging option listed in:

Manual:How to debug

These settings are to be added to LocalSettings.php, as follows:

1. At the top, right under <?php

error_reporting( -1 ); 
ini_set( 'display_errors', 1 );

2. At the bottom, underneath "# Add more configuration options below."

$wgShowExceptionDetails = true; 
$wgDebugToolbar = true; 
$wgShowDebug = true; 
$wgDevelopmentWarnings = true; 
$wgDebugDumpSql = true;

I then started requesting the visual editor URL in a new tab, incrementally subtracting query parameters until I discovered that leaving off the json query parameter gives me a proper error output as expected from the debug options which were previously enabled.

(http obfuscated to evade spam filter) hxxp://<your domain>/api.php?action=visualeditor&format=json&paction=parse&page=Main_Page&uselang=en&formatversion=2

In other words, at some point I got to format=json, removed it, reloaded and got the following output:

{
  "message": "Error: exception of type RuntimeException: bcmath or gmp extension required for 32 bit machines.",
  "exception": {
    "id": "f1802bf2024967674634873f",
    "type": "RuntimeException",
    "file": "/var/www/html/includes/libs/uuid/GlobalIdGenerator.php",
    "line": 637,
    "message": "bcmath or gmp extension required for 32 bit machines.",
    "code": 0,
    "url": "/rest.php/<your domain>/v3/page/html/Foo1/14?redirect=false&stash=true",
    "caught_by": "other",
    "backtrace": [
      {
        "file": "/var/www/html/includes/libs/uuid/GlobalIdGenerator.php",
        "line": 222,
        "function": "intervalsSinceGregorianBinary",
        "class": "Wikimedia\\UUID\\GlobalIdGenerator",
        "type": "->",
        "args": [
          "array",
          "integer"
        ]
      },
      {
        "file": "/var/www/html/includes/libs/uuid/GlobalIdGenerator.php",
        "line": 211,
        "function": "getUUIDv1",
        "class": "Wikimedia\\UUID\\GlobalIdGenerator",
        "type": "->",
        "args": [
          "array"
        ]
      },
      {
        "file": "/var/www/html/includes/utils/UIDGenerator.php",
        "line": 88,
        "function": "newUUIDv1",
        "class": "Wikimedia\\UUID\\GlobalIdGenerator",
        "type": "->",
        "args": []
      },
      {
        "file": "/var/www/html/extensions/VisualEditor/includes/VEParsoid/src/Rest/Handler/ParsoidHandler.php",
        "line": 610,
        "function": "newUUIDv1",
        "class": "UIDGenerator",
        "type": "::",
        "args": []
      },
      {
        "file": "/var/www/html/extensions/VisualEditor/includes/VEParsoid/src/Rest/Handler/PageHandler.php",
        "line": 90,
        "function": "wt2html",
        "class": "VEParsoid\\Rest\\Handler\\ParsoidHandler",
        "type": "->",
        "args": [
          "VEParsoid\\Config\\PageConfig",
          "array"
        ]
      },
      {
        "file": "/var/www/html/includes/Rest/Router.php",
        "line": 414,
        "function": "execute",
        "class": "VEParsoid\\Rest\\Handler\\PageHandler",
        "type": "->",
        "args": []
      },
      {
        "file": "/var/www/html/includes/Rest/Router.php",
        "line": 338,
        "function": "executeHandler",
        "class": "MediaWiki\\Rest\\Router",
        "type": "->",
        "args": [
          "VEParsoid\\Rest\\Handler\\PageHandler"
        ]
      },
      {
        "file": "/var/www/html/includes/Rest/EntryPoint.php",
        "line": 168,
        "function": "execute",
        "class": "MediaWiki\\Rest\\Router",
        "type": "->",
        "args": [
          "MediaWiki\\Rest\\RequestFromGlobals"
        ]
      },
      {
        "file": "/var/www/html/includes/Rest/EntryPoint.php",
        "line": 133,
        "function": "execute",
        "class": "MediaWiki\\Rest\\EntryPoint",
        "type": "->",
        "args": []
      },
      {
        "file": "/var/www/html/rest.php",
        "line": 31,
        "function": "main",
        "class": "MediaWiki\\Rest\\EntryPoint",
        "type": "::",
        "args": []
      }
    ]
  },
  "httpCode": 500,
  "httpReason": "Internal Server Error"
}

I was using Docker, and I needed to install bcmath.

In docker, first you enter the Docker container (named "mediawiki" in my case, you may have a different name, or even a hashed id) and start a shell inside it like so:

docker exec -it mediawiki /bin/bash

Then, you install bcmath, like so:

docker-php-ext-install bcmath

Then, you exit, and you restart the container, like so:

docker restart mediawiki

Visual editing now works. This was necessary for me, because my Docker image runs on ARM 32-bit.

Note that e.g. x86 Ubuntu users running php 7.4 can install the package with:

sudo apt update && sudo apt -y install php7.4-bcmath

...And they can adjust the php version in the package name to a different version if so required. Oberman23 (talk) 13:09, 17 October 2022 (UTC)

Error contacting the Parsoid/RESTBase server (HTTP 404): (no message) 106.202.209.74 (talk) 15:04, 18 October 2022 (UTC)

help me sir to solve this problem 106.202.209.74 (talk) 15:04, 18 October 2022 (UTC)

Unless you provide all the steps you've tried to solve the problem (listed on this thread), the server software used and your configuration, nobody is able to help you to solve the problem.

Alternatively, you may be interested in Professional development and consulting Ciencia Al Poder (talk) 16:54, 18 October 2022 (UTC)

Now this is really driving me nuts. When I create an article and edit it with the Visual Editor, everything works fine. BUT when I use in the article the word ".htaccess" (literally), this triggers the "Error contacting the Parsoid/RESTBase server (HTTP 403)". When changing ".htaccess" to "htaccess" (without period), everything works again as expected. Woot?! O.o Anyone else experienced this issue? ZelulaX (talk) 09:18, 18 November 2022 (UTC)

VisualEditor fails with HTTP 403 errors on NameCheap hosting with Apache

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I recently encountered this issue when deploying MediaWiki 1.35 + VisualEditor onto Namecheap Shared Hosting which uses Apache.

If you experience this error when attempting to save a page, it is likely that ModSecurity has triggered a warning. In order to resolve this issue I simply had to contact Namecheap support and request that they whitelist the security rules that were being triggered on my site, since then I have been able to use VisualEditor perfectly fine. Csharries (talk) 20:40, 5 October 2020 (UTC)

Hello. I too am on Namecheap shared hosting (Apache). It is quite frustrating that everyone talks about this out-of-the-box issue, but there seems to be no clear solution. Would you be able to share your ticket number with me please (email?), so that I can try reaching out to namecheap, asking them if they can apply that fix for me? Rehman 03:54, 9 October 2020 (UTC)

Did you try this already? SSastry (WMF) (talk) 14:37, 15 October 2020 (UTC)

Hello @Csharries, I cannot thank you enough for sharing the above. You are right. I did contact Namecheap and their ModSecurity WAF was the cause of the issue. Once they turned it off on all my test domains/subdomains, VE worked.

I cannot seem to create or edit in [at least] the User namespace though, but I guess that is a VE setting.

I doubt I'd be able to resolve this issue if you hadn't posted the above comment. So, thank you again.

For anyone wanting to contact Namecheap for the same issue, you may quote the ticket number QSE-776-10867. For others, just see if your hosting service have ModSecurity or another WAF enabled, and if they could turn it off (at least temporarily) for you to test.

Hope this helps. Rehman 03:54, 17 October 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Fresh 1.35 install, Error contacting the Parsoid/RESTBase server: (curl error: 35) SSL connect error

On a fresh MediaWiki 1.35 install, I'm getting this error when I attempt to edit a page with the Visual Editor. With $wgDebugLogFile enabled, I get this in the log:

[http] Error fetching URL "[myhostname]/rest.php/[myhostname]/v3/page/html/Main_Page/1?redirect=false&stash=true": (curl error: 35) SSL connect error

If I try to visit that URL in my browser, I get a 403 error.

I have tried both open and closed MediaWiki installations; it makes no difference. KeenMouse (talk) 18:57, 7 October 2020 (UTC)

I have started a relative task in Phabricator: Error contacting the Parsoid/RESTBase server (HTTP 403)" when trying to edit an existing page with VisualEditor

You can subscribe or even contribute to it if you wish. Costas Athan (talk) 18:24, 8 October 2020 (UTC)

VisualEditor incompatible with Media: direct links?

This is captured by https://phabricator.wikimedia.org/T265144

We upgraded wo MediaWiki 1.35 and can now use Visual Editor that comes built into MediaWiki. Everything works fine except when the page has Media: links, e.g. links to PDF files.

When editing a page with Media: links, the links are replaced by index.php?title=Media:.... on save even when the links themselves are not edited. If I try to edit the links, very strange things happen. If I create a new link Media:Link.pdf in the link editor, the link changes to =Media:link.pdf, or it just changes to a red link to the text of the link and the link itself is lost. Sometimes it cuts the word media to edia:Link.pdf. In all cases, the links are broken.

I could not see errors in the debug log.

Mediawiki is installed on a subdomain root, and all standard mediawiki features have worked fine for years.

Is there anything I can try?

MediaWiki	1.35.0
PHP	7.3.23 (cgi-fcgi)
MariaDB	10.1.47-MariaDB
ICU	4.2.1
Lua	5.1.5
VisualEditor	0.1.2

Entry point	URL
Article path	/index.php?title=$1
Script path	/
index.php	/index.php
api.php	/api.php
rest.php	/rest.php

Ryansbudza (talk) 08:08, 9 October 2020 (UTC)

This is https://phabricator.wikimedia.org/T265144 SSastry (WMF) (talk) 14:40, 15 October 2020 (UTC)

Does VE have a known bug in 1.35?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hello. After unsuccessfully searching for the answer, I decided to ask this here.

It seems like a number of wiki owners cannot get VisualEditor running out-of-the-box in MW 1.35.

Is this a known problem, and has a solution been shared anywhere?

Pinging User:Reedy (based on the MW 1.35 announcement). Rehman 11:51, 11 October 2020 (UTC)

Do go through that ticket again now. Most users have been able to get their installs working. But, based on the email thread and the other namecheap thread, it looks like you need to manually configure your private wiki usecase and also figure out namecheap issues. SSastry (WMF) (talk) 14:38, 15 October 2020 (UTC)

Thank you for commenting. In my case, the issue was caused by the ModSecurity WAF used by Namecheap. I will share more details on the other threads. Rehman 03:46, 17 October 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Error contacting the Parsoid-/RESTBase-Server (HTTP 403)

I do get the error "Error contacting the Parsoid-/RESTBase-Server (HTTP 403)", as soon as I want to edit with Visual Editor. As long as I work with the source code, everythings fine.

I recently updated from MediaWiki 1.34 to MW 1.35, my wiki is not private and i run the website via cPanel/NameCheap. As I could not find any solution to my problem in the past week, i am now hoping to find help in this forum.

As I am a noob to wikimedia, i installed no extensions (except VisualEditor via MW 1.35) and the only additions i wrote into my localsettings.php are the following:

wfLoadExtension( 'VisualEditor' );

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

$wgVisualEditorParsoidAutoConfig = true;

These changes are the result of my former investigation. Without these VE is not shown as an option to edit my wiki.

Furthermore, the Insert-options i get by editing via VisualEditor are only for tabulars, images and comments. Options for inserting formulae or graphs are missing. As i want to insert mathematical equations, please tell me how to get this option into my VE.

I would appreciate any kind of support. Thanks in advance! Grimaldi42 (talk) 05:40, 16 October 2020 (UTC)

Check Extension talk:VisualEditor/2020#h-VisualEditor_fails_with_HTTP_403_errors_on_NameCheap_hosting_with_Apache-Maybe_they'll_fix_it-2020-10-05T20:40:00.000Z SSastry (WMF) (talk) 14:01, 17 October 2020 (UTC)

I had $wgGroupPermissions['*']['writeapi'] set to false and got the same error message ("Error contacting the Parsoid/RESTBase server (HTTP 403)").

Therefore, I suggest that you include the following: $wgGroupPermissions['*']['writeapi'] = true; Tlgonline (talk) 15:44, 19 October 2020 (UTC)

This has no change on the issue for me. 198.179.105.60 (talk) 16:34, 12 April 2021 (UTC)

Where did you change that setting??? 47.145.162.48 (talk) 03:18, 10 March 2021 (UTC)

Where in cpanel? 47.145.162.48 (talk) 03:44, 10 March 2021 (UTC)

I am putting this out more widely as an answer to this issue as I had a LOT of trouble resolving it. Basically, on some (cPanel) hosted sites the Parsoid/RESTBase Server API communications are blocked by several ModSecurity rules. I had to contact my hosting tech support and get them to whitelist rules for my wiki one or two at a time, while generating new ModSecurity rule errors by attempting to edit using VisualEditor until we had found all the rules which were resulting in this error. NB: At some point during this process a few pages might start working - not throwing a 403 - but then test a few more pages as they might still trigger ModSecurity.

To answer the last two questions above - you have to add that code as new lines in your wiki's LocalSettings.php file 220.244.3.130 (talk) 05:34, 7 June 2021 (UTC)

I've got the same problem here.

In my case the problem disappeared, when I removed the .htaccess file from the root folder of the server, which just allowed access from a specific IP address. GordonBernstein (talk) 20:28, 24 June 2021 (UTC)

Turn off notice create page

Hi all, can I turn off the notice "You have followed a link to a page that does not exist yet. To create the page, start typing in the box below (see the help page for more info). If you are here by mistake, click your browser's back button" I get when editing a new page. We have developed our own skin and now just want a blank page after clicking "Add new page", without a notice. It is unclear to the user, he/she just want to type text in a new page. Waanders (talk) 13:59, 16 October 2020 (UTC)

Now I read this VisualEditor/Feedback/Archive/2018/10#h-Is_it_possible_to_turn_off_the_notices_on_visual_editor?-2018-10-27T06:50:00.000Z and https://phabricator.wikimedia.org/T265798. No other way to achieve this? Waanders (talk) 17:19, 17 October 2020 (UTC)

Switch off VisualEditor on mobile version

Hi there! Can someone let me know how to switch off VisualEditor on mobile version of my site? (I use MobileFront end extension) Fokebox (talk) 16:53, 16 October 2020 (UTC)

VisualEdit on ssl return error "Parsoid/RESTBase server: (curl error: 60)"

When I set permanent redirect in apache to https i'm getting error "Parsoid/RESTBase server: (curl error: 60)".

Here is my VirtualHost configuration:

<VirtualHost wiki.***.eu:80>

ServerName wiki.***.eu

Redirect permanent / https ://wiki.***.eu/

</VirtualHost>

<IfModule mod_ssl.c>

...

<VirtualHost wiki.***.eu:443>

ServerName wiki.***.eu

DocumentRoot /var/www/wiki/

ErrorLog ${APACHE_LOG_DIR}/error.log

CustomLog ${APACHE_LOG_DIR}/access.log combined

SSLEngine on

SSLCertificateFile /etc/ssl/certs/nazwa/cert.pem

SSLCertificateKeyFile /etc/ssl/certs/nazwa/cert.key

<FilesMatch "\.(cgi|shtml|phtml|php)$">

SSLOptions +StdEnvVars

</FilesMatch>

<Directory /usr/lib/cgi-bin>

SSLOptions +StdEnvVars

</Directory>

</VirtualHost>

</IfModule> 5.252.214.1 (talk) 19:45, 21 October 2020 (UTC)

Error contacting the Parsoid/RESTBase server (HTTP 401)

I've got this error when I try to edit an article with Visual Editor. This error does not appear when I write a new article.

So, LapisLazuli33 wrote good pieces of information about rewrite rule. And so I found out, that my .htaccess auth file makes the problem:

AuthUserFile /www/htdocs/*/*/.htpasswd

AuthGroupFile /dev/null

AuthName 'please insert password'

AuthType Basic

require valid-user

When I rename the file, I can use VisualEditor. But this authorization is important for my NGO. Is there a way, I can use both? TruckerB88 (talk) 21:43, 26 October 2020 (UTC)

Yes same here on my test MediaWiki installation which is protected by a basic auth for the whole virtual host in nginx. If I delete the basic auth, everything is working fine. But I think there should be a way to use MediaWiki and VE behind a basic auth???

cheers

Andreas 46.5.70.252 (talk) 18:05, 29 October 2020 (UTC)

maybe the following helps, depending on your setup Project:Support desk/Flow/2020/10#h-Visual_Editor_on_a_password_protected_site-2020-10-14T21:00:00.000Z

It whitelists localhost, the VisualEditor user-agent, and an authenticated user...

  SetEnvIfNoCase User-Agent VisualEditor-MediaWiki/* visualeditor

  <Directory /var/www/>

               AuthUserFile /var/www/files/.htpasswd

               AuthName "Restricted Access"

               AuthType Basic

               Require local

               Require env visualeditor

               Require valid-user

  </Directory> Eddie K Smith (talk) 13:05, 4 November 2020 (UTC)

Thanks for the hint. I am using nginx and my solution is the following:

  # BASIC AUTH infront of the complete vhost
  # Excluding the VisualEditor user agent
  satisfy any;
  auth_basic 'Restricted Area';
  auth_basic_user_file /etc/nginx/conf.d/.htpasswd.pwd;
  auth_request /auth;
  location = /auth {
      if ($http_user_agent ~ VisualEditor-MediaWiki/*) {
         return 200;
      }
         return 403;
      }

Alaub81 (talk) 20:37, 6 November 2020 (UTC)

Sorry but your solution implied security problem.

If i switch "user agent" on my browser the basic auth not exist. 82.120.36.23 (talk) 21:30, 5 April 2021 (UTC)

Hello,

I also want to use MediaWiki behind a Basic Auth (in my case haproxy), and I am running into the same problem.

Is there any other possibility to use the VisualEditor with MediaWiki, behind Basic Auth? As "82.120.36.23" says, it's a security hole, you just need to change your user-agent to VisualEditor-Mediawiki/* and you can access the Wiki without any authentication. 193.80.211.83 (talk) 07:51, 21 June 2021 (UTC)

Private wiki configuration

I have a private Wiki, which I have updated to version 1.35.

I have activated the extension as follows:

wfLoadExtension( 'VisualEditor' );

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

When I try to edit a page I don't get an error message, but the content of the page is not loaded into the editor, but the content of the footer.

URL: /api.php?action=visualeditor&format=json&paction=parse&page=Hauptseite&uselang=de-formal&formatversion=2

Shortened answer:

{ "visualeditor": { result: "success", content: "↵<!DOCTYPE html>↵<html class="client-nojs" lang="de-x-formal" dir="ltr">↵<head>↵<meta charset="UTF-8"/>↵<title>Anmeldung erforderlich – Wiki</title>↵[... more content ...]" } }

"Anmeldung erforderlich" means "Login required".

Does anyone know how I have to configure the Wiki to make the VisualEditor work? AVNeu (talk) 12:01, 27 October 2020 (UTC)

Share some experiance with MediaWiki 1.35, Apache 2.4.46 and SubPages

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hello!

I just switched from MediaWiki 1.34 to 1.35, installed on Ubuntu Server 20.04, equiped with PHP 7.4, MqSQL 8 and Apache 2.4.46.

Everything went fine except Extension:VisualEditor. There were two troubles that took me about 3 hour and I decided to share this experience:

• Initially VisualEditor didn't worked at all. When I did press the Edit button nothing happens.

I've solved this issue by removing extensions/VisualEditor and then install it again.

• Editing of Sub Pages wasn't possible. I was receiving: "Error contacting the Parsoid/RESTBase server (HTTP 404)" each time.

I've solved this issue by adding the directive AllowEncodedSlashes On within the Apache's VirtualHost configuration.

Now everything works great! Spas.Z.Spasov (talk) 13:08, 31 October 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Config instruction for private MediaWiki needed

We have a private Wiki (updated drom 1.34 to 1.35) for our company (and I'm sure many companies have) which means:

- pages only visible for logged in users

- users are automatically logged in via Windows authentication

(To complicate things a bit more, we are using an IIS server which seems to do things a bit different.)

When I'm trying to use VisualEditor "out-of-the-box" I ran into some problems when editing a page:

- Parsoid/RESTbase Error 401 - because VisualEditor seems to run as Anonymous user (no wiki user problem) or user has no rights for folder

- when I disable Windows authentication and login manually as some user I get error 403.

I already did some recommended tuning like "forwardcookies" but without success. (I also set correct userrights like writeapi etc.).

So I think we really need a detailed instruction (or checklist) how to config MediaWiki 1.35 for using VisualEditor in private wikis.

Thanks in advance,

Marcel

PS: Which wiki folder does VisualEditor try to access when I'm running into the 401 error? It seems the Windows authentication of the logged in user is not passed to the IIS when trying to load VisualEditor. 80.152.132.238 (talk) 13:31, 2 November 2020 (UTC)

Having a similar problem. After I implemented Windows Authentication, Visual Editor broke. Using Win2016, IIS, MediaWiki 1.35.5, PHP 7.4.13. Visual editor was working with recommended modifications to LocalSettings.php file. Then I turned on Windows Authentication and URL Authorization rules, and Visual Editor broke again. Gregzme17 (talk) 17:09, 17 March 2022 (UTC)

VisualEditor with my personal tag based extension

I cannot find a document about how I can create my own extension using the VisualEditor.

My extension is very simple.

When "<mytag>" is shown in the EditPage, I replace with the different present.

When "<mytag>" is shown in the ViewPage, I replace with another text.

Basically, I'm hiding the original content encapsulated by "<mytag>"

It works well in "Edit Source" tag.

However, when it enters "Edit" as the VisualEditor, it shows like ViewPage, but when I click the text encapsulated by "<mytag>", it pops up the "Edit" with the original text. I want it to be the text like in EditPage in the "Edit Source" mode.

I wish there is a VisualEditor document for other extension for "Edit", "View", and "Save", but couldn't find it yet.

Does anyone know where I could find it? 75.9.133.35 (talk) 18:49, 8 November 2020 (UTC)

VisualEditor create mess of html for empty page

Hi!

When I try to use VisualEditor it add a lot of extra html ( looks like it add a lot of elements from main page).

If I Use code editor all works great.

Regards,

Vlad 95.67.109.238 (talk) 11:55, 9 November 2020 (UTC)

I'm seeing this too and have no idea why. Nicholaslue (talk) 18:41, 14 December 2020 (UTC)

is this a fresh install with new data or are you migrating from an existing localsettings.php? Nicholaslue (talk) 19:11, 14 December 2020 (UTC)

Same thing here, no idea of what to do 107.159.96.153 (talk) 03:17, 17 December 2020 (UTC)

Bump 95.67.109.238 (talk) 13:11, 5 January 2021 (UTC)

Hi!

I resolved this issue with instructions found on Parsoid manual:

If you're serving MediaWiki with Nginx, you'll need to also add something like this to your server conf:

location /rest.php/ {

try_files $uri $uri/ /rest.php?$query_string;

} Brunolefellic (talk) 05:28, 14 January 2021 (UTC)

You use unsupported browser

On clean 1.35 wiki with last version of VisualEditor, when you try to open it from moible through Chrome 86 - last version Chrome for Android - pops up a warning "You use borwser, oficially not supported by this editor". The text can be not excactly that because I user Russian local and just translated. Theme Timeless.

So, what's the problem? I don't see such a problem on Wikipedia despite of they use the same editor. Аргскригициониец (talk) 10:28, 16 November 2020 (UTC)

Error Converting to markup

I'm having trouble with VisualEditor when I attempt to convert to markup. I can load the editor, and use it normally. However, when I attempt to save the page, or when I attempt to switch to source editing, I receive the following error box:

Something went wrong

[efc7a9f068c2562546e9c149] Caught exception of type Error

The bracketed hex string varies, even performing the same task (switch editors/save). Obviously, the varying hex string and vagueness of the rest make tracking down the issue difficult. Any ideas? Meltybits (talk) 14:53, 21 November 2020 (UTC)

VisualEditor not compatible with SyntaxHighlight extension

I recently installed 1.35 and enabled VisualEditor. I am able to create/edit pages using the VE with the exception of anything that uses the SyntaxHighlight extension-- these pages won't even load. If I disable VE, I do not have this issue. Is anyone else experiencing this? JGTompkins (talk) 17:10, 15 December 2020 (UTC)

Do you have the correct version of the SyntaxHighlight extension? The two extensions interact, but if you're using mis-matched versions they might well break like that. Jdforrester (WMF) (talk) 17:55, 15 December 2020 (UTC)

Yes, I am on the 1_35 version of the SyntaxHighlight extension. JGTompkins (talk) 18:43, 15 December 2020 (UTC)

Is there anything in your browser's console? You say the pages don't load; do you get a 503 error, a blank page, or something else? Jdforrester (WMF) (talk) 18:47, 15 December 2020 (UTC)

Nothing--- no http errors, it will just show as loading indefinitely JGTompkins (talk) 18:59, 15 December 2020 (UTC)

Most odd. Sorry, I've not heard of this issue from anyone else, and don't have any ideas if there aren't any logs to point in any direction. Jdforrester (WMF) (talk) 19:17, 15 December 2020 (UTC)

Don't know if this adds any information, but when I go to save a new page that tries to use syntaxhighlight, I get "The server did not respond within the expected time." JGTompkins (talk) 14:58, 16 December 2020 (UTC)

More information: Access log shows http 500 error when trying to load pages using the syntaxhighlight extension or when saving a new page that tries to use the extension. JGTompkins (talk) 18:45, 17 December 2020 (UTC)

FYI, the problem is old and a known (and still unresolved) Windows bug -- this one: https://www.mediawiki.org/w/index.php?title=Project%3ASupport%20desk/Flow/2020/03#c-46.232.228.6-2020-03-11T22%3A06%3A00.000Z-46.232.228.6-2020-03-10T15%3A57%3A00.000Z JGTompkins (talk) 14:26, 23 December 2020 (UTC)

Error contacting the Parsoid/RESTBase server (HTTP 404)

Issue appears for MW 1.35 if you would like to do https://wiki.example.org/Main_Page rather than something https://wiki.example.org/page/Main_Page. Reported as T270376. [[kgh]] (talk) 11:58, 17 December 2020 (UTC)

Error contacting the Parsoid/RESTBase server (HTTP 500) when editing page with big Table

Issue appears in MW 1.35. Only happens when using Visual Editor to edit a page that has 900+ rows. Anyone seen this before and know what's causing it?

Thanks Taylor002 (talk) 14:11, 17 December 2020 (UTC)

I have the same precise issue: an edited Table not letting me save whereas a blank table saves.

Internet has not been helpful so far. I may copy and paste my text cell by cell onto a new page, and save after each paste, to see if I can isolate what aspect of the Table is causing the error. 24.231.18.174 (talk) 22:40, 25 January 2021 (UTC)

UPDATE: What a weird anomaly. I narrowed it down to parentheses and/or the underline code <u></u>.

From the source editor:

(<u>…</u>) and (<u>…)</u> saves just fine, whereas

<u>(…)</u> or <u>(…</u>) crashes the save, giving me an error "The server encountered an internal error or misconfiguration and was unable to complete your request."

When I create this syntax with the VisualEditor, then I get the HTTP 500 error like noted above, plus cannot switch to the source editor, which gives off this error: "Error loading data from server: Error contacting the Parsoid/RESTBase server (HTTP 500)."

Hitting the back button and shifting the left parenthesis outside <u> allows the page to save just fine.

However, if I attempt to simply de-underline from the VisualEditor (Command+U), the RESTBase error still pops up. So maybe de-underlining isn't removing the <u> code on the source side?

Regardless, it appears an open-ended left parenthesis (, with or without underlining, is the culprit for me.

How odd. 24.231.18.174 (talk) 23:20, 25 January 2021 (UTC)

*NOTE: Oops, forgot one detail: the underline code is inside the table. I just tested the <u>(…)</u> code outside the editor: when applied via the VisualEditor with COMMAND+U, it saves; when this code is pasted inside the source editor, it crashes the save, taking me to "The server encountered an internal error…"

Does anyone have any clue how the code of an underlined parenthesis might be causing issues? 24.231.18.174 (talk) 23:23, 25 January 2021 (UTC)

Cannot save edit with Hitch and Varnish in front of Apache

The problem was due to a setting in the VCL file.

MediaWiki: 1.35.0 PHP: 7.4.11 (apache2handler) MySQL: 5.7.31-0ubuntu0.18.04.1

VisualEditor works fine with https directly to Apache. However, with Hitch and Varnish in front of Apache we get this error message on trying to save an edit: "Error contacting the Parsoid/RESTBase server: http-bad-status". Hitch and Varnish work OK, at least things get cached. Hitch listens on port 443, Varnish listens on ports 80 (from web) and 8443 (from Hitch), Apache listens on port 8080 (from Varnish).

When I do "systemctl status hitch" after I have tried saving a VE edit, it lists two entries like this: "{backend} Socket error: Connection reset by peer". What could be the reason for this problem? Any help would be much appreciated. Henryfunk (talk) 10:32, 19 December 2020 (UTC)