Topic on Extension talk:StructuredDiscussions/Archive 2

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

After upgrading from 1.38.4 to 1.39.0 VisualEditir does not work at Flow (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 the patch helped 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's 1.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 here https://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 the REL1_39 on GitHub is working.

@Tinss: Flow works properly on this wiki and it's 1.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, the version listed as such on the extension's GitHub is 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 a ticket 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 the comment of 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 the Parsoid and Flow configs used 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 with problem. But if I have success, then I want to implement DiscussionTools extension, 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 replicate these configs on your installation ? The bug here does seem to be related to the zero-config setup.

@Tinss, @Fokebox I 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 to DuscussionTools. I have not too many Flow pages to be changed, so I decided to resolve the issue this way.

@Fokebox,@Tinss I 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 as https://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 to Extension:DiscussionTools

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

@Tinss this 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 to Extension:StructuredDiscussions#Troubleshooting ?

Added to the troubleshooting section.

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