Extension talk:VisualEditor/2021

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.

Error contacting the Parsoid/RESTBase server (HTTP 404) when using short links.

Product Version
MediaWiki 1.35.1
PHP 7.3.25 (cgi-fcgi)
MySQL 5.7.26-29-log
ICU 63.2

Shared hosting, Siteground

Apache/Nginx Compatible Server

.htaccess file has been created to assist in link shortening.


I'm having some trouble getting VisualEditor (herein referred to as VE) to work. It worked perfectly out the box when I installed MediaWiki and activated it, but the second I tried to shorten links (hide the index.php?title=main_page), it broke. Here are the steps I took:

  1. Installed MediaWiki 1.35.1.
  2. Created .htaccess file to activate rewrite capabilities. (VE worked at this point)
  3. Added " $wgScriptExtension = ".php"; $wgArticlePath = "/$1"; "


When I added that code to shorten the link from "https://example.net/index.php?title=Main_Page" to "https://example.net/Main_Page", I suddenly got the 404 error. Removing those lines of code results in the extension working as expected.

I've added my two cents to this bug report, as it's pretty close to if not exactly the issue I'm going for. Only difference is my .htaccess file doesn't harm the functionality of VE. There are many bug reports on phabricator with the same issues. I've tried the steps outlined in VE's troubleshooting section on the extension page for 404 errors, but nothing seems to work. I don't think I have root access. Any ideas what's going on? Orribu (talk) 09:47, 5 January 2021 (UTC)

As an update, I can't create new pages using VE either; I get the same error when I go to save changes. Orribu (talk) 01:18, 10 January 2021 (UTC)
Looks like currently VE won't work with Short URL per T270376, and it won't work on subpages if users don't have access to apache config files to do the VE doc recommended AllowEncodedSlashes NoDecode (which can't be done in .htaccess). The closest I could get to a shorter URL config was the default /wiki/ setup.
What worked in my case was to ensure the site was on https, then to have in LocalSettings.php:
$wgScriptPath = "/w"; # Folder MW is installed in on server
$wgArticlePath = "/wiki/$1"; # Short URL path shown in browser
Also ensure this line had https:
$wgServer = "https://www.sitename.com";
And in .htaccess (apache non-root config file, at root web level, not in the w folder):
RewriteEngine on
RewriteBase /
# Rewrites all URLS without blog in them
RewriteCond %{REQUEST_URI} !^/w/
# Rewrites all URLS [Replace "example-sitename" with the actual domain, without the TLD (.com, .net, .biz, etc)]
RewriteCond %{HTTP_HOST} ^(www\.)?example-sitename\.
# Rewrite all those to insert /folder
RewriteRule ^(.*)$ /w/$1 [L] TiltedCerebellum (talk) 02:06, 3 March 2021 (UTC)
Hey @TiltedCerebellum, thanks for the input! I've reconfigured the wiki to point to /wiki/$1! Unfortunately, I've run into another snag. It's giving me a 500 error this time:
Error contacting the Parsoid/RESTBase server (HTTP 500)
I tried doing the .htaccess in both the root and mediawiki folders and got a 404. I moved the .htaccess to the root instead of the mediawiki folder and got the same issue. Am I doing something wrong? Orribu (talk) 06:45, 11 March 2021 (UTC)
Are you wikis physical files nested in a /w/ folder in its web directory? Basically I had to use the recommended default MediaWiki setup that Wikipedia uses. My files were not nested in a /w/ folder in the web directory... I had to move it there and figure out the recommended URL rewrites from my host to cause it to redirect the domain to see the files in a subdirectory rather than web root. From your prior settings it looks like you have your MediaWiki files in web root instead of nested in a /w/ folder?
That told the browser that my site files physically lives in site.com/w/ (a subdirectory /w/ in my web directory), but the URL was rewritten to look like it is living in site.com/wiki/ . That was the only setup under which I was currently able to get VE working as intended. Though it still doesn't work on subpages, I see multiple bug reports regarding that--a problem with VE itself. No idea if that helps (I'm just a user of MW like you, and this was just the only config that worked for me on my host). You might need assistance from VE extension developer/user or a MediaWiki Support Desk member. TiltedCerebellum (talk) 21:11, 13 March 2021 (UTC)
Hey there, thanks for getting back to me! I really appreciate your help and patience with this matter.
I've done as you instructed and nested my installation in a "w" folder, so now the site physically lives in wiki.twistedfates.net/w/.
That url works, but the second I edit LocalSettings.php and add the $wgArticlePath = "/wiki/$1"; I get a 404 error. Commenting the ArticlePath line out allows wiki.twistedfates.net/w/ to work again.
So just to recap to make sure I've understood you correctly, I have the following code in /.htaccess:
RewriteEngine on
RewriteBase /
# Rewrites all URLS without blog in them
RewriteCond %{REQUEST_URI} !^/w/
# Rewrites all URLS [Replace "example-sitename" with the actual domain, without the TLD (.com, .net, .biz, etc)]
RewriteCond %{HTTP_HOST} ^(www\.)?example-sitename\.
# Rewrite all those to insert /folder
RewriteRule ^(.*)$ /w/$1 [L]
(I replaced "example-sitename" with "wiki.twistedfates" but I could be misunderstanding something!)
Then, I added the following lines in /w/LocalSettings.php:
$wgScriptPath = "/w"; # Folder MW is installed in on server
$wgArticlePath = "/wiki/$1"; # Short URL path shown in browser
Just to triple-check, I have ensured that wgServer contains https:// instead of http://.
I just can't seem to get the shortened URL to work... Orribu (talk) 07:39, 16 March 2021 (UTC)
You're probably better off following the MW Short URL/Apache simple manual example than my example for the URL rewrites, or seeing if someone from the help desk can provide a solid answer, I'm not good at this part myself frankly. I wasn't able to get their example working properly because I simply don't know enough about this, so not a good person to ask for this, sorry.
If mine did work (and isn't incorrect--not sure it's the right way to do it AT ALL), I'd think you'd end up with something like:
RewriteCond %{HTTP_HOST} ^(wiki\.)?twistedfates\.
Then I'd try accessing pages for viewing-specifically at:
https://wiki.twistedfates.net/wiki/? TiltedCerebellum (talk) 05:51, 17 March 2021 (UTC)
Aw no worries! Thank you so much for helping out. We'll figure this shortURL business out and hopefully VE will be compatible with /$1 in the future! Orribu (talk) 20:23, 17 March 2021 (UTC)
Yw. I hope so too, we prefer it with that config also... many of our uses are used to typing certain things direct in the URL so having the added /wiki/ threw everyone off. Having the edit page URL be /w/ and the view page url being /wiki/ also threw them off. :| TiltedCerebellum (talk) 04:53, 19 March 2021 (UTC)
i am done with this nonsense i will use classic editor now....
why release with software if it has this issues at first plase for god sake ! 176.232.58.40 (talk) 21:59, 30 April 2021 (UTC)

Error contacting the Parsoid/RESTBase server: http-request-error

Getting the error mentioned in the Topic when trying to edit anything on mediawiki.

Upgraded Wiki from 1.32 to 1.35 (sequential upgrade). This is a private Wiki.

Followed the steps as per the Visualeditor extension page. I have read other users thread who are having similar issues.

Following is the setup in localsettings.php

wfLoadExtension( 'VisualEditor' );

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

$wgDefaultUserOptions['visualeditor-editor'] = "visualeditor";

$wgVisualEditorParsoidAutoConfig = true;

#Added this based on reading a few threads as VE requests as an anonymus user

if (in_array($_SERVER['REMOTE_ADDR'],

  [

        $_SERVER['SERVER_ADDR'],

        '127.0.0.1',

        'localhost',

        '<public IP>',

        '<IPv6>',

        '::1']

)) {

        $wgGroupPermissions['*']['read'] = true;

        $wgGroupPermissions['*']['write'] = true;

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

}

Appreciate if any one could help me with this Wikiusr23 (talk) 19:45, 7 January 2021 (UTC)

Any update for this? 5.173.139.226 (talk) 09:58, 15 May 2021 (UTC)
Had the same problem and couldn't find any solution here. After a bit of debugging i found out, that the problem was the HTTPS communication within the web server. We use for $wgServer = the HTTPS-address and a certificate of our own PKI. Therefore we had to make sure, that the web server trusts this PKI.
We copied the public certificates of our PKI to /usr/share/pki/trust/anchors/ and run update-ca-certificates. After this the PKI certificates were listed at /etc/ssl/certs and the visual editor works.
Hope this helps anybody. 212.7.174.107 (talk) 08:56, 19 May 2021 (UTC)
Got the same issue, when saving changes on any page. Parsoid-/RESTBase-Server:http-request-error. None of the workarounds worked for me. Does someone has another idea? Mediawiki version is 1.35 as well. 37.24.39.98 (talk) 11:11, 14 September 2021 (UTC)
The tool is connected to the local server. So check that you can connect to the address given in $wgServer from the machine
$wgServer = "yourSiteAddress";
try from the server: ping yourSiteAddress
if it doesn't work, you can add an entry in the /etc/hosts file Nevaram (talk) 10:02, 20 September 2021 (UTC)
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; MattPilz (talk) 01:34, 10 January 2022 (UTC)

Error with IIS and Windows-Authentication

Product Version
Mediawiki 1.35.1
PHP 8.0
MariaDB 10.5
IIS 10


I use the LDAP Plugins (LDAP Stack) on an IIS to work with an AD-Environment.


It works and the users automatically get logged in.


Unfortunately i cannot launch Visual Editor when i have "Anonymous Authentication" deactivated in IIS.


If i enable anonymous authentication in IIS the VE starts working as expected again - but this leads to users not getting logged in automatically.


It throws an 401 Error as soon as I click on "Edit", which I think is caused by the IIS already denying the connection for the anonymous "Visual Editor" User-Agent.


I have seen workarounds for Apache, but unfortunately i could not find mixed authentication configs for iis. Is there any workaround possible? For example "creating" a windows service account for the VE which is used so i can use VE and automatic logins?


Thanks in advance! 2A02:810B:1040:712C:E01A:5E1A:6335:E030 (talk) 15:28, 13 January 2021 (UTC)

Same problem, saw your post with no response, which makes me sad. Been googling for 2 days trying to resolve. Gregzme17 (talk) 18:05, 17 March 2022 (UTC)

When I press the "save changes" button after making changes in the Visual Editor, then the following notice pops up:

Please note that all contributions to EkklesiaWiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.

You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see ... for details). Do not submit copyrighted work without permission!


Q: How / Where can I change this copyright notice? Frank on MW (talk) 13:40, 20 January 2021 (UTC)

I need this info too. And I see after 3 years no one has answered your question. 
I think I picked the wrong Wiki to work with. Theitguy1 (talk) 16:48, 31 July 2023 (UTC)

Save page on edit dont close "save changes" dialog

On creating page - all ok.

If i am try to save changes when editing page - no errors in Chrome dev console, no error in Parsoid logs.

api.php XHR request return 200 OK status. But... Dialog does not closing and page not reload.

Excepted: page roloaded after saving 176.37.172.54 (talk) 13:44, 22 January 2021 (UTC)

My wiki version: 1.35
Parsoid ver: 0.11.0
if click "Save changes" when no any changes - all ok. Page reloaded as excepted.
If i am add any char(make any changes on page) - save button does not close dialog and not relolad page...
Response from api.php
{
"visualeditoredit": {
"categorieshtml": "<div id=\"catlinks\" class=\"catlinks catlinks-allhidden\" data-mw=\"interface\"></div>",
"content": "<div class=\"mw-parser-output\"><p>sdfdf <b>dfasfaffff asd as</b>\n</p>\n\n\n\n\n</div>",
"contentSub": "",
"displayTitleHtml": "Test2",
"isRedirect": "",
"jsconfigvars": [
],
"lastModified": {
"date": "22 января 2021",
"time": "14:27"
},
"modules": [
],
"newrevid": 98,
"result": "success",
"watched": true,
"watchlistexpiry": null
},
"warnings": [
{
"code": "unrecognizedparams",
"html": "Нераспознанный параметр: vetags",
"module": "main"
}
]
} 62.244.50.171 (talk) 14:31, 22 January 2021 (UTC)
Skin: vector
i am trying parsoid 0.8 - has same issue.
Looks like some issue in VE js code. 62.244.50.171 (talk) 14:42, 22 January 2021 (UTC)
In skin MinervaNeue - all working like expected 62.244.50.171 (talk) 14:44, 22 January 2021 (UTC)
Screen recording with issue: youtu .be/-9CXOyctjFE AssadaKiev (talk) 15:33, 22 January 2021 (UTC)

