X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/d7eca43103a47f0184edb65e2bcf4240f795e3c6..e71622d233660b5ba305d68e586d7d14ff2124e6:/doc/plugins/trail/discussion.mdwn?ds=sidebyside diff --git a/doc/plugins/trail/discussion.mdwn b/doc/plugins/trail/discussion.mdwn index 4a12aa8e0..6b1b58bd8 100644 --- a/doc/plugins/trail/discussion.mdwn +++ b/doc/plugins/trail/discussion.mdwn @@ -31,7 +31,7 @@ or trail member has actually been edited. For it to be useful for `trail`, the `prebuild` hook has to run after both pagespecs and sorting work. The other use case -I've seen for a similar hook was for Guiseppe Bilotta to +I've seen for a similar hook was for Giuseppe Bilotta to sort an inline-of-inlines by mtime of newest post, but that can't be the same hook, because it has to run after pagespecs work, but before sorting. @@ -42,7 +42,8 @@ work, but before sorting. > prebuild, but dunno that the hook prolieration is worth the minor cleanup > it allows in trail. --[[Joey]] ->> Hmm, t/trail.t is failing several tests here. --[[Joey]] +>> Hmm, t/trail.t is failing several tests here. To reproduce, I build the +>> debian package from a clean state, or `rm -rf .t` between test runs. --[[Joey]] 
 t/trail.t .................... 1/? 
@@ -59,7 +60,126 @@ t/trail.t .................... 1/?
 #   Failed test at t/trail.t line 231.
-> These all seem to relate to sorting. --[[Joey]] +> Looking at the first of these, it expected "trail=sorting n=sorting/new p=" +> but gets: "trail=sorting n=sorting/ancient p=sorting/new" +> +> Looking at the second failure, it expected "trail=sorting n=sorting/middle p=sorting/old$" +> but got: "trail=sorting n=sorting/old p=sorting/end" +> +> Perhaps a legitimate bug? --[[Joey]] ->> This was reproducible once when I build the debian package, but ->> now I cannot reproduce it. --[[Joey]] +>> I saw this while developing, but couldn't reproduce it, and assumed +>> I'd failed to update `blib` before `make test`, or some such. +>> In fact it's a race condition, I think. +>> +>> The change and failure here is that `sorting.mdwn` is modified +>> to sort its trail in reverse order of title. Previously, it +>> was sorted by order of directives in the page, and secondarily +>> by whatever sort order each directive specified (e.g. +>> new, old and ancient were sorted by increasing age). +>> `old` appearing between `new` and `ancient`, and `new` appearing +>> between `end` and `old`, indicates that this re-sorting has not +>> actually taken effect, and the old sort order is still used. +>> +>> I believe this is because the system time (as an integer) remained +>> the same for the entire test, and mtimes as used in ikiwiki +>> only have a 1-second resolution. We can either fix this with +>> utime or sleep; I chose utime, since sleeping for 1 second would +>> slow down the test significantly. Please merge or cherry-pick +>> `smcv/trail-test` (there's only one commit). --[[smcv]] + +---- + +[[!template id=gitbranch branch=smcv/ready/trail author=smcv]] + +Some later changes to trail: + +* Display the trail links at beginning/end of default `page.tmpl` + as suggested on IRC +* Improve CSS, particularly in blueview and goldtype themes + ([example](http://blueview.hosted.pseudorandom.co.uk/posts/second_post/)) +* Fix a possible bug regarding state deletion + +--[[smcv]] + +> Applied --[[Joey]] + +---- + +### Trail plugin creates unexpected interdependencies? +*(ikiwiki master branch 2014-06-06 also tested with 3.20140228 release)* + +I noticed the problem when using the [[/plugins/contrib/album]] plugin but a bit of testing revealed that the [[trail]] plugin, which is used by [[/plugins/contrib/album]] may be the cause of the problem. + +On a site with the following structure where all albumN.mdwn files have the `\[[!inline pages="page(./album01/*)" trail="yes"]]` directive set. All albumN pages and imgN pages get rebuilt whenever any one of the albumN or imgN pages are changed and the command `ikiwiki --setup wiki.setup --refresh --verbose` + is issued. + + /index.mdwn Contains no links maps or inlines + |-album01.mdwn \[[!inline pages="page(./album01/*)" trail="yes"]] + |-album01/ + | |-imgA.mdwn + | |-imgB.mdwn + | + |-album02.mdwn \[[!inline pages="page(./album02/*)" trail="yes"]] + |-album02/ + | |-imgC.mdwn + | |-imgD.mdwn + | + |-album03.mdwn \[[!inline pages="page(./album03/*)" trail="yes"]] + |-album03/ + | |-imgE.mdwn + | |-imgF.mdwn + +Changing the index.mdwn page also triggers a full rebuild of all pages with [[trail]] directives. My sites tend to look like the above but with double digit numbers of files in at each level. Changing any file then means a full rebuild of a rather complex site which takes a long time. + +My setup and test may very well have mistakes but perhaps someone using the trail plugin could check (using the --verbose flag) if all their trails get rebuild when changing only one. I also find it curious that changes to the parent index.mdwn page triggers the same behaviour. + +I have removed a similar comment from the album discussion. + + --[[kjs]] + +> I would expect changing imgE.mdwn to rebuild album03.mdwn (because album03 +> inlines imgE) and vice versa (because imgE uses album03's \[[!meta title]]). +> +> I would not expect changing imgE.mdwn or album03.mdwn to affect album02 +> or imgC. +> +> I would also not expect changing index.mdwn to rebuild anything else +> unless there is a valid dependency reason to do so. +> +> Can you reproduce this problem in a wiki that does not contain anything +> private, and publish its git repo somewhere? (I realise photo galleries +> tend to be more personal/private than typical wikis, so you don't +> necessarily want to link the real thing - that's why my album demos +> tend to use dummy data). --[[smcv]] + +>> I was expecting the same depends pattern you describe. +>> My photo wikis are mostly public so I've set up a publicly accessible repo +>> (update-server-info type, git clone the first link below), a low-res copy of +>> the underlay and a quick sanitized setup file. + +>>* [[http://www.kalleswork.net/downloads/stockholm/.git]] +>>* [[http://www.kalleswork.net/downloads/stockholm.underlay.tar.gz]] +>>* [[http://www.kalleswork.net/downloads/stockholm.setup]] + +>> It might be a bit unwieldly and the site itself at [[http://stockholm.kalleswork.net]] +>> uses a few tweaks to the album templates and css, but I don't currently +>> have access to the machine where I setup a cleaner debug wiki to test. +>> (travelling atm). The images will likely be distorted due to the up scaling +>> bug in the [[img]] plugin but other than that it should work. + +>> Let me know if you need anything else. Would be great to hear it works +>> as expected for everyone else ;) --[[kjs]] + +>>> Hmm. Investigating the indexdb: +>>> +>>> perl -le 'use Storable; my $index = Storable::retrieve("stockholm/.ikiwiki/indexdb"); use Data::Dumper; print Dumper $index' |less +>>> +>>> indicates that `20130504` depends on `internal(*)` and so does `20130505`. +>>> +>>> After adding some `Carp::cluck` calls to the bits of IkiWiki.pm that add +>>> dependencies, this turns out to be two similar issues, in `album` and +>>> `trail`: they each use `pagespec_match_list` with the pagespec +>>> `internal(*)` in order to apply a trivial filter (accept everything) +>>> to an existing list for its side-effect of sorting that list. +>>> Bug filed as [[bugs/trails depend on everything]] --smcv