Support for redirects

[claudiofreda]

When a page is moved, it leaves behind an empty page. This can easily break hyperlinks and penalize the wiki in search rankings.

Obviously, this can be achieved by the administrator by making a 301 redirect in a reverse proxy like nginx. However it would be a lot more user friendly and less error prone if Otterwiki automatically managed page redirects when a page is moved.

[deseven]

Yes, I wanted to raise this issue for some time, but I keep forgetting :)

The way to fix it could be tricky, we will either need to:

• browse git tree for the path on every unknown page load (might be costly)
• built a redirect tree on wiki startup and update when needed
• keep internal redirect rules in sqlite

I'd like to solve this, but let's brainstorm a bit first.

For now, indeed, the reverse proxy helps. For reference I use this (nginx):

map $request_uri $redirect_uri {
    ~^/Home/$ /;
    ~^/Home$  /;
    ~^/Some/Old/Page/Path(.*)$     /Some/New/Page/Path$1;
}

server {
    ...

    if ($redirect_uri) {
        return 301 $redirect_uri;
    }

    ...
}

[claudiofreda]

I think the best option among the ones you quoted is to keep redirect rules in sqlite, automatically add a redirect rule on moving a page, and show some kind of interface for editing them in the admin panel.

[deseven]

Nah, after thinking about it more, I'd say keeping it in the DB is wrong: the wiki might be edited externally or be migrated to the new instance without keeping the existing database.

I think a combo between the first two might work:

1. On page request if such page does not currently exist check via git if there was something with this path before.
2. If there was, redirect to that page.
3. If there wasn't, return 404.
4. In both cases cache the result in a map (old_path: new_path).

[claudiofreda]

Just spitballing here, but maybe it's simpler to just keep a file with the redirects in a top folder in git in some format like YAML?

[deseven]

Hm, but if we will require to edit some file then what's the point? :D To add some more redirects to nginx you also just edit a file. Of course this will make us webserver-agnostic, but is it good enough?

@redimp would love to hear your take on this when you have a minute

[claudiofreda]

I think you may be misunderstanding: the idea is that the config file in the repository would be automatically edited when you move a page, but it'd also be openly available for modification in case the user wants to add additional redirects or remove the existing ones.

Having the redirects be a single file simplifies the editing experience (as it can just be the same as editing any other text file).

But again, it's just a spitball. Anything that solves the problem is fine by me.

---

Regarding webserver-agnosticism---I do think there is some value in providing a solution that's not dependent on running behind a reverse proxy. For example, in my selfhosting scenario I'm directly pushing an otterwiki instance through a Cloudflare tunnel. At the moment, I have to run it behind a nginx instance just to have redirection, and I'd rather get rid of the extra complexity.

Considering otterwiki is trying to be a easy to set up wiki, I do think that it fits within the scope of the project.

[redimp]

Hey @claudiofreda, thank you for bringing this up!

My thought process matches @deseven's process and haven't come to a conclusion yet.

(1) Tracking renamed pages and adding redirects to the database and looking this up in case of not finding the page in the storage sounds solid to. Admins can control what should be redirected.

(2) Using git to check if a file has been renamed and redirecting to the new name also sounds nice. And this would work "automagically". Have to run some tests. From the first look

git log --oneline -m --first-parent --diff-filter=R --name-status

seems not to be costly.

Will come back to you!

[deseven]

(2) We can also cache it, so only one git call per unique non-existent page path per wiki restart. Unless I'm missing something, that cache doesn't even need to be checked for validity - if the source page appears again with the old path we will serve it normally (a simple file existence check that we already do), if the target page will be moved or deleted this will again fall into normal processing logic.

The question is would admins want to influence this mechanism manually? I don't see many reasons for anyone to want that to be honest. The repository is our source of truth after all, adding support for renames is just a deeper integration with it. If someone would want it anyway, technically this could be added as a separate mechanism on top of the existing one, for example an admin page where you can set up custom redirects that override the ones dictated by the repo.

[claudiofreda]

@redimp do let me know if I can contribute in any way with the implementation.

[skirmess]

Please make this an option. I would like to see #210 implemented but I would not like redirects for renamed page. If you go to the old URL of a page that was renamed, I would like to see the "Do you want to create it?".

[redimp]

@skirmess request is valid, this should be optional when implemented.

Even when enabled, I think it should show that you have been forwarded to another page. This info should include a link to the old name and if clicked should not forward to the nw page, but offer to create a page with the old name.