In T386002#10537242, @matmarex wrote:

I can't reproduce on a new 1.43 wiki: https://patchdemo.wmcloud.org/wikis/c3cedb3da2/

Maybe this is Windows-specific, or maybe only happens in some specific configuration.

In T386002#10537242, @matmarex wrote:

I can't reproduce on a new 1.43 wiki: https://patchdemo.wmcloud.org/wikis/c3cedb3da2/

Maybe this is Windows-specific, or maybe only happens in some specific configuration.

@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 :-)

For now, fixed it by hardcoding location in

In T274916#6836521, @Aklapper wrote:

Hi @ti_infotrad, thanks for taking the time to report this!
I assume this is about https://www.mediawiki.org/wiki/Manual:Interface/Sidebar#Section_order_(elements) .

• 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 :

@Johnywhy, you just need to follow the installation instructions given at https://www.mediawiki.org/wiki/Extension:VisualEditor#Linking_with_Parsoid

In T261921#6799600, @Johnywhy wrote:

In T261921#6685679, @ti_infotrad wrote:

This was working fine with the external Parsoid service

Is it possible to use the external Parsoid service with MW 1.35?

In T269673#6693674, @matmarex wrote:

Per above, it was a configuration issue, not a VisualEditor bug.

I documented this on https://www.mediawiki.org/wiki/Extension:VisualEditor#Troubleshooting (https://www.mediawiki.org/w/index.php?title=Extension:VisualEditor&diff=4285920&oldid=4285674). @ti_infotrad Please have a look and correct/improve that if you can.

In T270328#6696620, @matmarex wrote:

This sounds the same as T269673?

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;

hi @ti_infotrad – would it be accurate for us to think this issue is resolved?

Yes

Found an alternative solution that

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).

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.

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.

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.

In T265144#6534835, @matmarex wrote:

Parsoid and VisualEditor basically assume that you have short URLs set up on your wiki (or at least that you have $wgUsePathInfo enabled). I've recently ran into similar problems (https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/623873 / T261711). This would probably take lots of work to fix and I don't really see it happening… Sorry.

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:

@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.

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:

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

Reporting same issue. I just upgraded from 1.33 to 1.35 and so I have some existing pages to test with.

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.

Sorry for the delay. I confirm the fix functions as expected.

Yes I will.

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

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?

• 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)

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

• Your fix is for media dialogs; the issue I described is for internal link dialogs (see screenshot below):

Yes:

• Excerpt or JSON returned by api.php (see Special:FilePath string)

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?