You are here
Tango - Tue, 2023/12/05 - 06:41
As you may have surmised from the title, the issue of the day is getting VisualEditor working in a MediaWiki instance. I've gotten far enough down the rabbit hole that I get a functional VE UI, but when I try to save changes to an edit, I get, "Error contacting the Parsoid/RESTBase server: http-request-error." I've been raking over the the documentation and my setup for the past 3 weeks. I just can't figure out what's broke or how to fix it.
Versions: MediaWiki 1.37.1, Debian 11, VisualEditor REL1_39
#######################################
# Added configs below.
#VisualEditor Extension
wfLoadExtension( 'VisualEditor' );
// Enable by default for everybody
$wgDefaultUserOptions['visualeditor-enable'] = 1;
// Don't allow users to disable visualeditor
$wgHiddenPrefs[] = 'visualeditor-enable';
// Optional: Set VisualEditor as the default editor for anonymous users
// otherwise they will have to switch to VE
$wgDefaultUserOptions['visualeditor-editor'] = "visualeditor";
#$wgVirtualRestConfig['modules']['parsoid'] = array(
// URL to the Parsoid Instance
// Use port 8142 for Debian installs
# 'url' => 'http://localhost:8142'
// Parsoid "domain", see below (optional)
# 'domain' => 'localhost'
// Parsoid "prefix", see below (optional)
# 'prefix' => 'localhost'
# );
#// Fix parsoid error by forwarding token to parsoid server
$wqVirtualRestConfig['modules']['parsoid']['forwardCookies'] = true;
# everything above this line currently works
wfLoadExtension('Parsoid', 'vendor/wikimedia/parsoid/extension.json');
This is commented out because it breaks page load when enabled.
#$wgVirtualRestConfig['modules']['parsoid'] = array( // URL to the Parsoid Instance // Use port 8142 for Debian installs # 'url' => 'http://localhost:8142' // Parsoid "domain", see below (optional) # 'domain' => 'localhost' // Parsoid "prefix", see below (optional) # 'prefix' => 'localhost' # );
Forum:
Tags:
Hi Tango, welcome to TurnKey :)
Hi Tango, welcome to TurnKey :)
So I have a question, perhaps it's a stupid one, perhaps not.
Do you have the "Parsoid/RESTBase server" (some sort of RESTful API server I assume?) configured and running? I'm assuming that it is (or at least should be) running on port 8142?
My suspicion is that either you have missed that step. Or if you have followed that step, that there is something not quite right there.
Another question/thought (which may be way off target), I note that you are trying to use localhost. Is that recommended config? (And actually, if you can point to the docs you used to set this up might be useful too).
I ask because if I'm right about the "Parsoid/RESTBase server" being some sort of RESTful API server, often they connect within the user's web browser. It's usually done by javascript embedded in the page, which interacts directly with the backend API server, via a connection within your web browser. I have no idea if MediaWIki do it that way (hence why I might be way off the mark), but I've seen that sort of set up in lots of different dynamic apps these days.
So if you're binding the API server to localhost (rather than a domain), then you probably can't connect to it in your browser!? (Still assuming I understand correctly) It probably would work ok if you were running MediaWiki locally (i.e. on the same PC as your web browser) but otherwise, your web browser will never connect to your API server running on "localhost" (localhost in your browser will most likely resolve to your local computer not the server, otherwise it might just fail altogether).
As an additional point, the sort of connection I describe above has security implications. So you don't want to enable it via vanilla http, only https. But then the connection will still fail unless you have a proper CA signed certificate (API connection via self signed cert - like TurnKey ships with - will fail).
Anyway, maybe I'm completely wrong? My knowledge tends to be broad rather than deep and I have close to zero experience with MediaWiki.
So please share a bit more info about the docs you used to set this up and what (if any) config you have for the "Parsoid/RESTBase server". Feel free to redact anything that you feel is sensitive, but please somehow give me some indication of what has been redacted. For example to redact an IP address, use something like: 'xxx.xxx.xxx.xxx'; or to redact emails, use something like: 'somebody@example.com', etc...
#2.
Hey Jeremy:
To clarify, my intent is to get mediawiki stood up and visualeditor installed in the easiest manner possible. It's behind 2 secured network segments so I'm not concerned about utilization of https etc. I need to be able to load the wiki via remote browser (not locally). I did not intentionally standup a parsoid server that I know of. Just stood up the wiki and attempted to installed visualeditor.
As for setup guides, I mostly pulled from this one: https://www.mediawiki.org/wiki/Extension:VisualEditor
I found the guide to be pretty disjointed so not sure if I covered all the relevant bases or not, truithfully.
I'll go back and revisit your comments about the parsoid install and see if I can figure out where I went sideways.
Anyone know of a 'start to finish' walkthrough for visualeditor installation on a turnkey mediawiki instance?
Thanks for that.
Thanks for the additional info.
I've done a quick bit of research myself (i.e. googling...) and I concur. The documentation on installing/enabling "VisualEditor" is a mess! Not that we're in any position to make too much noise about inadequate documentation - TurnKey docs are fairly poor, to average at best. But still I get the frustration.
From what I can gather, it seems that the VisualEditor code (i.e. the VisualEditor plugin code) is now included in MediaWiki "Core". So that bit only needs to be enabled (what you've tried from what I gather). I can't find it now, but I recall reading somewhere that it will only work OOTB for new posts (will fail when editing existing posts). To get it to work while editing, more moving parts are required. There is talk about the "Parsoid library" (wiki markup to/from html parser) but it seems that that too is now included in MediaWiki "Core".
Another part required appears to be the RESTBase server. As I suspected, that is a RESTful API server. That is a NodeJS application (as opposed to PHP - like the rest of MediaWiki), that needs to be installed separately (can be on the same server - or not as you prefer). Hopefully those instructions will "just work", but it seems somewhat outdated, so I'm not 100% sure if that's the case (and the amount of random threads online with people having issues suggests that it's a PITA to get working). I also note that the RESTbase code readme also has install instructions but they are pretty minimal and the MediaWiki doc page has much more detail about config.
But wait, that's not all...! It seems that RESTbase also needs a DB backend (and doesn't use MySQL/MariaDB). It appears to use Cassandra (a NoSQL DB server). Unfortunately, Cassandra isn't packaged in Debian, but thankfully it seems that there is a Cassandra Debian apt repo which can be used to install Cassandra. Having said that, that doc page (again) looks really dated and I think we can do better. This page is better, although it notes to get the "latest version", use the '40x' repo - where the current v4 stable release actually appears to be '41x' - as noted on this page (about halfway down, under the heading "Installation from Debian packages").
To add to the confusion, it appears that there is also a v5.0 Cassandra release (which I'd guess would use a apt repo of '50x'?). However, it's unclear to me whether that is "stable" or not yet? As such, I'd probably be inclined to start with v4.1 (i.e. the '41x' repo). Although I note that the MediaWiki specific docs note a much older version of Cassandra. I'm working on the assumption that as those docs are clearly out of date, you'd actually want a recent version. However, there is a risk that the MediaWiki docs aren't as outdated/wrong as I suspect and you actually may need an older Cassandra version?
So TL;DR it looks pretty involved... Sorry to be the bearer of bad news, although at least it explains why you haven't been having any joy with it so far... Hopefully the links I've shared here help get you closer, but considering the complexity (and the scattered/incomplete/outdated docs), I won't at all be surprised if you need to circle back for additional help.
If/when you do come back to report issues, please post as much info as possible about what you've done so far and what the exact error(s) are (i.e. verbatim error message text) and where you are seeing them (e.g. log file, following cli commands, etc).
If your current MediaWiki server has content that you care about, I recommend starting with a clean MediaWiki server for the "trial and error" that will likely be required to get this all working. I also strongly suggest that you take notes of everything you do as you do it. That way once you're done, you can (re)follow those steps "for real" on your current server - and share them with us for the benefit of other users and as I noted, perhaps we'll look to include it by default?
Also if you're not already hosting your servers via some sort of virtualization, now would be a good time to start (at least for this development/testing). That way you can easily take snapshots when ever you appear to be having progress. Then if things go pearshaped, you can roll back to a known good state and refer to your notes to get back to where you were.
Good luck and please post back anytime and I'll try to respond ASAP (although please be aware when I'm deep in "dev mode" I can be a bit slow...). If you manage to work it out, please do share your notes! :)
resolution
For the record, I want to say that this is the sort of nonsense that makes people turn away from linux platforms and never look back. I found the problem.
LocalSettings.php:
now just looks like
LocalSettings.php: %local_hostname% is a variable for the hostname of the server (not even FQDN)
...this entry has to match the hostname of the server aparently. As soon as I put them in alignment (instead of using the IP) it suddenly works. So I geuss to change the name of the wiki I have to change the name of the server --- wish I had know that up front. yay! So yea... thanks for the moral support, Jeremy.
Ah ok, although I have questions...
Ah ok, thanks for posting back with the fix. Great news that you got VisualEditor working. Although I have lots of questions...
The first thing I'd like some clarification on is did you install and set up the RESTbase server at some point? Or is that no longer required? My reading (both online and of the config you've previously posted) suggests that it is, but your posts don't make that clear to me? Although perhaps I missed something?
Also, was '$wgServer' really set to 'https//domain.com'? Or was that just for example purposes? It should have been set to a domain name that resolves to your server (via DNS and/or hosts file adjustments on both your host and guests) and I'm guessing that you didn't set that up for https://domain.com!? FWIW newer "zeroconf" type dynamic addressing is pretty cool, but can be a bit flaky (there are competing standards and no all devices support all standards). It works well when it works, but when it doesn't it's a PITA in my experience so we don't actively try to support that (it's a bit of a rabbit hole in my experience). Although we did make some adjustments a while ago that should make it work somewhat with many common modern DHCP servers.
As you note, '$wgServer' should be set to a name that resolves to your server. Although that should be resolvable both internally, and externally (either via DNS or by adjusting hosts files on the server and the guests). From what I can gather, you've essentially changed it to use a locally resolvable hostname. So whilst it now "works", I suspect that that name is not externally resolvable. So whilst the VisualEditor may now work (because it can connect locally), I suspect that you may hit other (perhaps more subtle) issues (unless I'm mistaken and that same hostname is also externally resolvable). E.g. some internal links may no longer work, some assets (e.g. pictures) may not load (if/when the links to them are being dynamically mapped to absolute URLs).
Sorry that I didn't pick up that possibility before. Although in fairness, unless the RESTbase server install is no longer required, it seemed not installing that seemed like the most likely reason why it wasn't working. You didn't mention installing that and the config clearly shows that it should be available via localhost port 8142.
So in summary I'm really happy to hear that you worked out how to get the VisualEditor working, but I think that a little more config is required to make your while MediaWiki install work perfectly.
Also, I get the frustration, but it's not really Linux's fault. I'd say it's more of a server thing, perhaps even an open source software server thing? E.g. MediaWiki can be installed on Windows and I bet that you'd hit exactly the same issues, actually probably more (some of this stuff is really hard to set up properly on Windows - it's a breeze on Linux). FWIW, before I became a Linux user, I was a "Windows Power user" and managed IT for a small NGO (actually I still do, but most of their backend infrastructure is now Linux). And I can confirm, that as soon as you move away from the sort of every day Windows user type activities, configuring server related stuff on WIndows is just as bad, if not worse IMO.
following up
The first thing I'd like some clarification on is did you install and set up the RESTbase server at some point? Or is that no longer required? My reading (both online and of the config you've previously posted) suggests that it is, but your posts don't make that clear to me? Although perhaps I missed something? Nope. Did not have to install that separately. You are correct, it is all baked in at this point.
Also, was '$wgServer' really set to 'https//domain.com'? Or was that just for example purposes? It should have been set to a domain name that resolves to your server (via DNS and/or hosts file adjustments on both your host and guests) and I'm guessing that you didn't set that up for https://domain.com!? It’s a very small environment and I didn’t want to have to manage and backup an internal dns server so I was attempting to utilize the server IP instead of a hostname. Defining the value as the hostname of the machine instead of the IP seemed to rectify the issue. This was the missing piece to my puzzle. My silver bullet.
FWIW newer "zeroconf" type dynamic addressing is pretty cool, but can be a bit flaky (there are competing standards and no all devices support all standards). It works well when it works, but when it doesn't it's a PITA in my experience so we don't actively try to support that (it's a bit of a rabbit hole in my experience). Although we did make some adjustments a while ago that should make it work somewhat with many common modern DHCP servers.
As you note, '$wgServer' should be set to a name that resolves to your server. Although that should be resolvable both internally, and externally (either via DNS or by adjusting hosts files on the server and the guests). From what I can gather, you've essentially changed it to use a locally resolvable hostname (Correct). So whilst it now "works", I suspect that that name is not externally resolvable. So whilst the VisualEditor may now work (because it can connect locally), I suspect that you may hit other (perhaps more subtle) issues (unless I'm mistaken and that same hostname is also externally resolvable). E.g. some internal links may no longer work, some assets (e.g. pictures) may not load (if/when the links to them are being dynamically mapped to absolute URLs).
Sorry that I didn't pick up that possibility before. Although in fairness, unless the RESTbase server install is no longer required (Correct, a secondary installation is not required.), it seemed not installing that seemed like the most likely reason why it wasn't working. You didn't mention installing that and the config clearly shows that it should be available via localhost port 8142.
So in summary I'm really happy to hear that you worked out how to get the VisualEditor working, but I think that a little more config is required to make your while MediaWiki install work perfectly.
Also, I get the frustration, but it's not really Linux's fault. I'd say it's more of a server thing, perhaps even an open source software server thing? E.g. MediaWiki can be installed on Windows and I bet that you'd hit exactly the same issues, actually probably more (some of this stuff is really hard to set up properly on Windows - it's a breeze on Linux). FWIW, before I became a Linux user, I was a "Windows Power user" and managed IT for a small NGO (actually I still do, but most of their backend infrastructure is now Linux). And I can confirm, that as soon as you move away from the sort of every day Windows user type activities, configuring server related stuff on WIndows is just as bad, if not worse IMO. I'm slowly but surely working my way into Linux.
This instance is only meant to be used and accessed internally – I can’t even setup smtp on this instance. My latest challenge is trying to figure out how to enjoy VisualEditor while also not having the read permissions open for everyone, because I would still like to meet a minimum bar of security.
Thanks heaps for the follow up
Thanks heaps for the follow up. It's really appreciated!
Now that you've confirmed that it's all baked in, I'll endeavor to test it out when we build our updated appliance and try to ensure that it "just works" OOTB. Thanks again.
Please do not hesitate to share any further tips you discover and/or rough edges you hit.
Add new comment