-
2012-09-24
phallobst
I don't know if this counts as a bug or just as "works as designed"...
Suppose you are using a page "foo:sidebar" with the new "dokuwiki" template that has two links to "foo:page1" and "foo:page2". When "page1" is displayed, the "page1" link in the sidebar is displayed as bold text (just as expected). However, when switching to "page2", the cached version of the sidebar is used, so the bold link is not the "page2" one. (If you go to "page2" first, then that link is permanently bold.)
Using "~~NOCACHE~~" in the sidebar solves this problem, but I don't know if that is the way it is supposed to be done.
The other solutions I can think of is either not to use the "curid" feature in the sidebar at all (obviously not good) or to have a separate sidebar cache for each page.
-
2012-09-24
ach
As far as I know this is the intended behaviour. Although I can see how not manually adding the no caching instruction would be beneficial, I also think that it's simply not feasible to "have a separate sidebar cache for each page". It's also overhead, because not everyone has a dynamic navigation in their sidebar. And I think there is no other solution.
But I don't know enough about the caching system to be sure. So, someone else should decide on this.
-
2012-10-06
Michitux
This is a known limitation of the caching system. However it is possible to change this. We have the information which links exist on a page available in the cache handler so we could simply use another cache file when $INFO['id'] is linked in the page, i.e. in this case we could append $INFO['id'] to the cache identifier (separated in some way of course). That way a different cache file will only be used when there is actually a link that is affected by the curid class in the page. This could also be implemented in a plugin. More complex navigation plugins like indexmenu do something similar in order to have a cache file per user or group (can be configured) while the simpler navigation plugins like simplenavi simply disable the whole sidebar cache.
As I'm loading external feeds in my sidebar page disabling the sidebar cache has a massive impact on the performance of my wiki so I think we should neither disable the cache by default nor should we create a cache file per page.
-
2013-02-20
Michitux
I wonder if there is anything that speaks against simply moving the addition of the curid span past the caching step. We are already adding the section edit buttons later in html_secedit and there could be a similar function that adds the curid span. It should be rather easy to generate a regex that matches all links to the current page and then add the curid span. We could also do a very simple text match if there is a link to the current page at all (in most pages there won't be any links to the current page) and only apply the regular expression if there is actually a link. In fact the link information should even be recorded in the metadata but I fear that most (especially dynamic) navigation plugins won't add this information to the metadata so it won't help for this use case.
-
2013-02-20
andi
I'd prefer removing the curid stuff from the PHP completely and move it to javascript.
-
2013-02-21
ach
Meh to JavaScript.
-
2016-06-27
Klap-in
-
2016-06-27
Klap-in
Discussion is now also in Github issue tracker