Page MenuHomePhabricator

Conversion from 'html' to 'wikitext' fails on MW 1.35
Closed, DuplicatePublicBUG REPORT

Description

I just updated my MW 1.34 to 1.35 with no problems. VisualEditor is working fine. However when I try to create a Flow thread, I get the following error:

Exception caught: Conversion from 'html' to 'wikitext' was requested, but core's Parser only supports 'wikitext' to 'html' conversion

Several users have reported the same issue at https://www.mediawiki.org/wiki/Topic:Vw6bf78zvy5fvlsi

Are we all doing something wrong? Thanks for your awesome work!

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Hello!

I'm experiencing the same problem. Recently I've switched from MW 1.34 to 1.35. Visual Editor works fine everywhere except Flow. I'm using the autoconfigure mode, so $wgVirtualRestConfig is not set. At the moment I found three different error messages:

(1) When I'm tring to edit an old existing comment:

An error occurred. The error message received was: internal_api_error_Flow\Exception\WikitextException

(2) When I'm tring to save a comment in visual mode:

[X6akA72QQzSDKWPFYEuVSAAAAAU] Exception caught: Conversion from 'html' to 'wikitext' was requested, but core's Parser only supports 'wikitext' to 'html' conversion

(3) When I'm trying to switch from visual to text mode (the other direction works):

Unable to transfer content: Error contacting the server for conversion between wikitext and HTML. Please check your Internet connection or try again later if the problem persists. If you still get this error please file a bug

Here is my current Setup:

wfLoadExtension( 'VisualEditor' );
$wgGroupPermissions['user']['writeapi'] = true;
$wgSessionsInObjectCache = true;
$wgVisualEditorAvailableNamespaces = array(
        NS_USER => true,
        NS_HELP => true,
        NS_PROJECT => true,
        NS_TEMPLATE => true,
        NS_LINK => true
);

wfLoadExtension( 'Flow' );
$wgFlowContentFormat = 'html';
$wgFlowEditorList = array( 'visualeditor', 'none' );
$wgFlowParsoidTimeout = 100;
$wgFlowParsoidForwardCookies = true;

My additional research:

  • I can switch between the visual and text mode only when I'm creating a new comment. Or sometimes when I save the post after 3rd message occurs, bot not every time.
  • 1st problem appear when I'm in a text mode. If I'm in visual mode I can open an existing comment for edit, but of course I can't save it because of the 2nd issue.
  • I can't say using $wgFlowContentFormat = 'wikitext'; solve any of the issues.
  • Using $wgFlowEditorList = array( 'wikitext' ); in order to force the usage only of the wikitext editor doesn't work.
  • $wgFlowContentFormat and $wgFlowEditorList doesn't change anything at all.

Does we need something like $wgGroupPermissions['flow']['writeapi'] = true;?

I can confirm and reproduce @Spas.Z.Spasov analysis.

After delving into Flow's code, I found that the error comes from Flow/includes/conversion/Utils.php:227 and tracking it back, it seems that Flow expects a Virtual REST Service object from the makeVRSObject method in the same file, but isn't getting it because neither $wgVirtualRestConfig nor $wgFlowParsoid* are set. However, since Parsoid now comes with core MediaWiki, these variables appear obsolete. I tried to fill them anyway, using values such as:

$wgFlowParsoidURL = 'https://sophivorus.com/w/api.php';
$wgFlowParsoidURL = 'https://sophivorus.com/w/rest.php';
$wgVirtualRestConfig['modules']['parsoid'] = [ 'url' => 'https://sophivorus.com/w/api.php' ];
$wgVirtualRestConfig['modules']['parsoid'] = [ 'url' => 'https://sophivorus.com/w/rest.php' ];
$wgVirtualRestConfig['modules']['restbase'] = [ 'url' => 'https://sophivorus.com/w/api.php' ];
$wgVirtualRestConfig['modules']['restbase'] = [ 'url' => 'https://sophivorus.com/w/rest.php' ];

but no joy. Is there some way to fill these variables so that Flow is able to build the object it expects out of the core Parsoid?

I saw this issue also on MW 1.35 and in fact this issue is the same as T260648 - although this other one is more abstract and does not explicitely describe the visible issues.

I post there a minimal fix extracted for the patch currently in preparation.