Extension talk:VisualEditor/Flow

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.

My wiki's style keeps reverting to the default active skin's CSS, even though I've modified both the Vector.css and Common.css. In fact, this happens even when using other skins. I have to resort to refreshing the page with CTRL + SHIFT + R, which is obviously not a sustainable solution.

I've noticed that disabling the VisualEditor in LocalSettings.php fixes the issue. So, I'm wondering: is there a cache file for VisualEditor that's causing the original CSS to reappear whenever I reload the page?

This problem has been driving me crazy for a week.

Please help!

My wiki: sonic-city.net/wiki

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!

Same here, it would be a nice option

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

Not yet.

Looking for this as well.

Would appreciate a solution for this as well!

Hello all,

I have had a quick look at this, and decided it was too much of a specific hack. But for all of you asking this question, see the file:

 VisualEditor/modules/ve-mw/init/targets/ve.init.mw.ArticleTarget.js

where you will find this function:

 ve.init.mw.ArticleTarget.prototype.showSaveDialog

and I'm pretty sure that is where the magic happens. It isn't just a simple case of saying "skip the dialogue" because there are numerous messages that are handled.

HtH,

DanShearer (talk) 01:25, 11 December 2022 (UTC)

Adding this at the beginning of ve.init.mw.ArticleTarget.prototype.showSaveDialog

this.save(this.getDocToSave(), this.getSaveOptions());

this.tryTeardown(true);

return;

Seems to save the changes without annoying popup and leave the editing mode. But it still requires a manual page refresh (or clicking the Page tab) to see the saved changes.

A better way is to replace

`var openPromise = windowAction.open( 'mwSave', data, action );` with `var openPromise = windowAction.open( 'mwSave', data, 'save' );`

This opens the pop-up, but closes it again immediately and the user is taken back to the reading view without having to refresh the page. The briefly opened pop-up bothers me less than having to manually switch back to the reading view.

Read tab, not the Page tab

Well both are fine actually ;-)

I am facing a strange issue on my wiki. After saving the content once without refresing the page the subsequent edits are not saved. No actions takes place on clicking the save button of the save changes dialog box tinyurl.com/2ypssbqd

I am using mediawiki 1.40.0-wmf.25

Kindly help!

Product	Version
MediaWiki	1.36.1
PHP	7.4.20 (fpm-fcgi)
MariaDB	10.5.11-MariaDB
ICU	67.1
Lua	5.1.5
Elasticsearch	6.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

No wiki farm on my end, but getting the HTTP 400 error as well on my single wiki running 1.36.1. NGINX web server. Also getting the same debug log code as you. I'll post more if I find any resolution.

Edit: Specifically, it works when creating a new page, but it doesn't work when editing an existing page. See mention of it here: https://www.mediawiki.org/w/index.php?title=Topic:Vunt92vkiyisn8cu&topic_showPostId=vupnmgwaasz9pvfm#flow-post-vupnmgwaasz9pvfm

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

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

Adding to hosts file ie; /etc/hosts on Linux, fixed it until the solution is known

127.0.0.1 yourwikidomain.com

Adding my external hostnames to /etc/hosts (mapping them to 127.0.0.1) fixed this for me. If the local server cannot resolve its own public-facing hostname+domain, then VisualEditor fails in this way. In my case, I was iterating on a new server build to upgrade from 1.27 to 1.38, and I kept hitting this problem because my host is not yet officially deployed, with DNS updated appropriately.

Alas, this did not fix for me on MW 1.38

I noticed in the apache2 access log that it was trying to get /wiki/rest.php/https(link)://my.fullqualifiedwiki.domain/v3/page/html/Main_page instead of /wiki/rest.php/my.fullqualifiedwiki.domain/v3/page/html/Main_page (there is no"(link)" but I'm trying to get around the "abusefilter-warning-linkspam")

So in LocalSettings.php I added 'domain' => 'my.fullyqualifiedwiki.domain' to the

$wgVirtualRestConfig['modules']['parsoid'] = array(
    'url' => $wgServer . $wgScriptPath . '/rest.php',
    'domain' => 'my.fullyqualifiedwiki.domain',
);

