User Details
- User Since
- Dec 19 2017, 8:59 PM (331 w, 5 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Ti infotrad [ Global Accounts ]
Jul 13 2023
@matmarex If I provide a fix, what is the chance of it being included in the code base?
So this is the second ticket opened for the same issue (I opened the other one T265144). As mentioned in the other ticket, this was working fine before. So what if it not possible to switch our site to short URLs? As far as you remark ("you might haver to live with it for now"), how long do you think the "for now" will be :-)
Feb 22 2021
For now, fixed it by hardcoding location in
Feb 17 2021
Feb 16 2021
Feb 7 2021
- Are you running MW 1.36 Alpha? As far as I can tell, the Parsoid extension is only available for 1.36 (excerpt from https://www.mediawiki.org/wiki/Extension:VisualEditor#Linking_with_Parsoid below)
Le sam. 6 févr. 2021 14 h 54, Johnywhy <no-reply@phabricator.wikimedia.org>
a écrit :
Feb 4 2021
@Johnywhy, you just need to follow the installation instructions given at https://www.mediawiki.org/wiki/Extension:VisualEditor#Linking_with_Parsoid
Feb 3 2021
Dec 16 2020
For the record, just reverted to using the external parsoid service and it works fine.
Code hack for fixing the issue:
- As far as I can tell, there is not such thing as AllowEncodedSlashes for IIS;
Dec 15 2020
hi @ti_infotrad – would it be accurate for us to think this issue is resolved?
Yes
Dec 14 2020
Found an alternative solution that
Dec 11 2020
I disagree with this task being marked as resolved. This was working fine with the external Parsoid service and got broken in the virtual rest service in 1.35. It does not make sense to me that the web server configuration should be changed to accomodate what I call a bug. Of course, I am interested in seing it fixed properly for IIS (T265614) but I think my point about changing the configuration of the web server to fix it is valid.
That might be why the rest of your site worked fine? Perhaps the API code doesn't try to detect the fallback encoding, and perhaps it should (but it might also have been left off intentionally, as this kind of magical detection could also prove problematic in an API).
Dec 10 2020
Likely answer: bug in FastCGI module implementation (https://support.microsoft.com/en-us/help/2277918/fix-a-php-application-that-depends-on-the-request-uri-server-variable)
In any event, adding the registry key
If anyone can explain to me why the change below seems to fix the issue, I will be extremely happy :-)
Running into a similar issue. However, in my case, I cannot even create a page with a "/" in it, same error as above (404). Still looking for a solution. Although I understand IIS is not the mainstream web server used with MediaWiki, it would be nice to be able to get this one fixed - any site running on IIS and allowing subpages is going to encounter this issue.
Dec 9 2020
Another test: created a page with accents in the title without using VisualEditor, it works fine and the page title in the DB is utf-8 encoded.
Dec 8 2020
I have checked my php settings (default-language is utf-8) and the globalization for IIS and everything seems to be fine.
The input on the POST line below is UTF-8.
I will look into it. But note I did not run into any issues with VisualEditor when running MW 1.27.3 or MW 1.33
The following code seems to be fixing it.
Oct 12 2020
Oct 9 2020
Also, although normal links do not get corrupted in the same way, editing them still tags the "index.php?title=" in the input box as an invalid link (see screenshot below)
The following experimental modification (removing "index.php?title=" from the resource attribute) seems to fix the issue for my installation:
Oct 7 2020
@D3nnis3n For what it is worth, in 1.33, I had to modify the timeout in resources/src/mediawiki.api/index.js to fix a timeout for a page with lots of media links (https://www.mediawiki.org/wiki/Topic:Uqam69xv019t4r3m). Not sure if it applies to 1.35 or to your configuration.
Oct 5 2020
For the record, I found the following piece of code in extensions/VisualEditor/includes/VisualEditorHooks.php
OK so it looks like I was able to fix my issue by simply commenting out the cookie forwarding option in my LocalSettings
More debugging info:
Oct 4 2020
The plot thickens.
As per https://www.mediawiki.org/wiki/Extension:VisualEditor#Setting_up_VisualEditor
Follow up my post:
- Turned off all extensions (except VE), same issue
Oct 2 2020
Reporting same issue. I just upgraded from 1.33 to 1.35 and so I have some existing pages to test with.
Feb 11 2020
Jan 24 2020
Thanks for the update. With respect to server timeout, you are right:, I also had to change the IIS timeout for this change to function.
Jan 8 2020
Sorry for the delay. I confirm the fix functions as expected.
Nov 15 2019
Yes I will.
Nov 6 2019
The code change below (implemented in extensions/VisualEditor/modules/ve-mw/init/styles/ve.init.mw.Target.css) fixes the issues my clients are experiencing
Oct 31 2019
To be more specific, the line that causes the issue described above is
tr:not( :first-child ),
Commenting out following section in resources\src\jquery\jquery.makeCollapsible.styles.less fixes the issue
Here is a sample code where the client is experiencing an issue:
Still running into issues, collision with collapsible table option in VE. I will try and post an example.
It seems to work nicely. One question, though: was the change designed to show the inactive [Expand] toggle?
Oct 30 2019
- In 1.27, when editing a collapsible div, the collapsed element was automatically expanded (and the js toggle disappeared)
- In 1.33, when editing the same collapsible div, the collapsed element remains hidded and what looks like the js toggle is displayed but it does not work (i.e clicking on it does nothing)
Oct 23 2019
Sep 27 2019
OK so the change describe by the diff below seems to work, at least for me...
In file modules\ve-mw\ui\contextitemsve.ui.MWInternalLinkContextItem.js
Sep 23 2019
- Your fix is for media dialogs; the issue I described is for internal link dialogs (see screenshot below):
I may be able to use your method to fix the related code, looking into it.
Sep 19 2019
Yes:
- Excerpt or JSON returned by api.php (see Special:FilePath string)
Sep 12 2019
Mar 6 2019
For the record, this issue still exists in MW 1.27.3 but seems to be fixed in later versions [1.33] (confirmed by testing at https://test.wikipedia.org/w/index.php?title=T176657&action=history). Anyway of backporting the fix?