Extension talk:VisualEditor

About this board

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.

Error contacting the Parsoid/RESTBase server (HTTP 404)

5
LoikFR (talkcontribs)

Hello everyone

I've been trying to configure VisualEditor on a private wiki in local (for testing), but I always have an "Error contacting the Parsoid/RESTBase server (HTTP 404)" when I try to open the editor. I've been looking for a solution all day but can't find anything that work

I'm on MediaWiki 1.38.2 and using the version of VisualEditor that come with it.

Here's the content of the LocalSettings.php file that I added:


wfLoadExtension( 'VisualEditor' );

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

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

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

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


I use PHP 8.0 if it can help.


Thanks in advance !

185.107.107.2 (talkcontribs)

The same for me, just an easy installation in Fedora, gives me always Error contacting the Parsoid/RESTBase server (HTTP 404) and nobody knows how to fix it.

This is a serious bug, because Visual Editor is a must this days.

Spas.Z.Spasov (talkcontribs)

Probably the PHP version is the troublemaker see: Compatibility#PHP. If you are using PHP-FPM it is pretty easy to install php7.4-fpm along with php8.0-fpm and set the MediaWiki instance to use it.

79.253.44.73 (talkcontribs)

Hi @Spas.Z.Spasov

i am using php7-4.fpm alongside php8.1-fpm and php8.0-fpm.

There is no difference at all in each of this versions, i still get the mentioned error.

kind regards

Spas.Z.Spasov (talkcontribs)

Yes, I can confirm it is not PHP version issue. Weeks ago, I've switched to PHP 8.1 and everything works correct on my MW instance.

Reply to "Error contacting the Parsoid/RESTBase server (HTTP 404)"

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

53
Summary last edited by MyWikis-JeffreyWang 03:17, 13 July 2021 1 year ago

The problem

This issue seems to occur on private wikis:

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

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

The workaround

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

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

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

curl ifconfig.me

Maybe they'll fix it

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

Chitinlink (talkcontribs)

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.

LapisLazuli33 (talkcontribs)

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.

Chitinlink (talkcontribs)
Chitinlink (talkcontribs)

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.

Jörgi123 (talkcontribs)

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.

Chitinlink (talkcontribs)

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"

Cscott (talkcontribs)
Ciencia Al Poder (talkcontribs)

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.

Aschroet (talkcontribs)

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.

Jörgi123 (talkcontribs)

An additional Restbase installation is not needed. It is optional, you do not need it.

Ciencia Al Poder (talkcontribs)

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

Rehman (talkcontribs)

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

This post was hidden by Chitinlink (history)
This post was hidden by Chitinlink (history)
This post was hidden by Chitinlink (history)
This post was hidden by Chitinlink (history)
This post was hidden by Chitinlink (history)
Chitinlink (talkcontribs)

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

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

Spas.Z.Spasov (talkcontribs)

I just solved similar issue by removing extensions/VisualEditor and installing it again.

50.204.98.114 (talkcontribs)

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?

Chitinlink (talkcontribs)

No, though I haven't really tried much since my last post. Do you happen to also have a private wiki?

50.204.98.114 (talkcontribs)

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

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?

Chitinlink (talkcontribs)
Sidnaught (talkcontribs)

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.

Metalliqaz (talkcontribs)

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.

89.251.251.99 (talkcontribs)

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.

Chitinlink (talkcontribs)

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.

MyWikis-JeffreyWang (talkcontribs)

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.

MyWikis-JeffreyWang (talkcontribs)

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.

Woozle (talkcontribs)

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.

MyWikis-JeffreyWang (talkcontribs)

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.

Woozle (talkcontribs)

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.

MrStonedOne (talkcontribs)

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)(/.+)$;

UGOBOSS777 (talkcontribs)

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

Ciencia Al Poder (talkcontribs)

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

UGOBOSS777 (talkcontribs)

I tried with 127.0.0.1... It didn't work for me

MyWikis-JeffreyWang (talkcontribs)

@UGOBOSS777 Try replacing the if condition with: $_SERVER['REMOTE_ADDR'] === $_SERVER['SERVER_ADDR']

UGOBOSS777 (talkcontribs)

I changed the condition, still doesn't work

Revansx (talkcontribs)

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;
}
206.123.222.162 (talkcontribs)

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

MattPilz (talkcontribs)

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;

206.123.222.162 (talkcontribs)

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

Ajmichels (talkcontribs)

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.

DJ7BA (talkcontribs)

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.

Fmherschel (talkcontribs)

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

Ciencia Al Poder (talkcontribs)

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.

Fmherschel (talkcontribs)

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

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

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.

Ciencia Al Poder (talkcontribs)

Looks like that solution was already provided in the Troubleshooting section of the page.

WilliamKnak (talkcontribs)

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.

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

How to hide the “Save your changes” confirmation window when saving a page on Mediawiki

6
Paulxu20 (talkcontribs)

I have a personal wiki running on mediawiki and don't think I really need to track the page edit summary or whatsoever, so is there anyway to skip it? which means when I am done with editing on a page and click on Save, it just Save the page without asking me to describe what I changed..

Thank you!

