Extension talk:VisualEditor

Jump to navigation Jump to search

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.

000Tom0000 (talkcontribs)
Costas Athan (talkcontribs)
This post was hidden by Costas Athan (history)
000Tom0000 (talkcontribs)

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

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

Costas Athan (talkcontribs)

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

000Tom0000 (talkcontribs)

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

This post was hidden by Costas Athan (history)
D3nnis3n (talkcontribs)

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

Costas Athan (talkcontribs)

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

D3nnis3n (talkcontribs)

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.

Costas Athan (talkcontribs)

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

D3nnis3n (talkcontribs)

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.

Costas Athan (talkcontribs)
D3nnis3n (talkcontribs)

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.

110.33.200.115 (talkcontribs)

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.

This post was hidden by Costas Athan (history)
Scripcat (talkcontribs)

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?

D3nnis3n (talkcontribs)

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.

Costas Athan (talkcontribs)

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

D3nnis3n (talkcontribs)

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.

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

Junebug12851 (talkcontribs)

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

154.17.24.21 (talkcontribs)

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

D3nnis3n (talkcontribs)
Scripcat (talkcontribs)

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

D3nnis3n (talkcontribs)

So this works for you?

Scripcat (talkcontribs)

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.

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.

No other modification in LocalSettings.php, My env: Ubuntu 18.04 + PHP7.4 + Apache2

Costas Athan (talkcontribs)

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.

This post was hidden by Costas Athan (history)
95.222.50.200 (talkcontribs)

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.

95.222.50.200 (talkcontribs)

So, if I set

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

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

   'domain' => '...',

];

I get a 404 error instead of the 403 error.

Antoine.rozenknop (talkcontribs)
location /rest.php/ {
    try_files $uri $uri/ /rest.php?$query_string;
}

worked for me, as it is written here : Parsoid

Junebug12851 (talkcontribs)

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

Bjsdaiyu (talkcontribs)

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"

Aron Manning (talkcontribs)

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.

Jahoti (talkcontribs)

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;

}

109.9.182.128 (talkcontribs)

Same here


Additional conf in nginx resolved the problem


location /rest.php {

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

}

109.9.182.128 (talkcontribs)

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

109.9.182.128 (talkcontribs)

In the end nothing mentionned here resolved the problem

171.97.48.45 (talkcontribs)

I solved by adding the following configuration:


location ~ /rest.php {

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

}

Reply to "Nginx configuration"
Joshua.yathin.yu (talkcontribs)

Functionally, my VisualEditor has been successfully installed on my Wiki on a Windows WAMP Server. The Wiki is located in port 81 and the Parsoid on 8000. I tried using this to edit small pages and it works completely fine (although really have to wait a bit).

The thing is, the communication between the Wiki and the Parsoid workers is seriously slow. A short page requires more than half a minute to finish parsing. The cmd always say the API being not accessible (because the whole port 81 is being consumed by the port 8000 when a parsing instruction is received. It makes it impossible to use the extension. Am I configuring it incorrectly?

Specifics:

  • Windows 7
  • WAMP Server 64-bit 2.5 (Apache 2.4.9), listen on port 81
  • 64-bit nodejs
  • Parsoid listen on port 8000 (paranted by Windows Command Processor cmd.exe)
  • Parsoid configured to communicate with Wiki through localhost, vice versa
  • Users access Wiki by direct IP / hostname (with Apache lockdown; localhost is allowed unconditional access)
Joshua.yathin.yu (talkcontribs)

Actually, it takes around 120140 ms (2 minutes) to finish parsing a single page and hence timing it out. Also, I would want to point out that when parsoid starts parsing, the whole Apache (port 81) becomes inaccessible.

Jazeckel (talkcontribs)

I am having the same problem. Please help! I created a new page with just a single line of text saying "this is a visual editor test." The create worked fine with the visual editor, and it saved fine. Then I tried to edit the page, and it timed out. The output from the parsoid service says "Failed API request, 8 retries remaining." After it gets down to 7 retries remaining, it times out. I then get a message saying "completed parsing in xxxx ms" but I am guessing that's just because I hit cancel on the retry prompt for the timeout.

I am using a private wiki on a Windows 2012 R2 server. I had some issues with the contextify install but I managed to install it manually instead (direct compile with node-gyp instead of via npm) to the directory of the parsoid package and parsoid passed all its unit tests.

89.247.250.82 (talkcontribs)

It's 2021-06-11 today and I have a similar problem: Can create a page using the visual editor but can't edit pages with the visual editor.


Error message on edit is:


"Error contacting the Parsoid/RESTBase server: (curl error: 28) Timeout was reached"

Reply to "Always timeout"

Visual Editor replacing urls in links/images

4
Desbrina1 (talkcontribs)

Every time I load the visual editor it replaces image and links.

i.e. If my image was showing using File:ROCKRUFF.png, it replaces it with Index.php?title=File:ROCKRUFF.png and then the images/links don't work if I save.

DHillBCA (talkcontribs)

I'm wondering if this is similar to an issue I ran into some weeks ago around categories. The capital "I" in "index.php" is the clue. If you're using FastCGI for your PHP, you might have a case sensitivity issue going on.

MarioSuperstar77 (talkcontribs)

What is the difference between "normal" PHP and FastCGI in regard to MediaWiki? I run a wiki website and I want to assure my visitors the best experience possible.

DHillBCA (talkcontribs)

I can empathize with ensuring good user experience, as that is one of my IT specialties. :)

