diff options
| -rw-r--r-- | doc/bugs/image_rescaling_distorts_with_small_pictures.mdwn | 43 | ||||
| -rw-r--r-- | doc/bugs/template_creation_error.mdwn | 8 | ||||
| -rw-r--r-- | doc/bugs/template_evaluation_oddities.mdwn | 67 | ||||
| -rw-r--r-- | doc/bugs/trails_depend_on_everything.mdwn | 14 | ||||
| -rw-r--r-- | doc/forum/Right-to-left_support.mdwn | 15 | ||||
| -rw-r--r-- | doc/plugins/contrib/album.mdwn | 4 | ||||
| -rw-r--r-- | doc/plugins/contrib/album/discussion.mdwn | 144 | ||||
| -rw-r--r-- | doc/plugins/contrib/navbar.mdwn | 3 | ||||
| -rw-r--r-- | doc/plugins/osm.mdwn | 22 | ||||
| -rw-r--r-- | doc/plugins/trail/discussion.mdwn | 13 | ||||
| -rw-r--r-- | doc/tips/Right-to-left___40__RTL__41___page_text.mdwn | 49 | ||||
| -rw-r--r-- | doc/todo/pagespec__95__match__95__list_can_result_in_excessive_dependencies.mdwn | 41 | ||||
| -rw-r--r-- | doc/users/kjs.mdwn | 5 |
13 files changed, 419 insertions, 9 deletions
diff --git a/doc/bugs/image_rescaling_distorts_with_small_pictures.mdwn b/doc/bugs/image_rescaling_distorts_with_small_pictures.mdwn index c535f88a4..a8c8deebf 100644 --- a/doc/bugs/image_rescaling_distorts_with_small_pictures.mdwn +++ b/doc/bugs/image_rescaling_distorts_with_small_pictures.mdwn @@ -1 +1,44 @@ If you use the rescaling feature of the directive [[ikiwiki/directive/img/]] with a smaller image it will distort. E.g. an image with 150x250 rescaled into size=200x200. --bastla + +> More specifically: `img` normally preserves aspect ratio: +> `size=200x200` normally means "as large as possible, keeping +> the width 200px or less, the height 200px or less, and the +> aspect ratio correct". So a 4:3 image with `size=200x200` +> would actually come out 200px wide and 150px tall. +> +> However, when (desired width is specified) && (desired height is specified) +> && ((width > desired width) || (height > desired height)), +> it uses exactly the desired size, without preserving aspect ratio. +> --smcv + +>> [[!template id=gitbranch branch=chrysn/imgforpdf-and-more author="[[chrysn]]"]] +>> +>> [[!tag patch]] +>> +>> i've implemented a fix for this along with a unit test. +>> +>> the patch branch is based on the imgforpdf branch +>> ([[bugs/svg and pdf conversion fails]]), because it would not cleanly merge. +>> the branch also enhances on how images are handled in preview, falling back +>> to data: urls if the image has not been rendered in a saved version. please +>> review. --[[chrysn]] + +>>> Mostly [[looks good to me|users/smcv/ready]]. +>>> +>>> Minor things, which wouldn't stop me merging it if I could: +>>> +>>> * `$imgdatalink = "data:image/".$im->Get("magick").";base64,".encode_base64($blob[0]);`: +>>> is the ImageMagick file type always valid as the second part of +>>> a MIME type? +>>> * In this code: +>>> +>>> +open (my $outhtmlfd, "<", "$outpath.html"); +>>> +local $/=undef; +>>> +my $outhtml = <$outhtmlfd>; +>>> +close $outhtmlfd; +>>> +>>> no block is closed, so the "local" is ineffective, so the `<>` operator +>>> remains in read-entire-file mode afterwards. To avoid odd side-effects, +>>> I would suggest using `readfile()` like `t/trail.t` does. +>>> +>>> --[[smcv]] diff --git a/doc/bugs/template_creation_error.mdwn b/doc/bugs/template_creation_error.mdwn index d3c0bcca5..d1fb788f5 100644 --- a/doc/bugs/template_creation_error.mdwn +++ b/doc/bugs/template_creation_error.mdwn @@ -261,4 +261,10 @@ same logic as IkiWiki itself. I don't think that's serious. --[[smcv]] >>>> an error to invoke scan in the render phase; that would mean that >>>> `readtemplate` needs to check whether it's invoked as a scan or not to >>>> decide whether to scan the template page, but would be generally more ->>>> robust for future plugin writing. --[[chrysn]] +>>>> robust for future plugin writing. +>>>> +>>>> **addendum**: if the new phase state is used to create warnings/errors +>>>> about improper ikiwiki api use of plugins (which is something i'd +>>>> advocate), that should likewise warn if `add_link` actually adds a link in +>>>> the render phase. such a warning would have helped spotting the +>>>> link-related [[template evaluation oddities]] earlier. --[[chrysn]] diff --git a/doc/bugs/template_evaluation_oddities.mdwn b/doc/bugs/template_evaluation_oddities.mdwn new file mode 100644 index 000000000..06ef57375 --- /dev/null +++ b/doc/bugs/template_evaluation_oddities.mdwn @@ -0,0 +1,67 @@ +[[ikiwiki/directive/template]]s expose odd behavior when it comes to composing +links and directives: + +* the parameters are passed through the preprocessor twice, once on + per-parameter basis and once for the final result (which usually contains the + preprocessed parameters). + + one of the results it that you have to write: + + \[[!template id="infobox" body=""" + Just use the \\\[[!template]] directive! + """]] + + (that'd be three backslashes in front of the opening [.) + + <!-- if you read this and wonder why there are only three backslashes in the + source code too, look at how backslash-escaping directives is implemented. + --> + + this also means that parts which are not used by the template at all still + have their side effects without showing. + + furthermore, the evaluation sequence is hard to predict. this might or might + not be a problem, depending on whether someone comes up with a less contrived + example (this one assumes a ``\[[!literal value]]`` directive that just + returns value but protects it from the preprocessor): + + we can use `\[[!literal """[[!invalid example]]"""]]`, but we can't use + `\[[!template id=literalator value="""[[!invalid example]]"""]]` with a + 'literalator' template `<span class="literal">\[[!literal """<TMPL_VAR + value>"""]]</span>` because then the `invalid` directive comes to action in + the first (per-argument) preprocessor run + +* links in templates are not stored at all; they appear, but the backlinks + don't work unless the link is explicit in one of the arguments. + + \[[!template id="linker" destination="foo"]] + + with a 'linker' template like + + Go to \[[<TMPL_VAR destination>]]! + + would result in a link to 'destination', but would not be registered in the + scan phase and thus not show a backlink from 'foo'. + + (a ``\[[!link to=...]]`` directive, as suggested in + [[todo/flexible relationships between pages]], does get evaluated properly + though.) + + this seems to be due to linkification being called before preprocess rather + than as a part of it, or (if that is on purpose) by the template plugin not + running linkification as an extra step (not even once). + +(nb: there is a way to include the ``raw_`` value of a directive, but that only +refers to htmlification, not directive evaluation.) + +both those behaviors are non-intuitive and afaict undocumented. personally, i'd +swap them out for passing the parameters as-is to the template, then running +the linkifier and preprocessor on the final result. that would be as if all +parameters were queried `raw_` -- then again, i don't see where `raw_` makes +anything not work that worked originally, so obviously i'm missing something. + + +i think it boils down to one question: are those behaviors necessary for +compatibility reasons, and if yes, why? + +--[[chrysn]] diff --git a/doc/bugs/trails_depend_on_everything.mdwn b/doc/bugs/trails_depend_on_everything.mdwn new file mode 100644 index 000000000..babb1e361 --- /dev/null +++ b/doc/bugs/trails_depend_on_everything.mdwn @@ -0,0 +1,14 @@ +[[!template id=gitbranch branch=smcv/ready/trail-sort +author="[[Simon McVittie|smcv]]" +browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/trail-sort]] +[[!tag patch users/smcv/ready]] + +On [[trail's discussion page|plugins/trail/discussion]], [[kjs]] pointed out +that [[plugins/trail]] and [[plugins/contrib/album]] get excessive +dependencies on `internal(*)`. I tracked this down to their (ab)use of +`pagespec_match_list` with the pagespec `internal(*)` to sort a pre-existing +list of pages. + +They should just sort the pages instead; they'll already have all the +dependencies they need. My branch adds `IkiWiki::sort_pages` but does not +make it plugin API just yet. --[[smcv]] diff --git a/doc/forum/Right-to-left_support.mdwn b/doc/forum/Right-to-left_support.mdwn new file mode 100644 index 000000000..7ca4f9ad6 --- /dev/null +++ b/doc/forum/Right-to-left_support.mdwn @@ -0,0 +1,15 @@ +Does ikiwiki support RTL languages? I read somewhere it does, but I don't see +any mention of that here (or anywhere else... that info may be wrong). + +I'd like to add RTL support to my wiki, for text direction and maybe for the +page layout too. Before I edit my CSS, page.tmpl and possibly Perl for +automatic direction setting - does ikiwiki support this in any way? + +On my wiki (ikiwiki version from Debian 7 stable) everything is aligned to +the left, and unicode RTL characters cannot change that - the .tmpl and +css files would need to be changed, it seems. + +I will happily share my insights and code, if I manage to get anything +useful to work :-) + +--[[fr33domlover]] diff --git a/doc/plugins/contrib/album.mdwn b/doc/plugins/contrib/album.mdwn index c2f991d5a..9fac11164 100644 --- a/doc/plugins/contrib/album.mdwn +++ b/doc/plugins/contrib/album.mdwn @@ -47,6 +47,10 @@ is to provide a direct link to the image.) Updated, June 2014: integrated changes from [[KathrynAndersen]], Lukas Lipavsky and kjs +An `album6` branch is also available, but is less suitable +for manual installation since it needs core IkiWiki changes +(until [[bugs/trails depend on everything]] is fixed). + ### Manual installation First, you need a version of ikiwiki with the [[trail]] plugin merged in diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn index a8779e279..442d02df0 100644 --- a/doc/plugins/contrib/album/discussion.mdwn +++ b/doc/plugins/contrib/album/discussion.mdwn @@ -649,8 +649,28 @@ My wishlist for the plugin would include: >>> 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. ->>> +>>> wiki page" things are concerned. --s + +>>>> I can see why it's important to keep these models simple and have figured out +>>>> that the viewer pages are stand-ins for the image. Just as a tought though. If +>>>> this relationship was made more explicit ie. the viewer pages *are the content* +>>>> just initially generated from the image metadata with a link to the image. Then +>>>> the mental model would stay intact and more in line with how html and the +>>>> implementation works. +>>>> +>>>> One thing to point out is that last time I tried pages can be members of +>>>> arbitrary numbers of trails/albums. You just get multiple rows of navigation, one +>>>> for each trail. This doesn't quite work as it's hard to know which one to click. +>>>> +>>>> --k + +>>>>> Pages can be part of arbitrarily many trails, yes - that's a consequence of +>>>>> how trails are created. If you can think of a better way to present a page +>>>>> that's in more than one trail, I'd welcome ideas... I did originally have an +>>>>> implementation where only one trail would generate links, but when I tried +>>>>> it on some (rather artificial) overlapping trails, the result was more +>>>>> confusing. --s + >>> 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", @@ -661,14 +681,21 @@ My wishlist for the plugin would include: >>> 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. ->>> +>>> --s + +>>>> The problem exposed by the tag page issue is very tricky. As you'd +>>>> probably want the exif info, captions and titles to transfer. Just not +>>>> necessarily the tags. +>>>> --k + >>> 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? ->>> +>>> --s + >>> * 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? @@ -697,6 +724,81 @@ My wishlist for the plugin would include: >>> and one of the side-effects of the albumviewer directive should be to >>> replace [[plugins/comments]] with a link to the original? --s +>>>> One thing to consider is the built in difference between the original and +>>>> the secondary inferred by the fact that the first is an `album` the second +>>>> an `inline` --k + +>>>>> I had assumed that both the "original" album (the one where the picture +>>>>> is physically located), and any other places you wanted to display it, +>>>>> would be some other directive whose implementation includes a call to +>>>>> `preprocess_inline`. `inline` on its own is not enough to create +>>>>> viewer pages to display the pictures, regardless of whether you +>>>>> want them to be one-per-picture or many-per-picture, and I'm not +>>>>> going to wedge yet more functionality into that plugin :-) +>>>>> +>>>>> It might be a good idea for the thing that displays pictures not +>>>>> physically located below that point to be a different directive, yes. +>>>>> --s + +>>>> ### Single viewer +>>>> For my own usecase what you describe makes sense. I see the content of an inline object +>>>> (struggling a bit with what terms to user here) as a particular composition of +>>>> viewers. Perhaps comments should only be possible on the page with the inline rather +>>>> than the secondary viewer pages as the inline page not the image viewer is +>>>> the first-class page in this scenario? The inline page would also be the page you tag +>>>> etc. to make it show up in various contexts such as the tag page. +>>>> +>>>> With the thinking outlined above I'd say that the secondary viewer should be a +>>>> non editable clone of the original viewer without any source. Just html output with +>>>> backlinks to the original page. This means that there are limitations to how these +>>>> secondary viewers can be used as the title, caption etc might fit some contexts +>>>> better than others. Personally this is fine as I see these inline based albums as +>>>> compositions or views on existing content. +>>>> --k +>>>> +>>>>> This is basically what I thought at first, but I realised while +>>>>> writing my earlier comments that it would be necessary +>>>>> to hack up [[plugins/trail]] fairly seriously to make it produce +>>>>> a trail through things that are not first-class wiki pages, and +>>>>> I'm not sure how much it would be necessary to subvert the +>>>>> rendering pipeline to get the right parentlinks and so on. --s +>>>> +>>>> ###Multiple viewers alternative +>>>> The alternative is having a page say in `/story/album.mdwn` with the following directive +>>>> \[[!inline pages="/01/IMGP6494 or /02/IMGP6601 or /04/IMGP6922" sort="title" show="0" template="albumitem"]] +>>>> that creates new fully fledged editable viewers for each image in `/story/album/' +>>>> without tags being auto populated but backlinks to the original album viewer. +>>>> --k +>>>> +>>>>> It can't *only* be an inline, because an inline wouldn't generate the +>>>>> viewer pages, but I see what you mean. --s +>>>>> +>>>>>> That's actually excellent as the inline is a very useful feature +>>>>>> the way it works now. I started writing about this yesterday but +>>>>>> got interrupted. My indexes of albums use the inline in it's current +>>>>>> form. --k +>>>> +>>>> This would make the viewers completely independent allowing for unique titles, captions and comments +>>>> depending on context. Very useful when creating powerpoint like slideshows where you might need +>>>> different captions depending on the context. In your example wiki with photos from gigs this would allow +>>>> a page with an album inline about stage lighting with a selections of images and captions that highlight +>>>> relevant things in the image as well as a separate inline album page, with some of the same images, +>>>> about drumming styles and posture/grip of drummers. +>>>> +>>>> I started writing all this supporting your single page case but looking at it now from my limited +>>>> understanding of how ikiwiki works it seems the multiple viewers option is conceptually cleaner +>>>> and more flexible. It relies on three things: + +>>>> * A mental model where the viewer page is the content not the image +>>>> * That tags aren't automatically transferred from the original context. This doesn't seem that critical however. +>>>> * Backlinks to the other places the image is used. +>>>> +>>>> --[[kjs]] + +I've added "--k" to some of your comments so other readers (possibly including +my future self) can keep track of our conversation, I hope you don't mind :-) +--s + ---- ## cbaines' CSS changes @@ -727,3 +829,37 @@ to `doc/style.css` should be enough? --[[smcv]] > >> I searched for `/* relevant to the index page */` and found it twice, >> so I stand by what I said :-) --s +>> +>>> And right you are, unsure how I missed that. My album branch is now rebased +>>> on your album5 branch (with the two now useless commits removed). +>>> --[[cbaines]] + +cbaines, would you mind publishing an album with more realistic pixel-sizes +of images using your modified CSS? It's difficult to get an idea of how it +will degrade under conditions like "image size > browser window" with +images as small as the ones you used. You might find +<http://git.pseudorandom.co.uk/smcv/ikiwiki-demos/ikialbum.git> +(`git clone git://git.pseudorandom.co.uk/git/smcv/ikiwiki-demos/ikialbum.git`), +or the same techniques, useful: it contains images with a realistic pixel +count, but very very lossy JPEG compression, to keep the size in bytes low. + +It's much, much easier to review changes if you use separate commits for +cosmetic changes like "separate index CSS from viewer CSS" and "more +consistent indentation", and functional changes like turning the prev/next +links from absolutely-positioned to floating. I'd be happy to apply +the cosmetic changes if they were in commits that were literally only +cosmetic changes, with no functional effect. + +For the functional bits: I think I'd have used floating boxes instead of the +absolutely-positioned boxes that are currently used if they provided the effect +I wanted. I can't remember exactly why I didn't do that now, but +it might have been because if the browser window shrinks below the image width, +floats have weird behaviour (they push the actual image out of the way), or because +I wanted the entire left/right margin of the image to be clickable to have +a large click-target for scrolling through the album. + +If there's something specific that you think is wrong with the CSS in my +branch, could you please explain it, and perhaps we can come up with something +that matches both our requirements? + +--smcv diff --git a/doc/plugins/contrib/navbar.mdwn b/doc/plugins/contrib/navbar.mdwn index f1c15c6e0..9de66f787 100644 --- a/doc/plugins/contrib/navbar.mdwn +++ b/doc/plugins/contrib/navbar.mdwn @@ -38,3 +38,6 @@ If you are interested in this, drop me a line tobi at oetiker dot ch In the meanwhile, I ([[MartinQuinson]]) have hacked this a bit to make it fit my needs. The result is [[here|http://www.loria.fr/~quinson/Hacking/ikiwiki/]] + +In the meanwhile I too have hacked this for my needs and fixed a few bugs in Martin's version. +The result (and source / instructions) can be found [[here|http://wiki.math.cmu.edu/iki/wiki/tips/20140720-ikiwiki-navbar.html]]. (It is not mobile ready yet, but might be soon...) diff --git a/doc/plugins/osm.mdwn b/doc/plugins/osm.mdwn index 040d175ca..a2455a4be 100644 --- a/doc/plugins/osm.mdwn +++ b/doc/plugins/osm.mdwn @@ -1,10 +1,10 @@ [[!template id=plugin name=osm author="Blars Blarson, Antoine Beaupré"]] [[!tag type/special-purpose todo/geotagging]] -## Openstreetmap/Openlayers support for ikiwiki +## OpenStreetMap/OpenLayers support for ikiwiki -This plugin provides simple Openstreetmap/Openlayers support for ikiwiki. -It can embed Openstreetmap viewports within a page or link to a bigger map +This plugin provides simple OpenStreetMap/OpenLayers support for ikiwiki. +It can embed OpenStreetMap viewports within a page or link to a bigger map that will have multiple markers, generated with a KML (or CSV, or GeoJSON) datafile of markers based on the different calling pages. Multiple distinct maps on a single wiki are supported. @@ -15,6 +15,22 @@ if the [[!cpan JSON]] perl module is installed. This provides the [[ikiwiki/directive/waypoint]] and [[ikiwiki/directive/osm]] directives. +### Examples + +A [[basic set of examples|http://cbaines.net/osm-examples]] is available +([[repository|http://git.cbaines.net/?p=ikiwiki/osm-examples.git;a=summary]]). +Note that none of these will work without patching the plugin. With the +following patches, most of the examples will work (while each patch is +seperate, the branch includes all previous patches in the list, so the +cbaines/osm-icon-fixes branch includes all patches). + + - [[bugs/osm plugin error TypeError: mapProjection is null]] + - [[todo/osm plugin GeoJSON popup patch]] + - [[todo/osm plugin icon patch]] + +Even with these patches, the CSV examples do not work, and there are cosmetic +issues with a few of the other examples. + --- The plugin was originally written by diff --git a/doc/plugins/trail/discussion.mdwn b/doc/plugins/trail/discussion.mdwn index 731b8c790..6b1b58bd8 100644 --- a/doc/plugins/trail/discussion.mdwn +++ b/doc/plugins/trail/discussion.mdwn @@ -170,3 +170,16 @@ I have removed a similar comment from the album discussion. >> 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 diff --git a/doc/tips/Right-to-left___40__RTL__41___page_text.mdwn b/doc/tips/Right-to-left___40__RTL__41___page_text.mdwn new file mode 100644 index 000000000..2b176c811 --- /dev/null +++ b/doc/tips/Right-to-left___40__RTL__41___page_text.mdwn @@ -0,0 +1,49 @@ +Here's a simple way to create pages in which the page body (or a part of it) goes right-to-left. +This includes things you insert into the page, such as polls and blockquotes and +lists and a progress bar and so on. Some things don't work perfectly, but if +you want to have some RTL pages in your wiki, this will probably do. + +It does not modify the things around the body, such as the page header and the +footer. Only what is rendered from the mdwn file is affected. + +# 1 Add an RTL Template + +Create a new template page *templates/rtl.mdwn* with the following content: + + <div class="rtl"> + <TMPL_VAR text> + </div> + <TMPL_UNLESS text> + Use this template to insert RTL text into a page. + This template has one parameter: + <ul> + <li>`text` - the text to display in RTL + </ul> + </TMPL_UNLESS> + +# 2 Add an RTL class to the CSS + +In your *local.css* add the following: + +[[!format css """ +/* rtl template */ +.rtl { + direction: rtl; +} +"""]] + +# 3 Use the Template + +To make a page or part of it RTL, use the [[ikiwiki/directive/template]] directive: + + \[[!template id="rtl" text=""" + + This text will be aligned to the right. You can write here in Hebrew, Arabic, etc. You can + put here anything you want to put on the page. As said above, some elements may not + align perfectly, but: + + 1. It can be solved per case + 2. It's not critical, everything works quite well and is readable. If you have any comments, + suggestions, improvements, bugs, etc - please share here :-) + + """]] diff --git a/doc/todo/pagespec__95__match__95__list_can_result_in_excessive_dependencies.mdwn b/doc/todo/pagespec__95__match__95__list_can_result_in_excessive_dependencies.mdwn new file mode 100644 index 000000000..9781f7573 --- /dev/null +++ b/doc/todo/pagespec__95__match__95__list_can_result_in_excessive_dependencies.mdwn @@ -0,0 +1,41 @@ +If you say + + pagespec_match_list($page, $spec, list => \@pages) + +with a small list `@pages` and a vague pagespec `$spec`, `$page` ends +up depending on (every page that matches) `$spec`. For instance, if you +already have a list of subpages of the sandbox, and you want to filter it +to only the discussion pages, you can do that like + + pagespec_match_list("sandbox", "*/discussion", + list => ["sandbox/discussion", "sandbox/things", "sandbox/stuff"]) + +but then a change to *any* discussion page will refresh the sandbox. + +The [[bugs/trails depend on everything]] bug was a particularly bad +case of this, with the widest possible pagespec `internal(*)` +matched against a small list (the trail). + +In principle it would be nice if `pagespec_match_list` could detect +this situation and make sandbox depend on only those subpages instead. + +Perhaps if the `list` parameter is given, `p_m_l` should add a +by-name (simple) dependency on each page in that list, instead +of a dependency on the pagespec? Or perhaps it should be documented +that plugins can pass `deptype => 0` to take responsibility for +their own dependency handling, and then do whatever they need? + +Uses of `pagespec_match_list` with a non-trivial list, in-tree, +after [[bugs/trails depend on everything]] is fixed: + +* brokenlinks: really does need to depend on the whole pagespec, + but that could be done separately + +* inline: the inliner already depends on the inlined pages + so no extra dependency is needed + +* pagestats: same as brokenlinks + +My album plugin is in the same situation as inline. + +--[[smcv]] diff --git a/doc/users/kjs.mdwn b/doc/users/kjs.mdwn index cfe13c685..d65b663c8 100644 --- a/doc/users/kjs.mdwn +++ b/doc/users/kjs.mdwn @@ -5,4 +5,7 @@ Websites using ikiwiki: * <http://img.kalleswork.net> * <http://stockholm.kalleswork.net> -Mostly using ikiwiki with the [[/plugins/contrib/album/]] and [[plugins/osm]] plugins. + +Mostly using ikiwiki with the [[/plugins/contrib/album/]] and [[plugins/osm]] plugins. My git repo with tweaks including the simplebw theme and changes to the [[plugins/contrib/album]] templates can be cloned via http at: + +* <http://src.kalleswork.net/ikiwiki.git> |