Topic on Help talk:Paragraph-based Edit Conflict Interface

Issue with the $wgDiff3 configuration.

On my local dev wiki, the (just installed) feature is broken : I choose thanks to the radio buttons which version I want to keep, but when I click save, the page reloads and every conflict paragraph is highlighted in red. None of the options I chose are memorized. If I start over and try to save again, the same thing happens.

Unfortunately that's not enough information. How was the conflict resolution interface triggered? How many rows of radio buttons appeared? Is JavaScript enabled? Does the JavaScript console show some error? It might also be the configuration of your webserver or PHP somehow not accepting array-structured form variables. But this is all speculation. Sorry.

Thanks for your swift response.

I trigger myself the conflict resolution thanks to two separate accounts (since it is my dev wiki) on two separate browsers (I tried a bunch, does not seem to be the cause of it).

I run MediaWiki 1.35.6 on a local EasyPHP dev server (Apache 2.4.25 x86 - PHP 7.4.19 x86 - MySQL 5.7.17 x86).

Javascript is enabled and works fine. No particular message in browser console either.

The error happens whether there is more than one paragraph or just one.

It seems that if I choose the newest, not saved yet, revision, the page reloads with a red "alert" background-color on conflicting paragraphs and deletes all choices.

If I choose the already saved revision, the paragraphs that had conflicts just disappear, but the page is still not saved: the interface shows then only the unchanged paragraphs, which is really weird.

I hear you about the PHP version, but every other extension works perfectly, so that would be odd.

Might be linked to my other extension configurations, I'll try on a fresh install and keep you posted.

That sounds really strange. Sorry, I have no idea. I even went back and tested this older version (it's almost 2 years old by now) and it seems to work fine for me. The error sounds like parts (?) of the POST request are lost. Maybe it's an overly aggressive security or spam protection plugin in Apache or PHP?

After several hours of digging deep in the code, I finally figured out was was causing the issue (at least for me). In includes/GlobalFunctions.php.

function wfMerge(
	string $old,
	string $mine,
	string $yours,
	?string &$simplisticMergeAttempt,
	string &$mergeLeftovers = null
): bool {
	global $wgDiff3;

	# This check may also protect against code injection in
	# case of broken installations.
	AtEase::suppressWarnings();
	$haveDiff3 = $wgDiff3 && file_exists( $wgDiff3 );
	AtEase::restoreWarnings();

	if ( !$haveDiff3 ) {
		wfDebug( "diff3 not found" );
		return false;
	}

file_exists ($wgDiff3) always returns false even if the diff3 tool exists and it's path is correctly set. For that matter, it appears that checking if a file exist outside the server directory always fail, so I suspect this is a security feature.

Just commenting out the return false part fixed everything,