User Details
- User Since
- Sep 27 2020, 2:48 AM (182 w, 4 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- D3nnis3n [ Global Accounts ]
Today
Confirmed issue is still present.
Confirmed ReCaptcha is working fine with Visual Editor as well, just ineffective nowadays.
Yesterday
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.
Turnstile is mentioned to work as of MW 1.41, but requiring the master branch - that is locked to 1.42 in extension.json though and hence conflicting. With adjusting that I meant changing this requirement in extension.json, to see if it works.
Which it does not, as then "Missing Captcha" will appear as error in Visual Editor. I hence simply used the patches from the implementation task (https://phabricator.wikimedia.org/T319068) and applied them to MW 1.41 ConfirmEdit, and the issue described here is the result, e.g. Turnstile does not work in MW 1.41 - and hence likely not in 1.42 either, as of that task the implementation was originally made for 1.40.
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.
Tue, Mar 26
We have a similar issue, but it &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.
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.
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
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.
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?
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.
Like, it looks like this, for ages now:
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 ()".
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.