diff options
Diffstat (limited to 'doc')
70 files changed, 991 insertions, 44 deletions
diff --git a/doc/bugs/SVG_files_not_recognized_as_images.mdwn b/doc/bugs/SVG_files_not_recognized_as_images.mdwn new file mode 100644 index 000000000..207edd426 --- /dev/null +++ b/doc/bugs/SVG_files_not_recognized_as_images.mdwn @@ -0,0 +1,29 @@ +In ikiwiki 2.66, SVG images are not recognized as images. In ikiwiki.pm, +the hardcoded list of image file extensions does not include ".svg", which +it probably should unless there's some other issue about rendering SVGs? + +The 'img' plugin also seems to not support SVGs. + +> SVG images can only be included via an `<object>`, `<embed>`, or +> `<iframe>` tag. Or, perhaps as [inline SVG](http://wiki.svg.org/Inline_SVG). +> The [[plugins/htmlscrubber]] strips all three tags since they can easily +> be used maliciously. If doing inline SVG, I'd worry that the svg file +> could be malformed and mess up the html, or even inject javascript. So, +> the only options seem to be only supporting svgs on wikis that do not +> sanitize their html, or assuming that svgs are trusted content and +> embedding them inline. None of which seem particularly palatable. +> +> I suppose the other option would be converting the svg file to a static +> image (png). The img plugin could probably do that fairly simply. +> --[[Joey]] + +>> I'm working on inline SVG and MathML support in ikiwiki and I've +>> modified my htmlscrubber to sanitize SVG and MathML using the +>> whitelists from html5lib. Here's a [patch][]. I've also made some +>> notes about this here: [[todo/svg]]. +>> +>> I suspect that this bug may have caught the eye of anyone interested +>> in this sort of thing. I'll elaborate a bit on my user page to avoid +>> getting off-topic here. --[[JasonBlevins]], October 21, 2008 + + [patch]: http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blobdiff;f=IkiWiki/Plugin/htmlscrubber.pm;h=3c0ddc8f25bd8cb863634a9d54b40e299e60f7df;hp=3bdaccea119ec0e1b289a0da2f6d90e2219b8d66;hb=fe333c8e5b4a5f374a059596ee698dacd755182d;hpb=be0b4f603f918444b906e42825908ddac78b7073 diff --git a/doc/bugs/cannot_preview_shortcuts.mdwn b/doc/bugs/cannot_preview_shortcuts.mdwn new file mode 100644 index 000000000..d7045b2dc --- /dev/null +++ b/doc/bugs/cannot_preview_shortcuts.mdwn @@ -0,0 +1,17 @@ +Shortcuts such as \[[!google foo]] do not work when previewing pages. +--[[JasonBlevins]] + +> Broken during the setup dumping changes, now fixed. --[[Joey]] [[done]] + +>> Just a quick note that this fix interacts with the way the `listdirectives` +>> directive gets its list of non-shortcut directives. At the moment it +>> still works, but it relies on the fact that the `listdirectives` `checkconfig` +>> hook is called before the `shortcut` `checkconfig` hook. +>> -- [[Will]] + +>> The order plugins are loaded is effectively random. (`keys %hooks`). +>> So I've made shortcuts pass a 'shortcut' parameter when registering +>> them, which listdirectives can grep out of the full list of directives. +>> That may not be the best name to give it, especially if other plugins +>> generate directives too. Seemed better than forcing shortcut's +>> checkconfig hook to run last tho. --[[Joey]] diff --git a/doc/bugs/disabling_backlinks.mdwn b/doc/bugs/disabling_backlinks.mdwn index ba96a4e2b..415708a50 100644 --- a/doc/bugs/disabling_backlinks.mdwn +++ b/doc/bugs/disabling_backlinks.mdwn @@ -28,3 +28,5 @@ auto-generated index is insufficient. > tagged, I think you have larger problems than tags and backlinks being > the same. Like keeping that list of links up to date as tags are added > and changed. --[[Joey]] + +I see your point, Joey. I need to maintain that list manually, though, because the automatically generated list is too brief. \[[!map ...]] generates just a list of titles or descriptions. I need a list that contains both. See [[this_posting|ikiwiki/directive/map/discussion]] for more details. Until \[[!map]] can do that, I'm stuck with a manually maintained list. Which means that every link shows up in the backlinks. diff --git a/doc/bugs/http_proxy_for_openid.mdwn b/doc/bugs/http_proxy_for_openid.mdwn index e8f87f9c4..3d0c99b83 100644 --- a/doc/bugs/http_proxy_for_openid.mdwn +++ b/doc/bugs/http_proxy_for_openid.mdwn @@ -6,10 +6,42 @@ I have found if I add: newenviron[i++]="HTTPS_PROXY=http://host.domain.com:3128"; -to IkiWiki/Wrapper.pm it solves the problem for https requests, however it obviously would be preferred if the proxy name is not configured. +to IkiWiki/Wrapper.pm it solves the problem for https requests, however it obviously would be preferred if the proxy name is not hard coded. Also, the ability to set HTTPS\_CA\_FILE and HTTPS\_CA\_DIR might benefit some people. Then again, it I can't see any evidence that the SSL certificate of the server is being checked. See the [[bug_report|ssl_certificates_not_checked_with_openid]] I filed on this separate issue. Unfortunately, HTTP\_PROXY doesn't work for http requests, it looks like that library is different. +--- + +Update 2008-10-26: + +Better solution, one that works for both http and https, and uses config options. It appears to work... + +Note that using $ua->proxy(['https'], ...); won't work, you get a "Not Implemented" error, see <http://community.activestate.com/forum-topic/lwp-https-requests-proxy>. Also see [[!debbug 129528]]. + +Also note that the proxy won't work with liblwpx-paranoidagent-perl, I had to remove liblwpx-paranoidagent-perl first. + +Please get the patch from the *.mdwn source. + +louie:/usr/share/perl5/IkiWiki/Plugin# diff -u openid.pm.old openid.pm +--- openid.pm.old 2008-10-26 12:18:58.094489360 +1100 ++++ openid.pm 2008-10-26 12:40:05.763429880 +1100 +@@ -165,6 +165,14 @@ + $ua=LWP::UserAgent->new; + } + ++ if (defined($config{"http_proxy"})) { ++ $ua->proxy(['http'], $config{"http_proxy"}); ++ } ++ ++ if (defined($config{"https_proxy"})) { ++ $ENV{HTTPS_PROXY} = $config{"https_proxy"}; ++ } ++ + # Store the secret in the session. + my $secret=$session->param("openid_secret"); + if (! defined $secret) { + + Brian May diff --git a/doc/bugs/rst_tweak.mdwn b/doc/bugs/rst_tweak.mdwn index 8c7d8134d..9d433e24e 100644 --- a/doc/bugs/rst_tweak.mdwn +++ b/doc/bugs/rst_tweak.mdwn @@ -27,3 +27,17 @@ Does the Perl version of this plugin still exist? There appears to be no "rst.p > No, only the python version exists. It does have `raw_enabled` set. > --[[Joey]] + +I am sorry, but I am confused. Does this mean that I can use Ikiwiki +features that translate to HTML in rst files? For example, when I use a +\[[pagename]]-style link in a rst file, the page generated by Ikiwiki's rst +plugin says <a href="./../pagename/">pagename</a> as text. The link +is expanded correctly, but the result isn't interpreted as HTML. Is that +what is supposed to happen? --Peter + +> `raw_enabled` allows you to use the +> [raw directive](http://docutils.sourceforge.net/docs/ref/rst/directives.html), +> but this is not used by ikiwiki for wikilinks or anything else. +> That's why the [[plugin_page|plugins/rst]] has its note about +> issues with wikilinks and directives. You'd have to put those inside +> raw directives yourself to avoid rst escaping their result. --[[Joey]] diff --git a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn index 2dc74a984..04ece0ae8 100644 --- a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn +++ b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn @@ -65,4 +65,21 @@ significantly harder than the network based attacks." With regards to implementation, I am surprised that the libraries don't seem to do this checking, already, and by default. Unfortunately, I am not sure how to test -this adequately, see <http://bugs.debian.org/466055>. -- Brian May +this adequately, see [[!debbug 466055]]. -- Brian May + +--- + +I think [[!cpan Crypt::SSLeay]] already supports checking the certificate. The trick +is to get [[!cpan LWP::UserAgent]], which is used by [[!cpan LWPx::ParanoidAgent]] to +enable this checking. + +I think the trick is to set one of the the following environment variables before retrieving +the data: + +$ENV{HTTPS\_CA\_DIR} = "/etc/ssl/certs/"; +$ENV{HTTPS\_CA\_FILE} = "/etc/ssl/certs/file.pem"; + +Unfortunately I get weird results if the certificate verification fails, see [[!debbug 503440]]. +It still seems to work though, regardless. + +-- Brian May diff --git a/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn b/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn index 5d5e90f7a..472597c46 100644 --- a/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn +++ b/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn @@ -11,6 +11,10 @@ Replacing "·" with "-" in `wikiname` fixed this login issue. > issues too.) Seems like I will have to possibly break some sessions and > entity-encode the wikiname in the cookie.. [[done]]. --[[Joey]] +>> I confirm it fixes the bug for me. --[[intrigeri]] + (BTW, such a char was replaced by -I don't remember what encoding thingie- in my setup file, when running `ikiwiki-transition setupformat`.) > Thanks for the heads up, fixed that too. --[[Joey]] + +>> I confirm it fixes the bug for me. --[[intrigeri]] diff --git a/doc/convert.mdwn b/doc/convert.mdwn new file mode 100644 index 000000000..871cd31fe --- /dev/null +++ b/doc/convert.mdwn @@ -0,0 +1,7 @@ +Do you have an existing wiki or blog using other software, and would like +to convert it to ikiwiki? Various tools and techniques have been developed +to handle such conversions. + +* [[tips/convert_mediawiki_to_ikiwiki]] +* [[tips/convert_MoinMoin_and_TWiki_to_ikiwiki]] +* [[tips/convert_blogger_blogs_to_ikiwiki]] diff --git a/doc/download.mdwn b/doc/download.mdwn index 6566dc122..86ddb46b2 100644 --- a/doc/download.mdwn +++ b/doc/download.mdwn @@ -24,6 +24,8 @@ Or download the deb from <http://packages.debian.org/unstable/web/ikiwiki>. There is a backport of a recent version of ikiwiki for Debian 4.0 at <http://packages.debian.org/etch-backports/ikiwiki>. +Fedora versions 8 and newer have RPMs of ikiwiki available. + There is also an unofficial backport of ikiwiki for Ubuntu Hardy, provided by [[PaweÅ‚_TÄ™cza|users/ptecza]], at [http://gpa.net.icm.edu.pl/ubuntu/](http://gpa.net.icm.edu.pl/ubuntu/index-en.html). diff --git a/doc/forum.mdwn b/doc/forum.mdwn index bab65cac6..729540774 100644 --- a/doc/forum.mdwn +++ b/doc/forum.mdwn @@ -5,4 +5,4 @@ _This is a bold experiment by me, since I have exactly such a question. This ove ## Current topics ## [[!inline pages="forum/* and !forum/discussion and !forum/*/*" -actions=yes rootpage="forum" postformtext="Add a new thread titled:" show=0]] +archive=yes rootpage="forum" postformtext="Add a new thread titled:" show=0]] diff --git a/doc/forum/Adding_new_markup_to_markdown.mdwn b/doc/forum/Adding_new_markup_to_markdown.mdwn new file mode 100644 index 000000000..39d233add --- /dev/null +++ b/doc/forum/Adding_new_markup_to_markdown.mdwn @@ -0,0 +1,11 @@ +I'm using ikiwiki to manage my personal wiki. One of the things I'm toying with is storing my grocery list in a wiki. The way I typically grocery-shop is to make one huge master list containing all the items I typically buy in a single cycle. Then, on any given trip, I make a subset list containing only the items I need. I'd like to streamline this process by making the master list a series of checkboxes. Before each trip, I load the list page on my phone, check off all the items I already have, then check off individual items as I get them. + +I'm not sure if there's a convenient way of adding checkboxes to wiki pages, and after a bit of thought I decided that "( )" would be a good markup for this. Ideally I'd like to still have access to other markdown conventions so I could, say, organize the list with headings and such when it grows large, so I don't want to create an entirely separate format, or a separate copy of the markdown plugin. + +Is there an existing means of, say, adding supersets to wiki markup? I suppose I could use an inline directive that inserts a multisellect HTML element, but I really like ( ). :) + +Ideal would be some sort of filter infrastructure. Plugins could register with a larger filter plugin that adds an inline directive. I could then invoke the checkbox filter at the top of my grocery list, and all instances of ( ) would be replaced with HTML. Might also make sense for the individual filters to specify whether or not they're invoked before or after the page template, or perhaps just always invoke them after. *shrug* + +Does something like this exist? I'd really like to avoid messing around with raw HTML or an inline for each of 40-50 list items. :) + +-- [[Nolan]] diff --git a/doc/forum/discussion.mdwn b/doc/forum/discussion.mdwn new file mode 100644 index 000000000..1e55d3f57 --- /dev/null +++ b/doc/forum/discussion.mdwn @@ -0,0 +1,7 @@ +I like the idea of this forum heirarchy -- but I think a map would be clearer than inlining the sub-pages. -- [[JonDowland]] + +> The easier way to accomplish this is to set archive=yes in the inline. +> Switching to archive view can be useful when there are a lot of long +> posts and people tend to want to scan by title to find interesting ones +> and not necessarily read them all, which probably fits this forum pretty +> well --[[Joey]] diff --git a/doc/forum/wiki_name_in_page_titles.mdwn b/doc/forum/wiki_name_in_page_titles.mdwn new file mode 100644 index 000000000..385e7a3f2 --- /dev/null +++ b/doc/forum/wiki_name_in_page_titles.mdwn @@ -0,0 +1,10 @@ +I'd like to have the wiki name appear in page titles as in "WikiName: +Page Title." If I use `<TMPL_VAR WIKINAME>: <TMPL_VAR TITLE>` in the +template this works for all pages except the index page itself which +will have title "WikiName: WikiName" as its title. Does anyone know +of a template-based solution to this or do I need to write a plugin +that provides a `IS_HOMEPAGE` template variable? --[[JasonBlevins]] + +> Hmm, one way to work around this is to put a meta title directive on the +> index page. Then TITLE will be that, rather than WIKINAME, and your +> template should work. --[[Joey]] diff --git a/doc/git.mdwn b/doc/git.mdwn index e5fef6a5a..e7f47f5a0 100644 --- a/doc/git.mdwn +++ b/doc/git.mdwn @@ -1,5 +1,12 @@ -Ikiwiki is developed in a git repository and can be checked out -like this: +Ikiwiki, and this documentation wiki, are developed in a git repository and +can be checked out like this: + +[[!template id=note text=""" +You can push changes back to ikiwiki's git repository over the `git://` +transport, to update this wiki, if you'd like, instead of editing it on the +web. Changes that could not be made via the web will be automatically +rejected. +"""]] git clone git://git.ikiwiki.info/ @@ -13,7 +20,8 @@ There is also a mirror [on github](http://github.com/joeyh/ikiwiki/tree/master). Commits to this git repository are fed into [CIA](http://cia.vc), and can be browsed, subscribed to etc on its -[project page](http://cia.vc/stats/project/ikiwiki). +[project page](http://cia.vc/stats/project/ikiwiki). They're also fed into +[twitter](http://twitter.com/ikiwiki). ## branches diff --git a/doc/ikiwiki/directive/format.mdwn b/doc/ikiwiki/directive/format.mdwn new file mode 100644 index 000000000..94cf1b04f --- /dev/null +++ b/doc/ikiwiki/directive/format.mdwn @@ -0,0 +1,21 @@ +The `format` directive is supplied by the [[!iki plugins/format desc=format]] +plugin. + +The directive allows formatting a chunk of text using any available page +format. It takes two parameters. First is the type of format to use, +ie the extension that would be used for a standalone file of this type. +Second is the text to format. + +For example, this will embed an otl outline inside a page using mdwn or +some other format: + + \[[!format otl """ + foo + 1 + 2 + bar + 3 + 4 + """]] + +[[!meta robots="noindex, follow"]] diff --git a/doc/ikiwiki/wikilink/discussion.mdwn b/doc/ikiwiki/wikilink/discussion.mdwn index b5cb848ed..0677ff7de 100644 --- a/doc/ikiwiki/wikilink/discussion.mdwn +++ b/doc/ikiwiki/wikilink/discussion.mdwn @@ -51,6 +51,19 @@ simply write [[wikilink]]s like `\[[../bar]]` (or even just `\[[..]]`?), but this doesn't work, so I had to resort to using `\[[foo/bar]]` instead. --[[tschwinge]] +> I believe, that doesn't entirely solve the problem. Just assume, your hierarchy is `/foo/bar/foo/bar`. + +> How do you access from the page `/foo/bar/foo/bar` the `/foo/bar` and not `/foo/bar/foo/bar`? + +> Do we have a way to implement `\[[../..]]` or `\[[/foo/bar]]`? + +> Even worse, trying to link from `/foo/bar` to `/foo/bar/foo/bar` ... this will probably need `\[[./foo/bar]]` --[[Jan|jwalzer]] + +>> There is no ".." syntax in wikilinks, but if the link begins with "/" it +>> is rooted at the top of the wiki, as documented in +>> [[subpage/linkingrules]]. Therefore, every example page name you listed +>> above will work unchanged as a wikilink to that page! --[[Joey]] + ---- How do I make images clickable? The obvious guess, \[[foo.png|/index]], doesn't work. --[[sabr]] @@ -64,3 +77,5 @@ How do I make images clickable? The obvious guess, \[[foo.png|/index]], doesn't Is it possible to refer to a page, say \[[foobar]], such that the link text is taken from foobar's title [[directive/meta]] tag? --Peter > Not yet. :-) Any suggestion for a syntax for it? Maybe something like \[[|foobar]] ? --[[Joey]] + +I like your suggestion because it's short and conscise. However, it would be nice to be able to refer to more or less arbitrary meta tags in links, not just "title". To do that, the link needs two parameters: the page name and the tag name, i.e. \[[pagename!metatag]]. Any sufficiently weird separater can be used instead of '!', of course. I like \[[pagename->metatag]], too, because it reminds me of accessing a data member of a structure (which is what referencing a meta tag is, really). --Peter diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn index ddf27d2c4..2492fd211 100644 --- a/doc/ikiwikiusers.mdwn +++ b/doc/ikiwikiusers.mdwn @@ -39,6 +39,7 @@ Projects * [Chaos Computer Club Düsseldorf](https://www.chaosdorf.de) * [monkeysphere](http://web.monkeysphere.info/) * [The Walden Effect](http://www.waldeneffect.org/) +* The [Fortran Wiki](http://fortranwiki.org/) Personal sites and blogs ======================== @@ -101,7 +102,8 @@ Personal sites and blogs * [Andrey Tarantsov's homepage](http://www.tarantsov.com/) * [Don Marti's blog](http://zgp.org/~dmarti/) * [[JonDowland]]'s [homepage](http://jmtd.net/) -* [[Xavier Maillard]] is using ikiwiki (http://maillard.mobi/~xma/wiki) +* [[xma]] is using ikiwiki (<http://maillard.mobi/~xma/>) +* [[JanWalzer|jwalzer]]'s [homepage](http://wa.lzer.net/) -- Work in Progress Please feel free to add your own ikiwiki site! diff --git a/doc/index/discussion.mdwn b/doc/index/discussion.mdwn index 89e12e6c2..d52cb0a2d 100644 --- a/doc/index/discussion.mdwn +++ b/doc/index/discussion.mdwn @@ -288,6 +288,10 @@ easily, perl is possible (but I'm not strong in perl). >>> It appears the scripts were never posted? I recently imported my Mediawiki site into Iki. If it helps, my notes are here: <http://iki.u32.net/Mediawiki_Conversion> --[[sabr]] +>>>>> The scripts have been posted now, see [[joshtriplett]]'s user page, +>>>>> and I've pulled together all ways I can find to [[convert]] other +>>>>> systems into ikiwiki. --[[Joey]] + ---- # LaTeX support? diff --git a/doc/install/discussion.mdwn b/doc/install/discussion.mdwn index 815b80f14..2b88f6e66 100644 --- a/doc/install/discussion.mdwn +++ b/doc/install/discussion.mdwn @@ -176,3 +176,5 @@ I've tried a couple of times and my cpan has never recognised Bundle::IkiWiki. I > Are you running perl with the environemnt settings specified on the page? > Can you show how it fails to find the bundle? --[[Joey]] + +>> I was not. Next time I build I will have to try that (I'll need to tweak it as I already override PERL5LIB; also I need to specify http proxies). Thanks for your help! -- [[JonDowland]] diff --git a/doc/news/git_push_to_this_wiki.mdwn b/doc/news/git_push_to_this_wiki.mdwn new file mode 100644 index 000000000..4b3fcbe69 --- /dev/null +++ b/doc/news/git_push_to_this_wiki.mdwn @@ -0,0 +1,3 @@ +Now you can use [[git]] to clone this wiki, and push your changes back, +thanks to ikiwiki's new support for [[tips/untrusted_git_push]]. Enjoy +working on the wiki while offline! --[[Joey]] diff --git a/doc/news/git_push_to_this_wiki/discussion.mdwn b/doc/news/git_push_to_this_wiki/discussion.mdwn new file mode 100644 index 000000000..33230c7ef --- /dev/null +++ b/doc/news/git_push_to_this_wiki/discussion.mdwn @@ -0,0 +1,37 @@ +Thanks, Joey! This is awesome...I had to try it out :) +--[[JasonBlevins]] + +I am really happy to hear of this new feature, that I was (more or less) +secretly dreaming of. But - and that's why I'm still insanely editing +this wiki inside a web browser - I wonder how I'll use it for real: my +own master branch contains a few dozens merge commits, and one is created +every time I `git pull` ikiwiki repository (or another clone of it, living +on one of my other boxes that by chance had Internet access more recently). +I do not want to clutter Joey's repository with these commits, so I guess +I have to learn some more of Git everything-is-possible world (a nice thing +is: I am not limited anymore to "Emacs can do it", and I'm now in a position +to say "Git can do it" or "ikiwiki already does it", depending on the +situation). Well, let's focus. Git wizards amongst us (let's use this wiki +as if it were users@ikiwiki.info, ok?), what would you suggest? I was thinking +of having a new branch in my cloned repository, dedicated to editing this wiki; +I could use `rebase` instead of `fetch+merge` to get the new upstream commits +into this special-purpose branch. I guess it would work nicely if I had only +one offline box with not-yet-pushed changes at the same time, but would break +in awful and various ways when it is not the case. Any alternative idea? +--[[intrigeri]] + +> Not that I'm very careful to avoid pushing merge commits (see git log ;-), +> but I sometimes use `git pull --rebase` to pull changes from a repo. That +> will rebase your local changes on top of the changes pulled, avoiding the +> merge commits. I'm sure more involved solutions are possible. --[[Joey]] + +> I decided to use my local `master` branch as a copy of `origin/master` +> (kitenet) and move my local modifications to a separate branch. I'm using +> `master` to edit the wiki but there is still the problem of new upstream +> commits since the last pull. I already had this problem as Joey had pushed +> some changes while I was editing locally. Not knowing about +> `pull --rebase`, I took the long way out: branch, roll back HEAD, rebase, +> and merge. That was too much work...It looks like `pull --rebase` is the +> way to go. --[[JasonBlevins]] + +Awesome ! --[[xma]] diff --git a/doc/plugins/autoindex/discussion.mdwn b/doc/plugins/autoindex/discussion.mdwn new file mode 100644 index 000000000..82e30aab1 --- /dev/null +++ b/doc/plugins/autoindex/discussion.mdwn @@ -0,0 +1,7 @@ +Would it be possible to add an option to only generate the index files +for the html output and not place the markdown files in the wiki source? + +The reason being that I have a lot of directories which need to be autoindexed, +but I would prefer if the index files didn't clutter up my git repository. + +even without that feature the plugin is a great help, thanks diff --git a/doc/plugins/calendar/discussion.mdwn b/doc/plugins/calendar/discussion.mdwn index 65c2459c6..148b83522 100644 --- a/doc/plugins/calendar/discussion.mdwn +++ b/doc/plugins/calendar/discussion.mdwn @@ -1,2 +1,4 @@ It would be nice if the "month" type calendar could collect all of the matching pages on a given date in some inline type way. --[[DavidBremner]] + +Is it possible to get the calendar to link to pages based not on their timestamp (as I understand that it does now, or have I misunderstood this?) and instead on for example their location in a directory hierarchy. That way the calendar could be used as a planning / timeline device which I think would be great. --[[Alexander]] 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 b4a7cd5d6..3efc68418 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 @@ -27,7 +27,7 @@ Somewhat more detailed usage documentation would be appreciated. I tried to setu those plugins with a current ikiwiki release, i.e. 2.61, but they appeared to do nothing, really. Also, those example pages don't seem to use those plugins, even; they set "copyright" and "license" properties using ordinary [[meta]] tags. Maybe -I'm missing something terribly obvious? --[[Peter]] +I'm missing something terribly obvious? --Peter > Only obvious if you read the source :-). You need to put a file named "copyright.html" >(respectively "license.html") in your wiki. Everything underneath that (in the wikilink sense) will use that >content for the license or copyright. Saves putting \[[meta license="foo"]] in every page [[DavidBremner]] diff --git a/doc/plugins/contrib/highlightcode.mdwn b/doc/plugins/contrib/highlightcode.mdwn index 9b43a106c..8abb76583 100644 --- a/doc/plugins/contrib/highlightcode.mdwn +++ b/doc/plugins/contrib/highlightcode.mdwn @@ -1,3 +1,6 @@ +[[!template id=plugin name=highlightcode author="[[sabr]]"]] +[[!tag type/format]] + A small plugin to allow Ikiwiki to display source files complete with syntax highlighting. Files with recognized extensions (i.e. my-file.cpp) are be rendered just like any other Ikiwiki page. You can even edit your source files with Ikiwiki's editor. It uses the Syntax::Highlight::Engine::Kate Perl module to do the highlighting. diff --git a/doc/plugins/contrib/linguas.mdwn b/doc/plugins/contrib/linguas.mdwn index 0c3366846..bf502606e 100644 --- a/doc/plugins/contrib/linguas.mdwn +++ b/doc/plugins/contrib/linguas.mdwn @@ -10,7 +10,8 @@ Download: [linguas.pm](http://ettin.org/pub/ikiwiki/linguas.pm) (2006-08-21). Note that even though it is still available for download, this plugin is no longer actively maintained. If you are interested in multilingual wiki pages, you -can also take a look at other approaches such as [[todo/l10n]] or Lars Wirzenius's +can also take a look at other approaches such as [[todo/l10n]], [[plugins/contrib/po]], +or Lars Wirzenius's [Static website, with translations, using IkiWiki](http://liw.iki.fi/liw/log/2007-05.html#20070528b). Usage diff --git a/doc/plugins/contrib/mediawiki.mdwn b/doc/plugins/contrib/mediawiki.mdwn new file mode 100644 index 000000000..c0a23254f --- /dev/null +++ b/doc/plugins/contrib/mediawiki.mdwn @@ -0,0 +1,5 @@ +[[!template id=plugin name=mediawiki author="[[sabr]]"]] +[[!tag type/format]] + +[The Mediawiki plugin](http://u32.net/Mediawiki_Plugin/) allows ikiwiki to +process pages written using MediaWiki markup. diff --git a/doc/plugins/contrib/opml.mdwn b/doc/plugins/contrib/opml.mdwn new file mode 100644 index 000000000..3f98e8065 --- /dev/null +++ b/doc/plugins/contrib/opml.mdwn @@ -0,0 +1,11 @@ +[[!template id=plugin name=opml author="[[JanWalzer|jwalzer]]"]] +[[!tag type/format]] + +The idea of this plugin is to parse in an OPML-File and output a linklist, maybe some customization. +OPML-Files are xml-files that most RSS-Readers write out, to summarize their subscribes feedlist. + +I have a "dumb" perlscript running on my website, that tries to do a opml2mdwn transformation, but its quite bad on that. + +This Plugin is **NOT Ready** in any way. I'm just putting this page up as a hook, to discuss it. + +I intend to work on this, but I'd appreciate any help on this. diff --git a/doc/plugins/contrib/opml/discussion.mdwn b/doc/plugins/contrib/opml/discussion.mdwn new file mode 100644 index 000000000..3a145c79a --- /dev/null +++ b/doc/plugins/contrib/opml/discussion.mdwn @@ -0,0 +1,4 @@ +If this is the wrong place for the development of the plugin, please mode it on to a more appropriate one. + +Currently I'm quite stuck with the perl-stuff itself. I'm trying to become comfortable with the language, but it seems, the language doesn't like me. I'm lost in complex datastructures, when trying to iterate through the output of XML::Simple. --[[Jan|jwalzer]] + diff --git a/doc/plugins/contrib/po.mdwn b/doc/plugins/contrib/po.mdwn new file mode 100644 index 000000000..f60b8fbea --- /dev/null +++ b/doc/plugins/contrib/po.mdwn @@ -0,0 +1,63 @@ +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/). + +More information: + +* It can be found in [my "po" branch](http://repo.or.cz/w/ikiwiki/intrigeri.git?a=shortlog;h=refs/heads/po): `git clone git://repo.or.cz/ikiwiki/intrigeri.git` +* It involves adding three hooks to ikiwiki core. +* It is documented (including TODO and plans for next work steps) in `doc/plugins/po.mdwn`, which can be found in the same branch. +* No public demo site is available so far, I'm working on this. + +My plan is to get this plugin clean enough to be included in ikiwiki. + +The current version is a proof-of-concept, mature enough for me to dare submitting it here, +but I'm prepared to hear various helpful remarks, and to rewrite parts of it as needed. + +Any thoughts on this? + +> Well, I think it's pretty stunning what you've done here. Seems very +> complete and well thought out. I have not read the code in great detail +> yet. +> +> Just using po files is an approach I've never seen tried with a wiki. I +> suspect it will work better for some wikis than others. For wikis that +> just want translations that match the master language as closely as +> possible and don't wander off and diverge, it seems perfect. (But what happens +> if someone edits the Discussion page of a translated page?) +> +> Please keep me posted, when you get closer to having all issues solved +> and ready for merging I can do a review and hopefully help with the +> security items you listed. --[[Joey]] + +>> Thanks a lot for your quick review, it's reassuring to hear such nice words +>> from you. I did not want to design and write a full translation system, when +>> tools such as gettext/po4a already have all the needed functionality, for cases +>> where the master/slave languages paradigm fits. +>> Integrating these tools into ikiwiki plugin system was a pleasure. +>> +>> I'll tell you when I'm ready for merging, but in the meantime, +>> I'd like you to review the changes I did to the core (3 added hooks). +>> Can you please do this? If not, I'll go on and hope I'm not going to far in +>> the wrong direction. +>> +>>> Sure.. I'm not completly happy with any of the hooks since they're very +>>> special purpose, and also since `run_hooks` is not the best interface +>>> for a hook that modifies a variable, where only the last hook run will +>>> actually do anything. It might be better to just wrap +>>> `targetpage`, `bestlink`, and `beautify_urlpath`. But, I noticed +>>> the other day that such wrappers around exported functions are only visible by +>>> plugins loaded after the plugin that defines them. +>>> +>>> Update: Take a look at the new "Function overriding" section of +>>> [[plugins/write]]. I think you can just inject wrappers about a few ikiwiki +>>> functions, rather than adding hooks. The `inject` function is pretty +>>> insane^Wlow level, but seems to work great. --[[Joey]] +>> +>>>> Thanks a lot, it seems to be a nice interface for what I was trying to achieve. +>>>> I may be forced to wait two long weeks before I have a chance to confirm +>>>> this. Stay tuned. --[[intrigeri]] +>> +>> The Discussion pages issue is something I am not sure about yet. But I will +>> probably decide that "slave" pages, being only translations, don't deserve +>> a discussion page: the discussion should happen in the language in which the +>> pages are written for real, which is the "master" one. --[[intrigeri]] diff --git a/doc/plugins/contrib/sourcehighlight.mdwn b/doc/plugins/contrib/sourcehighlight.mdwn index 2eb22e6ed..fb368945b 100644 --- a/doc/plugins/contrib/sourcehighlight.mdwn +++ b/doc/plugins/contrib/sourcehighlight.mdwn @@ -20,3 +20,8 @@ This problem with sourcehighlight needs to be fixed before it is very useful. - Is there a way to configure the colors used by source-highlight (other than editing the globally installed "default.style" file)? It would help if I could pass the command arbitrary command-line arguments; then I could configure which config file it's supposed to use. For instance, I'm not a fan of hard-coding the colors into the HTML output. IMHO, css-style formatting should be preferred. All that can be set via the command line ... --Peter > I don't really have time right now, but it should be easy to add, if you look at how src-lang is handled. Patches are welcome :-) --[[DavidBremner]] + +Note that [[Will]] wrote a plugin that uses source-highlight also. It's +available +[here|todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion]]. +--[[Joey]] diff --git a/doc/plugins/format.mdwn b/doc/plugins/format.mdwn new file mode 100644 index 000000000..91e707fcf --- /dev/null +++ b/doc/plugins/format.mdwn @@ -0,0 +1,9 @@ +[[!template id=plugin name=format core=0 author="[[Joey]]"]] +[[!tag type/format]] + +This plugin allows mixing different page formats together, by embedding +text formatted one way inside a page formatted another way. This is done +using the [[ikiwiki/directive/format]] [[ikiwiki/directive]]. + +For example, it could be used to embed an [[otl]] outline inside a page +that is formatted as [[mdwn]]. diff --git a/doc/plugins/pingee.mdwn b/doc/plugins/pingee.mdwn index d012004f9..6156c235f 100644 --- a/doc/plugins/pingee.mdwn +++ b/doc/plugins/pingee.mdwn @@ -3,7 +3,7 @@ This plugin causes ikiwiki to listen for pings, typically delivered from another ikiwiki instance using the [[pinger]] plugin. When a ping is -recieved, ikiwiki will update the wiki, the same as if `ikiwiki --refresh` +received, ikiwiki will update the wiki, the same as if `ikiwiki --refresh` were ran at the command line. An url such as the following is used to trigger a ping: diff --git a/doc/plugins/relativedate.mdwn b/doc/plugins/relativedate.mdwn index 121bce477..32f8c798b 100644 --- a/doc/plugins/relativedate.mdwn +++ b/doc/plugins/relativedate.mdwn @@ -10,7 +10,7 @@ show the absolute date instead. Also, this plugin can be used with other plugins like [[prettydate]] that change how the absolute date is displayed. If this plugin is enabled, you may also add relative dates to pages in the -wiki, by using html elements in the "date" class. For example, this will -display as a relative date: +wiki, by using html elements in the "relativedate" class. For example, this +will display as a relative date: - <span class="date">Fri Oct 17 18:36:13 EDT 2008</span> + <span class="relativedate">Fri Oct 17 18:36:13 EDT 2008</span> diff --git a/doc/plugins/rst.mdwn b/doc/plugins/rst.mdwn index 9355597ac..5e97e2d80 100644 --- a/doc/plugins/rst.mdwn +++ b/doc/plugins/rst.mdwn @@ -11,7 +11,7 @@ ikiwiki. Limitations include: * There are issues with inserting raw html into documents, as ikiwiki does with [[WikiLinks|ikiwiki/WikiLink]] and many - preprocessor [[directives|ikiwiki/directive]]. + [[directives|ikiwiki/directive]]. So while you may find this useful for importing old files into your wiki, using this as your main markup language in ikiwiki isn't recommended at diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn index 857d176d5..f147b0766 100644 --- a/doc/plugins/write.mdwn +++ b/doc/plugins/write.mdwn @@ -360,13 +360,6 @@ This hook is called whenever ikiwiki normally saves its state, just before the state is saved. The function can save other state, modify values before they're saved, etc. -### displaytime - - hook(type => "displaytime", id => "foo", call => \&display); - -This hook can be registered to override the regular `displaytime` function. -Only the last displaytime hook will be used. - ### renamepage hook(type => "renamepage", id => "foo", call => \&renamepage); @@ -857,6 +850,30 @@ it up in the history. It's ok if this is not implemented, and throws an error. +#### `rcs_receive()` + +This is called when ikiwiki is running as a pre-receive hook (or +equivalent), and is testing if changes pushed into the RCS from an +untrusted user should be accepted. This is optional, and doesn't make +sense to implement for all RCSs. + +It should examine the incoming changes, and do any sanity +checks that are appropriate for the RCS to limit changes to safe file adds, +removes, and changes. If something bad is found, it should exit +nonzero, to abort the push. Otherwise, it should return a list of +files that were changed, in the form: + + { + file => # name of file that was changed + action => # either "add", "change", or "remove" + path => # temp file containing the new file content, only + # needed for "add"/"change", and only if the file + # is an attachment, not a page + } + +The list will then be checked to make sure that each change is one that +is allowed to be made via the web interface. + ### PageSpec plugins It's also possible to write plugins that add new functions to @@ -884,6 +901,56 @@ By the way, to parse a ikiwiki setup file and populate `%config`, a program just needs to do something like: `use IkiWiki::Setup; IkiWiki::Setup::load($filename)` +### Function overriding + +Sometimes using ikiwiki's pre-defined hooks is not enough. Your plugin +may need to replace one of ikiwiki's own functions with a modified version, +or wrap one of the functions. + +For example, your plugin might want to override `displaytime`, to change +the html markup used when displaying a date. Or it might want to override +`IkiWiki::formattime`, to change how a date is formatted. Or perhaps you +want to override `bestlink` and change how ikiwiki deals with WikiLinks. + +By venturing into this territory, your plugin is becoming tightly tied to +ikiwiki's internals. And it might break if those internals change. But +don't let that stop you, if you're brave. + +Ikiwiki provides an `inject()` function, that is a powerful way to replace +any function with one of your own. This even allows you to inject a +replacement for an exported function, like `bestlink`. Everything that +imports that function will get your version instead. Pass it the name of +the function to replace, and a new function to call. + +For example, here's how to replace `displaytime` with a version using HTML 5 +markup: + + inject(name => 'IkiWiki::displaytime', call => sub { + return "<time>".formattime(@_)."</time>"; + }); + +Here's how to wrap `bestlink` with a version that tries to handle +plural words: + + my $origbestlink=\&bestlink; + inject(name => 'IkiWiki::bestlink', call => \&mybestlink); + + sub deplural ($) { + my $word=shift; + $word =~ s/e?s$//; # just an example :-) + return $word; + } + + sub mybestlink ($$) { + my $page=shift; + my $link=shift; + my $ret=$origbestlink->($page, $link); + if (! length $ret) { + $ret=$origbestlink->($page, deplural($link)); + } + return $ret; + } + ### Javascript Some plugins use javascript to make ikiwiki look a bit more web-2.0-ish. diff --git a/doc/plugins/write/discussion.mdwn b/doc/plugins/write/discussion.mdwn index 039775b79..9a36d7b0b 100644 --- a/doc/plugins/write/discussion.mdwn +++ b/doc/plugins/write/discussion.mdwn @@ -40,3 +40,7 @@ distributed wiki. > > OTOH, if something can be added to the documentation that encourages > good behavior, that'd be a good thing ... --[[Joey]] + +--- + +I would find this page clearer split up into sub-pages. Does anyone agree/disagree? -- [[JonDowland]] diff --git a/doc/plugins/write/external.mdwn b/doc/plugins/write/external.mdwn index 272f74a7c..e30bf2ff3 100644 --- a/doc/plugins/write/external.mdwn +++ b/doc/plugins/write/external.mdwn @@ -96,14 +96,13 @@ the sentinal. ## Function injection -Some parts of ikiwiki are extensible by adding functions. For example, the -RCS interface relies on plugins providing several IkiWiki::rcs_* functions. +Some parts of ikiwiki are extensible by adding or overriding functions. It's actually possible to do this from an external plugin too. -To make your external plugin provide an `IkiWiki::rcs_update` function, for +To make your external plugin override the `IkiWiki::formattime` function, for example, make an RPC call to `inject`. Pass it named parameters "name" and "call", where "name" is the name of the function to inject into perl (here -"Ikiwiki::rcs_update" and "call" is the RPC call ikiwiki will make whenever +"Ikiwiki::formattime" and "call" is the RPC call ikiwiki will make whenever that function is run. If the RPC call is memoizable, you can also pass a "memoize" parameter, set diff --git a/doc/rcs/details.mdwn b/doc/rcs/details.mdwn index e62f3ef49..089221cab 100644 --- a/doc/rcs/details.mdwn +++ b/doc/rcs/details.mdwn @@ -280,6 +280,9 @@ Here is a how a commit from a remote repository works: * git-commit in the remote repository * git-push, pushes the commit to the master repo on the server +* (Optionally, the master repo's pre-receive hook runs, and checks that the + update only modifies files that the pushing user is allowed to update. + If not, it aborts the receive.) * the master repo's post-update hook notices this update, and runs ikiwiki * ikiwiki notices the modifies page source, and compiles it diff --git a/doc/rcs/git.mdwn b/doc/rcs/git.mdwn index b210af825..6ba0da894 100644 --- a/doc/rcs/git.mdwn +++ b/doc/rcs/git.mdwn @@ -100,6 +100,33 @@ repository, should only be writable by the wiki's admin, and *not* by the group. Take care that ikiwiki uses a umask that does not cause files in the srcdir to become group writable. (umask 022 will work.) +## git repository with untrusted committers + +By default, anyone who can commit to the git repository can modify any file +on the wiki however they like. A `pre-receive` hook can be set up to limit +incoming commits from untrusted users. Then the same limits that are placed +on edits via the web will be in effect for commits to git for the users. +They will not be allowed to edit locked pages, they will only be able to +delete pages that the [[plugins/remove]] configuration allows them to +remove, and they will only be allowed to add non-page attachments that the +[[plugins/attachment]] configuration allows. + +To enable this, you need to set up the git repository to have multiple +committers. Trusted committers, including the user that ikiwiki runs as, +will not have their commits checked by the `pre-receive` hook. Untrusted +committers will have their commits checked. The configuration settings to +enable are `git_test_receive_wrapper`, which enables generation of a +`pre-receive` hook, and `untrusted_committers`, which is a list of +usernames of the untrusted committers. + +Note that when the `pre-receive` hook is checking incoming changes, it +ignores the git authorship information, and uses the username of the unix +user who made the commit. Then tests including the `locked_pages` [[PageSpec]] +are checked to see if that user can edit the pages in the commit. + +You can even set up an anonymous user, to allow anyone to push +changes in via git rather than using the web interface. + ## Optionally using a local wiki to preview changes When working on the "working clones" to add content to your wiki, diff --git a/doc/rcs/monotone.mdwn b/doc/rcs/monotone.mdwn index babd5cf01..2cfcdfbf5 100644 --- a/doc/rcs/monotone.mdwn +++ b/doc/rcs/monotone.mdwn @@ -17,3 +17,8 @@ There is also a mismatch between the way Ikiwiki handles conflicts and the way Monotone handles conflicts. At present, if there is a conflict, then Ikiwiki will commit a revision with conflict markers before presenting it to the user. This is ugly, but there is no clean way to fix it at present. + +Also note that not all recent ikiwiki features have been implemented in the +monotone plugin. At the moment we're missing: + + * [[todo/Untrusted_push_in_Monotone]] diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn index 9e709172a..986b59eac 100644 --- a/doc/sandbox.mdwn +++ b/doc/sandbox.mdwn @@ -1,5 +1,7 @@ This is the SandBox, a page anyone can edit to try out ikiwiki. +testing 1..2..3!! + ---- Here's a paragraph. สวัสดี diff --git a/doc/tips/convert_MoinMoin_and_TWiki_to_ikiwiki.mdwn b/doc/tips/convert_MoinMoin_and_TWiki_to_ikiwiki.mdwn new file mode 100644 index 000000000..5565dbd8a --- /dev/null +++ b/doc/tips/convert_MoinMoin_and_TWiki_to_ikiwiki.mdwn @@ -0,0 +1,3 @@ +[[JoshTriplett]] has developed scripts to convert MoinMoin and TWiki wikis +to ikiwikis backed by a git repository, including full history. For +details, see [[his_user_page|JoshTriplett]]. diff --git a/doc/tips/convert_mediawiki_to_ikiwiki.mdwn b/doc/tips/convert_mediawiki_to_ikiwiki.mdwn new file mode 100644 index 000000000..f03703b46 --- /dev/null +++ b/doc/tips/convert_mediawiki_to_ikiwiki.mdwn @@ -0,0 +1,4 @@ +[[sabr]] explains how to [import MediaWiki content into +git](http://u32.net/Mediawiki_Conversion/index.html?updated), including +full edit hostory. The [[plugins/contrib/mediawiki]] plugin can then be +used by ikiwiki to build the wiki. diff --git a/doc/tips/untrusted_git_push.mdwn b/doc/tips/untrusted_git_push.mdwn new file mode 100644 index 000000000..aef67a3db --- /dev/null +++ b/doc/tips/untrusted_git_push.mdwn @@ -0,0 +1,122 @@ +This tip will describe how to allow anyone on the planet to `git push` +changes into your wiki, without needing a special account. All a user needs +to know is: + + git clone git://your.wiki/path + # now modify any of the files the wiki would let you modify on the web + git push + +This is a wonderful thing to set up for users, because then they can work +on the wiki while offline, and they don't need to mess around with web +browsers. + +## security + +But, you might be wondering, how can this possibly be secure. Won't users +upload all sorts of garbage, change pages you don't want them to edit, and so +on. + +The key to making it secure is configuring ikiwiki to run as your git +repository's `pre-receive` hook. There it will examine every change that +untrusted users push into the wiki, and reject pushes that contain changes +that cannot be made using the web interface. + +So, unless you have the [[plugins/attachment]] plugin turned on, +non-page files cannot be added. And if it's turned on, whatever +`allowed_attachments` checks you have configured will also check files +pushed into git. + +And, unless you have the [[plugins/remove]] plugin turned on, no +files can be deleted. + +And if you have `locked_pages` configured, then it will also affect what's +pushed into git. + +Untrusted committers will also not be able to upload files with strange +modes, or push to any branch except for the configured `gitorigin_branch`, +or manipulate tags. + +One thing to keep an eye on is uploading large files. It may be easier to +do this via git push than using the web, and that could be abused. + +Also, no checking is done that the authors of commits are right, so people +can make a commit that pretends to be done by someone else. + +## user setup + +Add a dedicated user who will push in untrusted commits. This user should have +a locked password, and `git-shell` as its shell. + + root@bluebird:/home/joey>adduser --shell=/usr/bin/git-shell --disabled-password anon + Adding user `anon' ... + +## ikiwiki setup + +You should set up ikiwiki before turning on anonymous push in git. + +Edit your wiki's setup file, and uncomment the lines for +`git_test_receive_wrapper` and `untrusted_committers`. + + # git pre-receive hook to generate + git_test_receive_wrapper => '/srv/git/ikiwiki.info/.git/hooks/pre-receive', + # unix users whose commits should be checked by the pre-receive hook + untrusted_committers => ['anon'], + +The `git_test_receive_wrapper` will become the git `pre-receive` hook. The +`untrusted_committers` list is the list of unix users who will be pushing in +untrusted changes. It should *not* include the user that ikiwiki normally runs +as. + +Once you're done modifying the setup file, don't forget to run +`ikiwiki -setup --refresh --wrappers` on it. + +## git setup + +You'll need to arrange the permissions on your bare git repository so that +user anon can write to it. One way to do it is to create a group, and put +both anon and your regular user in that group. Then make make the bare git +repository owned and writable by the group. See [[rcs/git]] for some more +tips on setting up a git repository with multiple committers. + +Note that anon should *not* be able to write to the `srcdir`, *only* to the bare git +repository for your wiki. + +If you want to allow git over `ssh`, generate a ssh key for anon, and +publish the *private* key for other people to use. This is optional; you +can use `git-daemon` instead and not worry about keys. + +Now set up `git-daemon`. It will need to run as user `anon`, and be +configured to export your wiki's bare git repository. I set it up as +follows in `/etc/inetd.conf`, and ran `/etc/init.d/openbsd-inetd restart`. + + git stream tcp nowait anon /usr/bin/git-daemon git-daemon --inetd --export-all --interpolated-path=/srv/git/%H%D /srv/git + +At this point you should be able to `git clone git://your.wiki/path` from +anywhere, and check out the source to your wiki. But you won't be able to +push to it yet, one more change is needed to turn that on. Edit the +`config` file of your bare git repository, and allow `git-daemon` to +receive pushes: + + [daemon] + receivepack = true + +Now pushes should be accepted, and your wiki immediatly be updated. If it +doesn't, check your git repo's permissions, and make sure that the +`post-update` and `pre-receive` hooks are suid so they run as the user who +owns the `srcdir`. + +## infelicities + +If a user tries to push a changeset that ikiwiki doesn't like, it will +abort the push before refs are updated. However, the changeset will still +be present in your repository, wasting space. Since nothing refers to it, +it will be expired eventually. You can speed up the expiry by running `git +prune`. + +When aborting a push, ikiwiki displays an error message about why it didn't +accept it. If using git over ssh, the user will see this error message, +which is probably useful to them. But `git-daemon` is buggy, and hides this +message from the user. This can make it hard for users to figure out why +their push was rejected. (If this happens to you, look at "'git log --stat +origin/master..`" and think about whether your changes would be accepted +over the web interface.) diff --git a/doc/tips/vim_syntax_highlighting/ikiwiki.vim b/doc/tips/vim_syntax_highlighting/ikiwiki.vim index fd87f49a2..bbcad4239 100644 --- a/doc/tips/vim_syntax_highlighting/ikiwiki.vim +++ b/doc/tips/vim_syntax_highlighting/ikiwiki.vim @@ -1,6 +1,6 @@ " Vim syntax file " Language: Ikiwiki (links) -" Maintainer: Recai Oktaþ (roktasATdebian.org) +" Maintainer: Recai OktaÅŸ (roktasATdebian.org) " Last Change: 2007 May 29 " Instructions: diff --git a/doc/todo/Feature_parity_with_Trac.mdwn b/doc/todo/Feature_parity_with_Trac.mdwn index 8693da5e3..b2d9d43ed 100644 --- a/doc/todo/Feature_parity_with_Trac.mdwn +++ b/doc/todo/Feature_parity_with_Trac.mdwn @@ -5,11 +5,12 @@ Features needed: * Wiki, duh. * Source code viewing: This can be handled quite well with a [[shortcut|shortcuts]] to an external source viewer, or by putting - the source in the wiki itself (see the [[todo/automatic_use_of_syntax_plugin_on_source_code_files]] wishlist item) and using the - [[plugins/contrib/highlightcode]] or [[plugins/contrib/sourcehighlight]] plugins. + the source in the wiki itself (see the [[todo/automatic_use_of_syntax_plugin_on_source_code_files]] wishlist item and [[todo/syntax_highlighting]] todo item). * This could be improved with [[todo/source_link]]. * Currently the source highlighting is a little problematic, as there can be two source files with the same wikiname. e.g. a `hello-world.c` and `hello-world.h`. See [[bugs/multiple_pages_with_same_name]] + > That bug was fixed before you linked to the page. :-) + >> I was the one that fixed it... :) -- [[Will]] * Trac 'Timeline' feature: view history of the RCS - the `recentchanges` button. * Trac 'Roadmap' feature: Which TODOs/bugs are needed for which milestones. Use the [[plugins/progress]] directive to show percentage complete for each milestone. * Bug tracking: see [[tips/integrated_issue_tracking_with_ikiwiki]] and [[todo/Updated_bug_tracking_example]]. diff --git a/doc/todo/Option_to_make_title_an_h1__63__.mdwn b/doc/todo/Option_to_make_title_an_h1__63__.mdwn index efa07ad79..8676bec48 100644 --- a/doc/todo/Option_to_make_title_an_h1__63__.mdwn +++ b/doc/todo/Option_to_make_title_an_h1__63__.mdwn @@ -6,3 +6,9 @@ Currently, the page title (either the name of the page or the title specified wi > way, # is reserved for h1 if you choose to use headers in your page. --[[Joey]] [[done]] + +> For anyone interested, I've written a small plugin called [h1title][] that does the +> latter, making `#` (only when on the first line) set the page title, removing it from +> the page body. --[[JasonBlevins]], October 22, 2008 + + [h1title]: http://code.jblevins.org/ikiwiki/plugins/h1title.pm diff --git a/doc/todo/Untrusted_push_in_Monotone.mdwn b/doc/todo/Untrusted_push_in_Monotone.mdwn new file mode 100644 index 000000000..a8b1cd7c4 --- /dev/null +++ b/doc/todo/Untrusted_push_in_Monotone.mdwn @@ -0,0 +1,28 @@ +As noted in [[tips/untrusted_git_push]] an untrusted push capability was added recently, but only implemented in git. +(See also [[todo/rcs_updates_needed]]) + +This note describes (but does not implement) an approach for this with the [[rcs/monotone]] rcs backend. + +---- + +Monotone behaves a little differently to git in its networking. Git allows anyone to try to push, and then +check whether it is ok before finally accepting it. Monotone has no way to accept or reject revisions +in this way. However, monotone does have the ability to mark revisions, and to ignore unmarked revisions. + +This marking capability can be used to achieve a somewhat similar effect to what happens with git. The +problem with this is that anyone could put anything into the monotone database, and while this wouldn't +affect ikiwiki, it seems bad to leave open, untrusted storage on the web. + +The Plan +===== + +In the `note_netsync_revision_received` hook in the monotone server, have the server check to make sure +that either a) the revision is signed by someone trusted or, b) the revision is checked using the same +hook that git uses in `pre-receive`. If the revision passes the ikiwiki `pre-receive` check then the +monotone hook signs the revision. This gives that revision the 'ikiwiki seal of approval'. + +You'll also want to update the monotone trust hooks to only trust revisions signed by trusted people, or +ikiwiki. + +Now anyone can upload a revision, but only those signed by a trusted person, or which pass the ikiwiki +check and so get signed by the ikiwiki key, will be seen by ikiwiki. diff --git a/doc/todo/applydiff_plugin.mdwn b/doc/todo/applydiff_plugin.mdwn index d3eb9793b..d26b0dfe9 100644 --- a/doc/todo/applydiff_plugin.mdwn +++ b/doc/todo/applydiff_plugin.mdwn @@ -1,4 +1,4 @@ -[[!tag wishlist]] +[[!tag wishlist done]] [[!toc ]] @@ -54,3 +54,57 @@ modify only *one* page may be easier. Implementation ============== + +Also see [[joey]]'s idea on [[users/xma/discussion]], to allow (filtered) anonymous push to this wiki's repository. + +> Ideally the filtering should apply the same constraints on what's pushed +> as are applied to web edits. So locked pages can't be changed, etc. +> +> That could be accomplished by making the git pre-receive hook be a +> ikiwiki wrapper. A new `git_receive_wrapper` config setting could cause +> the wrapper to be generated, with `$config{receive}` set to true. +> +> When run that way, ikiwiki would call `rcs_receive`. In the case of git, +> that would look at the received changes as fed into the hook on stdin, +> and use `parse_diff_tree` to get a list of the files changed. Then it +> could determine if the changes were allowed. +> +> To do that, it should first look at what unix user received the +> commit. That could be mapped directly to an ikiwiki user. This would +> typically be an unprivelidged user (that was set up just to allow +> anonymous pushes), but you might also want to set up +> separate users who have fewer limits on what they can push. And, of +> course, pushes from the main user, who owns the wiki, would not be +> checked at all. So, let's say `$config{usermap}` is a hash, something +> like `{usera => "wikiusera", userb => "wikiuserb"}`, and pushes from +> users not in the hash are not checked. +> +> Then it seems like it would want to call `check_canedit` to test if an +> edit to each changed page is allowed. Might also want to call +> `check_canattach` and `check_canremove` if the attach and remove plugins +> are enabled. All three expect to be passed a CGI and a CGI::Session +> object, which is a bit problimatic here. So dummy the objects up? (To call +> `check_canattach` the changed attachment would need to be extracted to a +> temp file for it to check..) +> +> If a change is disallowed, it would print out what was disallowed, and +> exit nonzero. I think that git then discards the pushed objects (or maybe +> they remain in the database until `git-gc` .. if so, that could be used +> to DOS by uploading junk, so need to check this point). +> +> Also, I've not verified that the objects have been recieved already when +> whe pre-receive hook is called. Although the docs seem to say that is the +> case. --[[Joey]] + +>> Update: The git pre-receive hook stuff is written, and seems to work. +>> I think it makes more sense than using diffs, and so think this todo +>> could probably be closed. +>> --[[Joey]] + +>>> I agree, closing this. I really prefer this solution to the one I was +>>> initially proposing. +>>> Is this pre-receive hook already enabled on ikiwiki.info? +>>> If not, do you plan to enable it at some point? +>>> --[[intrigeri]] + +>>>> [[news/git_push_to_this_wiki]] gave me the answer. Well done! --[[intrigeri]] diff --git a/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion.mdwn b/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion.mdwn index 2fad9f19a..467ec350e 100644 --- a/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion.mdwn +++ b/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion.mdwn @@ -1,6 +1,6 @@ Here is another [[patch]] for this. It is more up to date than either of the patches linked on the previous page. It is most similar to [[plugins/contrib/sourcehighlight]]. -Note that if this is being used with `c` or `c++` then you'll probably want to wait until [[bugs/multiple_pages_with_same_name]] is fixed. +Updated to use fix noted in [[bugs/multiple_pages_with_same_name]]. -- [[Will]] @@ -92,7 +92,7 @@ Note that if this is being used with `c` or `c++` then you'll probably want to w foreach my $lang (split(/[, ]+/, $config{sourcecode_lang})) { if ($langs{$lang}) { - hook(type => "htmlize", id => $lang, call => \&htmlize); + hook(type => "htmlize", id => $lang, call => \&htmlize, keepextension => 1); } else { error("Your installation of source-highlight cannot handle sourcecode language $lang!"); } diff --git a/doc/todo/clear_page_to_delete.mdwn b/doc/todo/clear_page_to_delete.mdwn index ccb7634e5..50ae246bb 100644 --- a/doc/todo/clear_page_to_delete.mdwn +++ b/doc/todo/clear_page_to_delete.mdwn @@ -24,3 +24,10 @@ the page. That's what the user intended to do in this case. The information content of an empty vs. a deleted page is essentially the same, I'd say. But having ikiwiki remove those stale pages would save some (minimal, admittedly) time needed for manual clean-up. --[[tschwinge]] + +On EmacsWiki, a page is marked for deletion when it contains just the DeletedPage +keyword and if there were no page editions since XX days. Here, I use pages that +can be empty everyday and filled all day long. It does not make sense to me to +delete these pages :). --[[xma]] + +I was not aware of [[plugins/remove]]. I don't think another method is necessary -- [[JonDowland]] diff --git a/doc/todo/dynamic_rootpage.mdwn b/doc/todo/dynamic_rootpage.mdwn index fa0e23254..5cf80b0a8 100644 --- a/doc/todo/dynamic_rootpage.mdwn +++ b/doc/todo/dynamic_rootpage.mdwn @@ -23,3 +23,10 @@ What's your opinion, Joey? I hope it's also useful for another ikiwiki lovers :) >>> Seems like a job for good ol' string interpolation. rootpage="post/$current_year/$current_month/$current_day" >>> Ikiwiki could provide some vars, and it would be nice to write plugins to also provide vars. Sort of like templates. >>> Does that feel OK? --[[sabr]] + +> I want the exact same thing. My compromise was to create a `datedblog` module which overrides `inline`'s `sessioncgi` hook +> with something that sets the new page name to `%Y-%m-%d.$page` and sets up a meta directive at the beginning of +> the content, with the title you wanted. Now if you use the `datedblog` module, you get dated blog entries. But I'd +> 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]] diff --git a/doc/todo/firm_up_plugin_interface.mdwn b/doc/todo/firm_up_plugin_interface.mdwn index b0e92e65c..c2e190884 100644 --- a/doc/todo/firm_up_plugin_interface.mdwn +++ b/doc/todo/firm_up_plugin_interface.mdwn @@ -41,7 +41,7 @@ Another problimatic thing is plugins often define functions named 'preprocess', 6 IkiWiki::titlepage These go together; linkpage is needed by all link plugins, and the others are used widely. -All should be exported. +All should be exported. (Done) 7 IkiWiki::saveindex 5 IkiWiki::loadindex diff --git a/doc/todo/plugin.mdwn b/doc/todo/plugin.mdwn index 132de4480..b3e3a7889 100644 --- a/doc/todo/plugin.mdwn +++ b/doc/todo/plugin.mdwn @@ -70,10 +70,6 @@ Suggestions of ideas for plugins: > web-server-specific code to list all users, and openid can't feasibly do so > at all. --[[JoshTriplett]] -* It would be nice to be able to have a button to show "Differences" (or - "Show Diff") when editing a page. Is that an option that can be enabled? - Using a plugin? - * For PlaceWiki I want to be able to do some custom plugins, including one that links together subpages about the same place created by different users. This seems to call for a plugin that applies to every page w/o any diff --git a/doc/todo/provide_inline_diffs_in_recentchanges.mdwn b/doc/todo/provide_inline_diffs_in_recentchanges.mdwn index 7724576f5..39a35d0c6 100644 --- a/doc/todo/provide_inline_diffs_in_recentchanges.mdwn +++ b/doc/todo/provide_inline_diffs_in_recentchanges.mdwn @@ -1,3 +1,8 @@ It would rock if I could view diffs from the web without going via feeds. I envision toggle-style buttons on the recentchanges page, or just links to the CGI, which then displays the diff... --[[madduck]] +> The diffs are actually there, enabled by the `recentchangesdiff` +> plugin, but they are hidden in the XHTML version by the stylesheet. +> You might try a user stylesheet with `div.diff { display: block }`. +> --[[JasonBlevins]] + [[!tag wishlist]] diff --git a/doc/todo/provide_sha1_for_git_diffurl.mdwn b/doc/todo/provide_sha1_for_git_diffurl.mdwn new file mode 100644 index 000000000..9c8b340de --- /dev/null +++ b/doc/todo/provide_sha1_for_git_diffurl.mdwn @@ -0,0 +1,26 @@ +This [[patch]] allows for `\[[sha1]]` substitution in the `diffurl` +for git repositories. This is useful for use with [cgit][] which has +diffurls of the following form: + + /project.git/diff/\[[file]]?id=\[[sha1_commit]] + + [cgit]: http://hjemli.net/git/cgit/ + + diff --git a/IkiWiki/Plugin/git.pm b/IkiWiki/Plugin/git.pm + index 5bef928..164210d 100644 + --- a/IkiWiki/Plugin/git.pm + +++ b/IkiWiki/Plugin/git.pm + @@ -518,6 +518,7 @@ sub rcs_recentchanges ($) { #{{{ + + my $diffurl = defined $config{'diffurl'} ? $config{'diffurl'} : ""; + $diffurl =~ s/\[\[file\]\]/$file/go; + + $diffurl =~ s/\[\[sha1\]\]/$sha1/go; + $diffurl =~ s/\[\[sha1_parent\]\]/$ci->{'parent'}/go; + $diffurl =~ s/\[\[sha1_from\]\]/$detail->{'sha1_from'}/go; + $diffurl =~ s/\[\[sha1_to\]\]/$detail->{'sha1_to'}/go; + +> [[done]], but I called it `sha1_commit` since I think that's what it's +> actually a sha1 of. --[[Joey]] + +>> I was at a loss for something more descriptive...I like that much +>> better :) Thanks! --[[JasonBlevins]] diff --git a/doc/todo/rcs_updates_needed_for_rename_and_remove.mdwn b/doc/todo/rcs_updates_needed.mdwn index 2af659c3b..472a5800f 100644 --- a/doc/todo/rcs_updates_needed_for_rename_and_remove.mdwn +++ b/doc/todo/rcs_updates_needed.mdwn @@ -3,3 +3,8 @@ renaming and removing files using the web interface. The mercurial and tla [[rcs]] backends need implementions of these functions. (The maintainers of these backends have been mailed. --[[Joey]]) + +Also, currently git is the only VCS to have support for +[[untrusted_push|tips/untrusted_git_push]]. It _may_ be possible to +implement it for other DVCS, if they offer a hook that can be used to check +incoming pushes early. diff --git a/doc/todo/syntax_highlighting.mdwn b/doc/todo/syntax_highlighting.mdwn new file mode 100644 index 000000000..bb1c84f02 --- /dev/null +++ b/doc/todo/syntax_highlighting.mdwn @@ -0,0 +1,89 @@ +There's been a lot of work on contrib syntax highlighting plugins. One should be +picked and added to ikiwiki core. + +Ideally, it should support both converting whole source files into wiki +pages, as well as doing syntax highlighting as a preprocessor directive +(which is either passed the text, or reads it from a file). + +## The big list of possibilities + +* [[plugins/contrib/highlightcode]] uses [[cpan Syntax::Highlight::Engine::Kate]], + operates on whole source files only, has a few bugs (see + [here](http://u32.net/Highlight_Code_Plugin/), and needs to be updated to + support [[bugs/multiple_pages_with_same_name]]. +* [[cpan IkiWiki-Plugin-syntax]] only operates as a directive. + Interestingly, it supports multiple highlighting backends, including Kate + and Vim. +* [[plugins/contrib/syntax]] only operates as a directive + ([[not_on_source_code_files|automatic_use_of_syntax_plugin_on_source_code_files]]), + and uses [[cpan Text::VimColor]]. +* [[plugins/contrib/sourcehighlight]] uses src-highlight, and operates on + whole source files only. Needs to be updated to + support [[bugs/multiple_pages_with_same_name]]. +* [[sourcecode|todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion]] + also uses src-highlight, and operates on whole source files. + Updated to work with the fix for [[bugs/multiple_pages_with_same_name]]. Untested with files with no extension, e.g. `Makefile`. + +## General problems + +* Using non-perl syntax highlighting backends is slow. I'd prefer either + using a perl module, or a multiple-backend solution that can use a perl + module as one option. (Or, if there's a great highlighter python module, + we could use an external plugin..) +* Currently no single plugin supports both modes of operation (directive + and whole source file to page). +* Nothing seems to support + [[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]] + inside source files. Doing this probably means post-processing the + results of the highlighting engine, to find places where it's highlighted + comments, and then running them through the ikiwiki rendering pipeline. + This seems fairly doable with [[cpan Syntax::Highlight::Engine::Kate]], + at least. +* The whole-file plugins tend to have a problem that things that look like + wikilinks in the source code get munged into links by ikiwiki, which can + have confusing results. Similar problem with preprocessor directives. + One approach that's also been requested for eg, + [[plugins/contrib/mediawiki]] is to allow controlling which linkification + types a page type can have on it. +* The whole-file plugins all get confused if there is a `foo.c` and a `foo.h`. + This is trivially fixable now by passing the keepextension option when + registering the htmlize hooks, though. +* Whole-file plugins register a bunch of htmlize hooks. The wacky thing + about it is that, when creating a new page, you can then pick "c" or + "h" or "pl" etc from the dropdown that normally has "mdwn" etc in it. + Is this a bug, or a feature? (Even if a feature, plugins with many + extensions make the dropdown unusable.. One way to deal with that is have + a config setting that lists what extensions to offer highlighting for. + Most people won't need/want the dozens some engines support.) +* The per page highlighters can't handle creating wiki pages from + "Makefile", or other files without a significant extension. + Not clear how to fix this, as ikiwiki is very oriented toward file + extensions. The workaround is to use a directive on a wiki page, pulling + in the Makefile. + +## format directive + +Rather than making syntax highlight plugins have to provide a preprocessor +directive as well as handling whole source files, perhaps a generic format +directive could be used: + + \[[!format pl """..."""]] + +That would run the text through the pl htmlizer, from the syntax hightligh +plugin. OTOH, if "rst" were given, it would run the text through the rst +htmlizer. So, more generic, allows mixing different types of markup on one +page, as well as syntax highlighting. Does require specifying the type of +format, instead of allowing it to be guessed (which some syntax highlighters +can do). (This directive is now implemented..) + +Hmm, this would also allow comments inside source files to have mdwn +embedded in them, without making the use of mdwn a special case, or needing +to postprocess the syntax highlighter output to find comments. + + /* \[[!format mdwn """ + + This is a comment in my C file. You can use mdwn in here. + + """]] */ + +Note that this assumes that directives are expanded in source files. diff --git a/doc/todo/syntax_highlighting/discussion.mdwn b/doc/todo/syntax_highlighting/discussion.mdwn new file mode 100644 index 000000000..7a4095c65 --- /dev/null +++ b/doc/todo/syntax_highlighting/discussion.mdwn @@ -0,0 +1,26 @@ +sourcehighlight is annoyingly slow, but it does support wiki directives +in comments. See [here](http://www.cs.unb.ca/~bremner/teaching/java_examples/snippet/ListMerge/) +for an example (tags). + +> I think that is just a result of it expanding directives, and wikilinks, +> everywhere in the file, which is generally a possible problem.. +> --[[Joey]] + +* * * * * + +I think having the option to choose source code page types from the +dropdown list is definitely a feature. This gives users an easy way +to contribute programs (say `.pl` files) or code snippets (like, for +example, the Elisp area of the EmacsWiki). Actually, would there any +other way to create a `.pl` file without write access to the +repository? --[[JasonBlevins]] + +> Well, you can upload them as an attachment if the wiki is configured to +> allow it. Having them in the drop down becomes a problem when there are +> so many wacky extensions in there that you can't find anything. +> --[[Joey]] + +>> I should just note that the +>> [[sourcecode|todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion]] +>> plugin only adds the file extensions listed in the config. This shouldn't cause +>> massive drop-down menu pollution. -- [[Will]] diff --git a/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn b/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn index 08ca61b0c..a5244c9ef 100644 --- a/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn +++ b/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn @@ -1 +1,4 @@ -[[Wishlist]] item: I'd love to see the ability to optionally switch back to wiki syntax within the comments of code pretty-printed with the [[plugins/contrib/syntax]] plugin. This would allow the use of links and formatting in comments. +[[Wishlist]] item: I'd love to see the ability to optionally switch back to +wiki syntax within the comments of code pretty-printed with the +[[plugins/contrib/syntax]] plugin. This would allow the use of links and +formatting in comments. diff --git a/doc/users/alexander.mdwn b/doc/users/alexander.mdwn new file mode 100644 index 000000000..b2894a90c --- /dev/null +++ b/doc/users/alexander.mdwn @@ -0,0 +1 @@ +I use ikiwiki to organize information - projects, reading notes, outlines, todo lists, etc. diff --git a/doc/users/hb/discussion.mdwn b/doc/users/hb/discussion.mdwn index 6dfa6a23b..15c065e45 100644 --- a/doc/users/hb/discussion.mdwn +++ b/doc/users/hb/discussion.mdwn @@ -1,4 +1,5 @@ I'd love to see any notes you have on using ikiwiki for GTD. Would you consider documenting them? Perhaps we could turn the result into a [[tip|tips]]. -[[JoshTriplett]] -> Well, certainly. Basically it's just inline + tag feature. I'm going to have more time in May for ikiwiki, I hope.
\ No newline at end of file +> Well, certainly. Basically it's just inline + tag feature. I'm going to have more time in May for ikiwiki, I hope. +> > Any news about that ? diff --git a/doc/users/jasonblevins.mdwn b/doc/users/jasonblevins.mdwn index a07d5d14b..f69a8040c 100644 --- a/doc/users/jasonblevins.mdwn +++ b/doc/users/jasonblevins.mdwn @@ -1,18 +1,22 @@ [[!meta title="Jason Blevins"]] I'm currently hosting a private ikiwiki for keeping research notes -which, with some patches and a (currently unreleased) plugin, will +which, with some patches and a plugin (below), will convert inline LaTeX expressions to MathML. I'm working towards a patchset and instructions for others to do the same. -There is one thing that needs to be decided first: whether or not to -include [[sanitization|todo/svg]] of MathML in htmlscrubber (and while -we're at it, why not SVG). +I've setup a test ikiwiki [here](http://xbeta.org/colab/) where I've +started keeping a few notes on my progress. There is an example of +inline SVG on the homepage (note that the logo scales along with the +font size). There are a few example mathematical expressions in the +[sandbox](http://xbeta.org/colab/sandbox/). The MathML is generated +automatically from inline LaTeX expressions using an experimental +plugin I'm working on. My (also MathML-enabled) homepage: <http://jblevins.org/> (still using Blosxom...maybe one day I'll convert it to ikiwiki...) -Current issues of interest: +Current ikiwki issues of interest: * [[bugs/recentchanges_feed_links]] * [[bugs/HTML_inlined_into_Atom_not_necessarily_well-formed]] @@ -20,3 +24,63 @@ Current issues of interest: * [[todo/BibTeX]] * [[todo/svg]] * [[todo/Option_to_make_title_an_h1?]] + * [[bugs/SVG_files_not_recognized_as_images]] + +## Plugins + +These plugins are experimental. Use them at your own risk. Read the +perldoc documentation for more details. + + * [mdwn_itex][] - Works with the `mdwn` plugin to convert inline LaTeX + expressions to MathML using `itex2MML`. + + * [h1title][] - If present, use the leading level 1 Markdown header to + set the page title and remove it from the page body. + +## MathML and SVG support + +So far, I've made some notes on sanitizing MathML and SVG via +htmlscrubber on the [[todo/svg]] todo item. + +I've also worked out some content-negotiation issues. First of all, +one needs to modify the default templates to use the +XHTML+MathML+SVG doctype (see e.g., this [patch][template-patch]). +For most browsers, the content type of the pages should be +`application/xhtml+xml`. The solution is easy if you want to +just send `application/xhtml+xml` to everybody: +just change the content type of `.html` files across the board. + +However, if you want to support browsers that don't accept +`application/xhtml+xml` (and those that will but say they +don't, such as IE with the MathPlayer plugin), then one +needs a `mod_rewrite` rule like the following: + + RewriteCond %{HTTP_ACCEPT} application\/xhtml\+xml [OR] + RewriteCond %{HTTP_USER_AGENT} (W3C.*Validator|MathPlayer) + RewriteRule \.html$ - [T=application/xhtml+xml] + +This solves the problem of MathML and inline SVG in static pages +but some additional work is required for dynamically generated +pages, like page previews, that are generated by `ikiwiki.cgi`. +We need to allow `ikiwiki.cgi` to set the content type dynamically +based on the `HTTP_CONTENT_TYPE` environment variable +(e.g., with the following [patch][cgi-patch]). Then, the following +rewrite rules can pass the correct content type to ikiwiki: + + RewriteCond %{HTTP_ACCEPT} application\/xhtml\+xml [OR] + RewriteCond %{HTTP_USER_AGENT} (W3C.*Validator|MathPlayer) + RewriteRule ikiwiki.cgi$ - [T=application/xhtml+xml] + +One final critical issue is that a production-ready setup needs to +implement some sort of on-the-fly error handling. If a user submits +an invalid LaTeX expression or SVG code (not malicious, just invalid) +and saves the page, then browsers like Firefox will halt processing of +the page, preventing any further viewing or editing. A less than +optimal solution is to force users to preview the page before saving. +That way if someone introduces invalid XHTML then they can't save the +page in the first place (unless they post directly to the right URL). + + [template-patch]: http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blobdiff;f=templates/page.tmpl;h=380ef699fa72223744eb5c1ee655fb79aa6bce5b;hp=9084ba7e11e92a10528b2ab12c9b73cf7b0f40a7;hb=416d5d1b15b94e604442e4e209a30dee4b77b684;hpb=ececf4fb8766a4ff7eff943b3ef600be81a0df49 + [cgi-patch]: http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=commitdiff;h=fa538c375250ab08f396634135f7d79fce2a9d36 + [mdwn_itex]: http://code.jblevins.org/ikiwiki/plugins/mdwn_itex.pm + [h1title]: http://code.jblevins.org/ikiwiki/plugins/h1title.pm diff --git a/doc/users/jrblevin.mdwn b/doc/users/jrblevin.mdwn new file mode 100644 index 000000000..4eb250bfa --- /dev/null +++ b/doc/users/jrblevin.mdwn @@ -0,0 +1 @@ +[[!meta redir=users/jasonblevins]] diff --git a/doc/users/jwalzer.mdwn b/doc/users/jwalzer.mdwn new file mode 100644 index 000000000..e66ad1a52 --- /dev/null +++ b/doc/users/jwalzer.mdwn @@ -0,0 +1,3 @@ +Jan Walzer started to look on ikiwiki just recently. + +Read [here](http://wa.lzer.net/wiki/ikiwiki/whyikiwiki/) why he uses ikiwiki. diff --git a/doc/users/neale.mdwn b/doc/users/neale.mdwn index 364e58a02..5245c2c99 100644 --- a/doc/users/neale.mdwn +++ b/doc/users/neale.mdwn @@ -1 +1,10 @@ -I have a keyboard and I'm not afraid to use it. +I used IkiWiki to supplant some custom journal software. I like that it uses +the filesystem, my intent is to make journal entries as future-proof as +possible. I'll probably start using it for generation of entire sites, soon. + +Things generated by IkiWiki with some fancypants stylesheets: + +* [woozle.org](http://woozle.org/) +* [My page](http://woozle.org/~neale/) +* [Amy's blog](http://woozle.org/~aim/blog/) +* [Heidi's blog](http://woozle.org/~heidi/blog/) diff --git a/doc/users/nolan.mdwn b/doc/users/nolan.mdwn new file mode 100644 index 000000000..64b405e60 --- /dev/null +++ b/doc/users/nolan.mdwn @@ -0,0 +1 @@ +Hi, I'm Nolan. I'll add more later. diff --git a/doc/users/xma.mdwn b/doc/users/xma.mdwn index 782b6eab6..97a8ef869 100644 --- a/doc/users/xma.mdwn +++ b/doc/users/xma.mdwn @@ -20,3 +20,9 @@ Various channels to contact me: - mobile: +33 621-964-362 (I only anwser to people I know though) Voila. + +## Plans + +I am planning to make a presentation of [[ikiwiki]]to my [local LUG](http://lolica.org) for our next montly meeting. Any help would be greatly appreciated. + +We are discussing to replace our old unmaintained (and unmaintainable) [SPIP](http://spip.net) website with a wiki. This is why I would like using ikiwiki ;) diff --git a/doc/users/xma/discussion.mdwn b/doc/users/xma/discussion.mdwn new file mode 100644 index 000000000..34adbf821 --- /dev/null +++ b/doc/users/xma/discussion.mdwn @@ -0,0 +1,18 @@ +How do you edit this wiki (I mean [ikiwiki]) without the web browser ? Is there a way to git clone/pull/push and thus to use our favorite [text editor](http://www.gnu.org/software/emacs) ? --[[xma]] + +> You can clone ikiwiki's [[git]] repo. I have not implemented a way to +> allow users to push doc wiki only changesets anonymously, but you can +> mails changesets to me. --[[Joey]] +> > How can I send you the changesets ? (git command) --[[xma]] +> > > `git-format-patch` --[[Joey]] + +> > > > Glad to hear I can mail changesets to you, since I wrote the [[todo/applydiff_plugin]] wishlist entry. --[[intrigeri]] + +> It would be nice to have a git recieve hook that +> checked that a commit contained only changes to .mdwn or other allowed +> extensions.. if someone writes up a good one, I'd be willing to deploy it +> for ikiwiki. --[[Joey]] + +> > I'll think about it. It may solve some of my offline-being issues. --[[intrigeri]] + +>>>> Now developed! --[[Joey]] |