Extension talk:VisualEditor

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.

now documented

I have set the following to my "LocalSettings.php"

$wgVisualEditorAvailableNamespaces = [
        NS_MAIN => true,
        NS_USER => true,
        NS_EXTRA => true
        ];

What I expected was that VisualEditor is only available for the namespaces MAIN, USER and EXTRA. What is happening is that also the namespaces CATEGORY and FILE are available for editing with VisualEditor.

Changing the setting to the following does not change the set of available namespaces:

$wgVisualEditorAvailableNamespaces = [
        NS_MAIN => true,
        NS_USER => true,
        NS_EXTRA => true,
        '_merge_strategy' => 'array_plus'
        ];

So my question is: Which values are available to "_merge_strategy"? or What do I have to add to get VisualEditor only for the namespaces MAIN, USER and EXTRA?

Thanks for some insights.

Doing something like the following does not change anything either:

$wgVisualEditorAvailableNamespaces = [
        NS_MAIN => true,
        NS_USER => true,
        NS_FILE => false,
        NS_CATEGORY => false,
        NS_EXTRA => true
        ];

Adding something like 'array_replace' to '_merge_strategy' does not work either. Currently I just do not get it.

I believe the merge strategies are only available on extension.json. For the available values see Manual:Extension.json/Schema#Merge strategies.

Have you tried manipulating the value in an "extension function"? e.g.

$wgExtensionFunctions[] = function() {
  unset( $GLOBALS['wgVisualEditorAvailableNamespaces'][NS_CATEGORY] );
};

(Code not tested)

Thanks for you info. @Tgr: came up with the decisive hint for easy configuring. This was probably too obvious. Current docu is pretty bad so I will improve that. The info about the merge strategies was very interesting too. So this is nothing for use in "LocalSettings.php".

That's how to enable and disable namespaces:

$wgVisualEditorAvailableNamespaces = [
        "File" => false, 
        "Category" => false, 
        "Extra" => true
        ];

solution found

If i try to Insert a template, the template search shows me my template but also all the /Doku (germen translate of /Doc) subpages with the documentation for the template.

How can i hide the /doc Subpages?

Example:

if i search for "Löschen" (name of the template)

the dropdown shows me:

Löschen

Marks a Page as delete candidate

Löschen/Doku

Marks a page as delete candidate

I found the solution. you have to overwrite the systemmessage Templatedata-doc-subpage with the translated version of doc.

For example the german wikipedia MediaWiki:Templatedata-doc-subpage – Wikipedia

The default signature function in the visual editor currently uses the timestamp signature (~~~~). I would like it to use the signature without timestamp (~~~).

Is it possible to configure this function?

I upgraded my MediaWiki instance from 1.35.3 to 1.36.2 a couple days ago. I have everything pretty much up and running again but when trying to use the Visual Editor I'm now getting this error. I use Nginx1.20.1 + Apache2.4 + PHP7.4-FPM, and I have enabled the http2 protocol both on nginx and on apache. Curl is version 7.68.0. Any pointers on how to handle this one?

I have the same issue. Had to downgrade to HTTP 1.1 on the Nginx proxy

When using a self-signed cert signed by an internal root CA, I was able to find a workaround by placing our org's root CA certificate in the trust store of the server running MediaWiki.

On CentOS 7:

cp internal_root_ca.crt /etc/ssl/

ln -s /etc/ssl/internal_root_ca.crt /etc/pki/ca-trust/source/anchors/

update-ca-trust

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

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

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}

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 )

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)

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?

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

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

I reinstalled MediaWiki and it works now....

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

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.

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

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.

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

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.

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.

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

Thanks to 138.188.55.41 !

Thanks for the update, I had the same problem and this is what solved it for me

I'm new at VE, so please forgive my incompetence regarding some questions.

After inserting a Node (array of data with {type: 'mynode'}{type: '/mynode'}) at the end of a paragraph, the cursor is not positioned correctly (cursor is inserted before the node). There are no such problems in the middle of the sentence.

Insertion is performed using the insertContent method.

Can you please tell me what I'm doing wrong?

Thank you very much!!!!!!!!!!!

I'm VERY new at this, so I apologize in advance for my inexperience.

I'm using VisualEditor to add galleries to my pages -- WYSIWIG works extremely well for me, as a newbie to this sort of project -- and every single time I edit or even touch a gallery, it adds "Index.php?title=" to the file name, breaking ALL the files in the gallery. If the gallery isn't ever touched outside of the first time, it loads fine, but the moment you try to edit it, it renames all the file locations and everything breaks.

Does anyone know what is causing this, and how I can fix it? I've barely started this (private, personal project) Wiki but having multiple galleries is going to be a necessary thing :(

Hey guys,

I have a major problem with the parsing of a template we wrote. We have a template that uses a start and end template page to build a kind of a hexagon blog. We used the unordered list (<ul>-Tag) and custom counts of items (<li>-Tags) to create a good looking block of hexagons. This works for the page in the view-mode pretty fine.

Since the VE startet to show us the template visually (what I love, btw.) our templates are shown as they where without the <ul>-tag which looks strange and avoids the real styling to be loaded correctly. It kind of destroys the whole look. Seems like the editor closes the <ul>-Tag before adding the other Items. So in the HTML-code the <li>-tag isn't put in the <ul>-tags anymore.

Is there a solution for these kind of templates? (In terms of rewriting the template) Or can I disable the parsing for this specific template or the entire wiki somehow?

Does anyone have the same problems?

Sometimes when users submit an edit, the Visual Editor throws this error. Although it seems like just a visual bug.

https://i.imgur.com/C4zH4ZK.png