diff options
Diffstat (limited to 'doc/plugins')
| -rw-r--r-- | doc/plugins/contrib/album.mdwn | 114 | ||||
| -rw-r--r-- | doc/plugins/contrib/album/discussion.mdwn | 227 | ||||
| -rw-r--r-- | doc/plugins/trail/discussion.mdwn | 67 |
3 files changed, 288 insertions, 120 deletions
diff --git a/doc/plugins/contrib/album.mdwn b/doc/plugins/contrib/album.mdwn index 7344a158e..c2f991d5a 100644 --- a/doc/plugins/contrib/album.mdwn +++ b/doc/plugins/contrib/album.mdwn @@ -11,44 +11,29 @@ This plugin automatically enables the [[filecheck]], [[img]], [[inline]], [[trail]] and [[transient]] plugins. The [[meta]] plugin is also recommended. -## Changing the templates - -When a viewer page is generated or inlined into an album, the template can -contain these extra variables: - -* `<TMPL_VAR ALBUM>` - page name of the album -* `<TMPL_VAR ALBUMURL>` - relative URL to the album -* `<TMPL_VAR ALBUMTITLE>` - title of the album, usually taken from - a [[ikiwiki/directive/meta]] directive -* `<TMPL_VAR CAPTION>` - caption for the image -* `<TMPL_VAR THUMBNAIL>` - a small [[ikiwiki/directive/img]] for the image -* `<TMPL_VAR IMAGEWIDTH>` - width of the full-size image in pixels -* `<TMPL_VAR IMAGEHEIGHT>` - height of the full-size image in pixels -* `<TMPL_VAR IMAGEFILESIZE>` - size of the image, e.g. `1.2 MiB` -* `<TMPL_VAR IMAGEFORMAT>` - format of the image, typically `JPEG` - -The template for the viewer page can also contain: +## Demo -* `<TMPL_VAR IMG>` - a large [[ikiwiki/directive/img]] to display the image -* `<TMPL_VAR PREV>` - a link to the previous viewer, typically with a - thumbnail -* `<TMPL_VAR NEXT>` - a link to the next viewer, typically with a - thumbnail +* [HTML page of thumbnails](http://ikialbum.hosted.pseudorandom.co.uk/album/) + as an entry point to the album +* Each thumbnail links to + [a "viewer" HTML page](http://ikialbum.hosted.pseudorandom.co.uk/album/img_0120/) + with a full size image, optional next/previous thumbnail links, and + optional [[plugins/comments]] -## Including album entries elsewhere +### Altered Demo -To display images from elsewhere in the wiki with the same appearance as -an [[ikiwiki/directive/album]] or [[ikiwiki/directive/albumsection]], -you can use an [[ikiwiki/directive/inline]] with the `albumitem` -template: +[[!template id=gitbranch branch=cbaines/album]] +This uses the album plugin, with some altered css, and with the css applied to +all of the themes. - \[[!inline pages="..." sort="-age" template="albumitem"]] +* [Simple album, rendered using mutiple themes](http://cbaines.net/projects/ikiwiki/album/dest/basic) + using the ikiwiki logo. ----- +## Installation -[[!template id=gitbranch branch=smcv/album4 author="[[Simon_McVittie|smcv]]"]] +[[!template id=gitbranch branch=smcv/album5 author="[[Simon_McVittie|smcv]]"]] -Available from [[smcv]]'s git repository, in the `album4` branch. +Available from [[smcv]]'s git repository, in the `album5` branch. I've called it `album` to distinguish it from [[contrib/gallery|plugins/contrib/gallery]], although `gallery` might well be a better name for this functionality. @@ -59,9 +44,10 @@ individual photos can't be bookmarked in a meaningful way, and the best it can do as a fallback for non-Javascript browsers is to provide a direct link to the image.) -Updated, April 2012: rebased onto the version of [[trail]] that got merged +Updated, June 2014: integrated changes from [[KathrynAndersen]], +Lukas Lipavsky and kjs -## Manual installation +### Manual installation First, you need a version of ikiwiki with the [[trail]] plugin merged in (version 3.20120203 or later). @@ -69,35 +55,51 @@ First, you need a version of ikiwiki with the [[trail]] plugin merged in Manual installation requires these files (use the "raw" link in gitweb to download): -* [album.pm](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/IkiWiki/Plugin/album.pm) +* [album.pm](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album5:/IkiWiki/Plugin/album.pm) in an `IkiWiki/Plugin` subdirectory of your configured `plugindir` -* [albumviewer.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/templates/albumviewer.tmpl), - [albumitem.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/templates/albumitem.tmpl), - [albumnext.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/templates/albumnext.tmpl) and - [albumprev.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/templates/albumprev.tmpl), +* [albumviewer.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album5:/templates/albumviewer.tmpl), + [albumitem.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album5:/templates/albumitem.tmpl), + [albumnext.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album5:/templates/albumnext.tmpl) and + [albumprev.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album5:/templates/albumprev.tmpl), in your configured `templatedir`, or a `templates` subdirectory of your wiki repository * the album-related bits from the end of the - [stylesheet](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/doc/style.css) + [stylesheet](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album5:/doc/style.css) (put them in your local.css) -## Demo +## Changing the templates -* [HTML page of thumbnails](http://ikialbum.hosted.pseudorandom.co.uk/album/) - as an entry point to the album -* Each thumbnail links to - [a "viewer" HTML page](http://ikialbum.hosted.pseudorandom.co.uk/album/img_0120/) - with a full size image, optional next/previous thumbnail links, and - optional [[plugins/comments]] +When a viewer page is generated or inlined into an album, the template can +contain these extra variables: -## Bugs +* `<TMPL_VAR ALBUM>` - page name of the album +* `<TMPL_VAR ALBUMURL>` - relative URL to the album +* `<TMPL_VAR ALBUMTITLE>` - title of the album, usually taken from + a [[ikiwiki/directive/meta]] directive +* `<TMPL_VAR CAPTION>` - caption for the image +* `<TMPL_VAR THUMBNAIL>` - a small [[ikiwiki/directive/img]] for the image +* `<TMPL_VAR IMAGEWIDTH>` - width of the full-size image in pixels +* `<TMPL_VAR IMAGEHEIGHT>` - height of the full-size image in pixels +* `<TMPL_VAR IMAGEFILESIZE>` - size of the image, e.g. `1.2 MiB` +* `<TMPL_VAR IMAGEFORMAT>` - format of the image, typically `JPEG` + +The template for the viewer page can also contain: + +* `<TMPL_VAR IMG>` - a large [[ikiwiki/directive/img]] to display the image +* `<TMPL_VAR PREV>` - a link to the previous viewer, typically with a + thumbnail +* `<TMPL_VAR NEXT>` - a link to the next viewer, typically with a + thumbnail -* `thumbnailsize` doesn't actually work, they're always 96x96. - [[KathrynAndersen]] suggested a fix on the [[discussion]] page; - search for her name and look for a context diff. +## Including album entries elsewhere -* The album index is limited to 10 images. kjs suggested a fix on - the [[discussion]] page: the plugin should pass `show => 0` - to `preprocess_inline`. +To display images from elsewhere in the wiki with the same appearance as +an [[ikiwiki/directive/album]] or [[ikiwiki/directive/albumsection]], +you can use an [[ikiwiki/directive/inline]] with the `albumitem` +template: + + \[[!inline pages="..." sort="-age" template="albumitem"]] + +## Bugs * There's currently a hard-coded list of extensions that are treated as images: `png`, `gif`, `jpg`, `jpeg` or `mov` files. More image and video @@ -125,9 +127,9 @@ to download): * The generated viewer page should extract as much metadata as possible from the photo's EXIF tags (creation/modification dates, author, title, caption, - copyright). [[smcv]] has a half-written implementation which runs - `scanimage` hooks, and has an `exiftool` plugin using [[!cpan Image::ExifTool]] - as a reference implementation of that hook. + copyright). [[smcv]] once had a half-written implementation which runs + `scanimage` hooks, and an `exiftool` plugin using [[!cpan Image::ExifTool]] + as a reference implementation of that hook, but has lost that code somewhere :-( * There should be an option to reduce the size of photos and write them into an underlay (perhaps just the transient underlay), for this workflow: diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn index 0b8c7b1a5..a8779e279 100644 --- a/doc/plugins/contrib/album/discussion.mdwn +++ b/doc/plugins/contrib/album/discussion.mdwn @@ -1,3 +1,5 @@ +## installation queries from brush + thanks for this plugin. it might help me in my application, which is to provide album/galleries which can be edited (ie. new images added, taken away, etc.) through web interface. > That's my goal eventually, too. Perhaps you can help to @@ -60,6 +62,11 @@ i'm new to ikiwiki, apologies if this is dealt with elsewhere. -brush ## design feedback from joeyh on an earlier version +Not entirely relevant any more. +[[!toggle id="old-design-feedback" text="show"]] +[[!toggleable id="old-design-feedback" text=""" +[[!toggle id="old-design-feedback" text="hide"]] + You had wanted my feedback on the design of this. I have not looked at the code or tried it yet, but here goes. --[[Joey]] @@ -258,6 +265,7 @@ code or tried it yet, but here goes. --[[Joey]] >> changed, and only update those viewers where it has. But the dependency >> type stuff is still very new, and not plugin friendly .. so only just >> possible, --[[Joey]] +"""]] ---- @@ -266,6 +274,10 @@ code or tried it yet, but here goes. --[[Joey]] '''I think the "special extension" design is a dead-end, but here's what happened when I tried to work out how it would work. --[[smcv]]''' +[[!toggle id="special-extension-sketch" text="show"]] +[[!toggleable id="special-extension-sketch" text=""" +[[!toggle id="special-extension-sketch" text="hide"]] + Suppose that each viewer is a JPEG-or-GIF-or-something, with extension ".albumimage". We have a gallery "memes" with three images, badger, mushroom and snake. @@ -406,10 +418,17 @@ Things that would be nice, and are probably possible: * some way to deep-link to memes/badger.jpg with a wikilink, without knowing a priori that it's secretly a JPEG (probably harder than it looks - you'd have to make a directive for it and it's probably not worth it) +"""]] ---- -## bug: unable to vary thumbnail size +## resolved bug reports + +[[!toggle id="fixed-bugs" text="show"]] +[[!toggleable id="fixed-bugs" text=""" +[[!toggle id="fixed-bugs" text="hide"]] + +### bug: unable to vary thumbnail size Hi smcv, great plugin. I am an ikiwiki newbie but so far I've had success using your plugin. I've integrated the jquery masonry plugin into the albumitem template and it works great. @@ -417,11 +436,11 @@ But is there a way to create thumnails of different sizes? I've passed thumnails and value to album directive and while it does create the new thumbnail sizes it doesn't use them, The 96x96 thumbnails still appear on the page no matter what I do. - jaime -> [[KathrynAndersen]] fixed this, see below. --[[smcv]] +> Fixed in album5 branch, thanks to [[KathrynAndersen]]. --[[smcv]] ---- -## failed installation +### failed installation Hi, the plugin looks great, but I am probably too dumb to use it ;( here is what I did: created page gal.mdwn with just \[\[!album\]\] directive (no arguments) and subdirectory gal/ with images in form img_1234.jpg @@ -469,7 +488,7 @@ Thanks Lukas ---- -## bug + patch: not all images shown on album page +### bug + patch: not all images shown on album page Hi smcv, we spoke on irc the other day. Passed `show => "0"` on line 126 in album.pm to remove the limit on the thumbnails shown on the album page. Setting it on the album directive didn't work. @@ -478,54 +497,25 @@ Hi smcv, we spoke on irc the other day. Passed `show => "0"` on line 126 in albu > That sounds like a correct solution. I'll fix that in my branch when I work on > this again. --[[smcv]] +>> Fixed in `album5` branch --s + ---- -## bug: thumbnailsize doesn't work +### bug: thumbnailsize doesn't work As mentioned above by Jaime setting the thumbnailsize doesn't catch either. Or rather if I git push after changing the album directive the generated thumbnails (the image files) are the correct size as set in the directive. The html however uses the default thumbnailsize as hardcoded in album.pm and has broken thumbnails as it links to a file with the default size in the filename. > [[KathrynAndersen]] fixed this, see below. --[[smcv]] +>> Fixed in `album5` branch --s + Issuing `ikiwiki --rebuild` knocks the system into another gear where the thumbnails show up correctly but this is only due to the html being the same as above (linking to hardcoded thumbnailsize) but the generated thumbnail images are now matching the hardcoded size ignoring the thumbnailsize attribute on the album directive. For me this behaviour is way beyond my skills to sort out (I'm no coder). The albumplugin ikiwiki combo is very attractive to me and the plugin i soo close to working! --kjs ----- - -## wishlist + patch: make clicking on the large image go to the next - -I've changed the behavior of the "slideshow" to show the next image when clicking the large image as downloading a full resolution image is a rare use case in a gallery of this type imho. The large clicktarget means you are likely to unnecessarily download large files otherwise. I can't quite follow the template, album.pm flow so I can't figure out how to put a "download full resolution" link on the viewer page which would be my next step. To achieve the next link i added ` link => ($nextpage or $album),` around line 454 in `my $img` - ---kjs - -> That seems reasonable. I'll consider that when I work on this -> plugin again next. --[[smcv]] - ----- - -## wishlist from kjs - -My wishlist for the plugin would include: - -- Reading exif info from the imagefile -- ~~Keeping the full resolution image files out of version control~~ Solved this by simply creating a underlay for the images. Works out of the box for my non cgi workflow. -- Being able to create new albums by tag or by manually picking images from other albums. Could be a simple comma separated list of viewer names, or even full urls, in the album directive. -- A counter showing **current image/total number of images in album**. This would mean that you know how many images you have left to click through before you have seen all images in an album. This gives you enought info to decide weather to click through or go back/leave. - ---kjs - -> I want the first two of those too, perhaps one day I'll get round to -> implementing them. -> -> For the third, you can get the same practical effect using an inline -> as documented in the main page. --[[smcv]] ->> The downside to current behaviour is that clicking an inlined thumbnail will take you to the original album context. Previous/Next image will not match the thumbnails in the inline but the thumbnails in the album. This is a bit confusing for users and prevents using the image in multiple contexts without duplicating the image. To achieve what I'm looking for there would have to be several AlbumViewer pages for a single image. --kjs - ----- - -## suggested fix for thumbnail size bug +### suggested fix for thumbnail size bug I've tracked down the "always showing the 96x96 thumbnails" bug! @@ -576,9 +566,11 @@ Here's a context-diff of my fix: > > --[[smcv]] +>> Fixed in `album5` --s + ---- -## bug: inability to show more than 10 items +### bug: inability to show more than 10 items I've found another bug. The album plugin doesn't allow one to have more than 10 items in an album section. This is because it uses "inline" to display album sections, and the default for inline is to show only 10 items. So it only shows 10 items. @@ -594,37 +586,144 @@ What would be good is if the album directive could have a "show" parameter which > although I don't know how useful it would be; if it isn't passed, the > default should be 0 (unlimited). --[[smcv]] +>> Fixed in `album5` --s + ---- -## bug?: all albums and pages become interdependent -*(ikiwiki master branch 2014-06-06 and smcv album4 branch)* +### cbaines' commit to change default thumbnail size + +Regarding commit `Change the default thumbnail size`: as far as I +understand it, `size => 96x96` is meant to set the image size to +be as large as possible given these constraints: width ≤ 96px, +height ≤ 96px, and the original aspect ratio is preserved. So I +would hope that 96x96 doesn't distort the thumbnails. What distortion +are you seeing, and which versions of Imagemagick and Perlmagick +are you using? + +--[[smcv]] + +> I rebuilt the examples using both your album4 and album5 branches, and I only +> see this in the album4 branch. So this is probably ok to ignore. +> --[[cbaines]] +> +>> OK, I'll assume that was a duplicate of an earlier patch, probably the +>> one from KathrynAndersen. --s + +"""]] + +---- + +## wishlist + patch: make clicking on the large image go to the next + +I've changed the behavior of the "slideshow" to show the next image when clicking the large image as downloading a full resolution image is a rare use case in a gallery of this type imho. The large clicktarget means you are likely to unnecessarily download large files otherwise. I can't quite follow the template, album.pm flow so I can't figure out how to put a "download full resolution" link on the viewer page which would be my next step. To achieve the next link i added ` link => ($nextpage or $album),` around line 454 in `my $img` + +--kjs + +> That seems reasonable. I'll consider that when I work on this +> plugin again next. --[[smcv]] -On a site with the following structure where all album$n.mdwn files have the ``[[!album]]`` directive set. All albums and albumviewers get rebuilt whenever any one of the pages is touched and the command ``ikiwiki --setup debug.setup --refresh --verbose`` is issued. +---- - /index.mdwn - |-album01.mdwn - |-album01/ - | |-imgA.jpg - | |-imgB.jpg - | - |-album02.mdwn - |-album02/ - | |-imgC.jpg - | |-imgD.jpg - | - |-album03.mdwn - |-album03/ - | |-imgE.jpg - | |-imgF.jpg +## wishlist from kjs -This happens even if the indexpage has no links and when the tree is one level deeper than above with a folder between the index and each ``album$0n`` tuple. Touching index.mdwn rebuilds for instance imgF viewer and output like for example the following as a result of changing ``album01.mdwn`` and issuing ``ikiwiki --setup debug.setup --refresh --verbose`` +My wishlist for the plugin would include: - building album02/imgC, its previous or next page has changed - building album03/imgE, its previous or next page has changed - building album02.mdwn, which depends on album02/imgC +- Reading exif info from the imagefile +- ~~Keeping the full resolution image files out of version control~~ Solved this by simply creating a underlay for the images. Works out of the box for my non cgi workflow. +- Being able to create new albums by tag or by manually picking images from other albums. Could be a simple comma separated list of viewer names, or even full urls, in the album directive. +- A counter showing **current image/total number of images in album**. This would mean that you know how many images you have left to click through before you have seen all images in an album. This gives you enought info to decide weather to click through or go back/leave. -In other words using the album plugin means all changes trigger full rebuilds (as far as I can tell). With my workflow this hasn't been much of an issue as my sites are static and updated maximum once a week but it does make comments unfeasible. +--kjs -Perhaps there is something in my setup that triggers this problem? If anyone has an ikiwiki album installation where ``--refresh`` limits the scope of the rebuild to just one album I'd be interested to hear. See <http://img.kalleswork.net> for an live website that has this problem. I've tested a simpler debug site without any customization as well. --[[kjs]] +> I want the first two of those too, perhaps one day I'll get round to +> implementing them. +> +> For the third, you can get the same practical effect using an inline +> as documented in the main page. --[[smcv]] +>> The downside to current behaviour is that clicking an inlined thumbnail will take you to the original album context. Previous/Next image will not match the thumbnails in the inline but the thumbnails in the album. This is a bit confusing for users and prevents using the image in multiple contexts without duplicating the image. To achieve what I'm looking for there would have to be several AlbumViewer pages for a single image. --kjs +>> +>>> Hmm, OK. That breaks the "one picture : one page" mental model, +>>> unfortunately. The pictures themselves can't be first-class wiki pages (see +>>> lengthy design discussions with Joey above) because they aren't something +>>> that produces HTML, and don't have human-readable text source code. +>>> In the current (album5) design, the viewer pages that are automatically +>>> created to go alongside the pictures are basically stand-ins for the +>>> pictures, as far as metadata, wikilinks, tags and other "first-class +>>> wiki page" things are concerned. +>>> +>>> If there are to be viewer pages elsewhere in the wiki, I don't think +>>> inheriting the picture's metadata is desired. Suppose you have a +>>> picture of Alice and Bob in the album "holiday in Exampleton, 2010", +>>> and it is tagged people/alice, people/bob and places/exampleton; the +>>> other contexts it appears in might include "pictures of Alice" and +>>> "pictures near Exampleton". If you look at the tag page for +>>> places/exampleton, I doubt you want to see that photo listed three +>>> times - once is enough, there's only one actual photo after all. So +>>> I think the "main" viewer page should be the only one that has +>>> the taglinks for people/alice, people/bob, places/exampleton. +>>> +>>> My next question is, should the viewer page representing that +>>> particular picture in its context of "pictures near Exampleton" +>>> (i.e. its "next" and "previous" links go to the next and +>>> previous picture near Exampleton, regardless of whether it was +>>> on an earlier or later visit) be a first-class wiki page +>>> at all? +>>> +>>> * Does it make any sense to comment on "this picture in this +>>> context", if your wiki has comments, or should the only +>>> place you can comment on it be its "main" viewer page? +>>> * Is there any need for it to be possible to make a wikilink +>>> to that particular picture in that particular context, +>>> or does it only need wikilinks "to the picture" (which, +>>> as an implementation detail, really go to its "main" viewer +>>> page)? +>>> * Can the picture in that particular context have tags +>>> that are orthogonal to the tags its "main" viewer page has? +>>> * ... and so on for various wiki features +>>> +>>> It sound as though the answer might ideally be that this secondary +>>> viewer page doesn't need to be a first-class wiki page at all, +>>> only a HTML output... except that the trail plugin works in terms +>>> of next and previous first-class wiki pages, not next and +>>> previous HTML outputs, and the HTML-generation pipeline +>>> is really aimed towards real pages. +>>> +>>> Perhaps the secondary viewer page should end up looking +>>> something like this: +>>> +>>> \[[!albumviewer original=holiday-in-exampleton-2010/img1234 +>>> comment="To edit picture metadata, edit the original page instead"]] +>>> +>>> and one of the side-effects of the albumviewer directive should be to +>>> replace [[plugins/comments]] with a link to the original? --s +---- +## cbaines' CSS changes + +Regarding the CSS changes: I'll try to have a look soon, work out +what actually changed (since you re-ordered the CSS, so it isn't +immediately obvious from the diff), and integrate some or all of your +changes. Since Joey shows no signs of wanting to merge it, and "out of tree" +installation is currently a pain, I might split out the CSS changes into a +separate `ikiwiki/album.css` so that the only thing that needs to be merged +into style.css (or into local.css) is an appropriate +`@import` rule. + +It shouldn't be necessary to add the album stuff to each individual +theme's style.css unless you actually want an actiontabs album and +a blueview album to be styled differently, because the IkiWiki Makefile +concatenates them: for instance, `/usr/share/ikiwiki/themes/actiontabs/style.css` +is the output of `cat doc/style.css themes/actiontabs/style.css`. So adding it +to `doc/style.css` should be enough? --[[smcv]] + +> I don't think this is the case? Or at least, looking at the generated +> stylesheet for the examples built using my branch, I would expect there to be +> two copies of the album rules in the stylesheet [1], but there does not +> appear to be. This could quite easily be a result of some mistake in my part +> in not isolating the build though. --[[cbaines]] +> +> 1: <http://cbaines.net/projects/ikiwiki/album/dest/basic-actiontabs/style.css> +> +>> I searched for `/* relevant to the index page */` and found it twice, +>> so I stand by what I said :-) --s diff --git a/doc/plugins/trail/discussion.mdwn b/doc/plugins/trail/discussion.mdwn index 6c0b790b9..731b8c790 100644 --- a/doc/plugins/trail/discussion.mdwn +++ b/doc/plugins/trail/discussion.mdwn @@ -103,3 +103,70 @@ Some later changes to trail: --[[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]] |