195.65.170.10 (talkcontribs)

Did u find a way to this problem or is it still unsolved?

Paulxu20 (talkcontribs)

Not yet.

Michael Z Freeman (talkcontribs)

Looking for this as well.

2003:DF:9F2D:6E00:6059:29B5:482F:F412 (talkcontribs)

Would appreciate a solution for this as well!

Reply to "How to hide the “Save your changes” confirmation window when saving a page on Mediawiki"

Error contacting the Parsoid/RESTBase server (HTTP 415)

16
Summary last edited by Urfiner 18:05, 8 October 2020 1 year ago

Had the same error.

I have a redirect from http to https in apache. Apache does not pass headers on redirect (because a client should do it)

Also, I had

$wgServer           = "//brainstorage.amust.local";

Because of that http was used as a protocol for Parsoid.

I've changed it to:

$wgServer           = "https://brainstorage.amust.local";

Now everything works

85.255.235.204 (talkcontribs)

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

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}

Edmond Media (talkcontribs)

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

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

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?

Tstout21 (talkcontribs)

This appears to be related to HTTPS. When I use http I can save using VisualEditor. I get the error only when using SSL.

85.255.235.204 (talkcontribs)

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

Edmond Media (talkcontribs)

I reinstalled MediaWiki and it works now....

Corruptedxcomics (talkcontribs)

Same issue on 1.36.1 of mediawiki. Tried reinstalling it and it does not work.

138.188.55.41 (talkcontribs)

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.

OurOakland (talkcontribs)

Thank you!!! After chasing a bunch of different suggestions, this seems to have actually fixed it!

OurOakland (talkcontribs)

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

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

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

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.

Perohanych (talkcontribs)

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

Thanks to 138.188.55.41 !

Reply to "Error contacting the Parsoid/RESTBase server (HTTP 415)"
Nicolas senechal (talkcontribs)

Hello,

When the user writes some wiki code VE and parsoid disable it (with <nowiki> and other techniques) but I don't went this function how I can do it ?

because I don't see a configuration who do it in MediaWiki-Docker/Extension/VisualEditor - MediaWiki and in the configuration of the parotid, maybe I miss it ?

thank you.

Reply to "Configuration of VE"

Inconsitent error "Error contacting the Parsoid/RESTBase server (HTTP 400)"

4
Bluedreamer1 (talkcontribs)
ProductVersion
MediaWiki1.36.1
PHP7.4.20 (fpm-fcgi)
MariaDB10.5.11-MariaDB
ICU67.1
Lua5.1.5
Elasticsearch6.8.16

I had this error with 1.36.0 so I upgraded to 1.36.1 and still have it sometimes. It is a small private wiki farm. One way I can consistently cause the error is to use the VisualEditor on my User page. It does work on other pages though which is strange.

I have $wgGroupPermissions['user']['writeapi'] = true; set for all wikis in the farm.

I have the follow example in my vhost with the rewrite rules

<VirtualHost *:443>
   ServerAdmin webmaster@un9.io
   DocumentRoot [redacted]
   ServerName mitm.un9.io

   AllowEncodedSlashes NoDecode

   SSLEngine on
   Include /etc/letsencrypt/options-ssl-apache.conf
   SSLCertificateChainFile /etc/letsencrypt/live/un9.io/chain.pem
   SSLCertificateFile /etc/letsencrypt/live/un9.io/cert.pem
   SSLCertificateKeyFile /etc/letsencrypt/live/un9.io/privkey.pem

   RewriteEngine On
   RewriteRule ^/(.*):(.*) /index.php/$1:$2
   <Directory [redacted]>
      AllowOverride AuthConfig FileInfo Limit Options=FollowSymLinks
      Require all granted
      RewriteBase /
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteRule ^(.*) /index.php/$1 [L,QSA]
   </Directory>
</VirtualHost>

I enabled debug logging and code this

[http] HTTP complete: GET https://mitm.un9.io/rest.php/mitm.un9.io/v3/page/html/User%3ATestUser/16?redirect=false&stash=true code=400 size=194 total=0.887740 connect=0.530200
[VisualEditor] ApiParsoidTrait::requestRestbase: Received HTTP 400 from RESTBase

I've not seen errors in apache or php-fpm logs or audit/setroubleshoot logs. It looks a bit strange to me to see the domain in the URL twice. Is that because of the rewrite rules and how do I fix it.

Thanks

Lostraven (talkcontribs)
Bluedreamer1 (talkcontribs)

One consistent way I found so far, is editing my user page - I always get the error

TiltedCerebellum (talkcontribs)

Same issue here on 1.35.6 downloaded today (no added extensions installed, no short URLs, default config from the installer), not on a farm, same message also:

ApiParsoidTrait::requestRestbase: Received HTTP 400 from RESTBase

VE of course was from the installer package, so no mismatched packages or anything weird going on there either.

MediaWiki 1.35.6
PHP 7.4.25 (cgi-fcgi)
MySQL 8.0.28-0ubuntu0.20.04.3
Reply to "Inconsitent error "Error contacting the Parsoid/RESTBase server (HTTP 400)""

Caught exception of type Error when saving changes in VisualEditor

