Tue, Jul 26
Thanks @Nux. I tried the same operations in Firefox on Linux and they work fine. So it does seem like a Chrome issue.
I just tried out the fix in WikiEditor on en.wikipedia.org using the latest Chrome on Linux. The behavior is better than before, but still strange. Here are steps to reproduce:
May 10 2022
Thanks, @matmarex. For this request, api.php?action=visualeditor&format=json&paction=parse&page=Test_page&uselang=en&formatversion=2, I get an unexpected response that begins like this:
May 9 2022
Sure, if you can provide instructions for me to see those responses, so I can copy them into this ticket.
Apr 21 2022
This bug is a duplicate of T306048 and can be closed.
Apr 13 2022
Behavior confirmed in latest MW 1.37.2 as well.
Mar 16 2022
Update: After making no configuration changes at all, VisualEditor now fails 100% of the time on invocation, displaying a similar error:
Mar 10 2022
Thanks for the patch. I appreciate your work!
Mar 9 2022
If I understand your patch correctly, you're removing all whitespace from the name, instead of just trailing whitespace before the file extension. Is that what you meant to do?
Mar 3 2022
- On your hard drive, create an image file named Foobar .jpg with a space before the dot.
- Visit Special:Upload, browse to this filename, and select it.
- Notice that on Special:Upload, the Destination filename is Foobar_.jpg.
Jan 18 2022
I have encountered this exact error on a fresh install of MediaWiki 1.37.1 with no extensions other than VisualEditor and WikiEditor. Editing with WikiEditor works perfectly.
@Izno - Would you please provide a link to docs on how to create such a user script? Thank you.
Jan 17 2022
Jan 14 2022
Screenshot of the error (showing VisualEditor's state):
In case this helps: setting $wgForceHTTPS does not make VisualEditor work:
@matmarex : Yes, setting $wgCanonicalServer as follows makes VisualEditor work:
Jan 13 2022
I can confirm that my four wikis, which were unable to use VisualEditor, are now fixed. :-)
I restricted my test wiki to disallow anonymous edits:
@AndrewDBate - yes indeed, my LocalSettings.php did not include any $wgGroupPermissions changes. It is possible that two separate issues are masquerading as one issue:
The protocol-relative URL bug is now T299175.
I discovered the cause of the problem (documented in the previous comment). Changing this line in LocalSettings.php, which specifies a protocol-relative URL:
OK, I just went through an extensive debugging session for this problem (Error contacting the Parsoid/RESTBase server (HTTP 415) on save operations). I created a MediaWiki 1.37.1 test site with a minimal LocalSettings.php file plus VisualEditor. There are no $wgGroupPermissions statements at all, so wiki permissions should not be an issue -- the test site is wide open for anonymous editing.
Dec 28 2021
Ah, found some REST docs. @AndrewDBate, does this successful GET request prove that Parsoid is running on the given server?
Thanks @AndrewDBate. I really appreciate all of your advice.
A-ha... if I make my private wiki use http instead of https (by changing the Apache configuration), VisualEditor can save pages without error, without needing any of the workarounds in this ticket.
@AndrewDBate: I finally had a chance to try your error-logging alternative:
Nov 22 2021
@M4rkusd89: Thanks for the suggestion. php-curl is already installed on my server, so your fix may be necessary for VisualEditor but it's not sufficient to solve the problem.
Oct 11 2021
Ooo, this might explain the weird wfDebug behavior. From https://www.mediawiki.org/wiki/Manual:How_to_debug#Logging:
Oct 7 2021
I don't have an explanation but I do have a better analysis.
Thanks @AndrewDBate. I suspect the issues with the MediaWiki debug log were due to heavy caching -- I'd modify LocalSettings to enable debugging but MediaWiki wouldn't pick up that fact and wouldn't reread it.
Oct 4 2021
Thanks @AndrewDBate for your debugging help! Yes, in the big table output by this script:
Thanks @AndrewDBate! I did exactly as you said, and both $_SERVER['REMOTE_ADDR']) and $_SERVER['SERVER_ADDR']) are the empty string.
Oct 2 2021
@AndrewDBate: Your workaround unfortunately does not work for me with MediaWiki 1.35.3. I still get this error from VisualEditor on save:
Aug 4 2021
I'm being bitten by this bug on a wiki that permits anonymous reads and forbids anonymous writes. None of the suggested workarounds work for me.
May 20 2021
Glad to hear it! This was a tough bug to notice. I kept thinking it was my fault for clicking imprecisely. :-)
May 11 2021
Thanks for testing! My setup was Chrome on Ubuntu Linux 18.04.
Mar 20 2021
The bad behavior is still present. I can confirm that in MediaWiki 1.35.1, I can upload an image file and name it foo .jpg including a space character before the .jpg extension.
Feb 16 2021
Thank you so much! Sorry for taking up your time.
Feb 15 2021
May 31 2020
No, I haven't seen it for a long time. Thanks.
May 30 2020
May 13 2020
May 10 2020
Thank you for the suggestion, @Ammarpad. I added this line to LocalSettings.php:
FYI, I also just added application/epub+zip to /etc/mime.types (on my Ubuntu 18.04 system)
@Ammarpad - Thank you for the suggestion about the MIME type. I don't know much about epub files, but when I unzip my file, I see:
May 8 2020
Feb 29 2020
Dec 8 2019
Thanks. I upgraded to 1.31.5 a few hours ago. :-)
Oct 1 2018
Sep 7 2018
Jul 9 2018
May 2 2018
Apr 25 2018
Dec 28 2017
Works for me! Thanks so much, @Seb35!!
Dec 24 2017
Dec 2 2017
Nov 4 2017
Still a problem in MediaWiki 1.29.1.
Oct 11 2017
Sep 8 2017
Jun 30 2017
@zhuyifei1999 Yes, the current code successfully logs into a private wiki. There are some warnings, but the same warnings were already present before the changes.
Jun 26 2017
The error behavior has changed in the current version of pywikibot. The error is now RuntimeError: Unable to determine articlepath.
Jun 8 2017
@Anomie - thanks for the info. Would the following be a correct fix within Pywikibot?
@zhuyifei1999 - Thanks for the suggestion. This wiki is inside of a corporation that uses another authentication method.
Any estimate on when you might address this issue? Pywikibot is completely unusable on all wikis that require logins to read.
May 24 2017
@matmarex - Thanks so much for your extremely clear and detailed explanation. Thanks to you, I have updated the affected extension on our wiki, and it's now working perfectly. I also appreciate very much that the docs will be updated.
Apr 4 2017
Is there any kind of workaround for this issue? Our wiki hasn't been able to use Pywikibot for 4 months....
Feb 28 2017
You sure that T153346 is the same onBeforeUnload issue as this ticket?
Feb 16 2017
Feb 3 2017
Suggestion: Allow the user to provide the missing site information, either on the command line (using options), in a configuration file, or during script execution if the script can prompt the user interactively.
Jan 10 2017
This problem no longer occurs in MediaWiki 1.28.0, with the Linker class (deprecated) replaced by calls to LinkRenderer.
Jan 9 2017
Jan 5 2017
Jan 4 2017
This can be closed.
Looks like someone already patched this for bug T151973:
Jan 3 2017
Thank you for making the patch. Interestingly, I filed this bug report against a different extension that's also named DynamicPageList. I found the bug in the third-party extension known as DynamicPageList2, Your patch is against the original DynamicPageList from Wikimedia.
Finally managed to have time to get developer access, and submitted the patch above. This bug has been around for 3 releases, so hopefully this will eliminate it.