11

https://www.mediawiki.org/wiki/MediaWiki_1.35 is out and one of the advertise features seems to be the "built in"/"out of the box" Visual Editor that doesn't need an external server anymore.

So downloaded and installed the version just released and clicked "VisualEditor" so that it would appear in my LocalSettings.php as:

wfLoadExtension( 'VisualEditor' );

But when trying to edit a page the error message:

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

With no further hint on what to do.

The information in https://www.mediawiki.org/wiki/Extension:VisualEditor is still intimidating for me - it doesn't look like an "out of the box" configuration at all. I did not find anything there about the dialog's message content.

Where do i find the official information on how to avoid this dialog?

Screenshot

Wolfgang Fahl
  • 15,016
  • 11
  • 93
  • 186
  • The extension should work out of the box on 1.35. Make sure you do NOT have any Parsoid / RESTBase related configuration. Also make sure you are actually using 1.35 - master is configured differently. – Tgr Sep 28 '20 at 21:55
  • 1
    Specifically, make sure `$wgVirtualRestConfig` is not set. – Tgr Sep 28 '20 at 21:59
  • so far i removed the extension from the Localsettings.php to work around the issue. – Wolfgang Fahl Nov 01 '20 at 07:16
  • @WolfgangFahl did you ever solve this issue, other than disabling the extension? I've tried this install on a fresh Ubuntu box with MW 1.38 and still the same issue persists! – nadsy Dec 26 '22 at 14:24
  • @nadsy I never tried again. I am getting used to these kinds of quirks of software provided by the MediaWiki Foundation. Every once in a while i file bug reports and they might or might not be resolved. There is IMHO no way to influence the priorities by us mere mortals. – Wolfgang Fahl Dec 26 '22 at 19:09
  • @WolfgangFahl - thanks for letting me know. I might save time (and sanity) and disable the feature for now too in that case too. – nadsy Dec 28 '22 at 15:57
  • https://phabricator.wikimedia.org/T88016 is the main showstopper for me at this point and i have not accepted any answer yet since Where do i find the official information on how to avoid this dialog? isn't answered yet. – Wolfgang Fahl Dec 28 '22 at 16:33

4 Answers4

5

I've managed to wake up visual editor on an apache / ubuntu with mediawiki 1.37 set to private wiki.

This is what I've done

$wgServer = "https://example.org";

Note the https in wgServer!

End of my LocalSettings.php

if ( isset( $_SERVER['REMOTE_ADDR'] ) &&
     in_array( $_SERVER['REMOTE_ADDR'], [ $_SERVER['SERVER_ADDR'], '127.0.0.1' ] ) ) {
  $wgGroupPermissions['*']['read'] = true;
  $wgGroupPermissions['*']['edit'] = true;
  $wgGroupPermissions['*']['writeapi'] = true;
}
Áron Lukács
  • 51
  • 1
  • 2
  • The right answer! Besides the extension activation snippet, this is all that's needed, and nothing further in webserver config. Nice and centralized. – Andrej Jan 06 '23 at 01:05
3

Making sure that $wgServer in LocalSettings.php has https and not http in the string solved it for me.

kriffe
  • 41
  • 2
1

If you are using the HTTP based authentication of your webserver you have to allow localhost to be whitelisted, so MediaWiki can reach itself.

For Apache you can do this with

Require local

at the same spot where you configured the authentication. You can find detailed configuration descriptions in the MediaWiki Wiki.

https://www.mediawiki.org/wiki/Topic:Vwkv6abtipmknci8

However i would not recommend to use whitelisting based on the user agent. Attackers could circumvent the authentication just by changing their user agent string.

lalu
  • 331
  • 1
  • 3
  • 10
  • I am not looking for a workaround but the official solution by the MediaWiki foundation . I assume it is documented somewhere. – Wolfgang Fahl Jan 27 '21 at 11:40
  • It is not a workaround. MediaWiki is not expecting HTTP-based authentication to be in front of the API of the visual editor, so you have to whitelist the API if you use authentication. – lalu Jan 27 '21 at 11:43
  • 1
    You are pointing to a talk page, not the documentation. So it doesn't run out of the box yet although this is an LTS version. I 'll rather wait for the next LTS or the docs. – Wolfgang Fahl Jan 27 '21 at 11:55
  • It's not MediaWiki that is blocking the connection. It's the webserver preventing unauthenticated access to localhost. So you either have to equip MediaWiki with credentials (which would have to be implemented) or you allow MediaWiki unauthenticated access, which i described above. Of course it would be possible to not use the API at all, but i think it's unlikely that they will drop their advertised new feature. – lalu Feb 16 '21 at 15:58
  • Still this needs to be documented in the official docs and not here. I changed my question accordingly. – Wolfgang Fahl Feb 16 '21 at 16:35
  • 2
    @lalu I cannot thank you enough for pointing this out, as it lead me to realise I had some IP whitelisting in place that was blocking these requests. Thanks :) – Evee Jul 06 '22 at 08:20
1

In my case I only run into this problem, when I use a "nested" or structured wiki page.

It works for pages like TestPage, VideoCut, BestPractices but not pages like

TestPage/Test1, TestPage/Hugo and so on.

When looking at the webserver log page 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
  • 11
  • 1