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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Tue, Apr 23
Mon, Apr 15
Ah, you were right! Also applied that fix and the problem is resolved for now.
Thu, Mar 28
Confirmed issue is still present.
Confirmed ReCaptcha is working fine with Visual Editor as well, just ineffective nowadays.
Mar 27 2024
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.
Mar 26 2024
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.
Oct 2 2022
Confirmed in 1.38.4 as well.
Jul 26 2022
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.
Jun 27 2022
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.
Jun 26 2022
As of 1.38.1 Visual Editor works correctly with PHP 8.1, looks resolved.
Mar 27 2022
Glad to hear it worked, now I'm hoping for the bigger brains that might have an idea why PHP 8+ breaks this.
Mar 25 2022
@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.
Nov 23 2021
Oct 11 2021
Jul 12 2021
May 26 2021
Hello,
thank you so much, this indeed fixes the problem and spam is gone while anonymous users can still contribute with VE active.
Mar 15 2021
Feb 6 2021
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.
Nov 1 2020
Oct 7 2020
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!
Oct 5 2020
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: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
Oct 4 2020
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.
Oct 2 2020
^ 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.
Sep 28 2020
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 ;)
Sep 27 2020
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.
When doing 'php purgeList.php --all --purge --wiki=english --verbose' prior to 1.35 it showed a list of all pages on the wiki that it purged (like with ?action=purge). That was necessary when we changed Templates that are used on every page or changed content of LUA Modules we use to fill them.
When doing this today with 'php purgeList.php --all-namespace --db-touch --wiki=english --verbose' nothing happens. The pages still display outdated data or broken modules until ?action=purge is done. It also shows no list of pages it works through in verbose mode and the script never exits in the console.
Tried with --db-touch (i would never have guessed --purge is equal to --db-touch), same result. Just not actually doing anything.
So, with
location /specific/folder/rest.php {
try_files /specific/folder/rest.php =404;
}
404 error vanishes on my family wiki setup just the same as if i would set $wgVisualEditorRestbaseURL or $wgVisualEditorFullRestbaseURL, but pages are still loading forever not showing page content in the editor with /api/rest_v1/page/html/Main_Page?redirect=false&stash=true 404ing on the main wiki, and no error on the debug console on the family wikis.
(But i guess it's the same problem)
Okay, i set up another MediaWiki - no pretty urls, no $wgVisualEditorRestbaseURL or $wgVisualEditorFullRestbaseURL set. Just absolute basics.
The Visual Editor still doesn't load the content of the page i want to edit. And in this case, the error console of chrome doesn't even have any 404 errors.
I feel this might be more of an issue with pretty URLs, debug console complains it cannot find "/api/rest_v1/page/html/Main_Page?redirect=false&stash=true:1 Failed to load resource: the server responded with a status of 404 ()".
In T263928#6496370, @Aklapper wrote:@D3nnis3n: Thanks for reporting this. I've read this ticket (description and comments) twice and I'm still a bit unsure: Am I correct that this ticket basically says that "VisualEditor does not work out of box, until you manually set $wgVisualEditorRestbaseURL and $wgVisualEditorFullRestbaseURL"? Or does that just make the error message go away and it still doesn't show page content? If the latter, please manually use the URL parameter debug=true when loading a page in VE, and check both the console and the network tab of your web browser's developer tools for problems?
In general, following https://www.mediawiki.org/wiki/How_to_report_a_bug and splitting into Steps to Reproduce, Expected Outcome, Actual Outcome is very welcome, to avoid misunderstandings. Thanks!
The latter. Setting both configs makes the 404 go away, but loading is still endless. I'm now investigating this further with your tip and Seb35's remarks, though i doubt the latter will help, as it didn't work with a standalone MediaWiki either.
Mh, not sure. The last time i used this script and it was working it still had the --all parameter, which seemingly was not removed in that change.
When i tried to purge the pages i still tried with the --all parameter and it told me that one does no longer exist. I'm not sure if it also still had the --purge parameter.
The help page here https://www.mediawiki.org/wiki/Manual:PurgeList.php still doesn't make mention of the removal of --all and the introduction of --all--namespace, so i'm not sure in which version this was changed exactly.
I'm quite sure i used purgeList in 1.34 with the old parameter but i wouldn't testify for that, it might have been an older version - but in any case the current script is not working for me.
Oh, i forgot to mention what i mentioned in the topic:
"So, i found out that VisualEditor does show and work when trying to create a page that does not yet exist - but it fails when trying to edit a page that exists."
^ That was the case when i still had the 404 error on the family wikis, until i set the mentioned configs for them manually and the error subsequently gone for both editing and creating new pages.