This worked for me.

My wiki fixed after add text to Nginx config files srrver block. location /rest.php/ { try_files $uri $uri/ /zw/rest.php?$query_string; }

Hi!

This is a very good extension, but it should be even better!

Is there any hope that the developers will add a function to change the color of the text?

@Derek Jones Smr: Usually that's done with templates created on individual wikis, such as {{Green }}, {{Red }}, etc.

Of course, it's a bit easier with templates. Thanks!

But as a basic functionality of the add-on itself, it would be even better

I add internal link to some namespace page using widget. This widget insert link with text "Namespace:Page". Where is option or extension that will add link without namespace in text? Just "Page".

Visual Editor allows you to use a custom label for any link, though I'm guessing you want the label to be added automatically, right? In that case, you may be better off using the DisplayTitle extension to customise the link label for any wiki page (provided that the page exists on the wiki).

How do I activate this for Wiktionary?

How do I allow my users to choose wikitext/source-edit or VisualEditor AND use the wikitext/source-edit by default, not VisualEditor?

My users like VisualEditor, but it isn't always the right feature for editing pages that are primarily transclusions or conditional code. I would like MediaWiki to default to using "Edit Source" aka raw wikitext, but still keep the option to click the (Visual) "Edit" button to switch to VisualEditor.

I have tried many things in settings, but most just seem to remove the option for using VisualEditor entirely.

On all existing pages, things work fine: There are two buttons shown:

• "Edit" (VisualEditor) and
• "Edit source" (wikitext).

Users may click whichever button they prefer. However, following a redlink (URL ends in ./{pagename}&action=edit&redlink=1) always opens up a page in VisualEditor and furthermore does not allow the user to switch to "Edit source". Source editing button does not work

Thank you for your time.

P.S. I am using Skin:Citizen, a known compatible skin.

As soon as I save changes made with the VisualEditor the error message "Invalid response from 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?

I also have this error when try download images. When the page reloaded the image are there.

Got the same error. In my case switching the PHP version from 8.3 to 8.1. removed the error.

One of our clients does not want the save confirmation dialog to appear; they would like for the save to happen immediately.

They proposed using this code on their wiki:

ve.init.mw.ArticleTarget.prototype.showSaveDialog = function ( action, checkboxName ) {
    this.save(this.getDocToSave(), this.getSaveOptions());
    this.tryTeardown(true);
    return;
}

However, it only executes in the browser's console. When adding it to MediaWiki:Common.js, it doesn't do anything.

How can this snippet of code be modified to execute such that it can be stored in MediaWiki:Common.js?

Extension:EnhancedUpload does just that

It seems like that extension is for uploads of files only, whereas here we are trying to save pages without the summary/confirmation appearing. Am I mistaken?

ah, yes. I was not reading this properly. Yes, EnhanceUpload does onyl fix several options when uploading files with VE

hello @MyWikis-JeffreyWang could you try the following ?

(function () {

    // @see https://www.mediawiki.org/w/index.php?title=Topic%3AY42xiwa26cl6d1zl&topic_showPostId=y4cmacnoqiruyy2x&fromnotif=1#flow-post-y4cmacnoqiruyy2x
	mw.loader.using('ext.visualEditor.targetLoader', function () {
		// Register plugins to VE. will be loaded once the user opens VE
		mw.libs.ve.targetLoader.addPlugin(function () {

			ve.init.mw.ArticleTarget.prototype.showSaveDialog = function (
				action,
				checkboxName
			) {
				// @see ve.ui.MWSaveDialog.js -> getActionProcess
				var saveDeferred = ve.createDeferred();
				this.emit('save', saveDeferred);
				var saveOptions = this.getSaveOptions();

				// @see ve.init.mw.ArticleTarget.js -> onSaveDialogSave
				this.emit('saveInitiated');
				this.startSave(saveOptions);
				this.saveDeferred = saveDeferred;
			};
		});
	});
})();

That works well for me, I've passed it on to the client. Let's hope it works for them!

Thanks a bunch @Thomas-topway-it!