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

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

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?

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

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:

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

curl_multi_init() has been disabled for security reasons

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:

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.

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

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

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> 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)

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)

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

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

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

curl ifconfig.me

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)