I see, interesting. Both suggested solutions work, thank you! I'm going to use the one that only includes the policies, as I don't really need the checks.

I didn't only report that the docs were wrong, I also reported that the feature was not working (which is already visible in the title of the issue) and provided the necessary information identical to in this issue - which you ignored, answered rudely to and closed the ticket as invalid despite me confirming the actual issue I reported is still persistent - plus the docs actually have been wrong and were fixed, so even if you had only taken that into account the issue would have been valid. I can only ask for understanding that this was a highly disrespectful experience to me and that I think I have a valid complaint there.

In T368852#9999170, @Reedy wrote:

Being passive aggressive in your bug reports won't necessarily help getting them solved.

Turns out this one is on me, a good while ago composer.local.json was changed to include

Issue persists in MediaWiki 1.42.1.

Thank you so much @Alex44019 for the patch, it works great. I wish my report would have been taken serious, then your rollout wouldn't have needed to be stopped.

I have updated the OP with the form. I do not know what MediaWiki "Core" actually is, but it is about a normal 1.41.1 MediaWiki installation.

Ah, you were right! Also applied that fix and the problem is resolved for now.

Confirmed issue is still present in MW 1.41.

Confirmed ReCaptcha is working fine with Visual Editor as well, just ineffective nowadays.

We'll have to disagree on that one, it saying >= 1.41 (Currently only available in master branch of the extension.) for the average user clearly means it can be used in that version and higher with that branch and that is exactly what I am, not a developer.
The conflict in information to the one in the infobox can barely be on me. Especially given the master branch of many other extensions typically works fine in the released version.

Turnstile is mentioned to work as of MW 1.41 (which I have), but requiring the master branch of ConfirmEdit - that is locked to MW 1.42 in extension.json though and hence conflicting (will throw 500 on wiki). With adjusting that I meant changing this requirement in extension.json to MW 1.41, to see if it works.

Confirmed fixed in MediaWiki 1.41.

I just had time to try again and was not able to reproduce. Not sure what went wrong the first time - sorry, I'm closing myself.

We found similar messages in our logs, but &diff=prev works for us and seems to not be the reason for the problem.
(Example link similar to OP's one works fine: Click here (SFW))

I used wget for both directly on the server after copying the link locally, but I didn't test it more than once.
It just seemed like the link provided via "Download extension" -> "master" gave a different version than when downloading from Github directly.

I apologize for mentioning you. I still wanted to try to see if it is possible to get this to work on MediaWiki 1.41?
We have severe issues with spam bot registrations and hCaptcha is unfortunately absolutely ineffective. ReCaptcha v3 by Mirazhe was very effective, but was discontinued by them and no longer works starting MediaWiki 1.41. The main ConfirmEdit has no ReCaptcha v3 support and v2 and earlier are ineffective as well.
The only other option is disabling registrations until 1.42 again.

Confirmed in 1.38.4 as well.

Yes, it happens on 1.38.1 without my manual changes. I haven't gotten the time to update to 1.38.2 and FlaggedRevs for that version, though.

This is a PHP > 8 issue. It works fine until 7.4.

Yes, for my specific configuration with a global wiki in root and several language wikis in subfolders the following will work for both FlaggedRevs and Visual Editor on all of the family wikis:

I found a potential solution, adding the following to the .htaccess for the pretty urls worked and leaves both Visual Editor and FlaggedRevs intact - of course I wasn't able to check if something else broke:
RewriteCond %{REQUEST_URI} !^/en/rest.php/.*$ [NC]

I can confirm that reverting to 1.37.2 and the stable FlaggedRevs for that version restores functionality without any configuration change.

Visual Editor works fine with the current configuration, when I use any of the rewrites Visual Editor doesn't work anymore. It's been a hell to get that working to begin with, so given no config was changed during the update I'm wondering why it ceased working with the update.

As of 1.38.1 Visual Editor works correctly with PHP 8.1, looks resolved.

Glad to hear it worked, now I'm hoping for the bigger brains that might have an idea why PHP 8+ breaks this.

@Socksoff @Chapenkov11
Could both of you please try with a PHP version below 8?
I do have the exact same issue now, but only since I updated to PHP 8.
When I revert back to 7.4, it's gone and everything works.

Hello,
thank you so much, this indeed fixes the problem and spam is gone while anonymous users can still contribute with VE active.

Thanks for the patch, i applied it to my MediaWiki installation and it disables VisualEditor for Anons.
Unfortunately, it does not disable VisualEditor Wikitext 2017 which is activated by default and forced to be used.
I'm not sure if that is intended (it's a part of VisualEditor and causes the same issue with ReCaptcha not working, hence Anons not able to actually edit pages) or maybe even because I applied the patch to a version before 1.36, but i wanted to leave this feedback.

I guess there is no way to make Visual Editor learn HTML / BootstrapComponents? We use that on the main page and visual editing looks weirdly wrong-formatted there.

Okay, found the solution:
128 MB memory limit for PHP is not enough for that page, setting it to 256 MB fixed the issue, Visual Editor took about 15 seconds to load, though. So a higher default timeout might be useful in rare circumstances where it could take that long.