As I understand it (and someone please correct me if I'm wrong), there are two basic "flavors" of PHP - CLI (command line interface) and CGI (common gateway interface). RHEL 8, for example, appears to default to the "FastCGI" version as its default when you install PHP. Stackoverflow had a good answer to the "difference" question here: https://stackoverflow.com/questions/9315714/what-is-difference-between-php-cli-and-php-cgi

For the specific issue that was raised, it appeared (at least in my case) that FastCGI was not case sensitive. This is why the capital "I" in index was throwing VE off. We wound up having to implement settings to force the lower case "i" in "index.php", which resolved the issue. I believe if you do some looking around here for "Pretty URLs", you can find the workaround we used.

Reply to "Visual Editor replacing urls in links/images"

Visual Editor takes no effect when activate

1
Dorivaldo de C. M. dos Santos (talkcontribs)

Hi. I've installed and configured the latest stable mediawiki( Mediawiki 1.36), from git. It's working fine, except when i try to edit a page with visual editor it doesn't take any effect when press the button (Edit). Even worse, it doesn't show the button on code editor allowing me to switch between Visual Editor and normal editing.

I've downloaded and configured Visual Editor extension also, using git.

Reply to "Visual Editor takes no effect when activate"

Error contacting the Parsoid-/RESTBase-Server (HTTP 403)

7
Grimaldi42 (talkcontribs)

I do get the error "Error contacting the Parsoid-/RESTBase-Server (HTTP 403)", as soon as I want to edit with Visual Editor. As long as I work with the source code, everythings fine.

I recently updated from MediaWiki 1.34 to MW 1.35, my wiki is not private and i run the website via cPanel/NameCheap. As I could not find any solution to my problem in the past week, i am now hoping to find help in this forum.

As I am a noob to wikimedia, i installed no extensions (except VisualEditor via MW 1.35) and the only additions i wrote into my localsettings.php are the following:

wfLoadExtension( 'VisualEditor' );

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

$wgVisualEditorParsoidAutoConfig = true;

These changes are the result of my former investigation. Without these VE is not shown as an option to edit my wiki.

Furthermore, the Insert-options i get by editing via VisualEditor are only for tabulars, images and comments. Options for inserting formulae or graphs are missing. As i want to insert mathematical equations, please tell me how to get this option into my VE.

I would appreciate any kind of support. Thanks in advance!

SSastry (WMF) (talkcontribs)
Tlgonline (talkcontribs)

I had $wgGroupPermissions['*']['writeapi'] set to false and got the same error message ("Error contacting the Parsoid/RESTBase server (HTTP 403)").

Therefore, I suggest that you include the following: $wgGroupPermissions['*']['writeapi'] = true;

47.145.162.48 (talkcontribs)

Where did you change that setting???

47.145.162.48 (talkcontribs)

Where in cpanel?

220.244.3.130 (talkcontribs)

I am putting this out more widely as an answer to this issue as I had a LOT of trouble resolving it. Basically, on some (cPanel) hosted sites the Parsoid/RESTBase Server API communications are blocked by several ModSecurity rules. I had to contact my hosting tech support and get them to whitelist rules for my wiki one or two at a time, while generating new ModSecurity rule errors by attempting to edit using VisualEditor until we had found all the rules which were resulting in this error. NB: At some point during this process a few pages might start working - not throwing a 403 - but then test a few more pages as they might still trigger ModSecurity.


To answer the last two questions above - you have to add that code as new lines in your wiki's LocalSettings.php file

Reply to "Error contacting the Parsoid-/RESTBase-Server (HTTP 403)"

Error contacting the Parsoid/RESTBase server (HTTP 500)

1
Raikkonso (talkcontribs)

I am trying to add an Infobox, but whenever I use the {{}} syntax (whether its for the Infobox or for Math), I get the error message "Error contacting the Parsoid/RESTBase server (HTTP 500) when i try to save. Once I remove the {{}} code, everything is ok and i can use both VisualEditor or Source editor to save.


I'm using a fresh install of MediaWiki 1.35.2 from the Mediawiki website. I read that I do not have to install or configure VisualEditor or Parsoid for this version. I am running this on Windows 10 & xampp 8.0.6.

MediaWiki 1.35.2
PHP 8.0.6 (apache2handler)
MariaDB 10.4.19-MariaDB
Lua 5.1.5

Is there any configuration settings that I should add to the VisualEditor extension on LocalSettings.php? I only have the default:

wfLoadExtension( 'VisualEditor' );

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

Can I increase Timeout seconds on VisualEditor with Mediawiki 1.35?

2
MPThLee (talkcontribs)

Error contacting the Parsoid/RESTBase server: (curl error: 28) Timeout was reached


I'm using Parsoid/PHP, which added since MW 1.35


Since some of pages are needs much time to renders up, VisualEditor give up to rendering with curl error 28. Can I increase the timeout seconds?

It's not things like server misconfigure or else. It's just VE gives up to render on certain page on rendering.

MarioSuperstar77 (talkcontribs)
Reply to "Can I increase Timeout seconds on VisualEditor with Mediawiki 1.35?"

Forced to add a description/ verify i own the file i'm uploading.

3
Starbeam2 (talkcontribs)

I'm trying to upload images with the visual editor to a miraheze I run but it forces me to add descriptions to them, and verify i own them. Don't get me wrong regarding verification, I'm not stealing images, but all I do is just click a checkbox. Is there a way to turn this forced verification/ description stuff off? Before answering, bear in mind, i'm not a techie. Thanks in advance.

Universal Omega (talkcontribs)

There is $wgUploadDialog which if I'm not mistaken controls this, but I'm not sure if it can do what you want. Alternatively a bit of JavaScript could probably check the checkbox by default and/or set a default value for description which would allow continuing with uploading.

Starbeam2 (talkcontribs)

Thank you for the answer. Do you know how to do that on a miraheze?

Reply to "Forced to add a description/ verify i own the file i'm uploading."

Invalid Response from Server Error

1
Dapachy (talkcontribs)

As soon as I save changes made with the VisualEditor the error message "Invalid response form Server" is displayed. When the page is reloaded the changes are there and were therefore made.

This error happens everytime I save and is very confusing for our users.

Any solutions to this problem?

Reply to "Invalid Response from Server Error"

How to accept self-signed certificate? curl error: 60

6
Tadeshug (talkcontribs)

Hello,

I'm running private wiki with SSL enabled but I'm getting this error:

apierror-visualeditor-docserver-http-error: (curl error: 60) Peer certificate cannot be authenticated with given CA certificates

I have fallowed this Extension:VisualEditor#Parsoid over HTTPS

How can I resolve my problem?


Tadeshug (talkcontribs)

Hello,


Is there anybody that can help me with this topic? Or is there something that I can try to make it work?

Tadeshug (talkcontribs)

BUMP

213.160.6.194 (talkcontribs)

We are having the same problem. Since we only want to host a wiki server in our local intranet, we don't really want to use an actually signed certificate. Because of this, we are using a self signed certificate (which is also applied by a nginx - reverse proxy).


Is there any way to disable the certificate check? Thanks.

Avin Shum (talkcontribs)

BUMP

Ciencia Al Poder (talkcontribs)
Reply to "How to accept self-signed certificate? curl error: 60"