Description

Backlinks have been broken since subpages were introduced.

Backlinks as in 1.3.3 are quite broken; only the last path segment is searched for. So if we want to get the backlinks of HilfeAllgemein/FragenUndAntworten, get all pages that contain /FragenUndAntworten. If you have parallel structures like A/FragenUndAntworten, B/FragenUndAntworten, etc., this would yield many false positives.

MoinMoin could build a fulltext query. But its length will quickly exceed the limit of GET request lines (i.e. the querystring gets too long), besides that it looks like an unneeded way of indirection. The query would look like this: ("HilfeAllgemein/FragenUndAntworten" or (t:r:^HilfeAllgemein and "/FragenUndAntworten") or (t:r:^HilfeAllgemein/ and "../FragenUndAntworten")

Realising that this is O(n^2), i.e. it will get much faster complex than your pagename, you may even notice that this way of searching hides other important links - all links that cannot be found by a simple string search. This might include macros that issue links or other parsers that use a different link format.

So how about introducing a new search modifier? My current patch allows to search using this term: linkto:HilfeAllgemein/FragenUndAntworten. Now think about grouping this term - like if you want to know which page links to page A and B - that is quite simple using this scheme.

Example

Click onto the title of this page.

Details

This wiki.

Workaround

Build a query like above and wonder why it still does not catch all backlinks.

Use the new backlink system, see the patch.

Reorder your world view to just include forward references.

Patch

See backlinks.patch

This patch is not acceptable, we will not add a new search modifier as part of a bug fix release. Its a major user interface change. The fix should use the current code.

-- NirSoffer 2005-02-10 23:58:36

Discussion

This is possible, but it is much simpler to create a new action, "backlinks", that does this search. Example of short and nice url:

http://wiki.example.com/PageName?action=backlinks

We should not modify the search syntax to solve specific problem. We should change search syntax only if it is really needed by the users - and after much thought.

• So you do not like to see new search terms? This is an enhancement, no change that breaks nearly every search query (like it happened for 1.2 --> 1.3). First, I thought about writing an action. But it has several drawbacks and is less user-friendly than adding a search term.

  • I would like to see new search terms, and linkto might be useful, but this is not related to this issue. The issue is solve one problem without unneeded dependencies.

I just tried this in my test wiki, the results are so broken its pathetic. We must fix this as soon as possible. Seems that using the full page name for the search is a trivial fix. It will ignore ../ links and such but that better then huge amount of false positive results. Another option is to look into the pagelinks cache that each page has, maybe this cache even expand those ../ links?

• Filtering the results gives wrong results as well. Wikis that use many relative links would see it as a big drawback. Umm, re your second proposal: you may want to look at the text above and at my patch, I do exactly that.

If the second approach works, we should simply add an action "backlinks" that will run this code instead of full text search. It should be also faster. -- NirSoffer 2005-02-11 18:16:07

• And why don't you like the search modifier? I do not see any disadvantages compared to an action.
  • Because we don't want to change search interface now, and will have to think about this before making any change.

    • Compared the occasions you broke the interface (mainly the call interfaces to some methods) after 1.3.0 was released, this is a vital enhancement I do not say that this would have been avoidable in some cases.

      • There is a difference between API changes and user interface changes. Only few users are effected by API changes, but all users are effected by user interface changes. If we add now linkto, we can't change it later, since users will see at as regression. Adding an action is transparent to users.

        • Where do you see a regression? This is a change, but a change that does not really break many queries compared to the 1.2 --> 1.3 transition.

          • The regression will come in few month when we will try to fix the stupid additions we did without thinking about them in the first place. Thats the reason we should not add stuff unless its needed, and in this case, its clear thats its not.
            • I have talked with a few people about this. You are the only one who thinks that this is not needed. And I do not see why this is a stupid addition ...

Plan

• Priority: High
• Assigned to:
• Status: Fixed in patch-623

CategoryMoinMoinBugFixed CategoryRelease1.3.4