Topic on Extension talk:StructuredDiscussions

1. InLocalSettings.php,explicitely load Parsoid like so:wfLoadExtension( 'Parsoid', "vendor/wikimedia/parsoid/extension.json" );
2. Apply thepatch

After upgrading from 1.38.4 to 1.39.0 VisualEditir does not work atFlow(Structered discussions) talk pages having following error:

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

Previously I had such problem but thepatchhelped to resolve the problem, but now it doesn't help.

Any ideas how to resolve the problem?

Damn!I'm definitely looking forward to a solution as well. Did you try asking the developers of the patch?

Flow works properly on this wiki and it's1.40.0.Is there a way to access the code base to see what fix they applied?

I think you can see the configuration of Parsoid for this wiki herehttps://gerrit.wikimedia.org/g/operations/mediawiki-config/+/fa477a5521e8acc290a02e7cf8f9219ebd2d5cf5/wmf-config/CommonSettings.php#2653.Though, I am not sure whether this can help you.

I can confirm the same issue, the patch mentioned does not work anymore. Working with version 1.39.1 and not even theREL1_39on GitHub is working.

@Tinss:Flow works properly on this wiki and it's1.40.0.Is there a way to access the code base to see what fix they applied?

It says this MediaWiki instance is running the version 1.40.0-wmf.20. So in theory, theversion listed as such on the extension's GitHubis the one featured here. If you happen to find anything, please share here with us, because apparently we can't expect the developers to prioritize the users of MediaWiki as much as they prioritize Wikimedia's projects.

It's been more than 2 years of this issue, still unresolved for most of us, except, well, Wikimedia.

Is there a phabricator ticket for the issue?Maybe we could try kindly asking the VE development team to look into it.

Flow is indeed very popular in enterprise MW.

I haven't made tickets for the issue at phabricator. I would appreciate if there will be one.

Since there's a demand for it, I created aticket for this issue(still unresolved on my end)

Thank you! Hope there will be a solution of the issue soon.

We received a reply, more than a month later basically confirming my suspicions related to this extension developers' priorities:

apparently we can't expect the developers to prioritize the users of MediaWiki as much as they prioritize Wikimedia's projects.

This turned out to be true, as can be seen by thecommentof this developer on the issue:

I'm afraid we don't offer much in the way of StructuredDiscussions maintenance/support, other than fixing issues that are highly disruptive on Wikimedia wikis. [...] Also, given that StructuredDiscussions does work on Wikimedia wikis, this seems an issue with the configuration, not the extension; the linked patch is about supporting a zero-config setup, but you probably wouldn't need a patch if it is correctly confiugred.

So what they are saying is – it's the fault of the users, not the developers for not documenting the configuration needed, or for focusing exclusively on Wikimedia projects.

So yeah, we can only rely on the users to fix that. If any of you ever find anything, let us know, I'll certainly do the same.

I was sort of expecting that kind of reply. Maybe the original author of the patch (@Lens0021) could lend us a hand?

Unfortunately, I am not using zero-config VisualEditor anymore (or never). I am sorry I've forgotten what was the issue after that patch merged. Here are my current configuration and the comment I've written.

# Disable "zero configuration" VisualEditor
# zero-conf VisualEditor assumes that all the services are served as the same host. ('/' for
# MediaWiki, '/rest.php/<domain>/v3/' for Parsoid and '/restbase/<domain>/v1/' for RESTBase)
# It is not our use case, we are serving those services behind the orchestration tool, Docker or
# Nomad and a variety of addresses are used.
$wgVisualEditorParsoidAutoConfig=false;

$wgVirtualRestConfig=[
'modules'=>[
'parsoid'=>[
'url'=>'http://'.(getenv('NOMAD_UPSTREAM_ADDR_http')?:'http:8080').'/rest.php',
],
'restbase'=>[
'url'=>'http://'.(getenv('NOMAD_UPSTREAM_ADDR_restbase')?:'restbase:7231'),
# https://github.com/femiwiki/femiwiki/issues/266
'domain'=>'femiwiki.com',
],
],
'global'=>[
'domain'=>'femiwiki.com',
'restbaseCompat'=>true,
'forwardCookies'=>false,
],
];

(original code:

https://github.com/femiwiki/docker-mediawiki/blob/408fbdf64fbcbc02c4ca96671f97b40fab7b5701/configs/LocalSettings.php#L357-L380)

Does anybody resolved the issue or not?

Not on my end. As I do not have MW 1.39 deployed on my test setup, could you give a look at theParsoid and Flow configsused by Wikimedia for this wiki to see if replicating them fixes the issue?

It appears that Flow is not finding Parsoid so this points to a configuration issue indeed.

will this thread help?Topic:W9nbm08t1cg25lop

This is the patch that used to work but no longer does.

No idea how to implement that. For now I am stuck - wanted to update to 1.39.3, but faced withproblem.But if I have success, then I want to implementDiscussionToolsextension, which, as I understand will be developed. And if I am not mistake Structured discussions are no longer supported, right?

StructuredDiscussions is only getting security fixes. Other type of support has halted. I suspect support will be entirely dropped, but not until there is a migration tool because some wikis (this one at least) are still using StructuredDiscussions.

@Fokebox,did you get a chance to replicatethese configson your installation?The bug here does seem to be related to the zero-config setup.

@Tinss,@FokeboxI don't know if you saw my complete thread, but there, in addition to the patch, is also a summary of the variable:

$wgVirtualRestConfig['modules']['parsoid']['url']

I tried this to connect parsoid php to visualeditor and from visualeditor to flow, it really worked for me, I don't know if you have tried this configuration

Well, I decided to drop off the extension as it is not maintained no longer and change it toDuscussionTools.I have not too many Flow pages to be changed, so I decided to resolve the issue this way.

@Fokebox,@TinssI was finally able to make it work, by the glory of Lenin. Here is what I had to put in the LocalSettings.php:

wfLoadExtension('Parsoid',"vendor/wikimedia/parsoid/extension.json");
$wgVirtualRestConfig['modules']['parsoid']=[
'url'=>$wgServer.'/rest.php',
];

I followed the instructions of the Parsoid/PHP setup. It recommends to manually declare Parsoid as an extension and to configure it, then just override the url parameter of $wgVirtualRestConfig['modules']['parsoid'] with your situation.

It's where you access the rest.php from. If you input the rest.php location correctly in your url, it should return a JSON catching a 404 error. You should see the same thing ashttps://en.prolewiki.org/rest.php

The URL of access of the rest.php is what you should put in the url parameter of that configuration.

Thanks, but I decided to change the extension toExtension:DiscussionTools

Wow, thanks. Can't wait to try it.

@Tinssthis might interest you. I still had a problem when doing the above. The problem was we have a private wiki, so I should also forward cookies:

wfLoadExtension( 'Parsoid', "vendor/wikimedia/parsoid/extension.json" );
$wgVirtualRestConfig['modules']['parsoid'] = [
'url' => $wgServer. '/rest.php',
'forwardCookies' => true,
];

But doing only the following also worked for me:

wfLoadExtension( 'Parsoid', "$IP/vendor/wikimedia/parsoid/extension.json" );

(EDITED: Added$IP)

When also applying the patch everybody uses.

You guys are awesome, I owe you both a virtual beer.

Anyone thinks this should be added toExtension:StructuredDiscussions#Troubleshooting?

Added to the troubleshooting section.

In my environment, I had to add$IP/and follow the codehereto get the maintenance script to work.