Wiki pages in subdirectories fail to render

Since updating to our docker based GitLab instance to 14.10.2 all wiki pages that are not at the root of the wiki [1] no longer render and instead show an alert box with the message:

The content for this wiki page failed to load. To fix this error, reload the page. 

This applies to existing pages as well as newly created ones. Existing and newly created pages at the wiki root work fine, e.g.
https://gitlab.example.com/example-group/example-wiki/-/wikis/home renders fine, while
https://gitlab.example.com/example-group/example-wiki/-/wikis/subdirectory/testpage does not.

I don’t see anything obvious in the logs, but I’m also not sure what to look for. Any suggestions how to narrow down which component is failing? Thanks!

[1] this is a small, internal setup and we really only use the project wiki of a single project.

2 Likes

Hello. I’ve noticed this problem too. While editing the page, it looks okay and even preview is fine, but link to it does not.

Does any other have this problem too? Thanks in advance for answers.

Edit: version is: v14.10.2-ee

Yes, I’ve had the same problem after upgrading to 14.10.2-ce. I’ve since upgraded to 15.0.0 and the problem remains.

I’ve raised an issue: https://gitlab.com/gitlab-org/gitlab/-/issues/363231

I should add that I see this problem on my production Debian 9 instance, but not on my test instance which runs Debian 11.

Hello, since mid of may, I was also looking for other people meeting this problem: happy to find you here and to see your issue on gitlab.com to follow the topic. As temporary work around in one of my wiki with few pages, I have moved the wiki-pages under the root by creating new pages and copy-pasting the markdown content, but I cannot do that on wikis with too much pages. Expecting a coming bug-fix soon ! gitlab-ce 14.10.3-ce.0 on ubuntu 20.04 LTS.

In my case rendering stopped because of introduction of API use.
Due to infrastructure proxy escaped url encoded requests, which then did not match wiki subdir entries anymore.
Could you check gitlabs nginx access log and post the api get request, e.g.:

tail /var/log/gitlab/nginx/gitlab_access.log
X.X.X.X - - [26/May/2022:08:45:03 +0000] “GET /gitlab/assets/icons-f305926186cfc3bb530f27269d545937c385578ba62adb0088d74f0d2d02cb56.svg HTTP/1.1” 200 39976 “https://XXX/YYY/MyProjectName/-/wikis/MyProjectWiki/REST-Calls” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0” -
192.168.10.100 - - [26/May/2022:08:45:03 +0000] “GET /gitlab/api/v4/projects/11/wikis/MyProject%2FREST-Calls?version=5adb4f0fa350bf4322d5db0778ab4cbc2e7ce84c&render_html=true HTTP/1.1” 200 415 “https://XXX/YYY/MyProjectName/-/wikis/MyProjectWiki/REST-Calls” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0” 1.61

Espacially check url encoding, in example above, the subdir path must be url encoded:
MyProject%2FREST-Calls

FWIW I’m seeing 404 in logs/nginx/gitlab_access.log when accessing a wiki page in a subdir:

"GET /api/v4/projects/5/wikis/TestFolder/TestPage?version=8c44a01c0a94cb3feefb4732122be4acc80dbde1&render_html=true HTTP/1.0" 404 25 "https://gitlab.example.com/test-group/test-wiki/-/wikis/TestFolder/TestPage" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0" -

I guess it should render fine if:

"GET /api/v4/projects/5/wikis/TestFolder%2FTestPage?version=8c44a0...

In case that your gitlab instance is behind proxy, it might be worth to check that proxy it is not URL encoding the request.