Page MenuHomePhabricator

Relative wiki links
Closed, ResolvedPublic

Description

Most of our users create new wiki pages like this:

  1. Edit a Wiki page
  2. Insert [[new page name]]
  3. Click the resulting link
  4. Create page

Many assume that [[new page name]] will be a relative link, so that writing it on /w/the/ will create /w/the/new_page_name/. This in turn messes up the wiki, because very generic page names will be used, which then leads to unexpected conflicts.

Apart from me educating my users, is there anything planned to simplify this workflow? E.g. make such links relative by default or provide a shortcut for relative wiki links?

Event Timeline

devurandom raised the priority of this task from to Needs Triage.
devurandom updated the task description. (Show Details)
devurandom added projects: Phriction, Remarkup.
devurandom added a subscriber: devurandom.

This comes up quite regularly among my users. Even for me it is rather annoying to always have to type full paths - the common case in our (including my) workflow seems to be to link to sub-pages, which becomes unnecessarily cumbersome in Phriction. Additionally this is contrary to experience with well known filesystem functions like symlinks, for example.

Thus I would urge again to have at least an option to make these links relative by default, and require absolute paths to be prefixed with /.

ivo added a subscriber: ivo.

@epriestley Can I write and submit a patch for this?

Roughly my thoughts are:

  • When a wiki link starts with ./, treat it as relative.
  • For relative links, removing the leading ./ and split on /.
  • Get the current Phriction path as the starting point, and split on /.
  • Append each item from the relative link array onto the Phriction path unless it's .., in which case pop the last item.
  • Join it all back together again with / to convert it into an absolute link.
  • Let that absolute path go through the rest of the pipeline.

That seems reasonable to me. I like using ./ to opt in to this and not making it the default.

(If the current page isn't a Phriction page, I guess just don't mark the thing up?)

Yeah that was my plan; relative links on non-Phriction pages just won't get marked up.

Cool. Yeah, that all sounds good to me.

Also, I don't know if this actually ends up being adjacent or if we even have a task for it, but three possibly-related things are:

  • If /w/x/ exists and is titled "History of X", it would be nice if [[ x ]] generated a link with the text "History of X" instead of a link with the text "x". Today, you must do [[ x | History of X ]] to get the proper link text.
  • If /w/y/ does not exist, it would be nice if [[ y ]] generated a red link to indicate that the page does not exist.
  • Stretching here, but if /w/z/ exists and the viewer does not have permission to see it, it would be nice if [[ z ]] generated a grey link with a icon.

I don't know if those are like 5 seconds of work or in a totally unrelated section of the codebase.

  • If /w/x/ exists and is titled "History of X", it would be nice if [[ x ]] generated a link with the text "History of X" instead of a link with the text "x". Today, you must do [[ x | History of X ]] to get the proper link text.

Ah yeah, I was going to file a task about that; the existing behaviour annoys on a daily basis.

It's pretty easy to change, it's right next to the relative link code where it determines the default name; I'll look at the object lookup remarkup rule (the one that is used for e.g. T1234) to see what the most optimal way of querying the title of the page is.

  • If /w/y/ does not exist, it would be nice if [[ y ]] generated a red link to indicate that the page does not exist.
  • Stretching here, but if /w/z/ exists and the viewer does not have permission to see it, it would be nice if [[ z ]] generated a grey link with a icon.

If I do the title querying thing, then we basically get these for free.