Relative links resolve outside of collectives

[max-nextcloud]

If the link contains ?fileId=... in the search query, Collectives should be able to still resolve it as it searches for matching fileIds as a fallback if the path lookup doesn't find a page.

The problem is the relative form ../../Pagename?fileId=23712 will be resolved by the browser first. And the path ../../ may bring the browser to a point, where there is no Collective any longer.

Example:

The document is at https://domain.example/apps/collectives/Collective-2/Page-226741. And now there is a link ../../Pagename?fileId=23712 in this document.

The browser will resolve the link to https://domain.example/apps/Pagename?fileId=23712 - and this will not work, since now only /apps/Pagename is requested and not even Collectives. And even if it would be https://domain.example/apps/collectives/Pagename?fileId=23712 then Collectives would produce an error that there is no Collective named "Pagename".

I don't know which version created relative links, but I believe this was not done manually but using the SmartPicker. Maybe I will check this using an older version on my test server if possible.

Originally posted by @arnowelzel in #1879

[max-nextcloud]

My understanding is that we are rewriting links when rendering them. So we should be able to handle this case.

[arnowelzel]

My understanding is that we are rewriting links when rendering them. So we should be able to handle this case.

Unfortunately, this is not the case. The links where created as shown: https://domain.example/apps/collectives/Collective-2/Page-226741/../../Pagename?fileId=23712. I had to manually correct some links like this. But I still have to investigate, how these links got created in the first place.