1
Summary by Winel10

I’ve changed the language for my wiki form German to English. Then the error message was more precisely “Exception caught: Call to undefined function gzinflate()”.

The solution is to install php7-zlib module on the server.

Winel10 (talkcontribs)

VisualEditor runs fine and I can edit any text as desired. But when I want to save my changes I got the following message: "Something went wrong" "[1d70eae393b2ae72f0869514] Caught exception of type Error". Now I just can click the "Dismiss"-button an return to the save changes dialogue. The number in the square brackets changes each time I try to save.

My configuration is:

MediaWiki 1.32.0 used with self signed certificate over https

OpenSUSE Linux 42.3

PHP 7.0.7 (apache2handler)

MariaDB 10.0.30-MariaDB

VisualEditor 0.1.0 (21d40ce) 23:33, 5 November 2018

nodejs v10.12.0

stunnel 5.0

parsoid listenting on localhost port 8000

stunnel listenting on port 8142


LocalSettings.php [extract]

$wgServer = "https://wiki.linux.local";

$wgVirtualRestConfig[….

    'url' => 'https://wiki.linux.local:8142',…


config.yaml [extract]

mwApis: ….

     uri: 'https://wiki.linux.local/api.php'


stunnel.conf [extract]

[parsoid]

accept = 8142

connect = 127.0.0.1:8000


Do you have any idea what might cause the error?

VisualEditor 503 Service Unavailable Error

1
WrOffi (talkcontribs)

When I click edit with VE in existing pages, the editor pops up a Window and shows me "Server returns error: 503". I'm not sure what happens.

On the PHP side, it says


[client 61.151.164.63:20061] AH01067: Failed to read FastCGI header, referer: https://sonicpedia.org.cn/wiki/%E9%A6%96%E9%A1%B5?action=edit&veswitched=1

[proxy_fcgi:error] [pid 1366536:tid 139996849719040] (104)Connection reset by peer: [client 61.151.164.63:20061] AH01075: Error dispatching request to : , referer: https://sonicpedia.org.cn/wiki/%E9%A6%96%E9%A1%B5?action=edit&veswitched=1"


Everything is normal when I create new pages with VE.

MediaWiki 1.37.2
PHP 7.4.28 (fpm-fcgi)
MySQL 5.7.37-log
ICU 66.1
Elasticsearch 6.8.23
Lua 5.1.5
Pygments 2.10.0
Reply to "VisualEditor 503 Service Unavailable Error"

VE does not work with any template

2
Tekthyrios (talkcontribs)

I have my VE cleanly installed and running fine until we started using templates. Any article with template, once saved, cannot be edited again with VE, and yields Error contacting the Parsoid/RESTBase server (HTTP 500) instead. But once the template tags are removed in the source code, the article become editable in VE again.

Spas.Z.Spasov (talkcontribs)

Hello, you should provide some information about the MediaWiki version and the environment - the PHP version, OS, so on.

Reply to "VE does not work with any template"

Error contacting the Parsoid/RESTBase server (HTTP 403)

4
Summary by AID-PMBD

Solution found in: https://stackoverflow.com/questions/64106004/error-contacting-the-parsoid-restbase-server-http-bad-status-on-fresh-mediawiki


Changed $wgServer = from $wgServer = "http://wiki.name.domain.com"; to $wgServer = "https://wiki.name.domain.com";

AID-PMBD (talkcontribs)

I just finished setting up a fresh wiki with the following configuration:

Mediawiki 1.35.6

PHP 7.4.3 (apache2handler)

MySQL 8.0.29-0ubuntu0.20.04.3

ICU 66.1

Lua 5.1.5

VisualEditor 0.1.2

wikimedia/parsoid 0.12.2


Parsoid and Visual Editor were installed through the Mediawiki bundling. I have a wiki with a similar configuration the only difference is Mediawiki 1.35.3, which works perfectly fine. On the wiki with Mediawiki 1.35.6 VisualEditor returns the following error:


Error contacting the Parsoid/RESTBase server (HTTP 403)


Any idea on how I can fix this without updating Mediawiki from 1.35 and downgrading it to 1.35.3? I need to stay on the legacy version of Mediawiki.

AID-PMBD (talkcontribs)

As additional information, I have given all users that are supposed to be able to edit the following permission:


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

AID-PMBD (talkcontribs)

Another additional piece of information:


I am running the wiki as a vhost with apache2. My .config file in etc/apache2/sites-available looks like this:

<VirtualHost *:80>

ServerAdmin admin@email.com

ServerName wiki.name.domain.com

ServerAlias www.wiki.name.domain.com

DocumentRoot /var/www/html

ErrorLog ${APACHE_LOG_DIR}/error.log

CustomLog ${APACHE_LOG_DIR}/access.log combined

RewriteEngine on

RewriteCond %{SERVER_NAME} =wiki.name.domain.com [OR]

RewriteCond %{SERVER_NAME} =www.wiki.name.domain.com

RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

</VirtualHost>

<Directory /var/www/html>

       AllowOverride All

</Directory>

AID-PMBD (talkcontribs)
Return to "VisualEditor" page.