Topic on Extension talk:VisualEditor

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.

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.

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.

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

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.

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.

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"

Jörgi123's advice looks correct to me.

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.

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.

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

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

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

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.

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

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

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?

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

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.

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?

I've made a bug report.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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

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

I changed the condition, still doesn't work

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

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

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;

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

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.

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]

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.

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

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.

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.

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.

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.

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

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.

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

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.

Error contacting the Parsoid/RESTBase server (HTTP 404): (no message)

help me sir to solve this problem

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

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?