diff options
Diffstat (limited to 'doc')
43 files changed, 899 insertions, 106 deletions
diff --git a/doc/bugs/defintion_lists_appear_to_be_disabled.mdwn b/doc/bugs/defintion_lists_appear_to_be_disabled.mdwn new file mode 100644 index 000000000..6dac9c8b8 --- /dev/null +++ b/doc/bugs/defintion_lists_appear_to_be_disabled.mdwn @@ -0,0 +1,54 @@ +Adding text of the format + + Apple + : Pomaceous fruit of plants of the genus Malus in + the family Rosaceae. + : An american computer company. + + Orange + : The fruit of an evergreen tree of the genus Citrus. + +Does not result in expected HTML as described in the [MultiMarkdown Syntax Guide](http://fletcherpenney.net/multimarkdown/users_guide/multimarkdown_syntax_guide/): + +Should be + + <dl xmlns="http://www.w3.org/1999/xhtml"> + <dt>Apple</dt> + <dd> + <p>Pomaceous fruit of plants of the genus Malus in + the family Rosaceae.</p> + </dd> + <dd> + <p>An american computer company.</p> + </dd> + <dt>Orange</dt> + <dd> + <p>The fruit of an evergreen tree of the genus Citrus.</p> + </dd> + </dl> + +But instead it gives: + + <p>Apple + : Pomaceous fruit of plants of the genus Malus in + the family Rosaceae. + : An american computer company.</p> + + <p>Orange + : The fruit of an evergreen tree of the genus Citrus.</p> + +> ikiwiki's markdown support does not include support for multimarkdown by +> default. If you want to enable that, you can turn on the `multimarkdown` +> option in the setup file. --[[Joey]] + +>> Sorry, I should have indicated, I have multimarkdown enabled: + + # mdwn plugin + # enable multimarkdown features? + multimarkdown => 1, + +>>Other features appear to be working, tables and footnotes for instance. See current install: <http://wiki.infosoph.org> + +>>> Ok, in that case it's a bug in the perl module. Forwarded to +>>> <http://github.com/bobtfish/text-markdown/issues#issue/6> --[[Joey]] +>>> [[!tag done]] diff --git a/doc/bugs/pagecount_is_broken.mdwn b/doc/bugs/pagecount_is_broken.mdwn index 101230d94..57df6b75d 100644 --- a/doc/bugs/pagecount_is_broken.mdwn +++ b/doc/bugs/pagecount_is_broken.mdwn @@ -1,3 +1,4 @@ -The [[plugins/pagecount]] plugin seems to be broken, as it claims there are [[!pagecount ]] pages in this wiki. (if it's not 0, the bug is fixed) +The [[plugins/pagecount]] plugin seems to be broken, as it claims there are +\[[!pagecount ]] pages in this wiki. (if it's not 0, the bug is fixed) [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/po_plugin_adds_new_dependency.mdwn b/doc/bugs/po_plugin_adds_new_dependency.mdwn new file mode 100644 index 000000000..3ddcc30f2 --- /dev/null +++ b/doc/bugs/po_plugin_adds_new_dependency.mdwn @@ -0,0 +1,38 @@ +Was it intended that the po plugin add a new dependency? + +> Yes; see debian/control Build-Depends. However, I have made it disable +> building that is po4a is not available. [[done]] --[[Joey]] + + PERL5LIB=.. ./po2wiki underlay.setup + Failed to load plugin IkiWiki::Plugin::po: Can't locate Locale/Po4a/Common.pm in @INC (@INC contains: .. /Library/Perl/Updates/5.8.8 /System/Library/Perl/5.8.8/darwin-thread-multi-2level /System/Library/Perl/5.8.8 /Library/Perl/5.8.8/darwin-thread-multi-2level /Library/Perl/5.8.8 /Library/Perl /Network/Library/Perl/5.8.8/darwin-thread-multi-2level /Network/Library/Perl/5.8.8 /Network/Library/Perl /System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level /System/Library/Perl/Extras/5.8.8 /Library/Perl/5.8.6 /Library/Perl/5.8.1 /sw/lib/perl5/5.8.8/darwin-thread-multi-2level /sw/lib/perl5/5.8.8 /sw/lib/perl5/darwin-thread-multi-2level /sw/lib/perl5 /sw/lib/perl5/darwin /usr/local/lib/perl5/site_perl/5.8.8/darwin-thread-multi-2level /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl .) at ../IkiWiki/Plugin/po.pm line 13. + BEGIN failed--compilation aborted at ../IkiWiki/Plugin/po.pm line 13. + Compilation failed in require at (eval 27) line 2. + BEGIN failed--compilation aborted at (eval 27) line 2. + + make[1]: *** [po2wiki_stamp] Error 2 + make: *** [extra_build] Error 2 + +And it looks like this dependency is not easy to work around. The issue is that the newly translated base wiki means that the po plugin is being used by the build system. It is no longer optional. I've turned it off in my workspace like this: (heavy handed, but it lets me keep going until a proper fix is available) + + diff --git a/Makefile.PL b/Makefile.PL + index 602d8fb..68728b7 100755 + --- a/Makefile.PL + +++ b/Makefile.PL + @@ -42,7 +42,7 @@ extra_build: ikiwiki.out ikiwiki.setup docwiki + ./mdwn2man ikiwiki-makerepo 1 doc/ikiwiki-makerepo.mdwn > ikiwiki-makerepo.man + ./mdwn2man ikiwiki-transition 1 doc/ikiwiki-transition.mdwn > ikiwiki-transition.man + ./mdwn2man ikiwiki-update-wikilist 1 doc/ikiwiki-update-wikilist.mdwn > ikiwiki-update-wikilist.man + - $(MAKE) -C po + + # $(MAKE) -C po + + docwiki: ikiwiki.out + $(PERL) -Iblib/lib $(extramodules) $(tflag) ikiwiki.out -libdir . -setup docwiki.setup -refresh + @@ -114,7 +114,7 @@ extra_install: underlay_install + install ikiwiki.out $(DESTDIR)$(PREFIX)/bin/ikiwiki + install ikiwiki-makerepo ikiwiki-transition ikiwiki-update-wikilist $(DESTDIR)$(PREFIX)/bin/ + + - $(MAKE) -C po install DESTDIR=$(DESTDIR) PREFIX=$(PREFIX) + + # $(MAKE) -C po install DESTDIR=$(DESTDIR) PREFIX=$(PREFIX) + + # These might fail if a regular user is installing into a home + # directory. diff --git a/doc/bugs/po_plugin_cannot_add_po_files_into_git.mdwn b/doc/bugs/po_plugin_cannot_add_po_files_into_git.mdwn new file mode 100644 index 000000000..8e3399611 --- /dev/null +++ b/doc/bugs/po_plugin_cannot_add_po_files_into_git.mdwn @@ -0,0 +1,34 @@ +po files are not added to git (error: /path/to/po/file not in repository tree) in my setup. + +I have set absolute path for srcdir = '/path/to/repo/doc/'. The root of my git repository is '/path/to/repo/'. When I enable the po plugin, it creates all po files and produces an error when it try to add the file saying that the /path/to/repo/doc/index.fr.po is not in the repository tree. + +I have no problem when I use an relative path like srcdir = '.'. + +I have an other issue with the po plugin when I set the srcdir to './doc/' (provided that my config file is in /path/to/repo). In this case the po plugin try to add 'doc/doc/index.fr.po' which does not exists (seems like the srcdir path is prepended twice). + +> You should never use a relative srcdir path with ikiwiki. +> +> I wonder what version of git you have there, since it works ok with the +> version I have here. But, the po plugin is definitly doing the wrong +> thing; it's telling git to add the po file with the full scrdir path +> rather than relative to its root. Fixed that. [[done]] --[[Joey]] + +>> Yeah, I figured for the relative path +>> Git version 1.6.3.3 (on both my dev and server machines) +>> +>> Here is an example of what I get when I update the po file on my laptop and I push to the master repository: + + From /srv/git/sb + 5eb4619..ecac4d7 master -> origin/master + scanning doc.fr.po + building doc.fr.po + building doc.mdwn, which depends on doc.fr + building recentchanges.mdwn, which depends on recentchanges/change_ecac4d7311b15a3a3ed03102b9250487315740bc + fatal: '/srv/www/sb.l.n/new/doc/doc.fr.po' is outside repository + 'git add /srv/www/sb.l.n/new/doc/doc.fr.po' failed: at /usr/share/perl5/IkiWiki/Plugin/git.pm line 161. + done + To ssh://git.lohrun.net/var/cache/git/songbook.git + 5eb4619..ecac4d7 master -> master + +>> The root repository used to run ikiwiki is `/srv/www/sb.l.n/new/` +>> -- [[AlexandreDupas]] diff --git a/doc/css_market.mdwn b/doc/css_market.mdwn index 61254c4b8..c0e349552 100644 --- a/doc/css_market.mdwn +++ b/doc/css_market.mdwn @@ -23,17 +23,6 @@ gnomes will convert them to css files..) Debian lighttpd index.html page. [[!meta stylesheet="embeddedmoose"]] -* **Refresh**, contributed by [[FredericLespez]]. Adapted from a free template - designed by [styleshout](http://www.styleshout.com). - You can see it [here](http://fred.ccheznous.org). You can download the local.css file and - the modified templates [here](http://fred.ccheznous.org/refresh_20060602.tgz). - - * This link (above) seems to deliver an empty tarball. - - * You'll find a updated version of these templates [here](http://www.der-winnie.de/~winnie/configs/ikiwiki-templates.tar.gz). - These templates are known to work with ikiwiki 2.31, and since I'll install always the newest one on my server I'll will update them on a regular basis. - * (This link appears to be broken?) - * **[[02_Template.css]]**, contributed and adapted by [maxx](http://martin.wuertele.net/), [original](http://www.openwebdesign.org/viewdesign.phtml?id=3057) designed by [jarico](http://www.openwebdesign.org/userinfo.phtml?user=jcarico) (License: public domain). You'll need a modified page.tmpl diff --git a/doc/css_market/discussion.mdwn b/doc/css_market/discussion.mdwn index 86d16de9a..3dc47b55a 100644 --- a/doc/css_market/discussion.mdwn +++ b/doc/css_market/discussion.mdwn @@ -18,3 +18,20 @@ The most recent version is always available at: <http://git.upsilon.cc/cgi-bin/g ---- Added small changes to embeddedmoose.css to work with ikiwiki 3.x. Figured here is as good as any until Josh can review and update if he so chooses: <http://bosboot.org/tb-embeddedmoose.css>. It removes annoying borders around the header and footer. -- [[TimBosse]] + +----- + +I removed this from the list since both places to download it are broken. +--[[Joey]] + +* **Refresh**, contributed by [[FredericLespez]]. Adapted from a free template + designed by [styleshout](http://www.styleshout.com). + You can see it [here](http://fred.ccheznous.org). You can download the local.css file and + the modified templates [here](http://fred.ccheznous.org/refresh_20060602.tgz). + + * This link (above) seems to deliver an empty tarball. + + * You'll find a updated version of these templates [here](http://www.der-winnie.de/~winnie/configs/ikiwiki-templates.tar.gz). + These templates are known to work with ikiwiki 2.31, and since I'll install always the newest one on my server I'll will update them on a regular basis. + * (This link appears to be broken?) + diff --git a/doc/examples/blog/tags/life.mdwn b/doc/examples/blog/tags/life.mdwn index ddc2e646c..719f2b192 100644 --- a/doc/examples/blog/tags/life.mdwn +++ b/doc/examples/blog/tags/life.mdwn @@ -1,4 +1,4 @@ This feed contains pages in the "life" category. -[[!inline pages="link(tags/life) and ./posts/* and !*/Discussion" +[[!inline pages="link(tags/life) and !*/Discussion" show="10" actions=yes]] diff --git a/doc/forum/google_openid_broken__63__.mdwn b/doc/forum/google_openid_broken__63__.mdwn index 2ca339c3c..1be9d0487 100644 --- a/doc/forum/google_openid_broken__63__.mdwn +++ b/doc/forum/google_openid_broken__63__.mdwn @@ -3,3 +3,28 @@ when I login via to this wiki (or ours) via Google's OpenID, I get this error: Error: OpenID failure: no_identity_server: The provided URL doesn't declare its OpenID identity server. Any idea how to fix this?? + +> Google is [doing things with openid that are not in the spec](http://googledataapis.blogspot.com/2008/10/federated-login-for-google-account.html) +> and it's not clear to me that they intend regular openid to work at all. +> What is your google openid URL so I can take a look at the data they are +> providing? --[[Joey]] + + +http://openid-provider.appspot.com/larrylud + +> I've debugged this some and filed +> <https://rt.cpan.org/Ticket/Display.html?id=48728> on the Openid perl +> module. It's a pretty easy fix, so I hope upstream will fix it quickly. +> --[[Joey]] + +>> A little more information here: I'm using that same openid provider at the moment. Note that +>> that provider isn't google - it is someone using the google API to authenticate. I normally have it +>> set up as a redirect from my home page (which means I can change providers easily). + + <link rel="openid.server" href="http://openid-provider.appspot.com/will.uther"> + <link rel="openid.delegate" href="http://openid-provider.appspot.com/will.uther"> + +>> In that mode it works (I used it to log in to make this edit). However, when I try the openid +>> URL directly, it doesn't work. I think there is something weird with re-direction. I hope this +>> isn't a more general security hole. +>> -- [[Will]] diff --git a/doc/git.mdwn b/doc/git.mdwn index 18fbd238b..f6971e84b 100644 --- a/doc/git.mdwn +++ b/doc/git.mdwn @@ -33,6 +33,8 @@ into [[Joey]]'s working tree. This is recommended. :-) * github `git://github.com/joeyh/ikiwiki.git` ([browse](http://github.com/joeyh/ikiwiki/tree/master)) A mirror of the main repo, automatically updated. +* l10n `git://l10n.ikiwiki.info/` + Open push localization branch used for <http://l10n.ikiwiki.info/> * [[smcv]] `git://git.pseudorandom.co.uk/git/smcv/ikiwiki.git` * [[intrigeri]] `git://gaffer.ptitcanardnoir.org/ikiwiki.git` * [[gmcmanus]] `git://github.com/gmcmanus/ikiwiki.git` @@ -46,6 +48,7 @@ into [[Joey]]'s working tree. This is recommended. :-) * [[arpitjain]] `git://github.com/arpitjain11/ikiwiki.git` * [[chrysn]] `git://github.com/github076986099/ikiwiki.git` * [[simonraven]] `git://github.com/kjikaqawej/ikiwiki-simon.git` +* [[schmonz]] `git://github.com/schmonz/ikiwiki.git` ## branches @@ -61,6 +64,8 @@ Some of the branches included in the main repository include: * `debian-stable` is used for updates to the old version included in Debian's stable release, and `debian-testing` is used for updates to Debian's testing release. +* `ignore` gets various branches merged to it that Joey wishes to ignore + when looking at everyone's unmerged changes. * `pristine-tar` contains deltas that [pristine-tar](http://kitenet.net/~joey/code/pristine-tar) can use to recreate released tarballs of ikiwiki diff --git a/doc/ikiwiki/directive/brokenlinks/discussion.mdwn b/doc/ikiwiki/directive/brokenlinks/discussion.mdwn new file mode 100644 index 000000000..65e97cff6 --- /dev/null +++ b/doc/ikiwiki/directive/brokenlinks/discussion.mdwn @@ -0,0 +1 @@ +Would it be possible to have such a thing also checking for external links? -- [[user/emptty]] diff --git a/doc/ikiwiki/directive/inline.mdwn b/doc/ikiwiki/directive/inline.mdwn index 9c55e07c2..99f795972 100644 --- a/doc/ikiwiki/directive/inline.mdwn +++ b/doc/ikiwiki/directive/inline.mdwn @@ -56,7 +56,7 @@ directive. These are the commonly used ones: * `postform` - Set to "yes" to enable a form to post new pages to a blog. * `postformtext` - Set to specify text that is displayed in a postform. -* `rootpage` - Enable the postform, and allows controling where +* `rootpage` - Enables the postform, and allows controling where newly posted pages should go, by specifiying the page that they should be a [[SubPage]] of. diff --git a/doc/ikiwiki/formatting.mdwn b/doc/ikiwiki/formatting.mdwn index 2ed5cc26f..befbce9aa 100644 --- a/doc/ikiwiki/formatting.mdwn +++ b/doc/ikiwiki/formatting.mdwn @@ -7,7 +7,7 @@ called [[MarkDown]], and it works like this: Leave blank lines between paragraphs. -You can \**emphasise*\* or \*\***strongly emphasise**\*\* text by placing it +You can *\*emphasise\** or **\*\*strongly emphasise\*\*** text by placing it in single or double asterisks. To create a list, start each line with an asterisk: diff --git a/doc/ikiwiki/markdown/discussion.mdwn b/doc/ikiwiki/markdown/discussion.mdwn deleted file mode 100644 index d3affec34..000000000 --- a/doc/ikiwiki/markdown/discussion.mdwn +++ /dev/null @@ -1 +0,0 @@ -Is anyone else having trouble using the definition list feature of multimarkdown? If not, then I could use some help figuring out why it's not working on my text site. Version is 3.141~bpo50+1 (debian backports), multimarkdown and mdwn support enabled in preferences. Any pointers to the obvious thing I'm missing would be appreciated. - dave diff --git a/doc/ikiwiki/searching.mdwn b/doc/ikiwiki/searching.mdwn index 539e7193d..4c1287933 100644 --- a/doc/ikiwiki/searching.mdwn +++ b/doc/ikiwiki/searching.mdwn @@ -5,7 +5,7 @@ then="This wiki has searching **enabled**." else="This wiki has searching **disabled**."]] If searching is enabled, you can enter search terms in the search field, -as you'd expect. There are a few special things you can do to constuct +as you'd expect. There are a few special things you can do to construct more powerful searches. * To match a phrase, enclose it in double quotes. diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn index 58dd51600..e1e25a045 100644 --- a/doc/ikiwikiusers.mdwn +++ b/doc/ikiwikiusers.mdwn @@ -124,6 +124,7 @@ Personal sites and blogs * [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) * [Skirv's Wiki](http://wiki.killfile.org) - formerly Skirv's Homepage +* [Jimmy Tang - personal blog and wiki](http://www.sgenomics.org/~jtang) Please feel free to add your own ikiwiki site! diff --git a/doc/news/openid.mdwn b/doc/news/openid.mdwn index 7a6f84518..79eeaec01 100644 --- a/doc/news/openid.mdwn +++ b/doc/news/openid.mdwn @@ -10,4 +10,4 @@ log back in, try out the OpenID signup process if you don't already have an OpenID, and see how OpenID works for you. And let me know your feelings about making such a switch. --[[Joey]] -[[!poll 63 "Accept only OpenID for logins" 19 "Accept only password logins" 36 "Accept both"]] +[[!poll 63 "Accept only OpenID for logins" 20 "Accept only password logins" 36 "Accept both"]] diff --git a/doc/plugins/contrib/cvs.mdwn b/doc/plugins/contrib/cvs.mdwn index 23e00201f..6b600eef7 100644 --- a/doc/plugins/contrib/cvs.mdwn +++ b/doc/plugins/contrib/cvs.mdwn @@ -22,8 +22,7 @@ Consider creating `$HOME/.cvsrc` if you don't have one already; the plugin doesn * [[ikiwiki-makerepo]]: * creates a repository, * imports `$SRCDIR` into top-level module `ikiwiki` (vendor tag IKIWIKI, release tag PRE_CVS), - * creates a small post-commit wrapper to prevent `cvs add <directory>` from being seen by ikiwiki's [[post-commit]] hook (and avoid `cvs` locking against itself), - * configures the wrapper itself as a post-commit hook in `CVSROOT/loginfo`. + * configures the post-commit hook in `CVSROOT/loginfo`. * CVS multi-directory commits happen separately; the post-commit hook sees only the first directory's changes in time for [[recentchanges|plugins/recentchanges]]. The next run of `ikiwiki --setup` will correctly re-render such a recentchanges entry. It should be possible to solve this problem with NetBSD's `commit_prep` and `log_accum` scripts (see below). ### To do diff --git a/doc/plugins/contrib/cvs/discussion.mdwn b/doc/plugins/contrib/cvs/discussion.mdwn new file mode 100644 index 000000000..e1fa6e428 --- /dev/null +++ b/doc/plugins/contrib/cvs/discussion.mdwn @@ -0,0 +1,91 @@ +I've started reviewing this, and the main thing I don't like is the +post-commit wrapper wrapper that ikiwiki-makerepo is patched to set up. +That just seems unnecessarily complicated. Why can't ikiwiki itself detect +the "cvs add <directory>" call and avoid doing anything in that case? +--[[Joey]] + +> The wrapper wrapper does three things: +> +> 7. It ignores `cvs add <directory>`, since this is a weird CVS +> behavior that ikiwiki gets confused by and doesn't need to act on. +> 7. It prevents `cvs` locking against itself: `cvs commit` takes a +> write lock and runs the post-commit hook, which runs `cvs update`, +> which wants a read lock and sleeps forever -- unless the post-commit +> hook runs in the background so the commit can "finish". +> 7. It fails silently if the ikiwiki post-commit hook is missing. +> CVS doesn't have any magic post-commit filenames, so hooks have to +> be configured explicitly. I don't think a commit will actually fail +> if a configured post-commit hook is missing (though I can't test +> this at the moment). +> +> Thing 1 can probably be handled within ikiwiki, if that seems less +> gross to you. + +>> It seems like it might be. You can use a `getopt` hook to check +>> `@ARGV` to see how it was called. --[[Joey]] + +>>> This does the trick iff the post-commit wrapper passes its args +>>> along. Committed on my branch. This seems potentially dangerous, +>>> since the args passed to ikiwiki are influenced by web commits. +>>> I don't see an exploit, but for paranoia's sake, maybe the wrapper +>>> should only be built with execv() if the cvs plugin is loaded? +>>> --[[schmonz]] + +>>>> Hadn't considered that. While in wrapper mode the normal getopt is not +>>>> done, plugin getopt still runs, and so any unsafe options that +>>>> other plugins support could be a problem if another user runs +>>>> the setuid wrapper and passes those options through. --[[Joey]] + +>>>>> I've tried compiling the argument check into the wrapper as +>>>>> the first thing main() does, and was surprised to find that +>>>>> this doesn't prevent the `cvs add <dir>` deadlock in a web +>>>>> commit. I was convinced this'd be a reasonable solution, +>>>>> especially if conditionalized on the cvs plugin being loaded, +>>>>> but it doesn't work. And I stuck debug printfs at the beginning +>>>>> of all the rcs_foo() subs, and whatever `cvs add <dir>` is +>>>>> doing to ikiwiki isn't visible to my plugin, because none of +>>>>> those subs are getting called. Nuts. Can you think of anything +>>>>> else that might solve the problem, or should I go back to +>>>>> generating a minimal wrapper wrapper that checks for just +>>>>> this one thing? --[[schmonz]] + +>>>>>> I don't see how there could possibly be a difference between +>>>>>> ikiwiki's C wrapper and your shell wrapper wrapper here. --[[Joey]] + +> Thing 2 I'm less sure of. (I'd like to see the web UI return +> immediately on save anyway, to a temporary "rebuilding, please wait +> if you feel like knowing when it's done" page, but this problem +> with CVS happens with any kind of commit, and could conceivably +> happen with some other VCS.) + +>> None of the other VCSes let a write lock block a read lock, apparently. +>> +>> Anyway, re the backgrounding, when committing via the web, the +>> post-commit hook doesn't run anyway; the rendering is done via the +>> ikiwiki CGI. It would certianly be nice if it popped up a quick "working" +>> page and replaced it with the updated page when done, but that's +>> unrelated; the post-commit +>> hook only does rendering when committing using the VCS directly. The +>> backgrounding you do actually seems safe enough -- but tacking +>> on a " &" to the ikiwiki wrapper call doesn't need a wrapper script, +>> does it? --[[Joey]] + +>>> Nope, it works fine to append it to the `CVSROOT/loginfo` line. +>>> Fixed on my branch. --[[schmonz]] + +> Thing 3 I think I did in order to squelch the error messages that +> were bollixing up the CGI. It was easy to do this in the wrapper +> wrapper, but if that's going away, it can be done just as easily +> with output redirection in `CVSROOT/loginfo`. +> +> --[[schmonz]] + +>> If the error messages screw up the CGI they must go to stdout. +>> I thought we had stderr even in the the CVS dark ages. ;-) --[[Joey]] + +>>> Some messages go to stderr, but definitely not all. That's why +>>> I wound up reaching for IPC::Cmd, to execute the command line +>>> safely while shutting CVS up. Anyway, I've tested what happens +>>> if a configured post-commit hook is missing, and it seems fine, +>>> probably also thanks to IPC::Cmd. +>>> --[[schmonz]] diff --git a/doc/plugins/contrib/rsync.mdwn b/doc/plugins/contrib/rsync.mdwn new file mode 100644 index 000000000..71cd63947 --- /dev/null +++ b/doc/plugins/contrib/rsync.mdwn @@ -0,0 +1,21 @@ +[[!template id=plugin name=rsync core=0 author="[[schmonz]]"]] + +[[!template id=gitbranch branch=schmonz author="[[schmonz]]"]] + +This plugin allows ikiwiki to push generated pages to another host +by running a command such as `rsync`. + +### Usage +7. Enable automated SSH key exchange between ikiwiki and the remote + host. [keychain](http://www.gentoo.org/proj/en/keychain/) makes + it easy to use a passphrase-protected key for this purpose. It's + also a good idea to specify the exact command line to be permitted + in the remote host's `$HOME/.ssh/authorized_keys`. +7. Set `rsync_command` in your setup file. If you're using a + passphrase-protected key, then set `rsync_command` to a shell + script which reads `keychain`'s current state before calling + `rsync`. + +### Implementation details +* The plugin relies on a new "postrefresh" hook called at the very end of + `IkiWiki/Render.pm:refresh()`. diff --git a/doc/plugins/contrib/rsync/discussion.mdwn b/doc/plugins/contrib/rsync/discussion.mdwn new file mode 100644 index 000000000..20c04af0f --- /dev/null +++ b/doc/plugins/contrib/rsync/discussion.mdwn @@ -0,0 +1,48 @@ +## A use case + +Why I needed this plugin: I have two web servers available to me +for a project. Neither does everything I need, but together they +do. (This is a bit like the [Amazon S3 +scenario](http://kitenet.net/~joey/blog/entry/running_a_wiki_on_Amazon_S3/).) + +Server (1) is a university web server. It provides plentiful space +and bandwidth, easy authentication for people editing the wiki, and +a well-known stable URL. The wiki really wants to live here and +very easily could except that the server doesn't allow arbitrary +CGIs. + +Server (2) is provided by a generous alumnus's paid [[tips/DreamHost]] +account. Disk and particularly network usage need to be minimized +because over some threshold it costs him. CGI, etc. are available. + +My plan was to host the wiki on server (1) by taking advantage of +server (2) to store the repository, source checkout, and generated +pages, to host the repository browser, and to handle ikiwiki's CGI +operations. In order for this to work, web edits on (2) would need +to automatically push any changed pages to (1). + +As a proof of concept, I added an rsync post-commit hook after +ikiwiki's usual. It worked, just not for web edits, which is how +the wiki will be used. So I wrote this plugin to finish the job. +The wiki now lives on (1), and clicking "edit" just works. --[[schmonz]] + +> Just out of interest, why use `rsync` and not `git push`. i.e. a +> different setup to solve the same problem would be to run a +> normal ikiwiki setup on the universities server with its git +> repository available over ssh (same security setup your using +> for rsync should work for git over ssh). On the cgi-capable server, +> when it would rsync, make it git push. It would seem that git +> has enough information that it should be able to be more +> network efficient. It also means that corruption at one end +> wouldn't be propagated to the other end. -- [[Will]] + +>> Hey, that's a nice solution. (The site was in svn to begin with, +>> but it's in git now.) One advantage of my approach in this particular +>> case: server (1) doesn't have `git` installed, but does have `rsync`, +>> so (1)'s environment can remain completely untweaked other than the +>> SSH arrangement. I kind of like that all the sysadmin effort is +>> contained on one host. +>> +>> This plugin is definitely still useful for projects not able to use +>> a DVCS (of which I've got at least one other), and possibly for +>> other uses not yet imagined. ;-) --[[schmonz]] diff --git a/doc/plugins/po.mdwn b/doc/plugins/po.mdwn index 2fbf67016..04420c115 100644 --- a/doc/plugins/po.mdwn +++ b/doc/plugins/po.mdwn @@ -114,7 +114,8 @@ 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. + +Add 'Options MultiViews' to the wiki directory's configuration in Apache. When `usedirs` is enabled, one has to set `DirectoryIndex index` for the wiki context. @@ -123,6 +124,8 @@ 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`. +For details, see [Apache's documentation](http://httpd.apache.org/docs/2.2/content-negotiation.html). + lighttpd -------- @@ -248,16 +251,7 @@ 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]] +and `meta` branches, and thus has this additional features. Language display order ---------------------- @@ -268,15 +262,67 @@ 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 ? ------------------- +Pagespecs +--------- + +I was suprised that, when using the map directive, a pagespec of "*" +listed all the translated pages as well as regular pages. That can +make a big difference to an existing wiki when po is turned on, +and seems generally not wanted. +(OTOH, you do want to match translated pages by +default when locking pages.) --[[Joey]] -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? +Edit links on untranslated pages +-------------------------------- + +If a page is not translated yet, the "translated" version of it +displays wikilinks to other, existing (but not yet translated?) +pages as edit links, as if those pages do not exist. + +That's really confusing, especially as clicking such a link +brings up an edit form to create a new, english page. + +This is with po_link_to=current or negotiated. With default, it doesn't +happen.. + +Also, this may only happen if the page being linked to is coming from an +underlay, and the underlays lack translation to a given language. --[[Joey]] +Double commits of po files +-------------------------- + +When adding a new english page, the po files are created, committed, +and then committed again. The second commit makes this change: + + -"Content-Type: text/plain; charset=utf-8\n" + -"Content-Transfer-Encoding: ENCODING" + +"Content-Type: text/plain; charset=UTF-8\n" + +"Content-Transfer-Encoding: ENCODING\n" + +Same thing happens when a change to an existing page triggers a po file +update. --[[Joey]] + +Ugly messages with empty files +------------------------------ + +If there are empty .mdwn files, the po plugin displays some ugly messages. + +Translation of directives +------------------------- + +If a translated page contains a directive, it may expand to some english +text, or text in whatever single language ikiwiki is configured to "speak". + +Maybe there could be a way to switch ikiwiki to speaking another language +when building a non-english page? Then the directives would get translated. + +2 test suite failures +-------------------- + +t/po is currently failing tests 57 and 59 (and I would like to release +soon..) --[[Joey]] + Documentation ------------- diff --git a/doc/plugins/po/discussion.mdwn b/doc/plugins/po/discussion.mdwn index 1c3f0e752..ab822e76c 100644 --- a/doc/plugins/po/discussion.mdwn +++ b/doc/plugins/po/discussion.mdwn @@ -699,3 +699,28 @@ and via CGI, have been tested. * 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** + +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]] + +> It would replace it. The only problematic case is when another +> plugin has its own reasons, in its `scan` hook, to add a page +> that is already there to `$links{$page}`. This other plugin's +> effect might then be changed by po's `scan` hook... which could +> be either good (better overall l10n) or bad (break the other +> plugin's goal). --[[intrigeri]] + +>> Right.. well, the cases where links are added is very small. +>> Grepping for `add_link`, it's just done by link, camelcase, meta, and +>> tag. All of these are supposed to work just link regular links +>> so I'd think that is ok. We could probably remove the currently scary +>> comment about only wanting to change the first link. --[[Joey]] + +>>> Commit 3c2bffe21b91684 in my po branch does this. --[[intrigeri]] +>>>> Cherry-picked --[[Joey]] diff --git a/doc/plugins/recentchanges.mdwn b/doc/plugins/recentchanges.mdwn index 4ab2cd078..9375296a4 100644 --- a/doc/plugins/recentchanges.mdwn +++ b/doc/plugins/recentchanges.mdwn @@ -24,3 +24,6 @@ Here's an example of how to show only changes that Joey didn't make. \[[!inline pages="internal(recentchanges/change_*) and !author(joey) and !author(http://joey.kitenet.net*)" template=recentchanges show=0]] + +If you want to generate feeds for the RecentChanges page, you have to use +[[`rss`_or_`atom`_in_the_setup_file|/todo/minor adjustment to setup documentation for recentchanges feeds]]. diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn index 9b0a53c68..96b880b34 100644 --- a/doc/sandbox.mdwn +++ b/doc/sandbox.mdwn @@ -4,16 +4,18 @@ This is the [[SandBox]], a page anyone can edit to try out ikiwiki (version [[!v 2009/7/13 Monday Blue...\\ While working on [[http://eoffice.im.fju.edu.tw/phpbb/viewtopic.php?p=27199|[97] Phpbb 與 Dokuwiki 之間的往來]] (External Link to //http://eoffice.im.fju.edu.tw/phpbb/viewtopic.php?p=27199// not working?), surf Internet for Wikis supporting //Creole V1.0//, found this site. -<<<<<<< HEAD:doc/sandbox.mdwn * I thought that creole markup is used by ikiwiki... * Thought about using //SVN/CVS// server, however with different idea * Kinda curious why **Tcl** does not show her face in this Wiki arena -======= -* Thought about using //SVN/CVS// server, however with different idea -* Kinda curious why **Tcl** does not show her face in this Wiki arena * It looks like that I was wrong, from Wikipedia Creole page it mention that ikiwiki is also adopting Creole markup. ->>>>>>> 55c1a37cce91d4fd01bf80fcaeeaf56535218a5c:doc/sandbox.mdwn +--- + +Guten Morgen aus Deutschland. Wir mögen Umläuter (ich weiß, der Plural ist falsch, aber dafür hat er einen). Die sind heutzutage kein Ärgernis mehr. + +&#x263a; becomes ☺ + +<script>alert("If this pops, ikiwiki is not cross site scripting safe."); /* Fortunately, this does not work. */</script> --- I try to have a discussion page !!! @@ -169,3 +171,13 @@ testing [[!toc levels=2]] [[Mamma Mia]] + +---- + +[[!format c """ +void main () { + printf("hello, world!"); +} +"""]] + + diff --git a/doc/setup/byhand.mdwn b/doc/setup/byhand.mdwn index 0184d3d2a..53f8d18bb 100644 --- a/doc/setup/byhand.mdwn +++ b/doc/setup/byhand.mdwn @@ -83,7 +83,7 @@ the rest of the files. A good place to put it is in a ~/.ikiwiki/ subdirectory. Most of the options, like `wikiname` in the setup file are the same as -ikiwiki's command line options (documented in [[usage]]. `srcdir` and +ikiwiki's command line options (documented in [[usage]]). `srcdir` and `destdir` are the two directories you specify when running ikiwiki by hand. Make sure that these are pointing to the right directories, and read through and configure the rest of the file to your liking. diff --git a/doc/shortcuts.mdwn b/doc/shortcuts.mdwn index 14cd5ff2b..500146a31 100644 --- a/doc/shortcuts.mdwn +++ b/doc/shortcuts.mdwn @@ -62,9 +62,9 @@ This page controls what shortcut links the wiki supports. To add a new shortcut, use the `shortcut` [[ikiwiki/directive]]. In the url, "%s" is replaced with the -text passed to the named shortcut, after url-encoding it, and '%S' is -replaced with the raw, non-encoded text. The optional `desc` parameter -controls the description of the link. +text passed to the named shortcut, after [[!wikipedia url_encoding]] +it, and '%S' is replaced with the raw, non-encoded text. The optional +`desc` parameter controls the description of the link. Remember that the `name` you give the shortcut will become a new [[ikiwiki/directive]]. Avoid using a `name` that conflicts @@ -73,5 +73,5 @@ parameter that will override the one provided at definition time. If you come up with a shortcut that you think others might find useful, consider contributing it to the [shortcuts page on the ikiwiki -ikiwiki](http://ikiwiki.info/shortcuts/), so that future versions of +wiki](http://ikiwiki.info/shortcuts/), so that future versions of ikiwiki will include your shortcut in the standard underlay. diff --git a/doc/style.css b/doc/style.css index e6512aed8..4770fc942 100644 --- a/doc/style.css +++ b/doc/style.css @@ -24,6 +24,10 @@ padding: 6px; list-style-type: none; } +.actions li { + display: inline; + padding: .2em .4em; +} .pageheader .actions ul { border-bottom: 1px solid #000; } @@ -32,14 +36,22 @@ border-bottom: 0; } -div.inlinecontent { - margin-top: .4em; +#otherlanguages ul { + margin: 0; + padding: 6px; + list-style-type: none; } - -.actions li { +#otherlanguages li { display: inline; padding: .2em .4em; } +.pageheader #otherlanguages { + border-bottom: 1px solid #000; +} + +div.inlinecontent { + margin-top: .4em; +} .pagefooter { clear: both; diff --git a/doc/tips/laptop_wiki_with_git_extended.mdwn b/doc/tips/laptop_wiki_with_git_extended.mdwn index 620370218..0666da450 100644 --- a/doc/tips/laptop_wiki_with_git_extended.mdwn +++ b/doc/tips/laptop_wiki_with_git_extended.mdwn @@ -10,7 +10,7 @@ a bare repo on `gitserver`, and clone that to a workingdir on gitserver. Next create a setup file for the laptop with gitorigin_branch=> "", - wrapper => "/working/dir/.git/hooks/post-commit", + git_wrapper => "/working/dir/.git/hooks/post-commit", At this point, assuming you followed page above, and not my hasty summary, @@ -21,7 +21,7 @@ a bare repo on `gitserver`, and clone that to a workingdir on gitserver. 2. Now create a setup file for the server (I call it server.setup). gitorigin_branch=> "origin", - wrapper => "/repo/wiki.git/hooks/post-update.ikiwiki" + git_wrapper => "/repo/wiki.git/hooks/post-update.ikiwiki" Note the non-standard and bizzare name of the hook. diff --git a/doc/tips/nearlyfreespeech/discussion.mdwn b/doc/tips/nearlyfreespeech/discussion.mdwn new file mode 100644 index 000000000..3d4dc732d --- /dev/null +++ b/doc/tips/nearlyfreespeech/discussion.mdwn @@ -0,0 +1,9 @@ +with version 3.141592 I get +<pre> +HOME=/home/me /usr/bin/perl -Iblib/lib ikiwiki.out -libdir . -dumpsetup ikiwiki.setup +Failed to load plugin IkiWiki::Plugin::inline: Can't use global $_ in "my" at IkiWiki/Plugin/inline.pm line 198, near "my $_" +Compilation failed in require at (eval 19) line 2. +BEGIN failed--compilation aborted at (eval 19) line 2. +</pre> + +perl is 5.8.9 diff --git a/doc/todo/Raw_view_link.mdwn b/doc/todo/Raw_view_link.mdwn index fd64074c2..b62a9022b 100644 --- a/doc/todo/Raw_view_link.mdwn +++ b/doc/todo/Raw_view_link.mdwn @@ -4,7 +4,7 @@ The configuration setting for Mercurial could be something like this: rawurl => "http://localhost:8000//raw-file/tip/\[[file]]", -> What I want to do when I want to see if the raw source is either +> What I do when I want to see if the raw source is either > click on the edit link, or click on history and navigate to it in the > history browser (easier to do in viewvc than in gitweb, IIRC). > Not that I'm opposed to the idea of a plugin that adds a Raw link @@ -14,4 +14,6 @@ The configuration setting for Mercurial could be something like this: >> to gitweb/etc. I think Will's patch is a good approach, and have improved >> on it a bit in a git branch. +>>> Since that is merged in now, I'm marking this [[done]] --[[Joey]] + [[!tag wishlist]] diff --git a/doc/todo/Restrict_page_viewing.mdwn b/doc/todo/Restrict_page_viewing.mdwn new file mode 100644 index 000000000..089d27fff --- /dev/null +++ b/doc/todo/Restrict_page_viewing.mdwn @@ -0,0 +1,36 @@ +I'd like to have some pages of my wiki to be only viewable by some users. + +I could use htaccess for that, but it would force the users to have +2 authentication mecanisms, so I'd prefer to use openID for that too. + +* I'm thinking of adding a "show" parameter to the cgi script, thanks + to a plugin similar to goto. +* When called, it would check the credential using the session stuff + (that I don't understand yet). +* If not enough, it would serve a 403 error of course. +* If enough, it would read the file locally on the server side and + return this as a content. + +Then, I'd have to generate the private page the regular way with ikiwiki, +and prevent apache from serving them with an appropriate and +much more maintainable htaccess file. + +-- [[users/emptty]] + +> While I'm sure a plugin could do this, it adds so much scalability cost +> and is so counter to ikiwiki's design.. Have you considered using the +> [[plugins/httpauth]] plugin to unify around htaccess auth? --[[Joey]] + +>> I'm not speaking of rendering the pages on demand, but to serve them on demand. +>> They would still be compiled the regular way; +>> I'll have another look at [[plugins/httpauth]] but I really like the openID whole idea. +>> --[[emptty]] + +>>> How about +>>> [mod_auth_openid](http://trac.butterfat.net/public/mod_auth_openid), then? +>>> A plugin for ikiwiki to serve its own pages is far afield from ikiwiki's roots, +>>> as Joey pointed out, but might be a neat option to have anyway -- for unifying +>>> authentication across views and edits, for systems not otherwise running +>>> web servers, for systems with web servers you don't have access to, and +>>> doubtless for other purposes. Such a plugin would add quite a bit of flexibility, +>>> and in that sense (IMO, of course) it'd be in the spirit of ikiwiki. --[[schmonz]] 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 0fb14bafe..4489dd5d2 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 @@ -23,4 +23,4 @@ that we're at the root of a (sub-)hierarchy. >> This sounds like WONTFIX to me? --[[smcv]] -[[!tag wishlist]] +[[!tag wishlist done]] diff --git a/doc/todo/l10n.mdwn b/doc/todo/l10n.mdwn index bba103494..fed3f63b6 100644 --- a/doc/todo/l10n.mdwn +++ b/doc/todo/l10n.mdwn @@ -1,3 +1,19 @@ +ikiwiki should be fully internationalized. + +---- + +As to the hardcoded strings in ikiwiki, I've internationalized the program, +and there is a po/ikiwiki.pot in the source that can be translated. +--[[Joey]] + +---- + +> The now merged po plugin handles l10n of wiki pages. The only missing +> piece now is l10n of the templates. +> --[[Joey]] + +---- + From [[Recai]]: > Here is my initial work on ikiwiki l10n infrastructure (I'm sending it > before finalizing, there may be errors). @@ -54,48 +70,3 @@ kullanıcının ait IP adresi: <TMPL_VAR REMOTE_ADDR>[2] <TMPL_VAR WIKIURL> This could be easily worked around in tmpl_process3, but I wouldn't like to maintain a separate utility. ----- - -As to the hardcoded strings in ikiwiki, I've internationalized the program, -and there is a po/ikiwiki.pot in the source that can be translated. ---[[Joey]] - ----- - -Danish l10n of templates and basewiki is available with the following commands: - - git clone http://source.jones.dk/ikiwiki.git newsite - cd newsite - make - -Updates are retrieved with this single command: - - make - -l10n is maintained using po4a for basewiki, smiley and templates - please send me PO files if you -translate to other languagess than the few I know about myself: <dr@jones.dk> - -As upstream ikiwiki is now maintained in GIT too, keeping the master mirror in sync with upstream -could probably be automated even more - but an obstacle seems to be that content is not maintained -separately but as an integral part of upstream source (GIT seems to not support subscribing to -only parts of a repository). - -For example use, here's how to roll out a clone of the [Redpill support site](http://support.redpill.dk/): - - mkdir -p ~/public_cgi/support.redpill.dk - git clone git://source.jones.dk/bin - bin/localikiwikicreatesite -o git://source.redpill.dk/support rpdemo - -(Redpill support is inspired by <http://help.riseup.net> but needs to be reusable for several similarly configured networks) - ---[[JonasSmedegaard]] - -> I don't understand at all why you're using git the way you are. -> -> I think that this needs to be reworked into a patch against the regular -> 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 90bfbef3b..44fcf32bb 100644 --- a/doc/todo/language_definition_for_the_meta_plugin.mdwn +++ b/doc/todo/language_definition_for_the_meta_plugin.mdwn @@ -95,7 +95,24 @@ This may be useful for sites with a few pages in different languages, but no ful >>> 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]] +>>> thinks it should be. --[[smcv]] + +>>>> Agreed, users of the po plugin would greatly benefit from it. +>>>> Seems doable. --[[intrigeri]] + +>>> Perhaps [[the_special_po_pagespecs|ikiwiki/pagespec/po]] should +>>> also work with meta-assigned languages? --[[smcv]] + +>>>> Yes. But then, these special pagespecs should be moved outside of +>>>> [[plugins/po]], as they could be useful to anyone using the +>>>> currently discussed patch even when not using the po plugin. +>>>> +>>>> We could add these pagespecs to the core and make them use +>>>> a simple language-guessing system based on a new hook. Any plugin +>>>> that implements such a hook could decide whether it should +>>>> overrides the language guessed by another one, and optionally use +>>>> the `first`/`last` options (e.g. the po plugin will want to be +>>>> authoritative on the pages of type po, and will then use +>>>> `last`). --[[intrigeri]] [[!tag wishlist patch plugins/meta translation]] diff --git a/doc/todo/mirrorlist_with_per-mirror_usedirs_settings.mdwn b/doc/todo/mirrorlist_with_per-mirror_usedirs_settings.mdwn new file mode 100644 index 000000000..6ca9962ba --- /dev/null +++ b/doc/todo/mirrorlist_with_per-mirror_usedirs_settings.mdwn @@ -0,0 +1,24 @@ +I've got a wiki that is built at two places: + +* a static copy, aimed at being viewed without any web server, using + a web browser's `file:///` urls => usedirs is disabled to get nice + and working links +* an online copy, with usedirs enabled in order to benefit from the + language negotiation using the po plugin + +I need to use mirrorlist on the static copy, so that one can easily +reach the online, possibly updated, pages. But as documented, "pages are +assumed to exist in the same location under the specified url on each +mirror", so the generated urls are wrong. + +My `mirrorlist` branch contains a patch that allows one to configure usedirs +per-mirror. Note: the old configuration format is still supported, so this should +not break existing wikis. + +OT: as a bonus, this branch contains a patch to support {hashes,arrays} of +{hashes,arrays} in `$config`, which I missed a bit when writing the po plugin, +and decided this time it was really needed to implement this feature. + +--[[intrigeri]] + +[[!tag patch]] diff --git a/doc/todo/optimize_simple_dependencies.mdwn b/doc/todo/optimize_simple_dependencies.mdwn new file mode 100644 index 000000000..91e184c29 --- /dev/null +++ b/doc/todo/optimize_simple_dependencies.mdwn @@ -0,0 +1,97 @@ +[[!template id=gitbranch branch=smcv/ready/depends-exact author="[[smcv]]"]] + +I'm still trying to optimize ikiwiki for a site using +[[plugins/contrib/album]], and checking which pages depend on which pages +is still taking too long. Here's another go at fixing that, using [[Will]]'s +suggestion from [[todo/should_optimise_pagespecs]]: + +> A hash, by itself, is not optimal because +> the dependency list holds two things: page names and page specs. The hash would +> work well for the page names, but you'll still need to iterate through the page specs. +> I was thinking of keeping a list and a hash. You use the list for pagespecs +> and the hash for individual page names. To make this work you need to adjust the +> API so it knows which you're adding. -- [[Will]] + +If you have P pages and refresh after changing C of them, where an average +page has E dependencies on exact page names and D other dependencies, this +branch should drop the complexity of checking dependencies from +O(P * (D+E) * C) to O(C + P*E + P*D*C). Pages that use inline or map have +a large value for E (e.g. one per inlined page) and a small value for D (e.g. +one per inline). + +Benchmarking: + +Test 1: a wiki with about 3500 pages and 3500 photos, and a change that +touches about 350 pages and 350 photos + +Test 2: the docwiki (about 700 objects not excluded by docwiki.setup, mostly +pages), docwiki.setup modified to turn off verbose, and a change that touches +the 98 pages of plugins/*.mdwn + +In both tests I rebuilt the wiki with the target ikiwiki version, then touched +the appropriate pages and refreshed. + +Results of test 1: without this branch it took around 5:45 to rebuild and +around 5:45 again to refresh (so rebuilding 10% of the pages, then deciding +that most of the remaining 90% didn't need to change, took about as long as +rebuilding everything). With this branch it took 5:47 to rebuild and 1:16 +to refresh. + +Results of test 2: rebuilding took 14.11s without, 13.96s with; refreshing +three times took 7.29/7.40/7.37s without, 6.62/6.56/6.63s with. + +(This benchmarking was actually done with my [[plugins/contrib/album]] branch, +since that's what the huge wiki needs; that branch doesn't alter core code +beyond the ready/depends-exact branch point, so the results should be +equally valid.) + +--[[smcv]] + +> Now [[merged|done]] --[[smcv]] + +---- + +> We discussed this on irc; I had some worries that things may have been +> switched to `add_depends_exact` that were not pure page names. My current +> feeling is it's all safe, but who knows. It's easy to miss something. +> Which makes me think this is not a good interface. +> +> Why not, instead, make `add_depends` smart. If it's passed something +> that is clearly a raw page name, it can add it to the exact depends hash. +> Else, add it to the pagespec hash. You can tell if it's a pure page name +> by matching on `$config{wiki_file_regexp}`. + +>> Good thinking. Done in commit 68ce514a 'Auto-detect "simple dependencies"', +>> with a related bugfix in e8b43825 "Force %depends_exact to lower case". +>> +>> Performance impact: Test 2 above takes 0.2s longer to rebuild (probably +>> from all the calls to lc, which are, however, necessary for correctness) +>> and has indistinguishable performance for a refresh. +>> +>> Test 1 took about 6 minutes to rebuild and 1:25 to refresh; those are +>> pessimistic figures, since I've added 90 more photos and 90 more pages +>> (both to the wiki as a whole, and the number touched before refreshing) +>> since testing the previous version of this branch. --[[smcv]] + +> Also I think there may be little optimisation value left in +> 7227c2debfeef94b35f7d81f42900aa01820caa3, since the "regular" dependency +> lists will be much shorter. + +>> You're probably right, but IMO it's not worth reverting it - a set (hash with +>> dummy values) is still the right data structure. --[[smcv]] + +> Sounds like inline pagenames has an already exstant bug WRT +> pages moving, which this should not make worse. Would be good to verify. + +>> If you mean the standard "add a better match for a link-like construct" bug +>> that also affects sidebar, then yes, it does have the bug, but I'm pretty +>> sure this branch doesn't make it any worse. I could solve this at the cost +>> of making pagenames less useful for interactive use, by making it not +>> respect [[ikiwiki/subpage/LinkingRules]], but instead always interpret +>> its paths as relative to the top of the wiki - that's actually all that +>> [[plugins/contrib/album]] needs. --[[smcv]] + +> Re coding, it would be nice if `refresh()` could avoid duplicating +> the debug message, etc in the two cases. --[[Joey]] + +>> Fixed in commit f805d566 "Avoid duplicating debug message..." --[[smcv]] diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn index 3ccef62fe..4b4e267f0 100644 --- a/doc/todo/should_optimise_pagespecs.mdwn +++ b/doc/todo/should_optimise_pagespecs.mdwn @@ -90,6 +90,8 @@ I can think about reducung the size of my wiki source and making it available on >> rather than a single pagespec. This does turn out to be faster, although >> not as much as I'd like. --[[smcv]] +>>> [[Merged|done]] --[[smcv]] + >>> I just wanted to note that there is a whole long discussion of dependencies and pagespecs on the [[todo/tracking_bugs_with_dependencies]] page. -- [[Will]] >>>> Yeah, I had a look at that (as the only other mention of `pagespec_merge`). @@ -105,4 +107,211 @@ I can think about reducung the size of my wiki source and making it available on >>>>> ikiwiki-transition, but that copy doesn't have to be optimal or support >>>>> future features like [[tracking_bugs_with_dependencies]]). --[[smcv]] +--- + +Some questions on your optimize-depends branch. --[[Joey]] + +In saveindex it still or'd together the depends list, but the `{depends}` +field seems only useful for backwards compatability (ie, ikiwiki-transition +uses it still), and otherwise just bloats the index. + +> If it's acceptable to declare that downgrading IkiWiki requires a complete +> rebuild, I'm happy with that. I'd prefer to keep the (simple form of the) +> transition done automatically during a load/save cycle, rather than +> requiring ikiwiki-transition to be run; we should probably say in NEWS +> that the performance increase won't fully apply until the next +> rebuild. --[[smcv]] + +>> It is acceptable not to support downgrades. +>> I don't think we need a NEWS file update since any sort of refresh, +>> not just a full rebuild, will cause the indexdb to be loaded and saved, +>> enabling the optimisation. --[[Joey]] + +>>> A refresh will load the current dependencies from `{depends}` and save +>>> them as-is as a one-element `{dependslist}`; only a rebuild will replace +>>> the single complex pagespec with a long list of simpler pagespecs. +>>> --[[smcv]] + +Is an array the right data structure? `add_depends` has to loop through the +array to avoid dups, it would be better if a hash were used there. Since +inline (and other plugins) explicitly add all linked pages, each as a +separate item, the list can get rather long, and that single add_depends +loop has suddenly become O(N^2) to the number of pages, which is something +to avoid.. + +> I was also thinking about this (I've been playing with some stuff based on the +> `remove-pagespec-merge` branch). A hash, by itself, is not optimal because +> the dependency list holds two things: page names and page specs. The hash would +> work well for the page names, but you'll still need to iterate through the page specs. +> I was thinking of keeping a list and a hash. You use the list for pagespecs +> and the hash for individual page names. To make this work you need to adjust the +> API so it knows which you're adding. -- [[Will]] + +> I wasn't thinking about a lookup hash, just a dedup hash, FWIW. +> --[[Joey]] + +>> I was under the impression from previous code review that you preferred +>> to represent unordered sets as lists, rather than hashes with dummy +>> values. If I was wrong, great, I'll fix that and it'll probably go +>> a bit faster. --[[smcv]] + +>>> It depends, really. And it'd certianly make sense to benchmark such a +>>> change. --[[Joey]] + +>>>> Benchmarked, below. --[[smcv]] + +Also, since a lot of places are calling add_depends in a loop, it probably +makes sense to just make it accept a list of dependencies to add. It'll be +marginally faster, probably, and should allow for better optimisation +when adding a lot of depends at once. + +> That'd be an API change; perhaps marginally faster, but I don't +> see how it would allow better optimisation if we're de-duplicating +> anyway? --[[smcv]] + +>> Well, I was thinking that it might be sufficient to build a `%seen` +>> hash of dependencies inside `add_depends`, if the places that call +>> it lots were changed to just call it once. Of course the only way to +>> tell is benchmarking. --[[Joey]] + +>>> It doesn't seem that it significantly affects performance either way. +>>> --[[smcv]] + +In Render.pm, we now have a triply nested loop, which is a bit +scary for efficiency. It seems there should be a way to +rework this code so it can use the optimised `pagespec_match_list`, +and/or hoist some of the inner loop calculations (like the `pagename`) +out. + +> I don't think the complexity is any greater than it was: I've just +> moved one level of "loop" out of the generated Perl, to be +> in visible code. I'll see whether some of it can be hoisted, though. +> --[[smcv]] + +>> The call to `pagename` is the only part I can see that's clearly +>> run more often than before. That function is pretty inexpensive, but.. +>> --[[Joey]] + +>>> I don't see anything that can be hoisted without significant refactoring, +>>> actually. Beware that there are two pagename calls in the loop: one for +>>> `$f` (which is the page we might want to rebuild), and one for `$file` +>>> (which is the changed page that it might depend on). Note that I didn't +>>> choose those names! +>>> +>>> The three loops are over source files, their lists of dependency pagespecs, +>>> and files that might have changed. I see the following things we might be +>>> doing redundantly: +>>> +>>> * If `$file` is considered as a potential dependency for more than +>>> one `$f`, we evaluate `pagename($file)` more than once. Potential fix: +>>> cache them (this turns out to save about half a second on the docwiki, +>>> see below). +>>> * If several pages depend on the same pagespec, we evaluate whether each +>>> changed page matches that pagespec more than once: however, we do so +>>> with a different location parameter every time, so repeated calls are, +>>> in the general case, the only correct thing to do. Potential fix: +>>> perhaps special-case "page x depends on page y and nothing else" +>>> (i.e. globs that have no wildcards) into a separate hash? I haven't +>>> done anything in this direction. +>>> * Any preparatory work done by pagespec_match (converting the pagespec +>>> into Perl, mostly?) is done in the inner loop; switching to +>>> pagespec_match_list (significant refactoring) saves more than half a +>>> second on the docwiki. +>>> +>>> --[[smcv]] + +Very good catch on img/meta using the wrong dependency; verified in the wild! +(I've cherry-picked those bug fixes.) + +---- + +Benchmarking results: I benchmarked by altering docwiki.setup to switch off +verbose, running "make clean && ./Makefile.PL && make", and timing one rebuild +of the docwiki followed by three refreshes. Before each refresh I used +`touch plugins/*.mdwn` to have something significant to refresh. + +I'm assuming that "user" CPU time is the important thing here (system time was +relatively small in all cases, up to 0.35 seconds per run). + +master at the time of rebasing: 14.20s to rebuild, 10.04/12.07/14.01s to +refresh. I think you can see the bug clearly here - the pagespecs are getting +more complicated every time! + +> I can totally see a bug here, and it's one I didn't think existed. Ie, +> I thought that after the first refresh, the pagespec should stabalize, +> and what it stabalized to was probably unnecessarily long, but not +> growing w/o bounds! +> +> a) Explains why ikiwiki.info has been so slow lately. Well that and some +> other things that overloaded the system. +> b) Suggests to me we will probably want to force a rebuild on upgrade +> when fixing this (via the mechanism in the postinst). +> +> I've investigated why the pagespecs keep growing: When page A changes, +> its old depends are cleared. Then +> page B that inlines A gets rebuilt, and its old depends are also cleared. +> But page B also inlines page C; which means C gets re-rendered. And this +> happens w/o its old depends being cleared, so C's depends are doubled. +> --[[Joey]] + +After the initial optimization: 14.27s to rebuild, 8.26/8.33/8.26 to refresh. +Success! + +Not pre-joining dependencies actually took about ~0.2s more; I don't know why. +I'm worried that duplicates will just build up (again) in less simple cases, +though, so 0.2s is probably a small price to pay for that not happening (it +might well be experimental error, for that matter). + +> It's weird that the suggested optimisations to +> `add_depends` had no effect. So, the commit message to +> b6fcb1cb0ef27e5a63184440675d465fad652acf is actually wrong.. ? --[[Joey]] + +>> I'll try benchmarking again on the non-public wiki where I had the 4% +>> speedup. The docwiki is so small that 4% is hard to measure... --[[smcv]] + +Not saving {depends} to the index, using a hash instead of a list to +de-duplicate, and allowing add_depends to take an arrayref instead of a single +pagespec had no noticable positive or negative effect on this test. + +> I see e4cd168ebedd95585290c97ff42234344bfed46c is still in your branch +> though. I don't like using an arrayref, it could just take `($page, @depends)`. +> and I don't see the need to keep it if it doesn't currently help. + +>> I'll drop it. --[[smcv]] + +> Is there any reason to keep 7227c2debfeef94b35f7d81f42900aa01820caa3 +> if it doesn't improve speed? +> --[[Joey]] + +>> I'll try benchmarking on a more complex wiki and see whether it has a +>> positive or negative effect. It does avoid being O(n**2) in number of +>> dependencies. --[[smcv]] + +Memoizing the results of pagename brought the rebuild time down to 14.06s +and the refresh time down to 7.96/7.92/7.92, a significant win. + +> Ok, that seems safe to memoize. (It's a real function and it isn't +> called with a great many inputs.) Why did you chose to memoize it +> explicitly rather than adding it to the memoize list at the top? + +>> It does depend on global variables, so using Memoize seemed like asking for +>> trouble. I suppose what I did is equivalent to Memoize though... --[[smcv]] + +Refactoring to use pagespec_match_list looks more risky from a code churn +point of view; rebuild now takes 14.35s, but refresh is only 7.30/7.29/7.28, +another significant win. + +--[[smcv]] + +> I had mostly convinced myself that +> `pagespec_match_list` would not lead to a speed gain here. My reasoning +> was that you want to stop after finding one match, while `pagespec_match_list` +> checks all pages for matches. So what we're seeing is that +> on a rebuild, `@changed` is all pages, and not short-circuiting leads +> to unnecessary work. OTOH, on refresh, `@changed` is small and I suppose +> `pagespec_match_list`'s other slight efficiencies win out somehow. +> +> Welcome to the "I made ikiwiki twice as fast +> and all I got was this lousy git sha1sum" club BTW :-) --[[Joey]] + [[!tag wishlist patch patch/core]] diff --git a/doc/todo/tmplvars_plugin/discussion.mdwn b/doc/todo/tmplvars_plugin/discussion.mdwn new file mode 100644 index 000000000..93cb9b414 --- /dev/null +++ b/doc/todo/tmplvars_plugin/discussion.mdwn @@ -0,0 +1 @@ +I find this plugin quite usefull. But one thing, I would like to be able to do is set a tmplvar e.g. in a sidebar so that it affects all Pages this sidebar is used in. --martin diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn index a198530fc..bfdbf0875 100644 --- a/doc/todo/tracking_bugs_with_dependencies.mdwn +++ b/doc/todo/tracking_bugs_with_dependencies.mdwn @@ -410,8 +410,8 @@ 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]] +>>> My [[remove-pagespec-merge|should_optimise_pagespecs]] branch has now +>>> solved all this by deleting the offending function :-) --[[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 diff --git a/doc/translation.mdwn b/doc/translation.mdwn index 459f47eb5..d869a6821 100644 --- a/doc/translation.mdwn +++ b/doc/translation.mdwn @@ -26,6 +26,10 @@ essentially three pieces needed for a complete translation: [[plugins/contrib/po]] ikiwiki plugin will allow translating wikis using po files and can be used for this. + There is now a website, [l10n.ikiwiki.info](http://l10n.ikiwiki.info) + that both demos the translated basewiki, and allows easy translation of + it. + 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`. diff --git a/doc/users/Jimmy_Tang.mdwn b/doc/users/Jimmy_Tang.mdwn new file mode 100644 index 000000000..a1402bcae --- /dev/null +++ b/doc/users/Jimmy_Tang.mdwn @@ -0,0 +1 @@ +<http://www.sgenomics.org/~jtang> diff --git a/doc/users/emptty.mdwn b/doc/users/emptty.mdwn new file mode 100644 index 000000000..08ef7d0f3 --- /dev/null +++ b/doc/users/emptty.mdwn @@ -0,0 +1,2 @@ +My professional homepage is [here](http://www.loria.fr/~quinson/). I'm currently (09/09) trying to move it from WML to ikiwiki. +I'm sure I'll have a bunch of ideas, requests and maybe even patches in the process. diff --git a/doc/users/schmonz.mdwn b/doc/users/schmonz.mdwn index 752880561..8273bdbb6 100644 --- a/doc/users/schmonz.mdwn +++ b/doc/users/schmonz.mdwn @@ -1,4 +1,3 @@ [Amitai Schlair](http://www.columbia.edu/~ays2105/) recently discovered ikiwiki and finds himself using it for all sorts of things. His attempts at contributing: -* [[plugins/contrib/unixauth]] -* [[plugins/contrib/cvs]] +[[!map pages="link(users/schmonz) and plugins/* and !*/Discussion"]] |