(Curl error: 60) SSL peer certificate or SSH remote key was not OK (MediaWiki 1.35 + VisualEditor + Windows/IIS)

Product Version
Mediawiki 1.35.0
PHP 7.3.24
MariaDB 10.5.8
IIS 10
OS Windows Server 2019

Symptoms:

New installation of private MediaWiki 1.35 with Visual Editor. IIS configured to use Windows Authentication (to enable authentication with Windows AD). MW works as excepted, launching VE causes Curl error 60.

VisualEditor documentation states that with MediaWiki 1.35, you should not need to download anything to get VE working, private wiki may need some configuration but otherwise VE should work out of the box.

Many hours (days) and lots of research later I can say, that getting VE work with MediaWiki 1.35 on Windows environment wasn’t such an easy task. I found lots of suggestions how to get VE work after “Error contacting the Parsoid/RESTBase server: (Curl error: 60) SSL peer certificate or SSH remote key was not OK”, but none of them worked for me.


Workaround:

This is my solution (quite simple, actually), hope this helps someone to get things working without days of work and banging head to the wall.

1. Install MediaWiki 1.35 with extensions of your choice.

2. Make sure that everything is working like you want (except that stubborn VisualEditor that gives you Curl error 60)

3. Export CA-certificate and add reference to it in php.ini -conf (*

4. Modify authentication settings of rest.php -file in IIS (**

5. Add following lines to LocalSettings.php

if($_SERVER['REMOTE_ADDR'] == 'your_server_ip_address'){

$wgGroupPermissions['*']['edit'] = true;

$wgGroupPermissions['*']['read'] = true;

}

6. Make iisreset


(* If I get it right, the Curl 60 is generated when you click on modify in MediaWiki, which leads to connection attempt to VE through PHP that can't verify the server certificate in use. To fix this error you need to export the CA-certificate and tell the PHP where it is found:

1. Open mmc → Add/Remove Snap-in → Certificates → Computer account

2. In certificates -console navigate to Trusted Root Certification Authorities → Certificates

3. Select your Root CA → Export → Base-64 encoded X.509 (.CER) (this is equivalent to .pem -certificate format) → Save to the wiki root -folder (same place where is your LocalSettings.php) with name “cacert.cer”

4. Go to your PHP install folder and find php.ini → find line ;curl.cainfo =

5. Remove ; and add absolute path to your exported cacert.cer -file, example: curl.cainfo = “c:\WIKI\cacert.cer”


Now the curl 60 should disappear, you can verify that by changing the IIS authentication settings to Anonymous Authentication and authenticating with log in form.


(** SSO wont work if you have Anonymous Authentication enabled in IIS and VE wont work if it is disabled. This is a problem if you use something else than username/password to authenticate users (you know what I mean if you have smart cards in use).

You can tackle the authentication problem by setting the Anonymous Authentication only to the rest.php -file (found in you wiki root) and everywhere else you can use Windows Authentication and keep the Anonymous Authentication disabled:

1. Navigate to your %windir%\system32\inetsrv\config directory and modify applicationHost.config

2. Search <location path=”your_wiki_site”> … </location> section and add a new section below it:

<location path=”your_wiki_site/rest.php”>

<system.webServer>

<security>

<authentication>

<anonymousAuthentication enabled=”true” />

</authentication>

</security>

</system.webServer>

</location>

3. Save your changes to the config file and make an iisreset.


Now you should have working MediaWiki with Visual Editor. Configmaster (talk) 10:45, 29 January 2021 (UTC)

I could not import my certificate in the cert store, so I added the ignore option for curl to get it running:
edit includes/libs/http/MultiHttpClient.php
                $ch = curl_init();
+                curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
+                curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
                curl_setopt( $ch, CURLOPT_PROXY, $req['proxy'] ?? $this->proxy );
Now curl does not check my certificate, but it works. 89.166.216.113 (talk) 11:12, 14 March 2021 (UTC)
Did that fix and it worked like a charm. Thanks for sharing !
NB: It's a private Wiki too, not open on public internet 81.220.61.63 (talk) 10:41, 15 October 2021 (UTC)
THANK YOU !!!!!!!!!! 217.110.33.34 (talk) 17:14, 12 May 2023 (UTC)
After hours of search & try I finally found a solution for my private wiki.
Here are my steps and solution. Maybe they will help someone.
- See what is the problem:
curl --trace-ascii trace.txt wiki-adress/api.php
My curl.cainfo in the php.config was not used. In the trace.txt I found the path.
- The I added my SSL cert at the end of ca-certificates.crt
sudo nano /etc/ssl/certs/ca-certificates.crt
   -> add private cert at the end
- I use NGINX with htaccess protection. But now I got a 401 error. Thats why I disabled the auth*
-> remove auth_* in NGINX config
   server {
       auth_basic "Restricted";
       auth_basic_user_file /etc/nginx/.htpasswd;
   }
- Now I got a 400 error. I added following line in NGINX config:
     location /rest.php/ {
           try_files $uri $uri/ /rest.php?$query_string;
       }
sudo nginx -t
sudo systemctl reload nginx
This finally worked for me.
Unfortunatelly I have no more htaccess protection. 88.130.78.70 (talk) 11:01, 5 May 2021 (UTC)
I have same error (Curl error: 60) with MW 1.35.2 working on the virtual server (Ubuntu 20.04, Apache2, PHP 7.4.3, MySQL 8.0.25). I have assumption that error arise from NGNIX - Apache bundle, where Apache works throwout 127.0.0.1 localhost.
I don't knew, how to fix this. No one of presented here methods don't work for me. KarelMike (talk) 16:04, 29 June 2021 (UTC)
Thanks this is good! Do you face any issues with image uploads? I get a Could not open lock file for "mwstore://local-backend/local-public/ while uploading Lokeshwarans (talk) 18:39, 27 September 2021 (UTC)
I have some wiki websites on different hosts and yesterday when using VE I faced with the same error: (Curl error: 60) SSL peer certificate or SSH remote key was not OK
What steps should be made to resolve this problem I really don't know. Can someone help me? Fokebox (talk) 10:59, 1 October 2021 (UTC)
     location /rest.php/ {
           try_files $uri $uri/ /rest.php?$query_string;
       }
This worked for me, thanks! 95.57.117.162 (talk) 08:43, 11 October 2021 (UTC)
How do I "Export CA-certificate"?
Thanks in advance!
Christian 2001:9E8:303B:7900:412F:8C5C:22AC:71D3 (talk) 15:52, 3 September 2022 (UTC)

Pasting images

Hi, I am writing an article, I would like to paste a picture .... Oh no dialog box appears, I have to confirm the license (1), click Send (2), enter a name (3), enter a description (4), press Use this image (5) , press Insert (6). That's six unnecessary clicks. When using other editors, pasting images is instant. I think everyone around the world would like these six clicks removed Karoljas96 (talk) 07:24, 30 January 2021 (UTC)

There is a necessary tension between the drive to make contributing easier and ensuring that users appropriately consent to the consequences of their actions. For Wikimedia uses, I seriously doubt we will want to reduce these steps; some consider it too easy as-is.
If you think a third party site using VisualEditor would value swinging that workflow closer to the former than that latter, please file a Phabricator task for having a setting adjusting this. Jdforrester (WMF) (talk) 17:09, 30 January 2021 (UTC)

Save dialog does not closing after page save

Save dialog does not closing after page save in Vector skin. If using MinervaNeue with VE - saving dialog works fine.

After clicking "Save" button in dialog - article saved successfully but this dialog does not closing. No js console errors or warnings. 18.235.19.247 (talk) 12:50, 8 February 2021 (UTC)

Also if switch editor from wikitext to VisualEditor - save dialog works as expect. This dialog broken only on edit(save NEW page - works fine). 18.235.19.247 (talk) 12:53, 8 February 2021 (UTC)

Not Working on 1.35

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


(also posted on https://phabricator.wikimedia.org/T265043)

I can view and edit pages, but i get error on clicking Save:

"Error contacting the Parsoid/RESTBase server (HTTP 403)"

Visual Editor is able to read and edit pages. Just cannot save. Here's my config:

// VISUAL EDITOR

wfLoadExtension( 'VisualEditor' );

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

$wgRevokePermissions['*']['writeapi'] = false;

$wgGroupPermissions['*']['read'] = true;

$wgGroupPermissions['*']['edit'] = true;


Here are some other parts of my LocalSettings.php which might be relevant. I shared relevant links. Protection is rather complicated, and i struggled with it at the time i set up this wiki (3 yrs ago):

# SUPPOSED TO REMOVE THE "PROTECT" TAB FOR THEIR NAMESPACES
# https://www.mediawiki.org/wiki/Manual:$wgNamespaceProtection
$wgNamespaceProtection[NS_PORTAL] = 
$wgNamespaceProtection['NS_FORM'] = 	
$wgNamespaceProtection[NS_PROJECT] =
$wgNamespaceProtection[NS_HELP] =
$wgNamespaceProtection[NS_CATEGORY] =array( 'editprotected' );
/* https://www.mediawiki.org/wiki/Manual:User_rights#List_of_permissions
The above statement means: Users and groups who have 'editprotected' permission shall have write-access to the Form namespace. editprotected makes sense here, cuz:
- Only admins have editprotected by default, and i want to target admins.
- "wgNamespaceProtection" is all about, well, editing something that's protected :)
- saves me the trouble of creating a new protection and applying to admins.
https://www.mediawiki.org/w/index.php?title=Project%3ASupport%20desk/Flow/2018/03#h-Apply_Protection_to_All_Category_Pages%3F-2018-03-27T15%3A44%3A00.000Z
https://www.mediawiki.org/w/index.php?title=Project%3ASupport%20desk/Flow/2018/03#c-Johnywhy-2018-03-28T13%3A47%3A00.000Z-Johnywhy-2018-03-27T15%3A44%3A00.000Z
*/


## FLOW & ECHO
wfLoadExtension( 'Flow' );
wfLoadExtension( 'Echo' );
$wgNamespaceContentModels[NS_TALK] = 'flow-board';		# MAIN TALK  https://www.mediawiki.org/wiki/Extension_default_namespaces#MediaWiki_Core
$wgNamespaceContentModels[NS_PROJECT_TALK] = 'flow-board';		
$wgNamespaceContentModels[NS_HELP_TALK] = 'flow-board';		
$wgNamespaceContentModels[NS_CATEGORY_TALK] = 'flow-board';		
$wgNamespaceContentModels[107] = 'flow-board';
$wgNamespaceContentModels[NS_DRAFT_TALK] = 'flow-board';		
$wgNamespaceContentModels[NS_PORTAL_TALK] = 'flow-board';	


## APPROVED REVS
wfLoadExtension( 'ApprovedRevs' );
$egApprovedRevsAutomaticApprovals = true;		# allow auto-approval of admin edits. 
$egApprovedRevsEnabledNamespaces[] = NS_DRAFT;	
$egApprovedRevsSelfOwnedNamespaces[] = NS_USER ;


## MODERATION 
wfLoadExtension( 'Moderation' );
$wgModerationTimeToOverrideRejection = 31556952;
$wgModerationNotificationEnable = true;
$wgGroupPermissions['sysop']['moderation'] = true; # Allow sysops to use Special:Moderation
$wgGroupPermissions['sysop']['skip-moderation'] = true; # Allow sysops to skip moderation
$wgGroupPermissions['automoderated']['skip-move-moderation'] = false;
$wgGroupPermissions['sysop']['skip-move-moderation'] = true;
$wgAutoConfirmCount = 10;	
$wgGroupPermissions['autoconfirmed']['skip-move-moderation'] = false;

$wgWhitelistReadRegexp = 
	['/Portal:/', '/ /', '/Draft:/', '/Template:/', '/Category:/',  '/Topic:/', 
	'/MediaWiki:Common.css/', '/MediaWiki:TopicTags.css/', '/Special:AllPages/', '/Special:RecentChanges/', '/Special:RequestAccount/'
	]; Johnywhy (talk) 23:46, 8 February 2021 (UTC)
Solved. This was apparently Softaculous fault.
VisualEditor works in a manual MW install, no problem, with this config:
wfLoadExtension( 'VisualEditor' );
$wgGroupPermissions['*']['writeapi'] = true;
$wgRevokePermissions['*']['writeapi'] = false;
$wgGroupPermissions['*']['read'] = true;
$wgGroupPermissions['*']['edit'] = true;
# By default, VisualEditor is only enabled for the namespaces "Main", "User", "File" and "Category"
$wgVisualEditorAvailableNamespaces = [
    "Portal" => true,
    "Draft" => true,
    NS_PORTAL_TALK => true,
    NS_DRAFT_TALK => true
    ]; Johnywhy (talk) 23:52, 11 February 2021 (UTC)
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Categories not being handled as expected

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I have an internal (non-private, all can view without login) wiki I'm currently testing and getting ready for migration from 1.31 and deployment. The new wiki runs 1.35.1 on RHEL8 with PHP 7.4.6 and MariaDB 10.3.27. Thus far, we've gotten VE working as we configured it, but have encountered an issue. When attempting to add a page to an existing category, the category does not consistently appear when entered using the Categories dialog via the menu selection (i.e., it is sometimes red). Saving the category assignment as part of the page associates it properly with the category (same when using the wikitext editor). When editing the page, the category previously assigned appears in the Category dialog as "index.php?title=Category: Testing" (Category: Testing was the assigned category).

Any idea what might be going on here?

Thanks! DHillBCA (talk) 21:35, 11 February 2021 (UTC)

I think I know what the issue might be, but I have no idea what's causing it or how to resolve it - the "I" in "index.php?title=Category: Testing" that I noted above is actually capitalized in what I'm seeing in the Categories dialog. There's also a space between the colon (:) and "Testing". I'm not seeing anything in localsettings.php that would explain this - we're not using short or pretty URLs.
Should I be filing a bug? DHillBCA (talk) 18:30, 24 February 2021 (UTC)
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

VisualEditor strange behavior (unregistered inputs, double line breaks, disappearing characters...)

Hi all,


On my wiki (using mediawiki 1.35.1), VisualEditor (0.1.2) behaves very strangely and I can't figure out what might be causing it.

Here's a gif showing this, with the on-screen keyboard on just for the purposes of seeing my inputs: vgy.me/u/DlMgW6


Partial list of some weird things I've seen:

- Can't enter text if there's nothing written yet (must use the toolbar to add a formatted string and then you're able to add to it).

- Can't input a line break if the cursor is at the end of the line (must add a random character, add the line break before it, then remove the character).

- Line breaks inconsistently add one or two lines.

- If adding several line breaks with no text, it's impossible to then navigate to one in the middle; arrows keys make the cursor jump to the next line with text.

- Sometimes inputs are simply not registered, or the characters get added to the end of the line regardless of where the cursor is.

- Adding line breaks sometimes makes random characters appear (presumably the same characters who did not appear when trying to input them earlier)

- etc.


Does anyone have any idea what might be causing this, and/or how to fix it? Thanks. Acccent (talk) 18:12, 16 February 2021 (UTC)

VisualEditor, article with a lot of Math tags at MediaWiki 1.35 > Timeout

Hello, few months ago, I've switched our private wiki to version 1.35. Yesterday I found, when I'm trying to edit a relatively large page, that contains a lot of math tags, I'm receiving the message:

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

On small pages everything is fine. In order to solve this problem, I've set $wgHTTPTimeout = 60; (the default value is 25 seconds). In this way I can edit a little bigger pages but the problem remains! Bigger values (like 720) doesn't change anything. The only change is in the error message, it changes to:

The server did not respond within the expected time.

I've tried to change almost all Timeout variables that I found at MediaWiki's documentation with no success, including $wgMathLaTeXMLTimeout, $wgMathMathMLTimeout and $wgMathConcurrentReqs.

Then I've copy an example content here within my user's page: User:Spas.Z.Spasov/math-test. You can see VE works as it is expected here.

So, I think the problem is that, because by default Extension:Math uses the MediaWiki's Mathoid server, but external users like us have low priority and the responses are slow. Setup own Mathoid server is too complicated task, due to lack of up-to-date documentation. But I think the problem is due to something hard codded in VisualEditor, because with the previous version, that uses Parsoid.js, despite of the long time for the response everything was fine.

Could you please guide me what I could tray to change in the VE's code in order to solve this issue? Spas.Z.Spasov (talk) 19:30, 16 February 2021 (UTC)

Probably this solution could solve the current issue.
Reference:

Error contacting the Parsoid/RESTBase server (HTTP 404)

So I noticed many people have been struggling with this issue for the past few months. My case is a little unusual... Visual Editor loads everywhere.. Edit: Actually only if the user subpage does not exist. However it is not able to save or preview any subpage under User:Admin. Editing pages in the main namespace works as usual. I've found that this page /api.php?action=visualeditor&format=json&paction=parse&page=User:Admin/Subpage returns fine if Subpage does not exist, but returns "Error contacting the Parsoid/RESTBase server (HTTP 404)" when the page exists (created using source editor). I also get the same error when trying to switch to source editor within any User:Admin subpage from Visual Editor.

A little about my setup: Mediawiki 1.35.1 (I used 1.35 before, upgraded today after I found these issues hoping it would solve the issues). Short URLs using apache's FallbackResource ($wgArticlePath = "/view/$1";). Vanilla config except for:

  • Hcaptcha (skip for User and Sysop, triggers for all pages)
  • Luasandbox config
  • Sysops may delete log entries
  • External link target _blank

I do **not** have "wfLoadExtension( 'Parsoid', ...)" in my config. I do **not** have "$wgVirtualRestConfig['modules']['parsoid']" in my config. Source61 (talk) 22:07, 18 February 2021 (UTC)

Hi Source61
Have you checked out Extension:VisualEditor#Allowing VisualEditor on page titles containing slashes? Sm8ps (talk) 15:08, 30 August 2021 (UTC)
Just to add another success story. I faced similar issue and I follow the advice from @Sm8ps. I'm using MacBook M1 Chip and MAMP (not Pro). I went to MAMP > conf > apache and open the httpd.conf file.
I add AllowEncodedSlashes NoDecode into the httpd.conf file. I restart the MAMP web server and go back to subpage and voila it works, I can edit the subpage now without error.
Thanks for the advice 01mina10cities (talk) 11:02, 25 September 2022 (UTC)

How to hide the “Save your changes” confirmation window when saving a page on Mediawiki

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! Paulxu20 (talk) 15:30, 21 February 2021 (UTC)
Same here, it would be a nice option Shadowritter (talk) 20:26, 5 August 2021 (UTC)
Did u find a way to this problem or is it still unsolved? 195.65.170.10 (talk) 07:41, 1 November 2021 (UTC)
Not yet. Paulxu20 (talk) 02:43, 17 November 2021 (UTC)
Looking for this as well. Michael Z Freeman (talk) 16:28, 4 June 2022 (UTC)
Would appreciate a solution for this as well! 2003:DF:9F2D:6E00:6059:29B5:482F:F412 (talk) 09:42, 31 July 2022 (UTC)
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. 81.59.58.232 (talk) 21:17, 23 April 2023 (UTC)
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. 2003:E6:4F41:2500:94C9:55B6:331D:67E7 (talk) 09:34, 16 August 2024 (UTC)
Read tab, not the Page tab 81.59.58.232 (talk) 22:07, 23 April 2023 (UTC)
Well both are fine actually ;-) 81.59.58.232 (talk) 22:18, 23 April 2023 (UTC)

Error contacting the Parsoid/RESTBase server: http-bad-status after moving Wiki from Windows 10 to Raspbian Lite

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I have had a private wiki running on my Windows 10 machine with Apache2 and MariaDB for quite a while and VisualEditor works fine, however today once I moved the wiki to my Raspberry Pi, also running Apache2 and MariaDB, VisualEditor will not load with the message box: Error contacting the Parsoid/RESTBase server: http-bad-status. I've read that private wikis can have issues with VisualEditor, however when I tried making the wiki public, the issue remained. I have nothing related to VisualEditor in my configuration file and the config file is identical to my other config file on Win10. The error comes up immediately when editing a page, or after pressing save if creating a new page. Does anyone have any ideas how I can fix this? If not I'll just use source editing instead.

Edit: This is my version table and installed extensions:

Product Version
MediaWiki 1.35.1
PHP 7.4.15 (apache2handler)
MariaDB 10.3.27-MariaDB-0+deb10u1
Lua 5.1.5
Entry point URL
Article path /index.php/$1
Script path /
index.php /index.php
api.php /api.php
rest.php /rest.php
Special pages
Extension Version Licence Description Authors
CiteThisPage GPL-2.0-or-later Adds a citation special page and toolbox link Ævar Arnfjörð Bjarmason and James D. Forrester
Interwiki 3.2 GPL-2.0-or-later Adds a special page to view and edit the interwiki table Stephanie Amanda Stevens, Alexandre Emsenhuber, Robin Pepermans, Siebrand Mazeland, Platonides, Raimond Spekking, Sam Reed, Jack Phoenix, Calimonius the Estrange and others
Nuke 1.3.0 GPL-2.0-or-later Gives administrators the ability to mass delete pages Brion Vibber and Jeroen De Dauw
Renameuser GPL-2.0-or-later Adds a special page to rename a user (need renameuser right) Ævar Arnfjörð Bjarmason and Aaron Schulz
Replace Text 1.4.1 GPL-2.0-or-later Provides a special page to allow administrators to do a global string find-and-replace on all the content pages of a wiki Yaron Koren, Niklas Laxström and others
Editors
Extension Version Licence Description Authors
CodeEditor GPL-2.0-or-later AND BSD-3-Clause Syntax-highlighted editing for JavaScript and CSS pages using Ace editor Brion Vibber, Derk-Jan Hartman and authors of Ace
VisualEditor 0.1.2 (4465cbe) 21:11, 5 February 2021 MIT Visual editor for MediaWiki Alex Monk, Bartosz Dziewoński, C. Scott Ananian, Christian Williams, David Lynch, Ed Sanders, Inez Korczyński, James D. Forrester, Moriel Schottlender, Roan Kattouw, Rob Moen, Subramanya Sastry, Thalia Chan, Timo Tijhof, Trevor Parscal and others
WikiEditor 0.5.3 GPL-2.0-or-later Provides an advanced, extensible wikitext editing interface Derk-Jan Hartman, Trevor Parscal, Roan Kattouw, Nimish Gautam and Adam Miller
Parser hooks
Extension Version Licence Description Authors
CategoryTree GPL-2.0-or-later Dynamically navigate the category structure Daniel Kinzler
Cite GPL-2.0-or-later Adds <ref> and <references> tags for citations Ævar Arnfjörð Bjarmason, Andrew Garrett, Brion Vibber, Ed Sanders, Marius Hoch, Steve Sanbeg, Trevor Parscal and others
ImageMap GPL-2.0-or-later Allows client-side clickable image maps using <imagemap> tag Tim Starling
InputBox 0.3.0 MIT Allow inclusion of predefined HTML forms Erik Moeller, Leonardo Pimenta, Rob Church, Trevor Parscal and DaSch
InteractiveTimeline 1.6.0 GPL-2.0+ Adds <itimeline>...<itimeline> tag to provide interactive timelines using the CHAP Timeline library Chris Page
ParserFunctions 1.6.0 GPL-2.0-or-later Enhance parser with logical functions Tim Starling, Robert Rohde, Ross McClure and Juraj Simlovic
Poem CC0-1.0 Adds <poem> tag for poem formatting Nikola Smolenski, Brion Vibber and Steve Sanbeg
Scribunto GPL-2.0-or-later AND MIT Framework for embedding scripting languages into MediaWiki pages Victor Vasiliev, Tim Starling and Brad Jorsch
SyntaxHighlight 2.0 GPL-2.0-or-later Provides syntax highlighting <syntaxhighlight> using Pygments - Python syntax highlighter Brion Vibber, Tim Starling, Rob Church, Niklas Laxström, Ori Livneh and Ed Sanders
TemplateData 0.1.2 GPL-2.0-or-later Implement data storage for template parameters (using JSON) Timo Tijhof, Moriel Schottlender, James D. Forrester, Trevor Parscal, Bartosz Dziewoński, Marielle Volz and others
Media handlers
Extension Version Licence Description Authors
PDF Handler GPL-2.0-or-later Handler for viewing PDF files in image mode Martin Seidel and Mike Połtyn
TimedMediaHandler 0.6.0 (bd0d5e6) 21:36, 24 August 2020 GPL-2.0-or-later Handler for audio, video and timed text, with format support for WebM, Ogg Theora, Vorbis, srt Michael Dale, Jan Gerber, Derk-Jan Hartman, Brion Vibber, Tim Starling and others
Spam prevention
Extension Version Licence Description Authors
ConfirmEdit 1.6.0 GPL-2.0-or-later Provides CAPTCHA techniques to protect against spam and password-guessing Brion Vibber, Florian Schmidt, Sam Reed and others
SpamBlacklist GPL-2.0-or-later Regex-based anti-spam tool allowing to blacklist URLs in pages and email addresses for registered users Tim Starling, John Du Hart and Daniel Kinzler
TitleBlacklist 1.5.0 GPL-2.0-or-later Allows administrators to forbid creation of pages and user accounts per a blacklist and whitelist Victor Vasiliev and Fran Rogers
API
Extension Version Licence Description Authors
PageImages WTFPL Collects information about images used on page Max Semenik
Other
Extension Version Licence Description Authors
Gadgets GPL-2.0-or-later Lets users select custom CSS and JavaScript gadgets in their preferences Daniel Kinzler and Max Semenik
LocalisationUpdate 1.4.0 GPL-2.0-or-later Keeps the localised messages as up to date as possible Tom Maaswinkel, Niklas Laxström and Roan Kattouw
MobileFrontend 2.3.0 (1421405) 22:43, 6 October 2020 GPL-2.0-or-later Mobile Frontend Patrick Reilly, Max Semenik, Jon Robson, Arthur Richards, Brion Vibber, Juliusz Gonera, Ryan Kaldari, Florian Schmidt, Rob Moen, Sam Smith and others
MultimediaViewer GPL-2.0-or-later Expand thumbnails in a larger size in a fullscreen interface MarkTraceur (Mark Holmquist), Gilles Dubuc, Gergő Tisza, Aaron Arcos, Zeljko Filipin, Pau Giner, theopolisme, MatmaRex, apsdehal, vldandrew, Ebrahim Byagowi, Dereckson, Brion VIBBER, Yuki Shira, Yaroslav Melnychuk, tonythomas01, Raimond Spekking, Kunal Mehta, Jeff Hall, Christian Aistleitner, Amir E. Aharoni and others
OATHAuth 0.4.4 GPL-2.0-or-later AND GPL-3.0-or-later Provides authentication support using HMAC based one-time passwords Ryan Lane, Robert Vogel <vogel@hallowelt.com> and Dejan Savuljesku <savuljesku@hallowelt.com>
SecureLinkFixer GPL-3.0-or-later Rewrites URLs to HTTPS if domain always requires HTTPS Kunal Mehta
TextExtracts GPL-2.0-or-later Provides plain-text or limited HTML extracts of page content Max Semenik
TollyH (talk) 12:40, 22 February 2021 (UTC)
I've found the issue. Because the Raspberry Pi is a 32-bit system, I needed to install the bcmath extension for php. TollyH (talk) 11:34, 24 February 2021 (UTC)
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Visual Editor save content as parent.location="/login.htm

I have installed Mediawiki 1.35.1 on php 7.4, nginx 1.19. Loaded visual editor but when loads the page content is missing and when its saves the content it is giving

<html><head><meta HTTP-EQUIV="Pragma" CONTENT="no-cache"><script language='javascript'>parent.location="/login.htm"</script></head><body></body></html>

on every page.


Installed software

Product Version
MediaWiki 1.35.1
PHP 7.4.15 (fpm-fcgi)
MariaDB 10.4.17-MariaDB-1:10.4.17+maria~bionic
ICU 65.1
Lua 5.1.5

Entry point URLs

Entry point URL
Article path /$1
Script path /
index.php /index.php
api.php /api.php
rest.php /rest.php

I tried a lot of options with nginx configuration and LocalSettings.php but no luck. The wiki is panchayatwiki.com Ranjithsiji (talk) 03:48, 23 February 2021 (UTC)

VisualEditor missing several insert options

I just installed MediaWiki 1.35 on an LXC container. Everything looks fine, except for the visual editor. I seem to be missing a few options under the 'insert' tab. When I drop down the tab it only displays the following options:


Images and Media

Template

Table

Comment

Gallery

Code Block

Your Signature

^ Fewer


I was looking to insert a formula, but it looks like that isn't in the drop down for some reason.

I assume there is a configuration that needs editing; however, I am extremely new to MediaWiki and really need some help. Anything is appreciated. Whissp (talk) 16:16, 11 March 2021 (UTC)

Hi, @Whissp, you need to install some extensions in order to get much of these options. For example you need Extension:Math in order to get option for typing and rendering formulas. Spas.Z.Spasov (talk) 16:55, 14 March 2021 (UTC)
What would you need to get the code block to come back? 68.96.82.33 (talk) 22:44, 3 July 2021 (UTC)
To bring syntax highlighting capability back to your visual editor, install this extension:
Special:ExtensionDistributor/SyntaxHighlight GeSHi
As a point of note, the fact that none of this is documented in the Visual Editor page is very frustrating. Thank you. Mlx2021 (talk) 23:13, 3 July 2021 (UTC)

Error contacting the Parsoid/RESTBase server (HTTP 500) - Linux server

Hi Everyone!

I have a MediaWiki 1.35 that comes with VisualEditor extension. I'd like to use the VisualEditor but when I try to create an article with accented character in the title, it drops the following error: Error contacting the Parsoid/RESTBase server (HTTP 500).

I use Linux server and hungarian language (it has a lot of accented characters). What could be the problem? Thanks! Jzbekeswiki (talk) 09:24, 13 March 2021 (UTC)

Get Welcome page instead of Article in VisualEditor

I'm upgrading to 1.35 (my VisualEditor used to work fine with Parsoid installed). I removed Parsoid service, and now, in 1.35, every article in Visual Editor shows the Welcome Page to edit, with all the menus... An idea what went wrong? https://pasteboard.co/JTFFefa.png Thanks! Plyd (talk) 17:40, 21 March 2021 (UTC)

In 1.35 Parsoid-PHP should be auto-configured, so you should remove existing $wgVirtualRestConfig, except very specific setup. There is still HTTP requests between MediaWiki and Parsoid-PHP, so it should be taken into account. There are a lot of possible errors listed in Extension:VisualEditor#Troubleshooting, e.g. Apache and nginx need a special new config for the endpoint rest.php and could return errors in any or some cases. ~ Seb35 [^_^] 15:52, 23 March 2021 (UTC)

VisualEditor loads page from another wiki hosted on the same machine

I have two wikis running on the same machine but different ports. Let us say wiki1(ip_address:8011) and wiki2(ip_address:8012).

I can load VisualEditor and it works fine on wiki1.

I can also load the VisualEditor on wiki2 but it loads the wrong page revision (seemingly from wiki1).

They both have their own database table.


The classic edit source works just fine on both sites.

I know I can just use the the edit source way, but I really need the VisualEditor to edit tables easily.

Anyone know how to solve this problem? 133.9.37.44 (talk) 09:12, 2 April 2021 (UTC)

Does these URLs work on your both wikis: http://ip_address:8011/rest.php/ip_address:8081/v3/page/html/Main_Page/12 when you replace:
  • Main_Page with some wiki page,
  • 12 with the revision ID of the wiki page (you can find it on the wiki page > toolbox (“Tools” section) > link “Permanent link”, it is the parameter oldid in the URL).
The VisualEditor is internally calling this endpoint, so check the returned pages work and correspond to the right page. Verify also in your LocalSettings.php the parameter $wgServer = 'http://ip_address:8081';
But I suspect there are issues with the custom ports, which is a bit unusual. If you cannot solve it, could you open a task on Phabricator to track the issue? (with the tag Parsoid (Third-party)) ~ Seb35 [^_^] 10:49, 5 April 2021 (UTC)
Thank you for your reply.
I cannot open the page. It says 404 not found.
What is the difference between the ip_address:8011 and ip_address:8081? If I understand it correctly, 8011 is for the wiki port. But I do not understand the 8081. Is it the Parsoid port? 133.9.37.44 (talk) 01:14, 15 April 2021 (UTC)

Visual Editor saves text with additional spaces at the start

The text of the first paragraph is formatted after save as being "preformatted" because of two spaces added to the start of the source text

so the text "my text" is saved as " my text"

The only way to solve this is using the source editor, which defies the benefit of VE 92.70.239.7 (talk) 13:12, 9 April 2021 (UTC)

Additional info:
Visual editor 0.1.2
Mediawiki 1.35 (WIndows IIS)
Browser: Chrome Version 87.0.4280.66 92.70.239.7 (talk) 13:38, 9 April 2021 (UTC)

Need instructions to remove the Visual Editor from MW 1.35

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


We are running Mediawiki 1.35. We don't want the Visual Editor that is bundled with MW 1.35. We want the old editor.

Please provide instructions to completely delete the Visual Editor and its dependencies. There's no need for the additional attack surface the dependencies provide. Noloader (talk) 02:12, 12 April 2021 (UTC)

You can just disable the VisualEditor extension by removing wfLoadExtension( 'VisualEditor' ); in your LocalSettings.php. If you want a deeper removal for security reasons, you can even delete the directory extensions/VisualEditor. ~ Seb35 [^_^] 14:56, 14 November 2021 (UTC)
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Can I increase Timeout seconds on VisualEditor with Mediawiki 1.35?

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. MPThLee (talk) 23:58, 14 April 2021 (UTC)

Check this out: Manual:$wgHTTPTimeout MarioSuperstar77 (talk) 20:32, 3 June 2021 (UTC)
This is also an issue for me, any advise would be appreciated 213.129.64.4 (talk) 08:10, 16 May 2022 (UTC)

Error contacting the Parsoid/RESTBase server (HTTP 400)

VisualEditor was working when I first installed but has stopped for seemingly unrelated reasons (nothing has changed, I've even tried reverting every other file/change). Getting the above error on every VE edit action. Any clues? 91.125.240.46 (talk) 21:49, 15 April 2021 (UTC)

Have a look at https://phabricator.wikimedia.org/T279039 - Reinstalling/Upgrading MW to match the VE version fixed this issue for me. GladOSkar (talk) 01:28, 4 May 2021 (UTC)

I recently upgraded my Wiki from 1.34 and decided I wanted to implement this Extension. However all of my controls to access the visual editor and the stuff inside is replaced with this alias. (I don't know how to describe it.) For example, the "Edit Source" button is replaced with "{visualeditor-ca-editsource}


I have troubleshooted for two hours trying to fix this. I think it has something to do with my existing database. Because I duplicated the database to a fresh install of 1.35 and I still have the issue.


I have run the update script.


What is wrong? TwentytwoXXII (talk) 14:44, 25 April 2021 (UTC)

Update: Truncating my Cache databases fixed the issue on not just VisualEditor but on other Extensions. TwentytwoXXII (talk) 21:40, 25 April 2021 (UTC)

VisualEditor not working on 1.35.2

I am running my wiki on a docker container on a server that runs three containers for three different websites. URL is https://wikimsk.org . I upgraded from 1.34 to 1.35.2 and was excited to try out VisualEditor. I enabled it in LocalSettings. When I click edit, the URL of the page changes, but nothing else happens, there is no parsing, and no edit windows shows up. The skin I use is compatible (Medik), but I also tried with Vector and had the same problem. When I try curl 'https://wikimsk.org/rest.php/v1/page/Main_Page' I get file not found. I looked at config/apache2/apache2.conf but can't find any <Virtual Host> line. Anyone have any ideas? InnerCitadel (talk) 00:43, 26 April 2021 (UTC)

I have a similar problem after upgrading. I enabled wfLoadExtension( 'VisualEditor' ); in LocalSettings.php and when I click edit, the URL is appended with &veaction=edit but there is no editor. I previously had parsoid running as a service (as was required in old versions of MW), but the behaviour does not change if this service is started or stopped. There are no obvious errors in /var/log/* either. 81.174.250.136 (talk) 11:20, 27 April 2021 (UTC)
Worked out what the problem was. I have Extension:AccessControl and when I set $wgAccessControlRedirect = false, then it worked. that setting redirects a user to a Deny user page rather than giving a generic error for the couple of pages that require a login. However even for the unlocked pages for some reason it was denying access. Obviously a super specific incompatibility. InnerCitadel (talk) 20:27, 27 April 2021 (UTC)

private wiki configuration & security

Hello,

Working on a private wiki, i am currently updating mediawiki 1.33 -> 1.35.2.

My LocalSettings parameters are:

   $wgGroupPermissions['*']['read'] = false;
   $wgGroupPermissions['*']['edit'] = false; 

1/ For security reason, i wanted to try this instead of forwarding cookies:

if ( $_SERVER['REMOTE_ADDR'] == '127.0.0.1' && $_SERVER['HTTP_USER_AGENT'] == "VisualEditor-MediaWiki/" . MW_VERSION ) {
   $wgGroupPermissions['*']['read'] = true;
   $wgGroupPermissions['*']['edit'] = true; 
}

... it worked!

=> do you think it is a secure option ?

2/ working around, i also tried to use VisualEditor without any specific adaptation for private wikis: it worked too! ... does it mean the problem has been solved ? Looxloox (talk) 08:30, 4 May 2021 (UTC)

Skin Timeless compability?

Hello at my private wiki I'm using skin Timeless and VisualEditor works nice with that skin. My question is - why the skin Timeless is not listed under the section Extension:VisualEditor#Skin compatibility? Spas.Z.Spasov (talk) 08:29, 9 May 2021 (UTC)

I was wondering the same thing. DHillBCA (talk) 21:54, 10 May 2021 (UTC)

How to enable Insert "Code Block" CodeEditor?

I am using MediaWiki 1.35, which comes with VisualEditor and CodeEditor extensions. Both are enabled in my LocalSettings.php:


wfLoadExtension( 'VisualEditor' );

wfLoadExtension( 'CodeEditor' );


However, in the "Insert" menu of my Visual Editor, I do not see the "Code block" option that I have experimented with on the Mediawiki sandbox page. How do I enable this? It would be very useful for our tech team support. 76.93.216.184 (talk) 22:24, 21 May 2021 (UTC)

Code block uses the syntaxhighlight-tag, maybe you need the extension Extension:SyntaxHighlight first? Escalatr (talk) 12:32, 30 July 2021 (UTC)

Visual Editor replacing urls in links/images

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. Desbrina1 (talk) 17:13, 27 May 2021 (UTC)

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. DHillBCA (talk) 17:57, 3 June 2021 (UTC)
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. MarioSuperstar77 (talk) 20:25, 3 June 2021 (UTC)
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. DHillBCA (talk) 15:11, 8 June 2021 (UTC)

Edit source never straight to edit

When using the edit source option it always goes to "The editor will now load. If you still see this message after a few seconds, please reload the page" instead of going straight to the edit source page. Desbrina1 (talk) 18:04, 27 May 2021 (UTC)

May be you've set custom URL for edit in Manual:$wgActionPaths. It seems not working well with the mobile theme. Try remove the edit from your actions array. Sparanoid (talk) 20:56, 24 October 2021 (UTC)

Invalid Response from Server Error

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? Dapachy (talk) 12:53, 28 May 2021 (UTC)

I also have this error when try download images. When the page reloaded the image are there. Klymets (talk) 20:11, 4 August 2021 (UTC)
Got the same error. In my case switching the PHP version from 8.3 to 8.1. removed the error. Stefahn (talk) 17:53, 4 June 2024 (UTC)

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

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. Starbeam2 (talk) 18:07, 31 May 2021 (UTC)

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. Universal Omega (talk) 03:43, 1 June 2021 (UTC)
Thank you for the answer. Do you know how to do that on a miraheze? Starbeam2 (talk) 04:08, 1 June 2021 (UTC)

Error contacting the Parsoid/RESTBase server (HTTP 500)

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' ); Raikkonso (talk) 17:36, 6 June 2021 (UTC)

Visual Editor takes no effect when activate

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. Dorivaldo de C. M. dos Santos (talk) 09:48, 7 June 2021 (UTC)

Error contacting the Parsoid/RESTBase server: (curl error: 56)

When clicking on the "Edit" button of an article I got

"Error contacting the Parsoid/RESTBase server: (curl error: 56) Failure when receiving data from the peer". (And no error log even when all logging is switched on.) "

I am running

Media Wiki: 1.35.2

VisualEditor: 0.1.2


in a docker container. Connection are redirected to that container by another container which is also doing the TLS-termination.


The error seems not be be like the other errors which http-response error code. I have (hopefully) already tried all suggestions from similar problems here.

I have just enabled the plugin via the corresponding like int he LocalSettings.php. 2A02:908:1080:24A0:C78F:83FF:91F4:DF76 (talk) 11:22, 22 June 2021 (UTC)

is this resolved? I am getting same issue. 132.234.47.35 (talk) 00:38, 9 November 2021 (UTC)
Now, this is not resolved. I have just updated to MediaWiki 1.37.0 (which includes VisualEditor 0.1.2) and the error is still the same.
also
  • Project:Support desk/Flow/2021/07#h-Visual_Editor:_Jump_to_navigation_Jump_to_search_Error_contacting_the_Parsoid/RE-2021-07-14T04:57:00.000Z
  • stackoverflow 68222305 2A02:908:108A:4080:AE30:8687:9EF4:D842 (talk) 08:32, 29 November 2021 (UTC)

Inconsitent error "Error contacting the Parsoid/RESTBase server (HTTP 400)"

ProductVersion
MediaWiki1.36.1
PHP7.4.20 (fpm-fcgi)
MariaDB10.5.11-MariaDB
ICU67.1
Lua5.1.5
Elasticsearch6.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 Bluedreamer1 (talk) 13:51, 5 July 2021 (UTC)

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=Extension%20talk%3AVisualEditor/2020#c-D3nnis3n-2020-09-26T17%3A37%3A00.000Z-Nginx_configuration Lostraven (talk) 17:48, 29 July 2021 (UTC)
One consistent way I found so far, is editing my user page - I always get the error Bluedreamer1 (talk) 00:59, 30 July 2021 (UTC)
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
|} TiltedCerebellum (talk) 03:14, 27 June 2022 (UTC)
Adding to hosts file ie; /etc/hosts on Linux, fixed it until the solution is known
127.0.0.1 yourwikidomain.com Compumatter (talk) 17:57, 23 August 2022 (UTC)
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. NotYour007 (talk) 15:43, 29 August 2022 (UTC)
Alas, this did not fix for me on MW 1.38 73.67.242.81 (talk) 04:14, 20 October 2022 (UTC)
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. SbairdMW (talk) 23:07, 20 October 2022 (UTC)
My wiki fixed after add text to Nginx config files srrver block.
location /rest.php/ {
try_files $uri $uri/ /zw/rest.php?$query_string;
} 2409:8900:789:37C:D96C:F76D:7DBC:C108 (talk) 08:00, 2 November 2022 (UTC)

When Visual Editor enabled: Error while opening any page containing sections (due to missing labels?)

See Project:Support desk/Flow/2021/07#h-When_Visual_Editor_enabled:_Error_while_opening_any_page_containing_sections_(du-2021-07-12T08:24:00.000ZTotina (talk) 08:43, 12 July 2021 (UTC)

Is it possible to adjust the length at which comments are cut off?

I used to transclude (?) a pre-formatted page with HTML-comments containing some detailed information about the intended structure of a new page. After switching to VisualEditor, these comments do show up -- which is good -- but they are cut off to 24 characters followed by an ellipsis (a … character). Is there a way to adjust the length from 24 to some greater value? I have searched all through the code without finding any clue whatsoever. Sm8ps (talk) 09:51, 16 July 2021 (UTC)

Advice for Running MW Instance With VE Behind Proxy

Don't rely on $wgVisualEditorParsoidAutoConfig for special situations

Hello. In short, I have a MW instance with VE. I am using the bundled installation of VE and Parsoid in 1.36.1. I need to change the endpoint VE uses to try and communicate with Parsoid when it makes recursive RESTful calls to the MW API for proxying reasons. The default "use $wgServer" will not work. I apologize for the length of this post, but I wanted to be detailed in hopes it would help with discussion and be insightful for anyone else searching about a similar issue. I appreciate any insight others may have as running MW behind a reverse-proxy doesn't seem like an obscure use case. Environment I am running MediaWiki 1.36.1 with the bundled VisualEditor and PHP Parsoid implementation. There is only one installation of media wiki on this machine and this is the only vhost configured on the Apache server. The installation lives behind several reverse proxies, one of which enforces HTTP basic authentication. This is where the problem began. We were initially seeing 403 errors and realized that because VE uses $wgServer as part of it's default configuration which is set to an FQDN. VE was resolving the public IP address the instance is exposed under and making extra trips through our FW and proxy infrastructure. Similar to the cookie issue private wikis experience, the Authorization header was not being forwarded which led to the 403s. This lengthy trip is undesirable because of the basic auth issue, and the extra load it will bring to our firewall, proxies, and NAT infrastructure even if we remove the basic auth requirement. Current "Solution"As far as I can tell, this does technically work in full so others may be satisfied to stop here if there is not a better way to fix this in the current MW version. My goal was/is to find a way to configure MW/VE in such a way that the internal HTTP calls to PHP/Parsoid can happen over the loopback interface. After much trial and error, the only way I could achieve this was to change $wgServer to be protocol relative and add an /etc/hosts override for my domain. The protocol relative step was important for me because TLS is terminated by an upstream proxy so the local system doesn't listen on 443 and must make plaintext requests. The protocol relative variant also helped avoid mixed-content warnings on some asset urls when loading the VisualEditor. This also technically still goes through our squid proxy cache. I believe I could just switch Apache to use 80 and squid to use something else since we already proxy in front of squid, but I would prefer to find a self-contained MW config solution to this problem anyway as this is a bit obtuse. I've tried adjusting $wgVisualEditorRestbaseURL and $wgVisualEditorFullRestbaseUrl, but both result in various errors. The only difference I see in the requests between the default working configuration and my modified version is that with auto-configuration, all the requests use the /v3/ API path, where my manual config uses /v1/. I cannot seem to control all the URLs through the existing config. Are these values meant to be hard-coded? Is the API actually different between the bundled RESTBase version and an external instance? Using mod_rewrite to change the /v1/s to /v3/s I was able to get everything but saving to work. With this config saving resulted in an HTTP 415 error from Parsoid. Parsonswy (talk) 00:27, 31 July 2021 (UTC)

I'll look into this in more depth later, but in theory what you should be tweaking is:
$wgVirtualRestConfig['modules']['parsoid'] = [
   'url' => 'http://localhost:8765',
   'domain' => 'external domain of your site',
];
The 'v1' vs 'v3' thing is the `restbaseCompat` parameter in that array, but you shouldn't need to change its default (or use mod_rewrite). cscott (talk) 15:38, 1 November 2021 (UTC)
Can you paste what's currently in your LocalSettings.php? Arlolra (talk) 20:07, 1 November 2021 (UTC)
Hello.
Cscott, modifying `$wgVirtualRestConfig` causes 404s.
$wgVirtualRestConfig['modules']['parsoid'] = [
'url' => 'localhost:81', // This does include http, the spam filter just won't let me include it.
'domain' => 'example.wiki.org'
];
127.0.0.1 - - [08/Nov/2021:18:23:58 +0000] "POST /example.wiki.org/v3/transform/html/to/wikitext/Fake_fake_page HTTP/1.1" 404 458 "-" "VisualEditor-MediaWiki/1.36.1".
Should I have something running on port `8765` or is that just legacy from the JS parsoid service? I set this to my Apache2 port.
Arlora, my configuration is posted on pastbin/1BCGkvmh. This includes the change recommended by Cscott. I can include it on this thread if you really want, but it is rather long and hard to read without good formatting.
Thank you for your thoughts. Parsonswy (talk) 18:47, 8 November 2021 (UTC)
8765 was just an example. What's listening on 81? The 'url' should be pointing at where your MediaWiki instance is, with Parsoid enabled. Arlolra (talk) 20:58, 8 November 2021 (UTC)
This is where the Apache server that is serving the Media Wiki instance listens. Parsonswy (talk) 21:34, 8 November 2021 (UTC)
And if you change it to:
'url' => 'http://localhost:81' . $wgScriptPath . '/rest.php' Arlolra (talk) 23:21, 8 November 2021 (UTC)
It looks like it is able to talk to Parsoid now, but Parsoid is returning an HTTP 400. This is what I see in the debug log.
Start request POST /api.php
IP: 10.12.11.16
HTTP HEADERS:
X-FORWARDED-FOR: ***, 127.0.0.1
X-FORWARDED-PROTO: https
COOKIE: VEE=visualeditor; dismissSiteNotice=0.1; ***_fl_UserID=100843; ***_fl_Token=55d078a7bc6e386dacfb2d17db3c5f98; ***_fl__session=vd396tuq74gee5p66r5popq06hmgahiv; ***_fl_UserName=Wparsons
CACHE-CONTROL: no-cache
PRAGMA: no-cache
SEC-FETCH-SITE: same-origin
SEC-FETCH-MODE: cors
SEC-FETCH-DEST: empty
REFERER: https://***.org/index.php?title=NewPage&action=edit&redlink=1
ORIGIN: https://***.org
CONTENT-TYPE: multipart/form-data; boundary=---------------------------34620589121387842396864004459
X-REQUESTED-WITH: XMLHttpRequest
ACCEPT-ENCODING: gzip, deflate, br
ACCEPT-LANGUAGE: en-US,en;q=0.5
ACCEPT: application/json, text/javascript, */*; q=0.01
USER-AGENT: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0
CONTENT-LENGTH: 2287
HOST: ***.org
AUTHORIZATION: Basic ***
(end headers)
[session] SessionManager using store MemcachedPhpBagOStuff
[localisation] LocalisationCache using store LCStoreDB
[memcached] MemCache: got WANCache:global:user:id:***-fl_:100843|#|v
[memcached] worthRefreshPopular(1636429268.1616, 60, 900, 1636429384.0179): p = 0.0012121212121212; refresh = N
[memcached] get(***-fl_:MWSession:vd396tuq74gee5p66r5popq06hmgahiv)
[memcached] MemCache: sock i:0; got ***-fl_:MWSession:vd396tuq74gee5p66r5popq06hmgahiv
[DBQuery] Wikimedia\Rdbms\DatabaseMysqlBase::open [0.001s] 127.0.0.1: SET group_concat_max_len = 262144, sql_mode = ''
[DBReplication] Wikimedia\Rdbms\LBFactory::getChronologyProtector: request info {
    "IPAddress": "10.12.11.16",
    "UserAgent": "Mozilla\/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko\/20100101 Firefox\/94.0",
    "ChronologyProtection": false,
    "ChronologyPositionIndex": 0,
    "ChronologyClientId": false
}
[DBReplication] Wikimedia\Rdbms\ChronologyProtector::lazyStartup: client ID is 7c87d3be59c36ef785fff0cce8fa98d1; key is global:Wikimedia\Rdbms\ChronologyProtector:7c87d3be59c36ef785fff0cce8fa98d1:v2
[memcached] get(global:Wikimedia\Rdbms\ChronologyProtector:7c87d3be59c36ef785fff0cce8fa98d1:v2)
[DBReplication] Wikimedia\Rdbms\ChronologyProtector::applySessionReplicationPosition: DEFAULT (127.0.0.1) has no position
[DBConnection] Wikimedia\Rdbms\LoadBalancer::lazyLoadReplicationPositions: executed chronology callback.
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: opened new connection for 0
[DBQuery] Wikimedia\Rdbms\DatabaseMysqlBase::serverIsReadOnly [0s] 127.0.0.1: SELECT @@GLOBAL.read_only AS Value
[DBQuery] Wikimedia\Rdbms\Database::beginIfImplied (MediaWiki\User\UserGroupManager::getUserGroupMemberships) [0s] 127.0.0.1: BEGIN
[DBQuery] MediaWiki\User\UserGroupManager::getUserGroupMemberships [0.001s] 127.0.0.1: SELECT  ug_user,ug_group,ug_expiry  FROM `fl_user_groups`    WHERE ug_user = 100843
[DBQuery] Wikimedia\Rdbms\DatabaseMysqlBase::open [0s] 127.0.0.1: SET group_concat_max_len = 262144, sql_mode = ''
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: opened new connection for 0
[DBQuery] SqlBagOStuff::fetchBlobMulti [0.001s] 127.0.0.1: SELECT  keyname,value,exptime  FROM `fl_objectcache`    WHERE keyname = '***-fl_:abusefilter:block-autopromote:100843'
[objectcache] SqlBagOStuff debug: get: no matching rows
[memcached] add WANCache:global:rdbms-server-readonly:127.0.0.1:***:|#|m (STORED)
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] Wikimedia\Rdbms\DatabaseMysqlBase::serverIsReadOnly [0s] 127.0.0.1: SELECT @@GLOBAL.read_only AS Value
[memcached] client: serializing data as it is not scalar
[memcached] add WANCache:global:rdbms-server-readonly:127.0.0.1:***:|#|v (STORED)
[memcached] MemCache: touch WANCache:global:rdbms-server-readonly:127.0.0.1:***:|#|m (TOUCHED)
[memcached] fetchOrRegenerate(global:rdbms-server-readonly:127.0.0.1:***:): miss, new value computed
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] LinkCache::fetchPageRow [0s] 127.0.0.1: SELECT  page_id,page_len,page_is_redirect,page_latest,page_restrictions,page_content_model  FROM `fl_page`    WHERE page_namespace = 0 AND page_title = 'NewPage'  LIMIT 1
[ContentHandler] Registered handler for wikitext: WikitextContentHandler
Unstubbing $wgLang on call of $wgLang::unstub from ContentHandler->getPageLanguage
[UserOptionsManager] Loading options from database
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] MediaWiki\User\UserOptionsManager::loadUserOptions [0s] 127.0.0.1: SELECT  up_property,up_value  FROM `fl_user_properties`    WHERE up_user = 100843
[http] HTTP start: POST http://localhost:81/wiki/rest.php/***.org/v3/transform/html/to/wikitext/NewPage
[DBReplication] ChronologyProtector using store MemcachedPhpBagOStuff
[memcached] MainWANObjectCache using store MemcachedPhpBagOStuff
Start request POST /wiki/rest.php/***.org/v3/transform/html/to/wikitext/NewPage
IP: 127.0.0.1
HTTP HEADERS:
CONTENT-TYPE: multipart/form-data; boundary=------------------------c5c4fafa494ab520
CONTENT-LENGTH: 503
PROMISE-NON-WRITE-API-ACTION: true
API-USER-AGENT: VisualEditor-MediaWiki/1.36.1
USER-AGENT: VisualEditor-MediaWiki/1.36.1
ACCEPT-LANGUAGE: en
ACCEPT: text/html; charset=utf-8; profile="https://www.mediawiki.org/wiki/Specs/HTML/2.0.0"
HOST: ***.org
(end headers)
[session] SessionManager using store MemcachedPhpBagOStuff
[localisation] LocalisationCache using store LCStoreDB
[memcached] get(***-fl_:MWSession:56fnpbbhjkiurp0fcqr6qm5v6vks3e0u)
[session] SessionBackend "56fnpbbhjkiurp0fcqr6qm5v6vks3e0u" is unsaved, marking dirty in constructor
[session] SessionBackend "56fnpbbhjkiurp0fcqr6qm5v6vks3e0u" save: dataDirty=1 metaDirty=1 forcePersist=0
[cookie] already deleted setcookie: "***_fl__session", "", "1604893384", "/", "", "", "1", ""
[cookie] already deleted setcookie: "***_fl_UserID", "", "1604893384", "/", "", "", "1", ""
[cookie] already deleted setcookie: "***_fl_Token", "", "1604893384", "/", "", "", "1", ""
[cookie] already deleted setcookie: "forceHTTPS", "", "1604893384", "/", "", "", "1", ""
[MessageCache] MessageCache using store MemcachedPhpBagOStuff
[DBQuery] Wikimedia\Rdbms\DatabaseMysqlBase::open [0.001s] 127.0.0.1: SET group_concat_max_len = 262144, sql_mode = ''
[DBReplication] Wikimedia\Rdbms\LBFactory::getChronologyProtector: request info {
    "IPAddress": "127.0.0.1",
    "UserAgent": "VisualEditor-MediaWiki\/1.36.1",
    "ChronologyProtection": false,
    "ChronologyPositionIndex": 0,
    "ChronologyClientId": false
}
[DBReplication] Wikimedia\Rdbms\ChronologyProtector::lazyStartup: client ID is e9fc49c3c8983bd18eaf490eecf80565; key is global:Wikimedia\Rdbms\ChronologyProtector:e9fc49c3c8983bd18eaf490eecf80565:v2
[memcached] get(global:Wikimedia\Rdbms\ChronologyProtector:e9fc49c3c8983bd18eaf490eecf80565:v2)
[DBReplication] Wikimedia\Rdbms\ChronologyProtector::applySessionReplicationPosition: DEFAULT (127.0.0.1) has no position
[DBConnection] Wikimedia\Rdbms\LoadBalancer::lazyLoadReplicationPositions: executed chronology callback.
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: opened new connection for 0
[DBQuery] Wikimedia\Rdbms\Database::beginIfImplied (LCStoreDB::get) [0s] 127.0.0.1: BEGIN
[DBQuery] LCStoreDB::get [0.001s] 127.0.0.1: SELECT  lc_value  FROM `fl_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'deps'  LIMIT 1
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] LCStoreDB::get [0.003s] 127.0.0.1: SELECT  lc_value  FROM `fl_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'list'  LIMIT 1
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] LCStoreDB::get [0s] 127.0.0.1: SELECT  lc_value  FROM `fl_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'preload'  LIMIT 1
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] LCStoreDB::get [0s] 127.0.0.1: SELECT  lc_value  FROM `fl_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'preload'  LIMIT 1
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] LCStoreDB::get [0s] 127.0.0.1: SELECT  lc_value  FROM `fl_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'messages:nonwrite-api-promise-error'  LIMIT 1
[session] Saving all sessions on shutdown
[DBConnection] Wikimedia\Rdbms\LBFactory::destroy: closing connection to database '127.0.0.1'.
[DBQuery] Wikimedia\Rdbms\Database::close [0s] 127.0.0.1: ROLLBACK
[DBQuery] Wikimedia\Rdbms\Database::ping [0s] 127.0.0.1: SELECT 1 AS ping
[http] HTTP complete: POST http://localhost:81/wiki/rest.php/***.org/v3/transform/html/to/wikitext/NewPage code=400 size=194 total=0.036314 connect=0.000474
[VisualEditor] ApiParsoidTrait::requestRestbase: Received HTTP 400 from RESTBase
[MessageCache] MessageCache using store MemcachedPhpBagOStuff
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] LCStoreDB::get [0.001s] 127.0.0.1: SELECT  lc_value  FROM `fl_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'deps'  LIMIT 1
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] LCStoreDB::get [0.003s] 127.0.0.1: SELECT  lc_value  FROM `fl_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'list'  LIMIT 1
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] LCStoreDB::get [0.001s] 127.0.0.1: SELECT  lc_value  FROM `fl_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'preload'  LIMIT 1
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] LCStoreDB::get [0.001s] 127.0.0.1: SELECT  lc_value  FROM `fl_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'preload'  LIMIT 1
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] LCStoreDB::get [0.001s] 127.0.0.1: SELECT  lc_value  FROM `fl_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'messages:apierror-visualeditor-docserver-http'  LIMIT 1
[memcached] MemCache: got WANCache:***-fl_:messages:en:hash:v1|#|v
[memcached] MemCache: got WANCache:***-fl_:messages:en|#|t
[memcached] get(***-fl_:messages:en)
[memcached] MemCache: sock i:0; got ***-fl_:messages:en
[MessageCache] MessageCache::load: Loading en... local cache is empty, got from global cache
ParserFactory: using default preprocessor
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] LCStoreDB::get [0.001s] 127.0.0.1: SELECT  lc_value  FROM `fl_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'magicWords'  LIMIT 1
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] LCStoreDB::get [0.001s] 127.0.0.1: SELECT  lc_value  FROM `fl_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'namespaceGenderAliases'  LIMIT 1
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] LCStoreDB::get [0.001s] 127.0.0.1: SELECT  lc_value  FROM `fl_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'linkPrefixExtension'  LIMIT 1
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] LCStoreDB::get [0.001s] 127.0.0.1: SELECT  lc_value  FROM `fl_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'messages:api-usage-docref'  LIMIT 1
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] LCStoreDB::get [0.001s] 127.0.0.1: SELECT  lc_value  FROM `fl_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'messages:api-usage-mailinglist-ref'  LIMIT 1
ApiMain::setCacheMode: setting cache mode private
[DBQuery] MediaWiki::preOutputCommit [0s] 127.0.0.1: COMMIT
MediaWiki::preOutputCommit: primary transaction round committed
MediaWiki::preOutputCommit: pre-send deferred updates completed
MediaWiki::preOutputCommit: session changes committed
[DBReplication] Wikimedia\Rdbms\ChronologyProtector::shutdown: no master positions/timestamps to save
[DBReplication] Wikimedia\Rdbms\LBFactory::shutdown: finished ChronologyProtector shutdown
[DBReplication] LBFactory shutdown completed
User::getBlockedStatus: checking blocked status for Wparsons
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for 0
[DBQuery] Wikimedia\Rdbms\Database::beginIfImplied (MediaWiki\Block\DatabaseBlock::newLoad) [0s] 127.0.0.1: BEGIN
[DBQuery] MediaWiki\Block\DatabaseBlock::newLoad [0.001s] 127.0.0.1: SELECT  ipb_id,ipb_address,ipb_timestamp,ipb_auto,ipb_anon_only,ipb_create_account,ipb_enable_autoblock,ipb_expiry,ipb_deleted,ipb_block_email,ipb_allow_usertalk,ipb_parent_block_id,ipb_sitewide,comment_ipb_reason.comment_text AS `ipb_reason_text`,comment_ipb_reason.comment_data AS `ipb_reason_data`,comment_ipb_reason.comment_id AS `ipb_reason_cid`,actor_ipb_by.actor_user AS `ipb_by`,actor_ipb_by.actor_name AS `ipb_by_text`,ipb_by_actor  FROM `fl_ipblocks` JOIN `fl_comment` `comment_ipb_reason` ON ((comment_ipb_reason.comment_id = ipb_reason_id)) JOIN `fl_actor` `actor_ipb_by` ON ((actor_ipb_by.actor_id = ipb_by_actor))   WHERE ipb_address IN ('Wparsons','10.12.11.16')  OR ((ipb_range_start  LIKE '0A0C%' ESCAPE '`' ) AND (ipb_range_start <= '0A0C0B10') AND (ipb_range_end >= '0A0C0B10'))
[DBQuery] MediaWiki::restInPeace [0s] 127.0.0.1: COMMIT
[DBReplication] LBFactory shutdown completed
Request ended normally
[session] Saving all sessions on shutdown
[DBConnection] Wikimedia\Rdbms\LBFactory::destroy: closing connection to database '127.0.0.1'.
[DBConnection] Wikimedia\Rdbms\LBFactory::destroy: closing connection to database '127.0.0.1'. Parsonswy (talk) 04:09, 9 November 2021 (UTC)
Hmm, can request the url directly from inside your network,
http://localhost:81/wiki/rest.php/***.org/v3/page/html/NewPage
and/or post to it (you should be able to just use a json blog, some examples are here https://github.com/wikimedia/parsoid/blob/master/tests/api-testing/Parsoid.js )
http://localhost:81/wiki/rest.php/***.org/v3/transform/html/to/wikitext/NewPage
If "NewPage" doesn't exist, try one that does Arlolra (talk) 16:16, 9 November 2021 (UTC)
Sorry for the delay.
No, I see 404s on both URLs, GET adn POST, with existing and non-existent pages.
{
"messageTranslations": {
"en": "The requested relative path (/test.mydomain.org/v3/page/html/[pagename]) did not match any known handler"
},
"httpCode": 404,
"httpReason": "Not Found"
} Parsonswy (talk) 00:00, 19 November 2021 (UTC)
Hmm, yeah, it looks like Parsoid's routes aren't loading because you're no longer using the autoconfig.
See !isset( $wgVirtualRestConfig['modules']['parsoid'] ) in https://github.com/wikimedia/mediawiki-extensions-VisualEditor/commit/09aed3b206dad3f5361fafe6d26650d840acacb6#diff-14616b5737d4e7761eaa057553c1809fa0e26122a50b4f6fb31124a7a058cc3f
Just try commenting that line out to see if it works Arlolra (talk) 00:31, 19 November 2021 (UTC)
I am able to GET/POST to those urls directly now, but am still seeing 400 errors when trying to use VE.
Possibly of note, I see in the debug log that the recursive/internal requests to RESTBase are to /wiki/rest.php/.... My $wgScriptPath is /w. I am using
RewriteRule ^wiki(/.*)?$ %{DOCUMENT_ROOT}/w/index.php [L]
RewriteRule ^/*$ %{DOCUMENT_ROOT}/w/index.php [L]
For short/pretty urls that would redirect that request to the main entry point.
Are these requests meant to use the script entry point? $wgVirtualRestConfig['modules']['parsoid']['url'] is still set to http://localhost:81${wgScriptPath}/rest.php. Parsonswy (talk) 01:44, 19 November 2021 (UTC)
Yes, they are meant to use the script entry point, so that should resolve to http://localhost:81/w/rest.php Arlolra (talk) 02:12, 19 November 2021 (UTC)
Oh, I had the Parsoid config above the wgScriptPath definition so the path was wrong. Everything is working now!
Is there a better way to handle overriding the parsoid URL or registering the VE routes so that I don't have to remember to modify src every time the extension updates? Parsonswy (talk) 02:22, 19 November 2021 (UTC)
wfLoadExtension( 'Parsoid' )
you might have to give a path to the parsoid extension.json because parsoid is included as a library not an extension, so
wfLoadExtension( 'Parsoid', /path/to/parsoid );
the path might be vendor/wikimedia/parsoid/extension.json Arlolra (talk) 02:56, 19 November 2021 (UTC)
That seems to have done the trick!
Thank you so much for your time and insight. :) Parsonswy (talk) 03:55, 19 November 2021 (UTC)
This took me all day to figure out. With short urls, things get wonky.
Apache 2.4
Mediawiki 1.38.2
You'll want your short urls to be:
          RewriteCond %{HTTP_USER_AGENT} !^(VisualEditor)
         RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
         RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
         RewriteRule ^(.*)$ %{DOCUMENT_ROOT}/w/index.php [L] TazzyTazzy (talk) 01:01, 13 September 2022 (UTC)

How to prevent VisualEditor to automatically add

    Is there a setting or way to prevent VisualEditor from automatically adding references tag? 72.80.198.91 (talk) 14:04, 11 August 2021 (UTC)

    Error contacting the Parsoid/RESTBase server (HTTP 415)

    Getting this error when trying to use VisualEditor on any page, no matter what I do. I think it is me not setting up parsoid correctly via Extension:VisualEditor#Installing Parsoid This is currently everything I have in my Localsettings.php related to Visualeditor/Parsoid. Idk If I need to do this Parsoid#Linking a developer checkout of Parsoid or not. # Visual editor enabled $wgGroupPermissions['*']['writeapi'] = true; wfLoadExtension( 'VisualEditor' ); Using latest stable verson of both VE and Wiki Corruptedxcomics (talk) 06:13, 19 August 2021 (UTC)

    Same problem here ...
    Had VisualEditor running for a couple of years without a problem, but since update to MW V1.36.1 I have this 'Error contacting the Parsoid/RESTBase server (HTTP 415)'.
    Too bad there is no information found anywhere, on how to resolve.
    I tried tens or maybe even hundreds of options, all causing different error-messages ... TieMichael (talk) 07:54, 22 August 2021 (UTC)
    People did have this issue about a year ago but the only solution someone had was to reinstall mediawiki which I have already done. I'm using hostinger as my service to run my wiki. What are you using?
    Also was it working on 1.36.0 and 1.36.1 broke it?
    EDIT: Downgrading to 1.36.0 seems to have fixed, could have been config issue though. Corruptedxcomics (talk) 13:18, 22 August 2021 (UTC)

    after upgrade to Debian 11: Error loading data from server: apierror-visualeditor-docserver-http-error

    Hello After upgrading from debian buster to bullseye, when the edit key is pressed this message shows: Error loading data from server: apierror-visualeditor-docserver-http-error: ⧼apierror-visualeditor-docserver-http-error⧽. Would you like to retry? edit source mode works. version info: Product Version MediaWiki 1.34.4 PHP 7.4.21 (apache2handler) MariaDB 10.5.11-MariaDB-1 ICU 67.1 I have logging set up for mediawiki and did no info was logged there or apache2 logs or parsoid log. If you have a suggestion to try to fix please post here. thanks for reading , Rob RobFantini (talk) 18:30, 22 August 2021 (UTC)

    on 2ND look at /var/log/parsoid/parsoid.log  :
    {"name":"parsoid","hostname":"wiki-v134","pid":932,"level":30,"levelPath":"info/service-runner","msg":"master(932) initializing 2 workers","time":"2021-08-22T18:49:14.192Z","v":0}
    {"name":"parsoid","hostname":"wiki-v134","pid":1028,"level":60,"code":"MODULE_NOT_FOUND","requireStack":["/usr/lib/parsoid/node_modules/service-runner/lib/base_service.js","/usr/lib/parsoid/node_modules/service-runner/lib/master.js","/usr/lib/parsoid/node_modules/service-runner/service-runner.js"],"moduleName":"../src/lib/index.js","levelPath":"fatal/service-runner/worker","msg":"Cannot find module '../src/lib/index.js'\nRequire stack:\n- /usr/lib/parsoid/node_modules/service-runner/lib/base_service.js\n- /usr/lib/parsoid/node_modules/service-runner/lib/master.js\n- /usr/lib/parsoid/node_modules/service-runner/service-runner.js","time":"2021-08-22T18:49:14.692Z","v":0}
    {"name":"parsoid","hostname":"wiki-v134","pid":932,"level":40,"message":"first worker died during startup, continue startup","worker_pid":1028,"exit_code":1,"startup_attempt":1,"levelPath":"warn/service-runner/master","msg":"first worker died during startup, continue startup","time":"2021-08-22T18:49:15.701Z","v":0}
    RobFantini (talk) 20:20, 22 August 2021 (UTC)
    since this is parsoid related I'll post at https://www.mediawiki.org/wiki/Talk:Parsoid RobFantini (talk) 20:56, 22 August 2021 (UTC)
    as i posted at parsoid discussion , solution:
    i found this: https://www.mediawiki.org/w/index.php?title=Talk%3AParsoid/2019#c-31.166.159.122-2019-12-01T20%3A33%3A00.000Z-210.195.7.193-2019-07-01T14%3A35%3A00.000Z
    after changing this in /etc/mediawiki/parsoid/config.yaml :
    old:
    services:
    - module: ../src/lib/index.js
    new:
    services:
    - module: /usr/lib/parsoid/src/lib/index.js
    and restarting parsoid the issue is fixed . RobFantini (talk) 23:43, 22 August 2021 (UTC)

    After updating to 1.35 when I paste an internal link in the Visual Editor, it creates an external link. I already update to 1.35.3 and VisualEditor-REL1_35-0137e71.tar.gz Baplue Eric (talk) 10:12, 23 August 2021 (UTC)

    Visual Editor adds html meta tags to the top of page content

    I just installed MediaWiki 1.36.1 on Windows Server 2016 with, along with php 8.0.10, and apache 2.4.48. I enabled the Visual Editor extension, but now when I edit a page, it adds this at the top of the page, and truncates a few characters of my content: <meta charset="utf-8" /> <meta property="mw:pageId" content="3" /> <meta property="mw:pageNamespace" content="0" /> <meta property="mw:revisionSHA1" content="bb2659172eaa00e18f1c55600806a1388976b06e" /><meta property="dc:modified" content="2021-09-14T21:05:25.000Z" /><meta property="mw:html:version" content="2.2.0" /> [1][/load.php?lang=en&modules=mediawiki.skinning.content.parsoid%7Cmediawiki.skinning.interface%7Csite.styles&only=styles&skin=vector] <meta http-equiv="content-language" content="en" /><meta http-equiv="vary" content="Accept" /> test <meta property="mw:pageId" content="3" /><meta property="mw:pageNamespace" content="0" /><meta property="mw:revisionSHA1" content="bb2659172eaa00e18f1c55600806a1388976b06e" /><meta property="dc:modified" content="2021-09-14T21:05:25.000Z" /><meta property="mw:html:version" content="2.2.0" /> [2] I have found other threads describing these problems, but only for version of mediawiki that are several years old at least, and none that seem to be from a version that is new enough to not require node.js and the parsoid service. Can anyone help me figure out what is going on here? Chandler ifg (talk) 21:31, 14 September 2021 (UTC)

    Parsoid/RESTBase server (HTTP 404) issue

    I have the same issue as described below but it appears to be related to only when I use a special character like "åäö" in the Swedish alphabet. Does any know how to fix this? System specification: Windows NT S324 10.0 MediaWiki 1.36.0 PHP 8.0.0 (cgi-fcgi) MySQL 8.0.25 ICU 68.1 Lua 5.1.4 Pt99bgu (talk) 10:59, 24 September 2021 (UTC)

    Error contacting the Parsoid/RESTBase server: (curl error: 92) Stream error in the HTTP/2 framing layer

    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? Lwangaman (talk) 20:48, 4 October 2021 (UTC)

    I have the same issue. Had to downgrade to HTTP 1.1 on the Nginx proxy Osnard (talk) 11:34, 26 September 2023 (UTC)

    Error contacting the Parsoid/RESTBase server: (curl error: 7) Couldn't connect to server

    My wiki is running in a container on my laptop and I access it via http through localhost:8080 (mapped to 80 in the container). The name is whatever docker picked (tender_tereshkova) 84.111.224.227 (talk) 09:50, 11 October 2021 (UTC)

    I have another wiki, using the same image basically, running on another machine, where VisualEditor works. 'ps' doesn't show any parsoid server or other difference between processes (basically just apache) 84.111.224.227 (talk) 10:18, 11 October 2021 (UTC)
    Using 1.36 with the bundled VisualEditor 84.111.224.227 (talk) 10:23, 11 October 2021 (UTC)
    I saw somewhere that visualeditor may try to use $wgServer, which is localhost:8080, which will not work from within the container. So I tried the setting $wgVirtualRestConfig['modules']['parsoid']['domain']='127.0.0.1:80'; which doesn't seem to work 84.111.224.227 (talk) 11:29, 11 October 2021 (UTC)
    Fixed by setting $wgServer to my external IP (since I was using my laptop, I could reach it via localhost:8080 which would be mapped to port 80 of the docker, but when the extension tried to do the same, it would be inside the container, where no one listens to 8080. Note that trying to fix $wgVirtualRestConfig['modules']for parsoid or restbase didn't work... 84.111.224.227 (talk) 12:24, 11 October 2021 (UTC)

    Error Revision IDs returned by the server do not match

    Hello ! I recently updated my version of mediaWiki to 1.36.2 with an existing database. No problem with that. However, when I want to use VisualEditor I get this error: Revision IDs returned by the server do not match I can't find anything recent about this :/ Any idea how to fix this? Maybe it's because of the existing database? Thanks Blacksly68 (talk) 09:21, 12 October 2021 (UTC)

    Modifying the Visual Editor Toolbar

    How would I go about removing a specific tool, like the "Cite" tool from the Visual Editor Toolbar? Is this even possible? AID-PMBD (talk) 15:18, 13 October 2021 (UTC)

    VisualEditor issue on Windows Server 2012

    Hi, I am trying to get VisualEditor working on a Windows Server 2012 server. The server is not connected to the Internet, but is on a local Intranet. The error message I get is:

    Error contacting the Parsoid/RESTBase server: (curl error: 60) SSL peer certificate or SSH remote key was not OK

    I do have it working on a local server that is connected on the Internet. I am running:

    • Wampserver 6.4
    • PHP 7.3.21 (also tested using 7.4.9)
    • Apache 2.4.46
    • MySQL 5.7.21

    I have OpenSSL installed (with WAMP), that is being used on the production server, but not on my local machine. I have looked at this post, but I can't seem to locate that code in the "MultiHttpClient.php". Any help is appreciated. Squeak24 (talk) 16:32, 26 October 2021 (UTC)

    Just been having a look at historic revisions of the page. Do I need Stunnel on the server to make this work?
    I have made some headway. I am now getting a Curl77 error now. Squeak24 (talk) 14:35, 2 November 2021 (UTC)
    OK, I am now getting a new error. I have added:
    $PARSOID_INSTALL_DIR = 'D:\wamp64\www\vanilla135\vendor\wikimedia\parsoid';
    wfLoadExtension( 'Parsoid', "$PARSOID_INSTALL_DIR/extension.json" );
    $wgVisualEditorParsoidAutoConfig = false;
    $wgParsoidSettings = [
       'useSelser' => true,
       'rtTestMode' => false,
       'linting' => false,
    ];
    $wgVirtualRestConfig['modules']['parsoid'] = [];
    $wgVirtualRestConfig['modules']['parsoid']['forwardCookies'] = true;
    $wgVirtualRestConfig['modules']['parsoid'] = array(
        'url' => 'https://127.0.0.1' . $wgScriptPath . '/rest.php',
    );
    But now, when try and edit with VisualEditor, I get the error:
    Error contacting the Parsoid/RESTBase server: (curl error: 28) Timeout was reached Squeak24 (talk) 15:32, 2 November 2021 (UTC)
    I think I'm going to have to give up on this for now. But I did find Parsoid - Wikitech (wikimedia.org) earlier.
    Do I need to have port 8000 open to make it work? Squeak24 (talk) 16:06, 3 November 2021 (UTC)

    How to turn off JavaScript preloading in view mode?

    The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    When viewing a site VE loads something in the background. I can see the little icon with the 3 dashes in the upper right corner for 1 or 2 seconds. How can I turn this off - at least for anonymous visitors that won't edit my wiki anyway? I found proof that VE is preloading JavaScript here (7th question). Stefahn (talk) 08:00, 3 November 2021 (UTC)
    I found that this has nothing to do with the VE, but instead it's https://www.semantic-mediawiki.org/wiki/Help:Entity_issue_panel. Stefahn (talk) 14:55, 18 November 2021 (UTC)
    The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

    Documentation update strategy? regarding legacy "parsoid" explanations

    Would anyone object to having these pages restructured to keep the older node/parsoid versions' documentation separate from the currently-used PHP software? I've found all the VisualEditor documentation hard to follow, with how the facts about one version or the other are intermingled. Jackalahg (talk) 15:00, 8 November 2021 (UTC)

    VisualEditor timeout on MW 1.35

    For big pages the VisualEditor times out. The log contains messages like:
    [Mon Nov 15 13:19:04.545572 2021] [fcgid:warn] [pid 363488] (104)Connection reset by peer: [client XXX] mod_fcgid: ap_pass_brigade failed in handle_request_ipc function
    
    [Mon Nov 15 13:19:44.692546 2021] [fcgid:warn] [pid 373859] (32)Broken pipe: [client XXX] mod_fcgid: ap_pass_brigade failed in handle_request_ipc function
    
    I learned that this results not so much from server but client timeout. Searching the source for the error message I got to mw message 'api-clientside-error-timeout'. This gets triggered after 30seconds. I manually raised that delay to two minutes (https://github.com/wikimedia/mediawiki/blob/ff7a116541249b67260f3c21d8ba2987f73649f0/resources/src/mediawiki.api/index.js#L75). This seems to do the trick for me. Why is this hardcoded and not configurable? C holtermann (talk) 12:46, 15 November 2021 (UTC)
    It's actual still Dimka665 (talk) 09:58, 5 May 2023 (UTC)
    Same error here, i got away with smaller articles using "$wgMainCacheType = CACHE_ACCEL;", this seemed to optimize the execution time to less than 30 seconds for smaller articles, however i still have the same problem for bigger articles
    I get this error when the VisualEditor's parse request loads for more than 30 seconds.
    Error:
    The server did not respond within the expected time.
    Is there another way to increase the time or use more resources? im currently using canasta image. 3atrous (talk) 16:09, 12 September 2023 (UTC)

    Needs

    Hi everyone, we want the Visual Editor to gain features such as aligning tables and cells, coloring. We waste a lot of time for this type of alignment and coloring in the resource editor. Kurmanbek (talk) 20:03, 15 November 2021 (UTC)
    hello
    I agree with that offer.
    In my opinion, it is better that a series of features in any other editor should be in the visual editor
    Like coloring the table text using alignment automatically Sokote zaman (talk) 19:30, 16 November 2021 (UTC)
    Exactly... Kurmanbek (talk) 21:18, 16 November 2021 (UTC)

    Error contacting the Parsoid/RESTBase server (HTTP 400)

    Hi,
    I recently upgraded from MW 1.29 to MW 1.36.2, and it's gone fine, however I am getting a consistent error message with VisualEditor, which is the above. I am given no more information, and not exactly sure where to find more.
    I don't understand what could cause this, I have double checked my versions to make sure they're compatible (which they are), but nothing I find has helped so far.
    Any help would be appreciated. If you need more information, let me know. The wiki is located at wiki.pioneer2.net if it helps at all
    Thank you. 90.241.185.51 (talk) 07:53, 16 November 2021 (UTC)
    Installing parsoid Sokote zaman (talk) 08:31, 23 March 2022 (UTC)
    It seems to be working now, e.g edit with VisualEditor this random page. ~ Seb35 [^_^] 17:15, 2 December 2021 (UTC)

    Needed to install php-curl extension to get VisualEditor working in private wiki

    The documentation says that the "forwardCookies" option is enabled by default if not everyone is allowed to read every page. However, this wasn't working for me. I had to install the PHP Curl extension to fix the issue. I do not need the workaround above to check the REMOTE_ADDR with this anymore. M4rkusd89 (talk) 10:48, 22 November 2021 (UTC)

    Error contacting the Parsoid/RESTBase server: (curl error: 3) URL using bad/illegal format or missing URL

    I have a personal MediaWiki site. VE can run without SSL. When the website has a SSL, and I click "Edit" button, it will back a error info: Error contacting the Parsoid/RESTBase server: (curl error: 3) URL using bad/illegal format or missing URL . If I want to create a new page, VE will back this info too. TsuyaMarisa (talk) 16:04, 24 November 2021 (UTC)
    Hello, in a page in my main namespace I want to add a link to a page in a custom namespace. I tried using $wgContentNamespaces to no success. Thank you so much. Carlo Carloposo (talk) 09:42, 26 November 2021 (UTC)