X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/ba71687077f0acd902294f9081eff11f7e843532..11787065a133f4884dfb8a8dc8a5ecacfe2fed63:/doc/bugs/bestlink_change_update_issue.mdwn diff --git a/doc/bugs/bestlink_change_update_issue.mdwn b/doc/bugs/bestlink_change_update_issue.mdwn index fee65c0de..8a526e821 100644 --- a/doc/bugs/bestlink_change_update_issue.mdwn +++ b/doc/bugs/bestlink_change_update_issue.mdwn @@ -1,16 +1,29 @@ * Has bugs updating things if the bestlink of a page changes due to adding/removing a page. For example, if Foo/Bar links to "Baz", which is Foo/Baz, and Foo/Bar/Baz gets added, it will update the links in Foo/Bar - to point to it, but will forget to update the linkbacks in Foo/Baz. + to point to it, but will forget to update the backlinks in Foo/Baz. -* And if Foo/Bar/Baz is then removed, it forgets to update Foo/Bar to link - back to Foo/Baz. + The buggy code is in `refresh()`, when it determines what + links, on what pages, have changed. It only looks at + changed/added/deleted pages when doing this. But when Foo/Bar/Baz + is added, Foo/Bar is not changed -- so the change it its + backlinks is not noticed. -As of 1.33, this is still true. The buggy code is the %linkchanged -calculation in refresh(), which doesn't detect that the link has changed in -this case. + To fix this, it needs to consider, when rebuilding Foo/Bar for the changed + links, what oldlinks Foo/Bar had. If one of the oldlinks linked to + Foo/Baz, and not links to Foo/Bar/Baz, it could then rebuild Foo/Baz. -Still true in 1.43 although the code is much different now.. + Problem is that in order to do that, it needs to be able to tell that + the oldlinks linked to Foo/Baz. Which would mean either calculating + all links before the scan phase, or keeping a copy of the backlinks + from the last build, and using that. The first option would be a lot + of work for this minor issue.. it might be less expensive to just rebuild + *all* pages that Foo/Bar links to. -> Still true as of 031d1bf5046ab77c796477a19967e7c0c512c417, -> and now this same problem also affects link dependencies. + Keeping a copy of the backlinks has some merit. It could also be + incrementally updated. + +* And if Foo/Bar/Baz is then removed, Foo/Bar gets a broken link, + instead of changing back to linking to Foo/Baz. + +This old bug still exists as of 031d1bf5046ab77c796477a19967e7c0c512c417.