Comment 2 for bug 1357402

Hmm, I originally thought: "We could move the work for this to an Ajax request after page load, which would be faster but we'd still have some ugly object cache pain." This was going to be our next step on the FILES "Move To" thing. But I suspect this work is being done in the page template, so the work would increase to throw jQuery at it.

I think I should assign this to Nat and see how he feels about the feature-removal-for-performance tradeoff. Agree?

--Paul

On Aug 20, 2014, at 3:11 PM, Chris Rossi <email address hidden> wrote:

> Right. It took some staring, but I found it. At some point, years ago,
> we were asked to use fuzzy matching for wiki links. So, the name
> someone might type for a link might differ from the name of an actual
> wikipage in some ways but still match. Unfortunately the code to handle
> this happens when rendering the wiki page--for every link it iterates
> over all of the pages in the wiki until it finds a match and inserts a
> link to the actual wiki page.
>
> Arguably, this feature wasn't a great idea to begin with. I'm not aware
> of other wiki's that are as flexible in this way.
>
> This may not really be super low hanging fruit, because it would involve
> rolling back that feature such that the name used in the link must
> exactly match the name/id of the wiki page being linked to. That would
> be fantastic for performance, but not so great in terms of changing how
> wikis work and making them somewhat harder to use. It would have been
> much easier, politically, to not allow the flexibility in the first
> place than it would be now to take it back.
>
> The alternative is to brainstorm ways to render the wiki pages more
> efficiently. Perhaps we could store link->document mapping behind the
> scenes somewhere, so we only have to connect a link to a document once,
> and then that information is stored. There may (probably) be edge cases
> that I haven't thought of with such a scheme. But, probably, that's
> what I would try to do.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1357402
>
> Title:
> Make wiki pages not load every wiki page
>
> Status in KARL3:
> In Progress
>
> Bug description:
> Shane wrote:
>
> It seems that wiki pages load the entire wiki on every page load.
> That's obviously expensive and could be low hanging fruit.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl3/+bug/1357402/+subscriptions