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.

AVNeu (talkcontribs)

I have a private Wiki, which I have updated to version 1.35.

I have activated the extension as follows:

wfLoadExtension( 'VisualEditor' );

$wgDefaultUserOptions['visualeditor-enable'] = 1;


When I try to edit a page I don't get an error message, but the content of the page is not loaded into the editor, but the content of the footer.

URL: /api.php?action=visualeditor&format=json&paction=parse&page=Hauptseite&uselang=de-formal&formatversion=2

Shortened answer:

{ "visualeditor": { result: "success", content: "↵<!DOCTYPE html>↵<html class="client-nojs" lang="de-x-formal" dir="ltr">↵<head>↵<meta charset="UTF-8"/>↵<title>Anmeldung erforderlich – Wiki</title>↵[... more content ...]" } }


"Anmeldung erforderlich" means "Login required".


Does anyone know how I have to configure the Wiki to make the VisualEditor work?

Reply to "Private wiki configuration"

Error contacting the Parsoid/RESTBase server (HTTP 401)

1
TruckerB88 (talkcontribs)

I've got this error when I try to edit an article with Visual Editor. This error does not appear when I write a new article.

So, LapisLazuli33 wrote good pieces of information about rewrite rule. And so I found out, that my .htaccess auth file makes the problem:

AuthUserFile /www/htdocs/*/*/.htpasswd

AuthGroupFile /dev/null

AuthName 'please insert password'

AuthType Basic

require valid-user

When I rename the file, I can use VisualEditor. But this authorization is important for my NGO. Is there a way, I can use both?

Reply to "Error contacting the Parsoid/RESTBase server (HTTP 401)"
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.

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"

Reply to "Nginx configuration"

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

19
Technoabyss (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.

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

Technoabyss (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 Technoabyss (history)
This post was hidden by Technoabyss (history)
This post was hidden by Technoabyss (history)
This post was hidden by Technoabyss (history)
This post was hidden by Technoabyss (history)
Technoabyss (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.

Technoabyss (talkcontribs)

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

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

VisualEdit on ssl return error "Parsoid/RESTBase server: (curl error: 60)"

1
5.252.214.1 (talkcontribs)

When I set permanent redirect in apache to https i'm getting error "Parsoid/RESTBase server: (curl error: 60)".

Here is my VirtualHost configuration:

<VirtualHost wiki.***.eu:80>

ServerName wiki.***.eu

Redirect permanent / https ://wiki.***.eu/

</VirtualHost>

<IfModule mod_ssl.c>

...

<VirtualHost wiki.***.eu:443>

ServerName wiki.***.eu

DocumentRoot /var/www/wiki/

ErrorLog ${APACHE_LOG_DIR}/error.log

CustomLog ${APACHE_LOG_DIR}/access.log combined

SSLEngine on

SSLCertificateFile /etc/ssl/certs/nazwa/cert.pem

SSLCertificateKeyFile /etc/ssl/certs/nazwa/cert.key

<FilesMatch "\.(cgi|shtml|phtml|php)$">

SSLOptions +StdEnvVars

</FilesMatch>

<Directory /usr/lib/cgi-bin>

SSLOptions +StdEnvVars

</Directory>

</VirtualHost>

</IfModule>

Reply to "VisualEdit on ssl return error "Parsoid/RESTBase server: (curl error: 60)""

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

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

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

Hi all, can I turn off the notice "You have followed a link to a page that does not exist yet. To create the page, start typing in the box below (see the help page for more info). If you are here by mistake, click your browser's back button" I get when editing a new page. We have developed our own skin and now just want a blank page after clicking "Add new page", without a notice. It is unclear to the user, he/she just want to type text in a new page.

Waanders (talkcontribs)
Reply to "Turn off notice create page"

VisualEditor fails with HTTP 403 errors on NameCheap hosting with Apache

4
Summary by SSastry (WMF)

NameCheap uses Apache. HTTP 403 there is triggered by ModSecurity.

Contact support to resolve these security issues. Whitelisting / turning off ModSecurity can help.

Csharries (talkcontribs)

I recently encountered this issue when deploying MediaWiki 1.35 + VisualEditor onto Namecheap Shared Hosting which uses Apache.

If you experience this error when attempting to save a page, it is likely that ModSecurity has triggered a warning. In order to resolve this issue I simply had to contact Namecheap support and request that they whitelist the security rules that were being triggered on my site, since then I have been able to use VisualEditor perfectly fine.

Rehman (talkcontribs)

Hello. I too am on Namecheap shared hosting (Apache). It is quite frustrating that everyone talks about this out-of-the-box issue, but there seems to be no clear solution. Would you be able to share your ticket number with me please (email?), so that I can try reaching out to namecheap, asking them if they can apply that fix for me?

SSastry (WMF) (talkcontribs)

Did you try this already?

Rehman (talkcontribs)

Hello @Csharries, I cannot thank you enough for sharing the above. You are right. I did contact Namecheap and their ModSecurity WAF was the cause of the issue. Once they turned it off on all my test domains/subdomains, VE worked.

I cannot seem to create or edit in [at least] the User namespace though, but I guess that is a VE setting.

I doubt I'd be able to resolve this issue if you hadn't posted the above comment. So, thank you again.

For anyone wanting to contact Namecheap for the same issue, you may quote the ticket number QSE-776-10867. For others, just see if your hosting service have ModSecurity or another WAF enabled, and if they could turn it off (at least temporarily) for you to test.

Hope this helps.

Does VE have a known bug in 1.35?

3
Summary by Rehman

In my case, the issue was caused by the ModSecurity WAF used by Namecheap. Once they turned it off, VE worked.

Rehman (talkcontribs)

Hello. After unsuccessfully searching for the answer, I decided to ask this here.

It seems like a number of wiki owners cannot get VisualEditor running out-of-the-box in MW 1.35.

Is this a known problem, and has a solution been shared anywhere?

Pinging User:Reedy (based on the MW 1.35 announcement).

SSastry (WMF) (talkcontribs)

Do go through that ticket again now. Most users have been able to get their installs working. But, based on the email thread and the other namecheap thread, it looks like you need to manually configure your private wiki usecase and also figure out namecheap issues.

Rehman (talkcontribs)

Thank you for commenting. In my case, the issue was caused by the ModSecurity WAF used by Namecheap. I will share more details on the other threads.

Switch off VisualEditor on mobile version

1
Fokebox (talkcontribs)

Hi there! Can someone let me know how to switch off VisualEditor on mobile version of my site? (I use MobileFront end extension)

Reply to "Switch off VisualEditor on mobile version"