Topic on Extension talk:VisualEditor/Flow

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?

I also get a 404 error (Error contacting the Parsoid/RESTBase server (HTTP 404)): https://www.mediawiki.org/wiki/Topic:Vuonx6s9lxsy1xew

I'm on a shared hosting which uses LiteSpeed web server.

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

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

The server's configuration or the LocalSettings.php file?

Servers configuration. The error seemed to be that my pretty url rewrite wrongly send it to index.php instead of rest.php.

Oh my gah!! I can't thank you enough. I just copied and pasted and voilà, it work pretty straight and flawlessly!!

I got the same issue and the nginx configuration Tom mentioned does not help either.

Because it's possible that there are multiple causes for the 404 error.

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.

You are right! It's the same for me.

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.

I have also posted about it here: Topic:Vuonx6s9lxsy1xew

I think there is already an entry about this issue on Phabricator: https://phabricator.wikimedia.org/T255963

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.

Did you ever find a solution, 10 months later? Having the same problem on 1.36.1.

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.

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?

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.

Does RESTbase come with MediaWiki 1.35 or should it be installed following these directions: RESTBase/Installation?

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.

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?

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.

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

You provide a great explanation but what do I do if I'm using NGINX.

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

    location @rewrite {

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

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

        }

    }

I have the same issues and Tom's solution doesn't works for me as well.

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

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

So this works for you?

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.

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

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.

The user agent conditional was the correct answer for me here. Thanks!

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.

So, if I set

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

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

   'domain' => '...',

];

I get a 404 error instead of the 403 error.

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

worked for me, as it is written here : Parsoid

This worked for me too

This didn't work for me, same 404 message.

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"

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.

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;

}

Same here

Additional conf in nginx resolved the problem

location /rest.php {

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

}

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

In the end nothing mentionned here resolved the problem

I solved by adding the following configuration:

location ~ /rest.php {

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

}

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

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.

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