diff options
Diffstat (limited to 'doc')
67 files changed, 1247 insertions, 99 deletions
diff --git a/doc/bugs/entirely_negated_pagespec_matches_internal_pages.mdwn b/doc/bugs/entirely_negated_pagespec_matches_internal_pages.mdwn index 02ce4e221..a9b223a46 100644 --- a/doc/bugs/entirely_negated_pagespec_matches_internal_pages.mdwn +++ b/doc/bugs/entirely_negated_pagespec_matches_internal_pages.mdwn @@ -21,3 +21,10 @@ pagespec, and implicitly add "and !internal()" to it. Either approach would require fully parsing the pagespec. And consider cases like "!(foo and !bar)". Doesn't seem at all easy to solve. --[[Joey]] + +> It occurs to me that at least one place in ikiwiki optimizes by assuming +> that pagespecs not mentioning the word "internal" never match internal +> pages. I wonder whether this bug could be solved by making that part of +> the definition of a pagespec, rather than a risky optimization +> like it is now? That seems strange, though - having this special case +> would make pagespecs significantly harder to understand. --[[smcv]] diff --git a/doc/bugs/html5_support.mdwn b/doc/bugs/html5_support.mdwn index 09ded91da..783f5e47c 100644 --- a/doc/bugs/html5_support.mdwn +++ b/doc/bugs/html5_support.mdwn @@ -3,8 +3,15 @@ Some elements of safely supported by ikiwiki. There are [several differences between HTML4 and HTML5](http://www.w3.org/TR/html5-diff/). +[[!template id=gitbranch branch=hendry/html5 author="[[Kai_Hendry|hendry]]"]] + * [HTML5 branch](http://git.webconverger.org/?p=ikiwiki;h=refs/heads/html5) * [ikiwiki instance with HTML5 templates](http://natalian.org) +* [HTML5 outliner tool](http://gsnedders.html5.org/outliner/) -- to check you have the structure of your markup correct + +# htmlscrubber.pm needs to not scrub new HTML5 elements + +* [new elements](http://www.w3.org/TR/html5-diff/#new-elements) # HTML5 Validation and t/html.t @@ -28,9 +35,9 @@ This element is poorly supported by browsers. As a workaround, `style.css` needs display: block; } -Internet Explorer will display it as a block, though you can't seem to be further control the style. +Internet Explorer will display it as a block, though you can't seem to be able to further control the style. -# Validator complains with no h1-h6 in header +# Validator complains about no h1-h6 in header * [#509](http://bugzilla.validator.nu/show_bug.cgi?id=509) diff --git a/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn b/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn index 0edba438c..0a67934aa 100644 --- a/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn +++ b/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn @@ -1,3 +1,5 @@ +[[!tag plugins/map patch]] + input: before. @@ -13,7 +15,7 @@ Presuming that the pagespec does not match, output: The UL element is not closed. -Patch[[!tag patch]]: +Patch: --- /usr/share/perl5/IkiWiki/Plugin/map.pm 2009-05-06 00:56:55.000000000 +0100 +++ IkiWiki/Plugin/map.pm 2009-06-15 12:23:54.000000000 +0100 @@ -45,3 +47,47 @@ Patch[[!tag patch]]: >> be regression-test friendly but I might have a go at reworking it. With >> this variety of problem I have a strong inclination to use HOFs like map, >> grep. - [[Jon]] + +>>> The patch in [[map/discussion|plugins/map/discussion]] has the same +>>> problem, but does suggest a simpler approach to solving it (bail out +>>> early if the map has no items at all). --[[smcv]] + +>>>> Thanks for pointing out the problem. I guess this patch should solve it. +>>>> --[[harishcm]] + +>>>>> Well, I suppose that's certainly a minimal patch for this bug :-) +>>>>> I'm not the IkiWiki maintainer, but if I was, I'd apply it, so I've put +>>>>> it in a git branch for Joey's convenience. Joey, Jon: any opinion? +>>>>> +>>>>> If you want to be credited for this patch under a name other than +>>>>> "harishcm" (e.g. your real name), let me know and I'll amend the branch. +>>>>> (Or, make a git branch of your own and replace the reference just below, +>>>>> if you prefer.) --[[smcv]] + +>>>>>> The current arrangement looks fine to me. Thanks. --[[harishcm]] + +[[!template id=gitbranch author="[[harishcm]]" branch=smcv/ready/harishcm-map-fix]] + +Patch: + + --- /usr/local/share/perl/5.8.8/IkiWiki/Plugin/map.pm + +++ map.pm + @@ -80,7 +80,17 @@ + my $indent=0; + my $openli=0; + my $addparent=""; + - my $map = "<div class='map'>\n<ul>\n"; + + my $map = "<div class='map'>\n"; + + + + # Return empty div if %mapitems is empty + + if (!scalar(keys %mapitems)) { + + $map .= "</div>\n"; + + return $map; + + } + + else { # continue populating $map + + $map .= "<ul>\n"; + + } + + + foreach my $item (sort keys %mapitems) { + my @linktext = (length $mapitems{$item} ? (linktext => $mapitems{$item}) : ()); + $item=~s/^\Q$common_prefix\E\/// diff --git a/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn b/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn index 042d6a20c..be14e5126 100644 --- a/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn +++ b/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn @@ -1,3 +1,5 @@ +[[!tag patch plugins/inline patch/core]] + The `IkiWiki::pagetitle` function does not respect title changes via `meta.title`. It really should, so that links rendered with `htmllink` get the proper title in the link text. --[[madduck]] @@ -5,7 +7,7 @@ The `IkiWiki::pagetitle` function does not respect title changes via `meta.title ---- It is possible to set a Page-Title in the meta-plugin, but that one isn't -reused in parentlinks. This [[patch]] may fix it. +reused in parentlinks. This patch may fix it. <ul> <li> I give pagetitle the full path to a page. @@ -132,7 +134,7 @@ diff -c /usr/share/perl5/IkiWiki/Plugin/meta.pm.distrib /usr/share/perl5/IkiWiki > >> It was actually more complicated than expected. A working prototype is >> now in my `meta` branch, see my userpage for the up-to-date url. ->> Thus tagging [[patch]]. --[[intrigeri]] +>> Thus tagging patch. --[[intrigeri]] >> >>> Joey, please consider merging my `meta` branch. --[[intrigeri]] diff --git a/doc/bugs/search_for_locale_data_in_the_installed_location.mdwn b/doc/bugs/search_for_locale_data_in_the_installed_location.mdwn index dace2ca19..08af5fe2c 100644 --- a/doc/bugs/search_for_locale_data_in_the_installed_location.mdwn +++ b/doc/bugs/search_for_locale_data_in_the_installed_location.mdwn @@ -11,7 +11,7 @@ It seems like gettext only searches for locale information in /usr/share/locale, return $gettext_obj->get(shift); } -[[!tag patch]] +[[!tag patch patch/core]] -- [[ThomasBleher]] > According to my testing, this patch makes ikiwiki's localisation fail for diff --git a/doc/git.mdwn b/doc/git.mdwn index 9e28f1464..18fbd238b 100644 --- a/doc/git.mdwn +++ b/doc/git.mdwn @@ -42,6 +42,10 @@ into [[Joey]]'s working tree. This is recommended. :-) * [[ikipostal|DavidBremner]] `git://pivot.cs.unb.ca/git/ikipostal.git` * [[ikimailbox|DavidBremner]] `git://pivot.cs.unb.ca/git/ikimailbox.git` * [[ikiplugins|DavidBremner]] `git://pivot.cs.unb.ca/git/ikiplugins.git` +* [[jonas|JonasSmedegaard]] `git://source.jones.dk/ikiwiki-upstream` +* [[arpitjain]] `git://github.com/arpitjain11/ikiwiki.git` +* [[chrysn]] `git://github.com/github076986099/ikiwiki.git` +* [[simonraven]] `git://github.com/kjikaqawej/ikiwiki-simon.git` ## branches diff --git a/doc/ikiwiki/pagespec.mdwn b/doc/ikiwiki/pagespec.mdwn index b476bde1f..5f0f44e2e 100644 --- a/doc/ikiwiki/pagespec.mdwn +++ b/doc/ikiwiki/pagespec.mdwn @@ -24,17 +24,18 @@ match all pages except for Discussion pages and the SandBox: Some more elaborate limits can be added to what matches using these functions: -* "`link(page)`" - match only pages that link to a given page (or glob) -* "`tagged(tag)`" - match pages that are tagged or link to the given tag (or glob) -* "`backlink(page)`" - match only pages that a given page links to -* "`creation_month(month)`" - match only pages created on the given month +* "`link(page)`" - matches only pages that link to a given page (or glob) +* "`tagged(tag)`" - matches pages that are tagged or link to the given tag (or + tags matched by a glob) +* "`backlink(page)`" - matches only pages that a given page links to +* "`creation_month(month)`" - matches only pages created on the given month * "`creation_day(mday)`" - or day of the month * "`creation_year(year)`" - or year -* "`created_after(page)`" - match only pages created after the given page +* "`created_after(page)`" - matches only pages created after the given page was created -* "`created_before(page)`" - match only pages created before the given page +* "`created_before(page)`" - matches only pages created before the given page was created -* "`glob(someglob)`" - match pages that match the given glob. Just writing +* "`glob(someglob)`" - matches pages that match the given glob. Just writing the glob by itself is actually a shorthand for this function. * "`internal(glob)`" - like `glob()`, but matches even internal-use pages that globs do not usually match. diff --git a/doc/ikiwiki/pagespec/attachment.mdwn b/doc/ikiwiki/pagespec/attachment.mdwn index 344a4a734..419f00ee4 100644 --- a/doc/ikiwiki/pagespec/attachment.mdwn +++ b/doc/ikiwiki/pagespec/attachment.mdwn @@ -16,14 +16,14 @@ check all attachments for viruses, something like this could be used: The regular [[ikiwiki/PageSpec]] syntax is expanded with the following additional tests: -* "`maxsize(size)`" - Tests whether the attachment is no larger than the +* "`maxsize(size)`" - tests whether the attachment is no larger than the specified size. The size defaults to being in bytes, but "kb", "mb", "gb" etc can be used to specify the units. -* "`minsize(size)`" - Tests whether the attachment is no smaller than the +* "`minsize(size)`" - tests whether the attachment is no smaller than the specified size. -* "`ispage()`" - Tests whether the attachment will be treated by ikiwiki as a +* "`ispage()`" - tests whether the attachment will be treated by ikiwiki as a wiki page. (Ie, if it has an extension of ".mdwn", or of any other enabled page format). @@ -31,7 +31,7 @@ additional tests: use `!ispage()` ; if you only want to allow wiki pages to be uploaded as attachments, use `ispage()`. -* "`mimetype(foo/bar)`" - This checks the MIME type of the attachment. You can +* "`mimetype(foo/bar)`" - checks the MIME type of the attachment. You can include a glob in the type, for example `mimetype(image/*)`. -* "`virusfree()`" - Checks the attachment with an antiviral program. +* "`virusfree()`" - checks the attachment with an antiviral program. diff --git a/doc/ikiwiki/pagespec/po.mdwn b/doc/ikiwiki/pagespec/po.mdwn new file mode 100644 index 000000000..e0264dd50 --- /dev/null +++ b/doc/ikiwiki/pagespec/po.mdwn @@ -0,0 +1,16 @@ +[[!if test="enabled(po)" + then="This wiki has po support **enabled**." + else="This wiki has po support **disabled**."]] + +If the [[!iki plugins/po desc=po]] plugin is enabled, the regular +[[ikiwiki/PageSpec]] syntax is expanded with the following additional +tests that can be used to improve user navigation in a multi-lingual +wiki: + +* "`lang(LL)`" - tests whether a page is written in the language + specified as a ISO639-1 (two-letter) language code. +* "`currentlang()`" - tests whether a page is written in the same + language as the current page. + +Note that every non-po page is considered to be written in +`po_master_language`, as specified in `ikiwiki.setup`. diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn index 8155790d7..72bdbf3d8 100644 --- a/doc/ikiwikiusers.mdwn +++ b/doc/ikiwikiusers.mdwn @@ -3,7 +3,6 @@ Projects & Organizations * [This wiki](http://ikiwiki.info) (of course!) * [Planet Debian upstream](http://updo.debian.net/) -* The [ion window manager homepage](http://modeemi.fi/~tuomov/ion/) * [Debian Mentors wiki](http://jameswestby.net/mentors/) * The [Sparse wiki](http://kernel.org/pub/linux/kernel/people/josh/sparse). * [The BSD Associate Admin Book Project](http://bsdwiki.reedmedia.net/) @@ -123,6 +122,7 @@ Personal sites and blogs * [NeoCarz Wiki](http://www.neocarz.com/wiki/) Yes - its actually Ikiwiki behind that! I'm using Nginx and XSL to transform the ikiwiki renderings thanks to the valid XHTML output of ikiwiki. Great work Joey!! * [Natalian - Kai Hendry's personal blog](http://natalian.org/) * [Mick Pollard aka \_lunix_ - Personal sysadmin blog and wiki](http://www.lunix.com.au) +* [tumashu's page](http://tumashu.github.com) This is my personal site in github created with ikiwiki and only a page,you can get the [source](http://github.com/tumashu/tumashu/tree/master) Please feel free to add your own ikiwiki site! diff --git a/doc/pagehistory.mdwn b/doc/pagehistory.mdwn index 465062736..5c3b4a8d0 100644 --- a/doc/pagehistory.mdwn +++ b/doc/pagehistory.mdwn @@ -1,8 +1,8 @@ ikiwiki supports adding "History" links to the top of pages to browse the -revison history of a page. This is enabled by the `historyurl` setting, +revision history of a page. This is enabled by the `historyurl` setting, which is used to specify the URL to a web interface such as [[ViewVC]] (for Subversion) or [[Gitweb]]. In that url, "\[[file]]" is replaced with the name of the file to view. -The [[plugins/repolist]] plugin can suppliment this information with +The [[plugins/repolist]] plugin can supplement this information with urls to the underlying repository of the wiki. diff --git a/doc/patch/core.mdwn b/doc/patch/core.mdwn new file mode 100644 index 000000000..fcf0bdb72 --- /dev/null +++ b/doc/patch/core.mdwn @@ -0,0 +1,7 @@ +Some [[patches|patch]] affect the ikiwiki core, rather than just a plugin. +This tag collects those patches. Please tag such patches with 'patch/core' +as well as 'patch'. + +[[!inline pages="(todo/* or bugs/*) and link(patch/core) + and !link(bugs/done) and !link(todo/done) and !*/Discussion" + rootpage="todo" archive="yes"]] diff --git a/doc/plugins/anonok.mdwn b/doc/plugins/anonok.mdwn index 497ca07c8..506657a1c 100644 --- a/doc/plugins/anonok.mdwn +++ b/doc/plugins/anonok.mdwn @@ -5,7 +5,12 @@ By default, anonymous users cannot edit the wiki. This plugin allows anonymous web users, who have not signed in, to edit any page in the wiki by default. -The plugin also has a configuration setting, `anonok_pagespec`. This +Please think twice before enabling this plugin. If your wiki is accessible +to the internet, it *will* be subject to spamming if this plugin is +enabled. Such spam is not only a pain to deal with, but it bloats the +revision control history of your wiki. + +The plugin has a configuration setting, `anonok_pagespec`. This [[ikiwiki/PageSpec]] can be used to allow anonymous editing of matching pages. If you're using the [[comments]] plugin, you can allow anonymous comments diff --git a/doc/plugins/comments/discussion.mdwn b/doc/plugins/comments/discussion.mdwn index 3d7452b9a..396d1f6d4 100644 --- a/doc/plugins/comments/discussion.mdwn +++ b/doc/plugins/comments/discussion.mdwn @@ -161,3 +161,30 @@ Raw HTML was not initially allowed by default (this was configurable). >>> all directives will contine to be inexpensive and safe enough that it's >>> sensible to allow users to (ab)use them on open wikis. >>> --[[Joey]] + +---- + +I have a test ikiwiki setup somewhere to investigate adopting the comments +plugin. It is setup with no auth enabled and I got hammered with a spam attack +over the last weekend (predictably). What surprised me was the scale of the +attack: ikiwiki eventually triggered OOM and brought the box down. When I got +it back up, I checked out a copy of the underlying git repository, and it +measured 280M in size after being packed. Of that, about 300K was data prior +to the spam attack, so the rest was entirely spam text, compressed via git's +efficient delta compression. + +I had two thoughts about possible improvements to the comments plugin in the +wake of this: + + * comment pagination - there is a hard-to-define upper limit on the number + of comments that can be appended to a wiki page whilst the page remains + legible. It would be useful if comments could be paginated into sub-pages. + + * crude flood control - asides from spam attacks (and I am aware of + [[plugins/blogspam]]), people can crap flood or just aggressively flame + repeatedly. An interesting prevention measure might be to not let an IP + post more than 3 sequential comments to a page, or to the site, without + at least one other comment being interleaved. I say 3 rather than 2 since + correction follow-ups are common. + +-- [[Jon]] diff --git a/doc/plugins/contrib/album.mdwn b/doc/plugins/contrib/album.mdwn index 94d5789d7..f550ca64c 100644 --- a/doc/plugins/contrib/album.mdwn +++ b/doc/plugins/contrib/album.mdwn @@ -1,4 +1,5 @@ [[!template id=plugin name=album author="[[Simon_McVittie|smcv]]"]] +[[!template id=gitbranch branch=smcv/album author="[[Simon_McVittie|smcv]]"]] [[!tag type/chrome]] Available from [[smcv]]'s git repository, in the `album` branch diff --git a/doc/plugins/contrib/default_content_for___42__copyright__42___and___42__license__42__.mdwn b/doc/plugins/contrib/default_content_for___42__copyright__42___and___42__license__42__.mdwn index 5e3db3d7c..b9ad3cc8e 100644 --- a/doc/plugins/contrib/default_content_for___42__copyright__42___and___42__license__42__.mdwn +++ b/doc/plugins/contrib/default_content_for___42__copyright__42___and___42__license__42__.mdwn @@ -39,3 +39,9 @@ I'm missing something terribly obvious? --Peter By the way: these need not be *HTML* files; `copyright.mdwn`, respectively `license.mdwn`, or every other format supported by ikiwiki are likewise fine. --[[tschwinge]] + +> Jon has done something similar in [[todo/allow_site-wide_meta_definitions]]; +> his version has the advantages that it doesn't invent magical page names, +> and can extend beyond just copyright and license, but has the disadvantage +> that it doesn't support setting defaults for a given "subdirectory" +> only. --[[smcv]] diff --git a/doc/plugins/contrib/trail.mdwn b/doc/plugins/contrib/trail.mdwn new file mode 100644 index 000000000..52dea52d6 --- /dev/null +++ b/doc/plugins/contrib/trail.mdwn @@ -0,0 +1,61 @@ +[[!tag type/chrome patch]] +[[!template id=gitbranch branch=smcv/trail author="[[smcv]]"]] + +Available from [[smcv]]'s git repository, in the `trail` branch. This +plugin aims to solve [[todo/wikitrails]] in a simpler way. + +Joey: what do you think of this plugin? If you like the general approach +and are likely to include it in ikiwiki, I'll try to modify +[[plugins/contrib/album]] to be based on it, rather than partially +reinventing it. + +This plugin can benefit from +[[another_of_my_branches|todo/inline_plugin:_specifying_ordered_page_names]] +but does not require it. + +---- + +[[!template id=plugin name=trail author="[[Simon_McVittie|smcv]]"]] + +It's sometimes useful to have "trails" of pages in a wiki, as a guided +tour, sequence of chapters etc. In this plugin, a trail is represented +by a page, and the pages in the trail are indicated by specially marked +links within that page. + +If using the default `page.tmpl`, each page automatically displays the +trails that it's a member of (if any), with links to the trail and to +the next and previous members. + +The `traillink` [[ikiwiki/directive]] is used to record which pages +are in a trail, and simultaneously link to them. Alternatively, the +[[ikiwiki/directive/inline]] directive can be used with `trail=yes` +to record the inlined pages as part of the trail, in the order in +which they are inlined. + +## Directives + +(These will go to the appropriate pages in [[ikiwiki/directive]] if this +plugin is included in ikiwiki.) + +### traillink + +The `traillink` directive is supplied by the [[!iki plugins/contrib/trail desc=trail]] +plugin. This directive appears on the page representing a trail. It acts +as a visible [[ikiwiki/WikiLink]], but also records the linked page as +a member of the trail. + +Various syntaxes can be used: + + \[[!traillink Badgers]] + \[[!traillink How_to_find_mushrooms_using_badgers|badgers]] + \[[!traillink badgers text="How to find mushrooms using badgers"]] + +### trailoptions + +The `trailoptions` directive is supplied by the [[!iki plugins/contrib/trail desc=trail]] +plugin. This directive appears on the page representing a trail, and +produces no output. + +Currently, the only option supported is `[[!trailoptions circular=yes]]`, +which adds links between the first and last pages, turning the trail into +a circle. diff --git a/doc/plugins/map/discussion.mdwn b/doc/plugins/map/discussion.mdwn index c724a6492..2f7b140d6 100644 --- a/doc/plugins/map/discussion.mdwn +++ b/doc/plugins/map/discussion.mdwn @@ -18,3 +18,32 @@ We'd also very much like to have an option to display the title of the page inst There's a patch implementing this in [[!debbug 484510]]. It needs a few fixes before I merge it. Now applied. --[[Joey]] + +---- + +I noticed that when the pagespec returns no map items, the map plugin does not close off the ul and div tags. Below is a simple patch +that seems to work on the examples I tried. I am a beginner so please help me out here. Thanks. --[[harishcm]] + + --- a/map.pm + +++ b/map.pm + @@ -81,6 +81,13 @@ + my $openli=0; + my $addparent=""; + my $map = "<div class='map'>\n<ul>\n"; + + + + # Return properly closed $map if %mapitems is empty + + if (!scalar(keys %mapitems)) { + + $map .= "</ul>\n</div>\n"; + + return $map; + + } + + + foreach my $item (sort keys %mapitems) { + my @linktext = (length $mapitems{$item} ? (linktext => $mapitems{$item}) : ()); + $item=~s/^\Q$common_prefix\E\/// + +> This was also reported as [[bugs/map_fails_to_close_ul_element_for_empty_list]]; +> this patch is simpler than the one there, but has the same problem (it emits +> `<ul></ul>`, which technically isn't valid HTML either). --[[smcv]] + +>> Thanks for the tip, I added another patch addressing the issue at +>> [[bugs/map_fails_to_close_ul_element_for_empty_list]]. --[[harishcm]] diff --git a/doc/plugins/po.mdwn b/doc/plugins/po.mdwn new file mode 100644 index 000000000..0c8110563 --- /dev/null +++ b/doc/plugins/po.mdwn @@ -0,0 +1,296 @@ +[[!template id=plugin name=po core=0 author="[[intrigeri]]"]] +[[!tag type/format]] + +This plugin adds support for multi-lingual wikis, translated with +gettext, using [po4a](http://po4a.alioth.debian.org/). + +It depends on the Perl `Locale::Po4a::Po` library (`apt-get install po4a`). +As detailed bellow in the security section, `po4a` is subject to +denial-of-service attacks before version 0.35. + +[[!toc levels=2]] + +Introduction +============ + +A language is chosen as the "master" one, and any other supported +language is a "slave" one. + +A page written in the "master" language is a "master" page. It can be +of any page type supported by ikiwiki, except `po`. It does not have to be +named a special way: migration to this plugin does not imply any page +renaming work. + +Example: `bla/page.mdwn` is a "master" Markdown page written in +English; if `usedirs` is enabled, it is rendered as +`bla/page/index.en.html`, else as `bla/page.en.html`. + +Any translation of a "master" page into a "slave" language is called +a "slave" page; it is written in the gettext PO format. `po` is now +a page type supported by ikiwiki. + +Example: `bla/page.fr.po` is the PO "message catalog" used to +translate `bla/page.mdwn` into French; if `usedirs` is enabled, it is +rendered as `bla/page/index.fr.html`, else as `bla/page.fr.html` + +(In)Compatibility +================= + +This plugin does not support the `indexpages` mode. If you don't know +what it is, you probably don't care. + + +Configuration +============= + +Supported languages +------------------- + +`po_master_language` is used to set the "master" language in +`ikiwiki.setup`, such as: + + po_master_language => { 'code' => 'en', 'name' => 'English' } + +`po_slave_languages` is used to set the list of supported "slave" +languages, such as: + + po_slave_languages => { 'fr' => 'Français', + 'es' => 'Español', + 'de' => 'Deutsch', + } + +Decide which pages are translatable +----------------------------------- + +The `po_translatable_pages` setting configures what pages are +translatable. It is a [[ikiwiki/PageSpec]], so you have lots of +control over what kind of pages are translatable. + +The `.po` files are not considered as being translatable, so you don't need to +worry about excluding them explicitly from this [[ikiwiki/PageSpec]]. + +Internal links +-------------- + +### Links targets + +The `po_link_to` option in `ikiwiki.setup` is used to decide how +internal links should be generated, depending on web server features +and site-specific preferences. + +#### Default linking behavior + +If `po_link_to` is unset, or set to `default`, ikiwiki's default +linking behavior is preserved: `\[[destpage]]` links to the master +language's page. + +#### Link to current language + +If `po_link_to` is set to `current`, `\[[destpage]]` links to the +`destpage`'s version written in the current page's language, if +available, *i.e.*: + +* `foo/destpage/index.LL.html` if `usedirs` is enabled +* `foo/destpage.LL.html` if `usedirs` is disabled + +#### Link to negotiated language + +If `po_link_to` is set to `negotiated`, `\[[page]]` links to the +negotiated preferred language, *i.e.* `foo/page/`. + +(In)compatibility notes: + +* if `usedirs` is disabled, it does not make sense to set `po_link_to` + to `negotiated`; this option combination is neither implemented + nor allowed. +* if the web server does not support Content Negotiation, setting + `po_link_to` to `negotiated` will produce a unusable website. + +Server support +============== + +Apache +------ + +Using Apache `mod_negotiation` makes it really easy to have Apache +serve any page in the client's preferred language, if available. +This is the default Debian Apache configuration. + +When `usedirs` is enabled, one has to set `DirectoryIndex index` for +the wiki context. + +Setting `DefaultLanguage LL` (replace `LL` with your default MIME +language code) for the wiki context can help to ensure +`bla/page/index.en.html` is served as `Content-Language: LL`. + +lighttpd +-------- + +lighttpd unfortunately does not support content negotiation. + +**FIXME**: does `mod_magnet` provide the functionality needed to + emulate this? + + +Usage +===== + +Templates +--------- + +When `po_link_to` is not set to `negotiated`, one should replace some +occurrences of `BASEURL` with `HOMEPAGEURL` to get correct links to +the wiki homepage. + +The `ISTRANSLATION` and `ISTRANSLATABLE` variables can be used to +display things only on translatable or translation pages. + +### Display page's versions in other languages + +The `OTHERLANGUAGES` loop provides ways to display other languages' +versions of the same page, and the translations' status. + +An example of its use can be found in the default +`templates/page.tmpl`. In case you want to customize it, the following +variables are available inside the loop (for every page in): + +* `URL` - url to the page +* `CODE` - two-letters language code +* `LANGUAGE` - language name (as defined in `po_slave_languages`) +* `MASTER` - is true (1) if, and only if the page is a "master" page +* `PERCENT` - for "slave" pages, is set to the translation completeness, in percents + +### Display the current translation status + +The `PERCENTTRANSLATED` variable is set to the translation +completeness, expressed in percent, on "slave" pages. It is used by +the default `templates/page.tmpl`. + +Additional PageSpec tests +------------------------- + +This plugin enhances the regular [[ikiwiki/PageSpec]] syntax with some +additional tests that are documented [[here|ikiwiki/pagespec/po]]. + +Automatic PO file update +------------------------ + +Committing changes to a "master" page: + +1. updates the POT file and the PO files for the "slave" languages; + the updated PO files are then put under version control; +2. triggers a refresh of the corresponding HTML slave pages. + +Also, when the plugin has just been enabled, or when a page has just +been declared as being translatable, the needed POT and PO files are +created, and the PO files are checked into version control. + +Discussion pages and other sub-pages +------------------------------------ + +Discussion should happen in the language in which the pages are +written for real, *i.e.* the "master" one. If discussion pages are +enabled, "slave" pages therefore link to the "master" page's +discussion page. + +Likewise, "slave" pages are not supposed to have sub-pages; +[[WikiLinks|wikilink]] that appear on a "slave" page therefore link to +the master page's sub-pages. + +Translating +----------- + +One can edit the PO files using ikiwiki's CGI (a message-by-message +interface could also be implemented at some point). + +If [[tips/untrusted_git_push]] is setup, one can edit the PO files in one's +preferred `$EDITOR`, without needing to be online. + +Markup languages support +------------------------ + +[[Markdown|mdwn]] is well supported. Some other markup languages supported +by ikiwiki mostly work, but some pieces of syntax are not rendered +correctly on the slave pages: + +* [[reStructuredText|rst]]: anonymous hyperlinks and internal + cross-references +* [[wikitext]]: conversion of newlines to paragraphs +* [[creole]]: verbatim text is wrapped, tables are broken +* [[html]] and LaTeX: not supported yet; the dedicated po4a modules + could be used to support them, but they would need a security audit +* other markup languages have not been tested. + +Security +======== + +[[po/discussion]] contains a detailed security analysis of this plugin +and its dependencies. + +When using po4a older than 0.35, it is recommended to uninstall +`Text::WrapI18N` (Debian package `libtext-wrapi18n-perl`), in order to +avoid a potential denial of service. + +TODO +==== + +Better links +------------ + +Once the fix to +[[bugs/pagetitle_function_does_not_respect_meta_titles]] from +[[intrigeri]]'s `meta` branch is merged into ikiwiki upstream, the +generated links' text will be optionally based on the page titles set +with the [[meta|plugins/meta]] plugin, and will thus be translatable. +It will also allow displaying the translation status in links to slave +pages. Both were implemented, and reverted in commit +ea753782b222bf4ba2fb4683b6363afdd9055b64, which should be reverted +once [[intrigeri]]'s `meta` branch is merged. + +An integration branch, called `meta-po`, merges [[intrigeri]]'s `po` +and `meta` branches, and thus has thise additional features. + +Self links +---------- + +If a page contains a WikiLink to itself, ikiwiki does not normally +turn that into a hyperlink. However, if a translated page contains a +WikiLink to itself, a hyperlink is inserted, at least with the default +`po_link_to` the link points to the English version of the page. Is there a +good reason for that to be done? --[[Joey]] + +Language display order +---------------------- + +Jonas pointed out that one might want to control the order that links to +other languages are listed, for various reasons. Currently, there is no +order, as `po_slave_languages` is a hash. It would need to be converted +to an array to support this. (If twere done, twere best done quickly.) +--[[Joey]] + +Duplicate %links ? +------------------ + +I notice code in the scan hook that seems to assume +that %links will accumulate duplicate links for a page. +That used to be so, but the bug was fixed. Does this mean +that po might be replacing the only link on a page, in error? +--[[Joey]] + +Bug when editing underlay file +------------------------------ + +While I've gotten translated underlays working, there is a bug +if the wiki is currently using a page from the underlay, and the master +language version is edited. This causes the edited page to be saved +to srcdir.. and all the translations get set to 0% and their +po files have the translated strings "emptied". What's really going on +is that these are entirely new po files not based on the old ones +in the basewiki, and thus lacking translations. --[[Joey]] + +Documentation +------------- + +Maybe write separate documentation depending on the people it targets: +translators, wiki administrators, hackers. This plugin may be complex +enough to deserve this. diff --git a/doc/plugins/contrib/po.mdwn b/doc/plugins/po/discussion.mdwn index 665e48343..1c3f0e752 100644 --- a/doc/plugins/contrib/po.mdwn +++ b/doc/plugins/po/discussion.mdwn @@ -1,3 +1,216 @@ +[[!toc ]] + +---- + +# Security review + +## Probable holes + +_(The list of things to fix.)_ + +### po4a-gettextize + +* po4a CVS 2009-01-16 +* Perl 5.10.0 + +`po4a-gettextize` uses more or less the same po4a features as our +`refreshpot` function. + +Without specifying an input charset, zzuf'ed `po4a-gettextize` quickly +errors out, complaining it was not able to detect the input charset; +it leaves no incomplete file on disk. I therefore had to pretend the +input was in UTF-8, as does the po plugin. + + zzuf -c -s 13 -r 0.1 \ + po4a-gettextize -f text -o markdown -M utf-8 -L utf-8 \ + -m GPL-3 -p GPL-3.pot + +Crashes with: + + Malformed UTF-8 character (UTF-16 surrogate 0xdfa4) in substitution + iterator at /usr/share/perl5/Locale/Po4a/Po.pm line 1449. + Malformed UTF-8 character (fatal) at /usr/share/perl5/Locale/Po4a/Po.pm + line 1449. + +An incomplete pot file is left on disk. Unfortunately Po.pm tells us +nothing about the place where the crash happens. + +> It's fairly standard perl behavior when fed malformed utf-8. As long +> as it doesn't crash ikiwiki, it's probably acceptable. Ikiwiki can +> do some similar things itself when fed malformed utf-8 (doesn't +> crash tho) --[[Joey]] + +---- + +## Potential gotchas + +_(Things not to do.)_ + + +### Blindly activating more po4a format modules + +The format modules we want to use have to be checked, as not all are +safe (e.g. the LaTeX module's behaviour is changed by commands +included in the content); they may use regexps generated from +the content. + +---- + +## Hopefully non-holes + +_(AKA, the assumptions that will be the root of most security holes...)_ + +### PO file features + +No [documented](http://www.gnu.org/software/gettext/manual/gettext.html#PO-Files) +directive that can be put in po files is supposed to cause mischief +(ie, include other files, run commands, crash gettext, whatever). + +### gettext + +#### Security history + +The only past security issue I could find in GNU gettext is +[CVE-2004-0966](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0966), +*i.e.* [Debian bug #278283](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=278283): +the autopoint and gettextize scripts in the GNU gettext package (1.14 +and later versions) may allow local users to overwrite files via +a symlink attack on temporary files. + +This plugin would not have allowed to exploit this bug, as it does not +use, either directly or indirectly, the faulty scripts. + +Note: the lack of found security issues can either indicate that there +are none, or reveal that no-one ever bothered to find or publish them. + +#### msgmerge + +`refreshpofiles()` runs this external program. + +* I was not able to crash it with `zzuf`. +* I could not find any past security hole. + +#### msgfmt + +`isvalidpo()` runs this external program. + +* I was not able to make it behave badly using zzuf: it exits cleanly + when too many errors are detected. +* I could not find any past security hole. + +### po4a + +#### Security history + +The only past security issue I could find in po4a is +[CVE-2007-4462](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4462): +`lib/Locale/Po4a/Po.pm` in po4a before 0.32 allowed local users to +overwrite arbitrary files via a symlink attack on the +gettextization.failed.po temporary file. + +This plugin would not have allowed to exploit this bug, as it does not +use, either directly or indirectly, the faulty `gettextize` function. + +Note: the lack of found security issues can either indicate that there +are none, or reveal that no-one ever bothered to find or publish them. + +#### General feeling + +Are there any security issues on running po4a on untrusted content? + +To say the least, this issue is not well covered, at least publicly: + +* the documentation does not talk about it; +* grep'ing the source code for `security` or `trust` gives no answer. + +On the other hand, a po4a developer answered my questions in +a convincing manner, stating that processing untrusted content was not +an initial goal, and analysing in detail the possible issues. +The following analysis was done with his help. + +#### Details + +* the core (`Po.pm`, `Transtractor.pm`) should be safe +* po4a source code was fully checked for other potential symlink + attacks, after discovery of one such issue +* the only external program run by the core is `diff`, in `Po.pm` (in + parts of its code we don't use) +* `Locale::gettext` is only used to display translated error messages +* Nicolas François "hopes" `DynaLoader` is safe, and has "no reason to + think that `Encode` is not safe" +* Nicolas François has "no reason to think that `Encode::Guess` is not + safe". The po plugin nevertheless avoids using it by defining the + input charset (`file_in_charset`) before asking `TransTractor` to + read any file. NB: this hack depends on po4a internals. + +##### Locale::Po4a::Text + +* does not run any external program +* only `do_paragraph()` builds regexp's that expand untrusted + variables; according to [[Joey]], this is "Freaky code, but seems ok + due to use of `quotementa`". + +##### Text::WrapI18N + +`Text::WrapI18N` can cause DoS +([Debian bug #470250](http://bugs.debian.org/470250)). +It is optional, and we do not need the features it provides. + +If a recent enough po4a (>=0.35) is installed, this module's use is +fully disabled. Else, the wiki administrator is warned about this +at runtime. + +##### Term::ReadKey + +`Term::ReadKey` is not a hard dependency in our case, *i.e.* po4a +works nicely without it. But the po4a Debian package recommends +`libterm-readkey-perl`, so it will probably be installed on most +systems using the po plugin. + +`Term::ReadKey` has too far reaching implications for us to +be able to guarantee anything wrt. security. + +If a recent enough po4a (>=2009-01-15 CVS, which will probably be +released as 0.35) is installed, this module's use is fully disabled. + +##### Fuzzing input + +###### po4a-translate + +* po4a CVS 2009-01-16 +* Perl 5.10.0 + +`po4a-translate` uses more or less the same po4a features as our +`filter` function. + +Without specifying an input charset, same behaviour as +`po4a-gettextize`, so let's specify UTF-8 as input charset as of now. + +`LICENSES` is a 21M file containing 100 concatenated copies of all the +files in `/usr/share/common-licenses/`; I had no existing PO file or +translated versions at hand, which renders these tests +quite incomplete. + + zzuf -cv -s 0:10 -r 0.001:0.3 \ + po4a-translate -d -f text -o markdown -M utf-8 -L utf-8 \ + -k 0 -m LICENSES -p LICENSES.fr.po -l test.fr + +... seems to lose the fight, at the `readpo(LICENSES.fr.po)` step, +against some kind of infinite loop, deadlock, or any similar beast. + +The root of this bug lies in `Text::WrapI18N`, see the corresponding +section. + + +---- + +## Fixed holes + + +---- + +# original contrib/po page, with old commentary + I've been working on a plugin called "po", that adds support for multi-lingual wikis, translated with gettext, using [po4a](http://po4a.alioth.debian.org/). @@ -153,11 +366,13 @@ Any thoughts on this? >> basewiki, which seems like it should be pretty easy to do, and would be >> a great demo! --[[Joey]] >> ->>> I have a complete translation of basewiki into danish, and am working with +>>> I have a complete translation of basewiki into danish, available merged into +>>> ikiwiki at git://source.jones.dk/ikiwiki-upstream (branch underlay-da), and am working with >>> others on preparing one in german. For a complete translated user >>> experience, however, you will also need templates translated (there are a few ->>> translatable strings there too). My not-yet-merged po4a Markdown improvements ->>> (see [bug#530574](http://bugs.debian.org/530574)) correctly handles multiple +>>> translatable strings there too). My most recent po4a Markdown improvements +>>> adopted upstream but not yet in Debian (see +>>> [bug#530574](http://bugs.debian.org/530574)) correctly handles multiple >>> files in a single PO which might be relevant for template translation handling. >>> --[[JonasSmedegaard]] >> @@ -452,3 +667,35 @@ daring a timid "please pull"... or rather, please review again :) secondary parameter overriding the default locale (for messages like "N/A" as percentage in po plugin). Alternatively (with above mentioned template support) all such strings could be externalized as templates that can then be localized. + +# Robustness tests + +### Enabling/disabling the plugin + +* enabling the plugin with `po_translatable_pages` set to blacklist: **OK** +* enabling the plugin with `po_translatable_pages` set to whitelist: **OK** +* enabling the plugin without `po_translatable_pages` set: **OK** +* disabling the plugin: **OK** + +### Changing the plugin config + +* adding existing pages to `po_translatable_pages`: **OK** +* removing existing pages from `po_translatable_pages`: **OK** +* adding a language to `po_slave_languages`: **OK** +* removing a language from `po_slave_languages`: **OK** +* changing `po_master_language`: **OK** +* replacing `po_master_language` with a language previously part of + `po_slave_languages`: needs two rebuilds, but **OK** (this is quite + a perverse test actually) + +### Creating/deleting/renaming pages + +All cases of master/slave page creation/deletion/rename, both via RCS +and via CGI, have been tested. + +### Misc + +* general test with `usedirs` disabled: **OK** +* general test with `indexpages` enabled: **not OK** +* general test with `po_link_to=default` with `userdirs` enabled: **OK** +* general test with `po_link_to=default` with `userdirs` disabled: **OK** diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn index d0f6a09e1..3976f9adf 100644 --- a/doc/plugins/write.mdwn +++ b/doc/plugins/write.mdwn @@ -330,6 +330,26 @@ This hook should avoid directly redirecting the user to a signin page, since it's sometimes used to test to see which pages in a set of pages a user can edit. +### canremove + + hook(type => "canremove", id => "foo", call => \&canremove); + +This hook can be used to implement arbitrary access methods to control +when a page can be removed using the web interface (commits from +revision control bypass it). It works exactly like the `canedit` hook, +but is passed the named parameters `cgi` (a CGI object), `session` +(a session object) and `page` (the page subject to deletion). + +### canrename + + hook(type => "canrename", id => "foo", call => \&canrename); + +This hook can be used to implement arbitrary access methods to control when +a page can be renamed using the web interface (commits from revision control +bypass it). It works exactly like the `canedit` hook, +but is passed the named parameters `cgi` (a CGI object), `session` (a +session object), `src`, `srcfile`, `dest` and `destfile`. + ### checkcontent hook(type => "checkcontent", id => "foo", call => \&checkcontent); @@ -342,8 +362,9 @@ the content the user has entered is a comment, it may also be passed some additional parameters: `author`, `url`, and `subject`. The `subject` parameter may also be filled with the user's comment about the change. -Note: When the user edits an existing wiki page, the passed `content` will -include only the lines that they added to the page, or modified. +Note: When the user edits an existing wiki page, this hook is also +passed a `diff` named parameter, which will include only the lines +that they added to the page, or modified. The hook should return `undef` on success. If the content is disallowed, it should return a message stating what the problem is, or a function @@ -394,9 +415,28 @@ they're saved, etc. hook(type => "renamepage", id => "foo", call => \&renamepage); This hook is called by the [[plugins/rename]] plugin when it renames -something. The hook is passed named parameters: `page`, `oldpage`, -`newpage`, and `content`, and should try to modify the content to reflect -the name change. For example, by converting links to point to the new page. +something, once per page linking to the renamed page's old location. +The hook is passed named parameters: `page`, `oldpage`, `newpage`, and +`content`, and should try to modify the content of `page` to reflect +the name change. For example, by converting links to point to the +new page. + +### rename + + hook(type => "rename", id => "foo", call => \&rename); + +When a page or set of pages is renamed, the referenced function is +called for every page, and is passed named parameters: + +* `torename`: a reference to a hash with keys: `src`, `srcfile`, + `dest`, `destfile`, `required`. +* `cgi`: a CGI object +* `session`: a session object. + +Such a hook function returns any additional rename hashes it wants to +add. This hook is applied recursively to returned additional rename +hashes, so that it handles the case where two plugins use the hook: +plugin A would see when plugin B adds a new file to be renamed. ### getsetup @@ -601,7 +641,7 @@ pages, as described in [[ikiwiki/SubPage/LinkingRules]]. Many plugins need to generate html links and add them to a page. This is done by using the `htmllink` function. The usual way to call -`htmlllink` is: +`htmllink` is: htmllink($page, $page, $link) @@ -810,7 +850,7 @@ of the page with the rcs's conflict markers on failure. Passed a message, user, and ip address. Should commit all staged changes. Returns undef on success, and an error message on failure. -Changes can be staged by calls to `rcs_add, `rcs_remove`, and +Changes can be staged by calls to `rcs_add`, `rcs_remove`, and `rcs_rename`. #### `rcs_add($)` diff --git a/doc/post-commit/discussion.mdwn b/doc/post-commit/discussion.mdwn index 31347a614..bbe529106 100644 --- a/doc/post-commit/discussion.mdwn +++ b/doc/post-commit/discussion.mdwn @@ -45,3 +45,18 @@ Thanks > Yes, ikiwiki does expect you to use your revision control system to check > in changes. Otherwise, recentchanges cannot work right, since it uses the > commit history from your revision control system. --[[Joey]] + +----- + +I'm working on an [[rcs]] plugin for CVS, adapted from `svn.pm`, in order to integrate ikiwiki at sites where that's all they've got. What's working so far: web commit (post-commit hook and all), diff, add (under certain conditions), and remove. What's not working: with rcs_add(), iff any of the new page's parent dirs aren't already under CVS control and the post-commit hook is enabled, the browser and ikiwiki stall for several seconds trying to add it, then time out. (If I kill ikiwiki when this is happening, it cvs adds the topmost parent that needed adding; if I wait for timeout, it doesn't. I think.) If I disable the post-commit hook and do the same kind of thing, the page is created and saved. + +In case you're lucky enough not to know, cvs adds on directories are weird -- they operate immediately against the repository, unlike file adds: + + $ cvs add randomdir + Directory /Users/schmonz/Documents/cvswiki/repository/ikiwiki/randomdir added to the repository + +I was able to work out that when I'm seeing this page save misbehavior, my plugin is somewhere inside `system("cvs", "-Q", "add", "$file")`, which was never returning. If I changed it to anything other than cvs it iterated correctly over all the parent dirs which needed to be added to CVS, in the proper order. (cvs add isn't recursive, sadly.) + +Can you offer an educated guess what's going wrong here? --[[Schmonz]] + +> Got `rcs_recentchanges` working, believe it or not, thanks to [cvsps](http://www.cobite.com/cvsps/). If I can figure out this interaction between the post-commit hook and `cvs add` on directories, the CVS plugin is mostly done. Could it be a locking issue? Where should I be looking? Any suggestions appreciated. --[[Schmonz]] diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn index 5e9c05225..6730dd146 100644 --- a/doc/sandbox.mdwn +++ b/doc/sandbox.mdwn @@ -106,7 +106,56 @@ But, of course, rsync is better. Let's see what happens... ~~ -測試的啦 +#中文标题一 +##中文标题二 +###中文标题三 +... +######中文标题六 + +###正文: + +君不见，黄河之水天上来，奔流到海不复回。 + +君不见，高堂明镜悲白发，朝如青丝暮成雪。 + +人生得意须尽欢，莫使金樽空对月。 + +天生我材必有用，千金散尽还复来。 + +###列表： + +* 天空 + + 1. 蓝色的 + 2. 好高啊 + +* 海洋 + + 1. 有鱼 + + * 鲸鱼 + * 鲨鱼 + + +* 大地 + +###链接： + +[谷歌](http://www.google.com) + +###引用： + +> 一级引用 +> +> 一级引用 +> +> > 二级引用 +> +>> 没有空格也可以 +>>> 三级引用 +> +> 回到一级引用 + ---- diff --git a/doc/templates/gitbranch.mdwn b/doc/templates/gitbranch.mdwn new file mode 100644 index 000000000..fcce925d9 --- /dev/null +++ b/doc/templates/gitbranch.mdwn @@ -0,0 +1,18 @@ +<span class="infobox"> +Available in a [[!taglink /git]] repository.<br /> +Branch: <TMPL_VAR branch><br /> +Author: <TMPL_VAR author><br /> +</span> +<TMPL_UNLESS NAME="branch"> +This template is used to create an infobox for a git branch. It uses +these parameters: + +<ul> +<li>branch - the name of the branch, prefixed with the name of one of the + remotes listed on the [[/git]] page and provided by the gitremotes script + (e.g. github/master)</li> +<li>author - the author of the branch</li> +</ul> + +It also automatically tags the branch with `/git`. +</TMPL_UNLESS> diff --git a/doc/todo/Add_DATE_parameter_for_use_in_templates.mdwn b/doc/todo/Add_DATE_parameter_for_use_in_templates.mdwn index 8ecdf36d0..e5ac391c3 100644 --- a/doc/todo/Add_DATE_parameter_for_use_in_templates.mdwn +++ b/doc/todo/Add_DATE_parameter_for_use_in_templates.mdwn @@ -83,4 +83,4 @@ regenerate this one against that). -- 1.5.2.2 -[[!tag patch]] +[[!tag patch patch/core plugins/inline]] diff --git a/doc/todo/Add_space_before_slash_in_parent_links.mdwn b/doc/todo/Add_space_before_slash_in_parent_links.mdwn index 40a334032..536980ea8 100644 --- a/doc/todo/Add_space_before_slash_in_parent_links.mdwn +++ b/doc/todo/Add_space_before_slash_in_parent_links.mdwn @@ -8,6 +8,11 @@ This [[patch]] adds a space before the forward-slash in the the parent links. Th >>> Yes, please. This seems to be something a lot of people want to customize. (I certainly do -- a forward slash only looks natural to Unix users) --[[sabr]] +>> Joey, would I be right to summarize your position on this as "people who +>> want to change the text of the templates should maintain their own version +>> of the `.tmpl` files"? It's not clear to me how this todo item could be +>> closed in a way acceptable to you, except perhaps as WONTFIX. --[[smcv]] + Before: ikiwiki/ todo/ Add space before slash in parent links @@ -56,3 +61,23 @@ Patch: +<TMPL_VAR INDEXLINK> / <TMPL_VAR TITLE> </span> </div> + +---- + +It's almost implicit in some of the discussion above but this can be achieved locally if you fork your templates directory from ikiwiki's, with an ammendment such as + + <h1><TMPL_LOOP NAME="PARENTLINKS"><a + href="<TMPL_VAR NAME=URL>"><TMPL_VAR NAME=PAGE></a> + → + </TMPL_LOOP><TMPL_VAR TITLE></h1> + +This is what I do on my site for example. -- [[Jon]] + +> You don't actually need to fork the whole directory, "only" `page.tmpl` - +> put `templatedir => "/foo/templates"` in your setup file, copy `page.tmpl` +> to that directory, and modify it there. IkiWiki will look in `templatedir` +> first, then fall back to its default templates if any are missing from +> `templatedir`. +> +> (Admittedly, `page.tmpl` is the hardest to maintain a fork of, because it +> tends to change whenever a new plugin is added...) --[[smcv]] diff --git a/doc/todo/Bestdir_along_with_bestlink_in_IkiWiki.pm.mdwn b/doc/todo/Bestdir_along_with_bestlink_in_IkiWiki.pm.mdwn index 95c38f794..bf8de16cd 100644 --- a/doc/todo/Bestdir_along_with_bestlink_in_IkiWiki.pm.mdwn +++ b/doc/todo/Bestdir_along_with_bestlink_in_IkiWiki.pm.mdwn @@ -1,5 +1,8 @@ This patch adds function bestdir() which returns best directory from the directory structure. This is in addition to the bestlink() function which is there in IkiWiki.pm +> Um, what is this for? :-) It would probably be a lot easier to review if it +> had documentation, and/or a plugin that used it. --[[smcv]] + ------- Index: IkiWiki.pm @@ -45,4 +48,4 @@ This patch adds function bestdir() which returns best directory from the directo ---- -[[users/arpitjain]] -[[!tag patch]] +[[!tag patch patch/core]] diff --git a/doc/todo/Gallery.mdwn b/doc/todo/Gallery.mdwn index bc1d5bea4..f41980333 100644 --- a/doc/todo/Gallery.mdwn +++ b/doc/todo/Gallery.mdwn @@ -1,3 +1,5 @@ +[[!template id=gitbranch branch=origin/gallery author="[[arpitjain]]"]] + New Version of gallery is available now. Few more features have been added like support for multiple pages, sorting and resizing of images etc. Gallery repo is now available at <http://github.com/joeyh/ikiwiki/tree/gallery> diff --git a/doc/todo/Raw_view_link.mdwn b/doc/todo/Raw_view_link.mdwn index e4f941743..fd64074c2 100644 --- a/doc/todo/Raw_view_link.mdwn +++ b/doc/todo/Raw_view_link.mdwn @@ -10,4 +10,8 @@ The configuration setting for Mercurial could be something like this: > Not that I'm opposed to the idea of a plugin that adds a Raw link > --[[Joey]] +>> In [[todo/source_link]], Will does this via the CGI instead of delegating +>> to gitweb/etc. I think Will's patch is a good approach, and have improved +>> on it a bit in a git branch. + [[!tag wishlist]] diff --git a/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn b/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn index 89167c084..4bc828e6e 100644 --- a/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn +++ b/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn @@ -1,4 +1,4 @@ -[[!tag patch]] +[[!tag patch plugins/calendar]] Here's my next version of the patch - still a work in progress. diff --git a/doc/todo/Suggested_location_should_be_subpage_if_siblings_exist.mdwn b/doc/todo/Suggested_location_should_be_subpage_if_siblings_exist.mdwn index c651b0a45..0fb14bafe 100644 --- a/doc/todo/Suggested_location_should_be_subpage_if_siblings_exist.mdwn +++ b/doc/todo/Suggested_location_should_be_subpage_if_siblings_exist.mdwn @@ -21,4 +21,6 @@ that we're at the root of a (sub-)hierarchy. > > IMHO, what you really want is [[Moving_pages]]. :-) --[[Joey]] +>> This sounds like WONTFIX to me? --[[smcv]] + [[!tag wishlist]] diff --git a/doc/todo/allow_creation_of_non-existent_pages.mdwn b/doc/todo/allow_creation_of_non-existent_pages.mdwn index 9055c8a13..61f311b8c 100644 --- a/doc/todo/allow_creation_of_non-existent_pages.mdwn +++ b/doc/todo/allow_creation_of_non-existent_pages.mdwn @@ -8,4 +8,6 @@ From the [apache documentation](http://httpd.apache.org/docs/2.2/custom-error.ht > Nice idea, I'll try to find time to add a plugin doing this. --[[Joey]] +>> [[done]] some time ago, as the [[plugins/404]] plugin --[[smcv]] + [[wishlist]] diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index 97515a312..70ccc2b68 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -1,8 +1,11 @@ +[[!tag plugins/meta patch]] +[[!template id=gitbranch branch=jon/defaultmeta author="[[Jon]]"]] + I'd like to define [[plugins/meta]] values to apply across all pages site-wide unless the pages define their own: default values for meta definitions essentially. -Here's a patch[[!tag patch]] to achieve this (also in the "defaultmeta" branch of +Here's a patch to achieve this (also in the "defaultmeta" branch of my github ikiwiki fork): diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm @@ -52,3 +55,20 @@ my github ikiwiki fork): * title -- [[Jon]] + +> This doesn't support multiple-argument meta directives like +> `link=x rel=y`, or meta directives with special side-effects like +> `updated`. +> +> The first could be solved (if you care) by a syntax like this: +> +> meta_defaults => [ +> { copyright => "© me" }, +> { link => "about:blank", rel => "silly", }, +> ] +> +> The second could perhaps be solved by invoking `meta::preprocess` from within +> `scan` (which might be a simplification anyway), although this is complicated +> by the fact that some (but not all!) meta headers are idempotent. +> +> --[[smcv]] diff --git a/doc/todo/attachments.mdwn b/doc/todo/attachments.mdwn index 56b2249ea..600c6cf7b 100644 --- a/doc/todo/attachments.mdwn +++ b/doc/todo/attachments.mdwn @@ -11,4 +11,12 @@ nice to add: srcdir. This would allow the admin to review them, and manually add/delete them before they bloat history. +> I'd be inclined to implement that one by writing them to a nominated +> underlay, I think, rather than having them in the srcdir but not in +> the VCS. My [[plugins/contrib/album]] plugin could benefit from this +> functionality, although in that case the photos should probably just +> stay in the underlay forever (I already use an underlay on my own +> websites for photos and software releases, which are too big to want +> them in the VCS permanently.) --[[smcv]] + [[!tag wishlist]] diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index f60fc3d6e..f1d33114f 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -4,7 +4,7 @@ Tags are mainly specific to the object to which they’re stuck. However, I ofte Also see: <http://madduck.net/blog/2008.01.06:new-blog/> and <http://users.itk.ppke.hu/~cstamas/code/ikiwiki/autocreatetagpage/> -[[!tag wishlist]] +[[!tag wishlist plugins/tag patch]] I would love to see this as well. -- dato diff --git a/doc/todo/backlinks_result_is_lossy.mdwn b/doc/todo/backlinks_result_is_lossy.mdwn new file mode 100644 index 000000000..02e5b2440 --- /dev/null +++ b/doc/todo/backlinks_result_is_lossy.mdwn @@ -0,0 +1,11 @@ +[[!tag patch patch/core]] +[[!template id=gitbranch branch=smcv/ready/among author="[[smcv]]"]] + +IkiWiki::backlinks returns a form of $backlinks{$page} that has undergone a +lossy transformation (to get it in the form that page templates want), making +it more difficult to use in other contexts (like pagestats). + +A commit on my `among` branch splits it into IkiWiki::backlink_pages +(which returns the keys of $backlinks{$page}, and might be suitable for +exporting) and IkiWiki::backlinks (which calls backlink_pages, then performs +the same lossy transformation as before on the result). diff --git a/doc/todo/blogpost_plugin.mdwn b/doc/todo/blogpost_plugin.mdwn index bb91ffd02..69df27271 100644 --- a/doc/todo/blogpost_plugin.mdwn +++ b/doc/todo/blogpost_plugin.mdwn @@ -153,4 +153,4 @@ Index: IkiWiki.pm our $version='unknown'; # VERSION_AUTOREPLACE done by Makefile, DNE </pre> -[[!tag patch]] +[[!tag patch patch/core]] diff --git a/doc/todo/dynamic_rootpage.mdwn b/doc/todo/dynamic_rootpage.mdwn index 5cf80b0a8..3c39484bc 100644 --- a/doc/todo/dynamic_rootpage.mdwn +++ b/doc/todo/dynamic_rootpage.mdwn @@ -30,3 +30,6 @@ What's your opinion, Joey? I hope it's also useful for another ikiwiki lovers :) > like to have traditional `inline` functionality too. This would work great if there were a way to change the `do` > parameter in the `blogpost` template's form; if I could change it to `datedblog` instead of `blog` then I could hook > my datedblog module in nicely, without having to override anything. What would be the right way to do that? --[[neale]] + +> This is basically the same request as +> [[todo/inline_postform_autotitles]]. --[[smcv]] diff --git a/doc/todo/enable-htaccess-files.mdwn b/doc/todo/enable-htaccess-files.mdwn index 15efab70c..e302a49ed 100644 --- a/doc/todo/enable-htaccess-files.mdwn +++ b/doc/todo/enable-htaccess-files.mdwn @@ -12,7 +12,7 @@ qr/(^|\/).svn\//, qr/.arch-ids\//, qr/{arch}\//], wiki_link_regexp => qr/\[\[(?:([^\]\|]+)\|)?([^\s\]#]+)(?:#([^\s\]]+))?\]\]/, -[[!tag patch]] +[[!tag patch patch/core]] This lets the site administrator have a `.htaccess` file in their underlay directory, say, then get it copied over when the wiki is built. Without @@ -39,6 +39,13 @@ access and such .htaccess files should not be accessible through wiki cgi. Of co > See [[!debbug 447267]] for a patch for this. +>> It looks to me as though this functionality won't be included in ikiwiki +>> unless someone who wants it takes responsibility for updating the patch +>> from that Debian bug to be applicable to current versions, so that there's a +>> setup file parameter for extra filenames to allow, defaulting to none +>> (i.e. a less simplistic patch than the one at the top of this page). +>> Joey, is this an accurate summary? --[[smcv]] + --- bump! I would like to see some form of this functionality included in ikiwiki. I use a patched version, but @@ -52,5 +59,3 @@ It should be off by default of course. --Max --- +1 for various purposes (but sometimes the filename isn't `.htaccess`, so please make it configurable) --[[schmonz]] - -[[!tag patch]] diff --git a/doc/todo/format_escape.mdwn b/doc/todo/format_escape.mdwn index 574883d1b..762f16646 100644 --- a/doc/todo/format_escape.mdwn +++ b/doc/todo/format_escape.mdwn @@ -97,7 +97,7 @@ I've created an updated [patch](http://www.idletheme.org/code/patches/ikiwiki-fo --Ryan Koppenhaver ## Original patch -[[!tag patch]] +[[!tag patch patch/core plugins/rst]] <pre> Index: debian/changelog diff --git a/doc/todo/generated_po_stuff_not_ignored_by_git.mdwn b/doc/todo/generated_po_stuff_not_ignored_by_git.mdwn new file mode 100644 index 000000000..1d24fd385 --- /dev/null +++ b/doc/todo/generated_po_stuff_not_ignored_by_git.mdwn @@ -0,0 +1,7 @@ +[[!template id=gitbranch branch=smcv/gitignore author="[[smcv]]"]] +[[!tag patch]] + +The recent merge of the po branch didn't come with a .gitignore. +It eventually annoyed me enough to fix it :-) --[[smcv]] + +[[done]] diff --git a/doc/todo/geotagging.mdwn b/doc/todo/geotagging.mdwn index cb07e5e0c..65658d7c4 100644 --- a/doc/todo/geotagging.mdwn +++ b/doc/todo/geotagging.mdwn @@ -3,3 +3,5 @@ and search/sort pages by distance to a given location, as well as showing page locations on a map (Google Map, OpenStreetMap, etc). -- [[users/vibrog]] [[!tag wishlist]] + +> [[!cpan Geo::Coordinates::UTM]] would probably be useful. --[[smcv]] diff --git a/doc/todo/hard-coded_location_for_man_pages_and_w3m_cgi_wrapper.mdwn b/doc/todo/hard-coded_location_for_man_pages_and_w3m_cgi_wrapper.mdwn index a6a6ec1e1..7cf37fbb9 100644 --- a/doc/todo/hard-coded_location_for_man_pages_and_w3m_cgi_wrapper.mdwn +++ b/doc/todo/hard-coded_location_for_man_pages_and_w3m_cgi_wrapper.mdwn @@ -12,7 +12,7 @@ while the default stays as it is now. > INSTALLMAN1DIR (though MakeMaker lacks one for man8). I'd prefer not > adding new variables where MakeMaker already has them. --[[Joey]] -[[!tag patch]] +[[!tag patch patch/core]] <pre> diff --git a/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn b/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn index fc575e013..457b47884 100644 --- a/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn +++ b/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn @@ -1,5 +1,7 @@ -A [[patch]] in my git repository (the inline-pagenames branch) adds the following -parameter to the [[ikiwiki/directive/inline]] directive: +[[!template id=gitbranch branch=smcv/ready/inline-pagenames author="[[smcv]]"]] + +A [[!taglink patch]] in my git repository (the inline-pagenames branch) adds +the following parameter to the [[ikiwiki/directive/inline]] directive: > * `pagenames` - If given instead of `pages`, this is interpreted as a > space-separated list of links to pages (with the same @@ -10,3 +12,5 @@ parameter to the [[ikiwiki/directive/inline]] directive: This is on my [[wishlist]] for my [[plugins/contrib/album]] plugin, which currently uses it internally (as it has already collected the pages in order). It could also be useful for other things, like [[todo/wikitrails]]. --[[smcv]] + +[[!tag plugins/inline]] diff --git a/doc/todo/inline_postform_autotitles.mdwn b/doc/todo/inline_postform_autotitles.mdwn index 5005208be..39713eb5f 100644 --- a/doc/todo/inline_postform_autotitles.mdwn +++ b/doc/todo/inline_postform_autotitles.mdwn @@ -1,5 +1,5 @@ -[[!tag wishlist]] -[[!tag patch]] +[[!tag wishlist patch plugins/inline]] +[[!template id=gitbranch branch=chrysn/patches author="[[chrysn]]"]] for postforms in inlines of pages which follow a certain scheme, it might not be required to set the title for each individual post, but to automatically set @@ -17,6 +17,21 @@ resulting in ascending numeric page titles to be created. the second patch is actually a one-liner, filtering the title through strftime. +> Something similar was requested in [[todo/more_customisable_titlepage_function]], +> in which [[Joey]] outlined a similar solution. +> +> What's your use-case for not prompting for the title at all? I can see +> [[madduck]]'s requirement for the title he typed in (say, "foo") +> being transformed into 2009/07/26/foo or something (I name blog posts +> like that myself), but I can't quite see the use for *entirely* automatic +> titles. +> +> However, if that's really what you want, I suspect your code could be +> extended so it also solves madduck's second request on +> [[todo/more_customisable_titlepage_function]]. +> +> --[[smcv]] + ### potential user interaction issues this has two side effects which have to be considered: first, the empty page diff --git a/doc/todo/l10n.mdwn b/doc/todo/l10n.mdwn index f777a33df..bba103494 100644 --- a/doc/todo/l10n.mdwn +++ b/doc/todo/l10n.mdwn @@ -96,4 +96,6 @@ For example use, here's how to roll out a clone of the [Redpill support site](ht > ikiwiki tree, that adds the po4a stuff needed to generate the pot files for the > basewiki and template content, as well as the stuff that generates the > translated versions of those from the po files. +> +> The now merged po plugin also handles some of this. > --[[Joey]] diff --git a/doc/todo/language_definition_for_the_meta_plugin.mdwn b/doc/todo/language_definition_for_the_meta_plugin.mdwn index 4ac4e2e25..90bfbef3b 100644 --- a/doc/todo/language_definition_for_the_meta_plugin.mdwn +++ b/doc/todo/language_definition_for_the_meta_plugin.mdwn @@ -81,4 +81,21 @@ This may be useful for sites with a few pages in different languages, but no ful > Please resolve lang somewhere reusable rather than within meta plugin: It is certainly usable outside > the scope of the meta plugin as well. --[[JonasSmedegaard]] +>> I don't see any problem with having this in meta? meta is on by default, and +>> other plugins are free to use it or even depend on it (e.g. inline does). +>> +>> My only comments on this patch beyond what Joey said are that the page +>> language could usefully go into `$pagestate{$page}{meta}{lang}` for other +>> plugins to be able to see it (is that what you meant?), and that +>> restricting to 2 characters is too restrictive (HTML 4.01 mentions +>> `en`, `en-US` and `i-navajo` as possible language codes). +>> This slightly complicates parsing the locale to get the default language: +>> it'll need `tr/_/-/` after the optional `.encoding` is removed. +>> --[[smcv]] + +>>> Now that po has been merged, this patch should probably also be adapted +>>> so that the po plugin forces the meta::lang of every page to what po +>>> thinks it should be. Perhaps [[the_special_po_pagespecs|ikiwiki/pagespec/po]] +>>> should also work with meta-assigned languages? --[[smcv]] + [[!tag wishlist patch plugins/meta translation]] diff --git a/doc/todo/meta_rcsid.mdwn b/doc/todo/meta_rcsid.mdwn index 158edea6e..9e112317f 100644 --- a/doc/todo/meta_rcsid.mdwn +++ b/doc/todo/meta_rcsid.mdwn @@ -1,4 +1,4 @@ -The following patch adds an 'rcsid' parameter to the Meta plugin, to allow inclusion +The following patch adds an 'rcsid' parameter to the [[!taglink plugins/Meta]] plugin, to allow inclusion of CVS/SVN-style keywords (like '$Id$', etc.) from the source file in the page template. > So the idea is you'd write something like: diff --git a/doc/todo/missingparents.pm.mdwn b/doc/todo/missingparents.pm.mdwn index c5f2ab535..cecac7a94 100644 --- a/doc/todo/missingparents.pm.mdwn +++ b/doc/todo/missingparents.pm.mdwn @@ -258,4 +258,4 @@ Index: IkiWiki.pm my $page=shift; </pre> -[[!tag patch]] +[[!tag patch patch/core]] diff --git a/doc/todo/more_class__61____34____34___for_css.mdwn b/doc/todo/more_class__61____34____34___for_css.mdwn index 4712c12b3..cace27d63 100644 --- a/doc/todo/more_class__61____34____34___for_css.mdwn +++ b/doc/todo/more_class__61____34____34___for_css.mdwn @@ -15,6 +15,8 @@ Here's the one-liner: > applied --[[Joey]] +---- + The following adds a div element with class="trailer" around the meta-information added after an inlined page (namely: the post date, the tags, and the actions): @@ -42,7 +44,7 @@ added after an inlined page (namely: the post date, the tags, and the actions): > gets confused by these nested div's and puts p's around one of them, generating > broken html. If you can come up with a way to put in the div that passes > the test suite, or a fix to markdown, I will accept it, but the above patch -> fails the test suite. --[[Joey]] +> fails the test suite. --[[Joey]] >> Just a note... This discrepancy doesn't exist in [pandoc](http://code.google.com/p/pandoc/) as >> demonstrated in the relevant [page](http://code.google.com/p/pandoc/wiki/PandocVsMarkdownPl). @@ -64,6 +66,16 @@ added after an inlined page (namely: the post date, the tags, and the actions): >>>> to at least get into debian testing before I make ikiwiki depend on it >>>> though. --[[Joey]] +>> This Markdown issue seems to have been worked around by the optimization +>> in which \[[!inline]] is replaced with a placeholder, and the +>> placeholder is later replaced by the HTML. Meanwhile, this patch +>> has been obsoleted by applying a similar one (wrapping things in a div +>> with class inlinefooter). That was the last remaining unapplied patch +>> on this page, so I think this whole page can be considered [[done]]. +>> --[[smcv]] + +---- + I'd like a class attribute on the `<span>` tag surrounding wikilinks that refer to non-existent pages, in Ikiwiki.pm:htmllink, so that such broken links can be styled more dramatically with CSS. --Jamey diff --git a/doc/todo/more_customisable_titlepage_function.mdwn b/doc/todo/more_customisable_titlepage_function.mdwn index 51b560746..97fefbafc 100644 --- a/doc/todo/more_customisable_titlepage_function.mdwn +++ b/doc/todo/more_customisable_titlepage_function.mdwn @@ -2,7 +2,9 @@ I understand the `IkiWiki::titlepage` function is used to generate filenames fro I imagine two things: a lookup hash and a template. -Since `IkiWiki::titlepage` basically translates characters, it would be cool to be able to define a lookup hash in the configuration, which would be consulted before falling back to the generic `__xx__` `ord()` representation of a letter. For instance, in German, I might prefer to have 'ä' become 'ae' instead of something illegible. +Since `IkiWiki::titlepage` basically translates characters, it would be cool to be able to define a lookup hash in the configuration, which would be consulted before falling back to the generic `__xx__` `ord()` representation of a letter. For instance, in German, I might prefer to have 'ä' become 'ae' instead of something illegible. + +> This is [[todo/unaccent_url_instead_of_encoding]]. --[[smcv]] Second, maybe a template could be honoured. The template could have a slot `%s` where the calculated title goes, and it could contain `strftime` symbols as well as variables, which get interpolated on use. @@ -10,6 +12,11 @@ Another option would be a function I could define in the setup file, or an exter -- [[madduck]] +> This somewhat resembles [[todo/inline_postform_autotitles]]. +> Another way to do this, suggested in that todo, would be to +> pre-fill the title field with YYYY/MM/DD/ using Javascript. +> --[[smcv]] + I don't think that changing titlepage is a good idea, there are compatability problems. @@ -28,4 +35,8 @@ is that having the directive appear in the edit box for a new page could confuse the user. The title could be passed on in a hidden field, and prepended to the page when it's saved.. +--[[Joey]] + +> I'll pass on these comments to the two similar todo items. --[[smcv]] + [[wishlist]] diff --git a/doc/todo/more_flexible_inline_postform.mdwn b/doc/todo/more_flexible_inline_postform.mdwn index 112220394..bc8bc0809 100644 --- a/doc/todo/more_flexible_inline_postform.mdwn +++ b/doc/todo/more_flexible_inline_postform.mdwn @@ -12,3 +12,7 @@ the post form and stuck it inside a [[plugins/toggle]]. logical first step towards doing comment-like things with inlined pages). -- [[Jon]] + +> Perhaps what we need is a `postform` plugin/directive that inline depends +> on (automatically enables); its preprocess method could automatically be +> invoked from preprocess_inline when needed. --[[smcv]] diff --git a/doc/todo/need_global_renamepage_hook.mdwn b/doc/todo/need_global_renamepage_hook.mdwn index b123340af..e3cec4a9b 100644 --- a/doc/todo/need_global_renamepage_hook.mdwn +++ b/doc/todo/need_global_renamepage_hook.mdwn @@ -61,7 +61,7 @@ would solve my problem. Hmmm? --[[intrigeri]] >>> not be broken. I will thus keep the existing `renamepage` as it >>> is, and call `rename` the global hook I need. --[[intrigeri]] ->>>> Done in my `po` branch. --[[intrigeri]] +>>>> [[Done]] in my `po` branch. --[[intrigeri]] I think I see a problem in the rename hook. The hook is called before the plugin adds any subpages to the set of pages to rename. diff --git a/doc/todo/pagestats:_ability_to_limit_to_links_from_certain_pages.mdwn b/doc/todo/pagestats:_ability_to_limit_to_links_from_certain_pages.mdwn deleted file mode 100644 index abf7c3fea..000000000 --- a/doc/todo/pagestats:_ability_to_limit_to_links_from_certain_pages.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -The `among` branch in my git repository refactors IkiWiki::Render a -bit, then uses this refactoring to add a [[ikiwiki/directive/pagestats]] -parameter `among` that will only count links from pages that match a -given [[ikiwiki/PageSpec]]. From its documentation: - -> The optional `among` parameter limits counting to pages that match a -> [[ikiwiki/PageSpec]]. For instance, to display a cloud of tags used on blog -> entries, you could use: -> -> \[[!pagestats pages="tags/*" among="blog/posts/*"]] -> -> or to display a cloud of tags related to Linux, you could use: -> -> \[[!pagestats pages="tags/* and not tags/linux" among="tagged(linux)"]] - -Suggestions for a better parameter name are welcome. --[[smcv]] diff --git a/doc/todo/pagestats_among_a_subset_of_pages.mdwn b/doc/todo/pagestats_among_a_subset_of_pages.mdwn new file mode 100644 index 000000000..446e5cc1b --- /dev/null +++ b/doc/todo/pagestats_among_a_subset_of_pages.mdwn @@ -0,0 +1,27 @@ +[[!tag patch plugins/pagestats]] +[[!template id=gitbranch branch=smcv/ready/among author="[[smcv]]"]] + +My `among` branch fixes [[todo/backlinks_result_is_lossy]], then uses that +to provide pagestats for links from a subset of pages. From the docs included +in the patch: + +> The optional `among` parameter limits counting to pages that match a +> [[ikiwiki/PageSpec]]. For instance, to display a cloud of tags used on blog +> entries, you could use: +> +> \[[!pagestats pages="tags/*" among="blog/posts/*"]] +> +> or to display a cloud of tags related to Linux, you could use: +> +> \[[!pagestats pages="tags/* and not tags/linux" among="tagged(linux)"]] + +I use this on my tag pages on one site, with the following template: + + \[[!pagestats pages="tags/* and !tags/<TMPL_VAR raw_tag> + and !tags/photogallery" + among="tagged(<TMPL_VAR raw_tag>)"]] + + \[[!inline pages="tagged(<TMPL_VAR raw_tag>)" + archive="yes" quick="yes" reverse="yes" timeformat="%x"]] + +--[[smcv]] diff --git a/doc/todo/passwordauth:_sendmail_interface.mdwn b/doc/todo/passwordauth:_sendmail_interface.mdwn index 9598af234..29f28ca32 100644 --- a/doc/todo/passwordauth:_sendmail_interface.mdwn +++ b/doc/todo/passwordauth:_sendmail_interface.mdwn @@ -1,4 +1,4 @@ -[[!tag wishlist]] +[[!tag wishlist plugins/passwordauth]] For sending out password reminder emails, the [[plugins/passwordauth]] plugin currently uses the *[Mail::Sendmail](http://search.cpan.org/perldoc?Mail::Sendmail)* module. @@ -52,3 +52,10 @@ Remaining TODOs: > lost it. --[[Joey]] Resent. --[[tschwinge]] + +> Debian now has Mail::Sender, Mail::SendEasy, and Email::Sender +> (which, according to its dpkg description, "replaces the old and sometimes +> problematic Email::Send library, which did a decent job at handling very +> simple email sending tasks, but was not suitable for serious use, for a +> variety of reasons"). Are any of those any better? It's unfortunate that +> there doesn't seem to be a clear "best practice"... --[[smcv]] diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn index c5485477f..3ccef62fe 100644 --- a/doc/todo/should_optimise_pagespecs.mdwn +++ b/doc/todo/should_optimise_pagespecs.mdwn @@ -79,6 +79,8 @@ I can think about reducung the size of my wiki source and making it available on > > --[[Joey]] +[[!template id=gitbranch branch=smcv/ready/optimize-depends author="[[smcv]]"]] + >> I've been looking at optimizing ikiwiki for a site using >> [[plugins/contrib/album]] (which produces a lot of pages) and it seems >> that checking which pages depend on which pages does take a significant @@ -96,4 +98,11 @@ I can think about reducung the size of my wiki source and making it available on >>>> I haven't actually deleted it), because the "or" operation is now done in >>>> the Perl code, rather than by merging pagespecs and translating. --[[smcv]] -[[!tag wishlist patch]] +[[!template id=gitbranch branch=smcv/ready/remove-pagespec-merge author="[[smcv]]"]] + +>>>>> I've now added a patch to the end of that branch that deletes +>>>>> `pagespec_merge` almost entirely (we do need to keep a copy around, in +>>>>> ikiwiki-transition, but that copy doesn't have to be optimal or support +>>>>> future features like [[tracking_bugs_with_dependencies]]). --[[smcv]] + +[[!tag wishlist patch patch/core]] diff --git a/doc/todo/source_link.mdwn b/doc/todo/source_link.mdwn index b051361a8..813e061eb 100644 --- a/doc/todo/source_link.mdwn +++ b/doc/todo/source_link.mdwn @@ -4,6 +4,31 @@ How about a direct link from the page header to the source of the latest version I just implemented this. There is one [[patch]] to the default page template, and a new plugin. -- [[Will]] +> The use of sessioncgi here seems undesirable: on wikis where anonymity is +> not allowed, you'll be asked to log in. Couldn't you achieve the same thing +> by loading the index with IkiWiki::loadindex, like [[plugins/goto]] does? +> --[[smcv]] + +[[!template id=gitbranch branch=smcv/ready/getsource + author="[[Will]]/[[smcv]]"]] + +>> I've applied the patch below in a git branch, fixed my earlier criticism, +>> and also fixed a couple of other issues I noticed: +>> +>> * missing pages could be presented better as a real 404 page +>> * the default Content-type should probably be UTF-8 since the rest of +>> IkiWiki tends to assume that +>> * emitting attachments (images, etc.) as text/plain isn't going to work :-) +>> +>> Any opinions on my branch? I think it's ready for merge, if Joey approves. +>> +>> --[[smcv]] + +>>> That looks like a nice set of fixes. One more that might be worthwhile: instead of reading the page source into a var, and then writing it out later, it might be nice to just +>>> `print readfile(srcfile(pagesources{$page}));` at the appropriate point. -- [[Will]] + +>>>> OK, I've committed that. --[[smcv]] + ---- diff --git a/templates/page.tmpl b/templates/page.tmpl diff --git a/doc/todo/tmplvars_plugin.mdwn b/doc/todo/tmplvars_plugin.mdwn index 644cf23aa..2fe819682 100644 --- a/doc/todo/tmplvars_plugin.mdwn +++ b/doc/todo/tmplvars_plugin.mdwn @@ -2,6 +2,29 @@ A simple plugin to allow per-page customization of a template by passing paramat [[!tag patch]] +> The implementation looks fine to me (assuming it works with current ikiwiki), +> apart from the "XXX" already noted in the patch. The design could reasonably +> be considered premature generalization, though - how often do you actually +> need to define new tmplvars? +> +> As for the page/destpage/preview thing, it would be good if the preprocess +> hook could distinguish between software-supplied and user-supplied +> parameters (the [[plugins/tag]] plugin could benefit from this too). Perhaps +> the IkiWiki core could be modified so that +> `hook(type => "preprocess", splitparams => 1, ...)` would invoke preprocess +> with { page => "foo", destpage => "bar", ... } as a special first argument, +> and the user-supplied parameters as subsequent arguments? Then plugins like +> tag could use: +> +> my $ikiparams = shift; +> my %params = @_; +> +> add_tags($ikiparams->{page}, keys %params); +> +> --[[smcv]] + +---- + #!/usr/bin/perl package IkiWiki::Plugin::tmplvars; diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn index 3a761731b..a198530fc 100644 --- a/doc/todo/tracking_bugs_with_dependencies.mdwn +++ b/doc/todo/tracking_bugs_with_dependencies.mdwn @@ -1,3 +1,5 @@ +[[!tag patch patch/core]] + I like the idea of [[tips/integrated_issue_tracking_with_ikiwiki]], and I do so on several wikis. However, as far as I can tell, ikiwiki has no functionality which can represent dependencies between bugs and allow pagespecs to select based on dependencies. For instance, I can't write a pagespec which selects all bugs with no dependencies on bugs not marked as done. --[[JoshTriplett]] > I started having a think about this. I'm going to start with the idea that expanding @@ -408,6 +410,9 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W >>>>> then the last definition (baz) takes precedence. >>>>> In the process of writing this I think I've come up with a way to change this back the way it was, still using closures. -- [[Will]] +>>> Alternatively, my [[remove-pagespec-merge|should_optimise_pagespecs]] +>>> branch solves this, in a Gordian knot sort of way :-) --[[smcv]] + >> Secondly, it seems that there are two types of dependency, and ikiwiki >> currently only handles one of them. The first type is "Rebuild this >> page when any of these other pages changes" - ikiwiki handles this. diff --git a/doc/todo/unaccent_url_instead_of_encoding.mdwn b/doc/todo/unaccent_url_instead_of_encoding.mdwn index 1be150a82..e5ad34335 100644 --- a/doc/todo/unaccent_url_instead_of_encoding.mdwn +++ b/doc/todo/unaccent_url_instead_of_encoding.mdwn @@ -4,6 +4,21 @@ This works right from a technical point of view, but the URLs will become ugly. So I made a patch which unaccent chars: <http://users.itk.ppke.hu/~cstamas/code/ikiwiki/unaccentpagetitlenames/> This is a one liner change, but requires a bit of reordering in the code. -[[cstamas]] +--[[cstamas]] -[[!tag wishlist patch]] +> This was previously requested in [[todo/more_customisable_titlepage_function]], +> in which [[Joey]] said "I don't think that changing titlepage is a good idea, +> there are compatability problems". +> +> The problem is that altering titlepage changes the meaning of your wiki, +> by resolving all wiki links to different page names. That means that: +> +> * unaccenting can't be automatic, it has to be a configuration option +> (so you don't accidentally get different behaviour by installing +> Text::Unaccent) +> * upgrading Text::Unaccent becomes risky, as I doubt it guarantees to +> have stable rules for how to transliterate into ASCII! +> +> --[[smcv]] + +[[!tag wishlist patch patch/core]] diff --git a/doc/todo/varioki_--_add_template_variables___40__with_closures_for_values__41___in_ikiwiki.setup.mdwn b/doc/todo/varioki_--_add_template_variables___40__with_closures_for_values__41___in_ikiwiki.setup.mdwn index b28469993..d292a1184 100644 --- a/doc/todo/varioki_--_add_template_variables___40__with_closures_for_values__41___in_ikiwiki.setup.mdwn +++ b/doc/todo/varioki_--_add_template_variables___40__with_closures_for_values__41___in_ikiwiki.setup.mdwn @@ -33,6 +33,12 @@ ManojSrivastava > > directory, which is not very easy for a plain ol' user. Not everyone is the > > sysadmin of their own machines with access to system dirs. --ManojSrivastava +>>> It seems worth mentioning here that the `libdir` configuration parameter +>>> lets you install additional plugins in a user-controlled directory +>>> (*libdir*`/IkiWiki/Plugin`), avoiding needing root; indeed, a full local +>>> ikiwiki installation without any involvement from the sysadmin is +>>> [[possible|tips/DreamHost]]. --[[smcv]] + <pre> varioki => {'motto' => '"Manoj\'s musings"', 'arrayvar' => '[0, 1, 2, 3]', diff --git a/doc/todo/wikitrails/discussion.mdwn b/doc/todo/wikitrails/discussion.mdwn index b2a0937ad..9dbbb6bc8 100644 --- a/doc/todo/wikitrails/discussion.mdwn +++ b/doc/todo/wikitrails/discussion.mdwn @@ -1,11 +1,3 @@ -This sounds like a more general version of what I want for -one-photo-per-page galleries, where each page has previous|up|next links -(like this plugin) and the index page has a list or grid of thumbnails -(\[[!inline]] with a specially modified template perhaps). I'll watch this -with interest! --[[smcv]] - ----- - This is a nice idea, I do have my gripes about the imeplementation. Assuming that the index's list is in mdwn format is not ideal. I guess the @@ -81,5 +73,8 @@ hook to run *after* trail's, or perhaps by having trail's pagetemplate hook disable itself for pages that contain a \[[!trail]] directive. -Does this sound viable? Should I think about implementing it? ---[[smcv]] +I have now implemented this at [[plugins/contrib/trail]]. +What do you think? I'm still not sure how it would relate +to [[plugins/contrib/album]], but if trail is reviewed +and approved in principle, I'll try to adapt album as +outlined above. --[[smcv]] diff --git a/doc/translation.mdwn b/doc/translation.mdwn index e3e458ce7..459f47eb5 100644 --- a/doc/translation.mdwn +++ b/doc/translation.mdwn @@ -22,11 +22,21 @@ essentially three pieces needed for a complete translation: * The names and values of parameters, both to the program, in the setup file, and in preprocessor directives. +1. The [[basewiki]] needs to be translated. The + [[plugins/contrib/po]] ikiwiki plugin will allow translating + wikis using po files and can be used for this. + + To generate the po and pot files for translating the basewiki, + get ikiwiki's source, edit the `po/underlay.setup` file, + adding your language. Then run 'make -C po underlays`. + This will generate many po files under `po/underlays`. The first + ones you'll want to translate are in the `po/underlays/basewiki` directory, + which is really not very large, just a few thousand words. + After that is done, you can tackle those under + `po/underlays/directives`, which are a much larger (tens of + thousands of words). + 1. The templates also need to be translated. Some work has been done on an infrastructure for maintaining translated templates, as documented in [[todo/l10n]], but until that's complete, you'd need to copy and translate the templates by hand. - -1. The [[basewiki]] itself needs to be translated. The - [[plugins/contrib/po]] ikiwiki plugin will allow translating - wikis using po files and can be used for this. diff --git a/doc/translation/discussion.mdwn b/doc/translation/discussion.mdwn index 26097b555..35e8fd054 100644 --- a/doc/translation/discussion.mdwn +++ b/doc/translation/discussion.mdwn @@ -17,15 +17,8 @@ updating my PO file? Should I send it to you for every ikiwiki issue? Maybe you should give write access to ikiwiki repository for translators of PO files? - > I recently set up a git repository mirroring the main svn repository (see - > [[download]]) and one idea is that perhaps translators can use that for a - > distributed revision control system that I can merge back from into svn. - > I can set up accounts for svn, but as it's on my own personal server and - > not a sourceforge/alioth like thing, it's a bit of a pain and maintenance - > burden for me. - - >> OK, I've picked up Subversion for your ikiwiki, so I can get into - >> Git now ;) + > We use git now, so you can clone my repo, commit to your clone, and + > use git to mail me patches. --[[Joey]] 3. What is the best way to update my PO file when you do some changes in `ikiwiki.pot` file? Should I translate my PO file from scratch or @@ -94,4 +87,4 @@ translators. Thank you! :) --[[Paweł|ptecza]] > size limits. This is generally done by adding comments in the pot file, > and I've turned that on, and added a few. --[[Joey]] ->> Thank you very much! It also will be a big help for me. --[[Paweł|ptecza]]
\ No newline at end of file +>> Thank you very much! It also will be a big help for me. --[[Paweł|ptecza]] diff --git a/doc/users/harishcm.mdwn b/doc/users/harishcm.mdwn new file mode 100644 index 000000000..47f28c83c --- /dev/null +++ b/doc/users/harishcm.mdwn @@ -0,0 +1 @@ +Using ikiwiki for my yet to be publish personal website :) diff --git a/doc/users/simonraven.mdwn b/doc/users/simonraven.mdwn index 0706859aa..5fc24711e 100644 --- a/doc/users/simonraven.mdwn +++ b/doc/users/simonraven.mdwn @@ -1,3 +1,8 @@ -New ikiwiki site at my personal site under /ikiwiki/ . This might move to /wiki/ or be on wiki.k.o depending on if I can import my MediaWiki stuff to it. +## personal/site info + +New ikiwiki site at my web site, blog, kisikew.org home site, for indigenews, and our indigenous-centric wiki (mostly East Coast/Woodlands area). Mediawiki stuff was imported successfully (as noted on this web site). + +## ikiwiki branch at github + +Maintain my own branch, partly to learn about VCS, git, ikiwiki, Debian packaging, and Perl. I don't recommend anyone pull from it, as I use third-party plugins included on this site that people may not want in a default installation of ikiwiki. This is why I don't push to Joey's -- so it's nothing personal, I just don't want to mess things up for other people, from my mistakes and stumbles. -Thought I'd try it out again and it grew on me. |