That seems to not be the case, as the 500 does come after only 2 - 3 seconds, not 30. For testing i changed the value to 300 seconds and it brought no change.
I'll try adding the debug log and see if i can find anything.

In T263928#6519933, @ssastry wrote:

In T263928#6519568, @D3nnis3n wrote:

Well, it's not completely working. On a long page with a lot of modules it fails to connect with an error 500, but on normal sized ones it seems to work fine.
...
//EDIT:
It actually seems like this is the only page i can get this error to happen. Would a link to the page help?

Yes, please. But, since it is a HTTP 500, if you have access to the logs and you can send us a stack trace from the logs, that would be even more helpful!

Thank you. I also added a screenshot to make clear where it happens and how it looks, hopefully that helps.
And hopefully this time my report was formatted correctly :)

But yeh, i can live with a single page not working in Visual Editor (actually two, as pages that are formatted with bootstrap html via BootstrapComponents extension aren't displayed correctly either).
So technically my issue is solved. If there is a fix for my 500 i'd like to know about that of course and i'm sure the others with issues in here would also like to get their visual editor going - it's awesome when it works!
But i could open a new report for the 500, given it's very likely a totally different issue. I'm not sure how that works here, so please advise on the correct steps.

I saw that task and hence assumed Visual Editor would now work with ReCaptcha, but as i noted in my OP as a "side-notice", ReCaptcha is not working either.

Well, it's not completely working. On a long page with a lot of modules it fails to connect with an error 500, but on normal sized ones it seems to work fine.

In T263928#6518900, @CostasAthan wrote:

@D3nnis3n

As I'm not familiar with Nginx, do you have an idea what the equivalent code for an .htaccess file would be?

Okay, i finally got it to work:

@cscott
That does not fix my issue. I'm using that in my configuration.
It errors out with 404: https://example.com/rest.php/example.com/v3/page/html/Main%20Page
https://example.com/rest.php/example.com/v3/page/html/Main_Page

In T263928#6515583, @Joergi123 wrote:

@D3nnis3n: Calls to rest.php need to be parsed by the PHP parser. Please make sure, in your server configuration, that such calls go through the PHP parser.

https://domain.com/rest.php/domain.com/v3/page/html/Main_Page downloads a file called "Main_Page" to my PC, containing rest.php.

The wiki mentions it does only need to be installed if you don't want 'dirty diffs' to happen when switching editors. So it should still work out-of-the-box.
I mean i don't need it to work out of the box, but i expected a bit of a documentation on how to set it up - currently there is neither a documentation nor is it working out of the box.

^ That's exactly the same thing i experience.

In T263928#6514179, @ssastry wrote:

We'll take a look next week but in case it helps anyone in the interim, https://twitter.com/aixnr/status/1310192041503141889 might be worth checking out.

Thank you very much for your patience with me and the fixes, very appreciated. And sorry again i haven't been clear enough on what my 'issue' is from the very beginning!

That indeed makes it show a list of what it does in --verbose mode, great!
Unfortunately my Jobs Queue is working well now, so i'm not currently having something to test if it does what i want. (Okay, that's not unfortunate)
The next time we change the infobox content module i'll test it again though :)

Has anyone got this to work on a base install?

In T263929#6497201, @Reedy wrote:

In T263929#6497065, @D3nnis3n wrote:

Also, for reference: https://www.mediawiki.org/wiki/Topic:Vmxeao5p27gidhnh

Which seems to agree with what we said ;)

Also, for reference: https://www.mediawiki.org/wiki/Topic:Vmxeao5p27gidhnh

Okay, the job queue isn't actually being run and thats only my fault. When setting up the family wiki the article recommended to set $wgJobRunRate to 0. So it's not actually running.
https://www.mediawiki.org/wiki/Manual:Wiki_family#Configure - I should have looked up what it does or rather that i need to setup a cronjob manually then.
So i guess my problem should be solved with setting up the cronjob for it. And if the script here is not supposed to purge pages, its not a bug either. But i'd really like to have the option of an easy --all purge if you were ever to consider an addition to purgePage.php.

Ah, yeh. I tried executing that manually as well, but it said there is no outstanding jobs to do - the pages weren't up-to-date and needed a purge nontheless, though. So that might indeed not work for some reason.

Just looked up when i last used the purgeList.php to purge all pages and it was working, that was on August 19, 2020 - and we definately had 1.34 installed back then. (We log actions in our discord)

Well, it's an old comment, but i've been using that method since five years now - without any issues. Now i suddenly had issues with it, so i tried to report that issue.
I'm sorry that i didn't know the intention of the script, but that really didn't bother me at that time - it fixed a problem i had for a long time and was a perfect solution.
I'm just a normal user, no developer. If it works for me, it's good ;)

Here, someone posted it on Stackoverflow, first answer: https://stackoverflow.com/questions/25597846/purging-all-pages-in-mediawiki

But that's exactly what it did pre 1.34 for me.
Cache related i only got '$wgMainCacheType = CACHE_DB;'

No, none. I've gone through the list in the release notes and updated all configs i had, but those weren't in my LocalSettings.php.

Like, it looks like this, for ages now: