diff options
Diffstat (limited to 'doc')
193 files changed, 3420 insertions, 434 deletions
diff --git a/doc/bugs/404_plugin_and_lighttpd.mdwn b/doc/bugs/404_plugin_and_lighttpd.mdwn index e478d98c3..8508d0dcd 100644 --- a/doc/bugs/404_plugin_and_lighttpd.mdwn +++ b/doc/bugs/404_plugin_and_lighttpd.mdwn @@ -1,5 +1,15 @@ Lighttpd apparently sets REDIRECT_STATUS=200 for the server.error-handler-404 page. This breaks the [[plugins/404]] plugin which checks this variable for 404 before processing the URI. It also doesn't seem to set REDIRECT_URL. +> For what it's worth, the first half is <http://redmine.lighttpd.net/issues/1828>. +> One workaround would be to make this script your 404 handler: +> +> #!/bin/sh +> REDIRECT_STATUS=404; export REDIRECT_STATUS +> REDIRECT_URL="$SERVER_NAME$REQUEST_URI"; export REDIRECT_URL +> exec /path/to/your/ikiwiki.cgi "$@" +> +> --[[smcv]] + I was able to fix my server to check the REQUEST_URI for ikiwiki.cgi and to continue processing if it was not found, passing $ENV{SEVER_NAME} . $ENV{REQUEST_URI} as the first parameter to cgi_page_from_404. However, my perl is terrible and I just made it work rather than figuring out exactly what to do to get it to work on both lighttpd and apache. This is with lighttpd 1.4.19 on Debian. diff --git a/doc/bugs/Error:_no_text_was_copied_in_this_page_--_missing_page_dependencies.mdwn b/doc/bugs/Error:_no_text_was_copied_in_this_page_--_missing_page_dependencies.mdwn new file mode 100644 index 000000000..0082eed4d --- /dev/null +++ b/doc/bugs/Error:_no_text_was_copied_in_this_page_--_missing_page_dependencies.mdwn @@ -0,0 +1,46 @@ +That one has bitten me for some time; here is the minimal testcase. There is +also an equivalent (I suppose) problem when using another plugin, but I hope +it's enough to track it down for this one. + + $ tar -xj < [bug-dep_order.tar.bz2](http://schwinge.homeip.net/~thomas/tmp/bug-dep_order.tar.bz2) + $ cd bug-dep_order/ + $ ./render_locally + [...] + $ find "$PWD".rendered/ -print0 | xargs -0 grep 'no text was copied' + $ [no output] + $ touch news/2010-07-31.mdwn + $ ./render_locally + refreshing wiki.. + scanning news/2010-07-31.mdwn + building news/2010-07-31.mdwn + building news.mdwn, which depends on news/2010-07-31 + building index.mdwn, which depends on news/2010-07-31 + done + $ find "$PWD".rendered/ -print0 | xargs -0 grep 'no text was copied' + /home/thomas/tmp/hurd-web/bug-dep_order.rendered/news.html:<p>[[!paste <span class="error">Error: no text was copied in this page</span>]]</p> + /home/thomas/tmp/hurd-web/bug-dep_order.rendered/news.html:<p>[[!paste <span class="error">Error: no text was copied in this page</span>]]</p> + +This error shows up only for *news.html*, but not in *news/2010-07-31* or for +the aggregation in *index.html* or its RSS and atom files. + +--[[tschwinge]] + +> So the cutpaste plugin, in order to support pastes +> that come before the corresponding cut in the page, +> relies on the scan hook being called for the page +> before it is preprocessed. +> +> In the case of an inline, this doesn't happen, if +> the page in question has not changed. +> +> Really though it's not just inline, it's potentially anything +> that preprocesses content. None of those things guarantee that +> scan gets re-run on it first. +> +> I think cutpaste is going beyond the intended use of scan hooks, +> which is to gather link information, not do arbitrary data collection. +> Requiring scan be run repeatedly could be a lot more work. +> +> Using `%pagestate` to store the cut content when scanning would be +> one way to fix this bug. It would mean storing potentially big chunks +> of page content in the indexdb. [[done]] --[[Joey]] diff --git a/doc/bugs/Highlight_extension_uses_hard_coded_paths.mdwn b/doc/bugs/Highlight_extension_uses_hard_coded_paths.mdwn index 1b9cb2e2d..275661fb8 100644 --- a/doc/bugs/Highlight_extension_uses_hard_coded_paths.mdwn +++ b/doc/bugs/Highlight_extension_uses_hard_coded_paths.mdwn @@ -1 +1,3 @@ The [[plugins/highlight]] plugin hard codes some paths up the top of the plugin. This means that you need to edit the ikiwiki source if you have highlight installed in a non-standard location (e.g. if you have done a user-level install of the highlight package). + +> configurable now, [[done]] --[[Joey]] diff --git a/doc/bugs/More_permission_checking.mdwn b/doc/bugs/More_permission_checking.mdwn new file mode 100644 index 000000000..e56cda98b --- /dev/null +++ b/doc/bugs/More_permission_checking.mdwn @@ -0,0 +1,9 @@ +I'm often confused about permissions and I wish ikiwiki could stamp it's foot down and ensure all the permissions are correctly (canonically?) setup. + +I keep ending up having to `sudo chown -R :www-data` and `sudo chmod -R g+w` on srcdir, destdir. I'm never quite sure what is the best practice for the srcdirs' `/srv/git/` is. Currently everything looks like `hendry:www-data` with ug+rw. + +I think I've triggered these problems by (not thinking and) running `ikiwiki --rebuild --setup /home/hendry/.ikiwiki/mywiki.setup` as my user. + +I don't know if there can be some lookup with `/etc/ikiwiki/wikilist`. Though shouldn't everything be under the `www-data` group in reality? + +Also when I use `sudo ikiwiki -setup /etc/ikiwiki/auto.setup`, I think I create a ton of problems for myself since everything is created as the root user, right? And `/etc/ikiwiki/wikilist` doesn't seem to have the latest created wiki added. I have to reluctantly manually do this. diff --git a/doc/bugs/UTF-16_and_UTF-32_are_unhandled.mdwn b/doc/bugs/UTF-16_and_UTF-32_are_unhandled.mdwn new file mode 100644 index 000000000..21df334a8 --- /dev/null +++ b/doc/bugs/UTF-16_and_UTF-32_are_unhandled.mdwn @@ -0,0 +1,20 @@ +Wide characters should probably be supported, or, at the very least, warned about. + +Test case: + + mkdir -p ikiwiki-utf-test/raw ikiwiki-utf-test/rendered + for page in txt mdwn; do + echo hello > ikiwiki-utf-test/raw/$page.$page + for text in 8 16 16BE 16LE 32 32BE 32LE; do + iconv -t UTF$text ikiwiki-utf-test/raw/$page.$page > ikiwiki-utf-test/raw/$page-utf$text.$page; + done + done + ikiwiki --verbose --plugin txt --plugin mdwn ikiwiki-utf-test/raw/ ikiwiki-utf-test/rendered/ + www-browser ikiwiki-utf-test/rendered/ || x-www-browser ikiwiki-utf-test/rendered/ + # rm -r ikiwiki-utf-test/ # some browsers rather stupidly daemonize themselves, so this operation can't easily be safely automated + +BOMless LE and BE input is probably a lost cause. + +Optimally, UTF-16 (which is ubiquitous in the Windows world) and UTF-32 should be fully supported, probably by converting to mostly-UTF-8 and using `&#xXXXX;` or `&#DDDDD;` XML escapes where necessary. + +Suboptimally, UTF-16 and UTF-32 should be converted to UTF-8 where cleanly possible and a warning printed where impossible. diff --git a/doc/bugs/__34__Currently_enabled_SSH_keys:__34___shows_only_first_139_characters_of_each_key.mdwn b/doc/bugs/__34__Currently_enabled_SSH_keys:__34___shows_only_first_139_characters_of_each_key.mdwn new file mode 100644 index 000000000..3c3352f66 --- /dev/null +++ b/doc/bugs/__34__Currently_enabled_SSH_keys:__34___shows_only_first_139_characters_of_each_key.mdwn @@ -0,0 +1,12 @@ +At least at http://free-thursday.pieni.net/ikiwiki.cgi the "SSH keys" page shows only the first 139 characters of each SSH key. I'm using iceweasel in 1024x768 resolution and there are not scrollbars visible. + +Please contact me at timo.lindfors@iki.fi + +> I have access to the same wiki, and do not see the problem Timo sees. I see 380 chars of the SSH keys, and do have a scrollbar. +> Weird. --liw + +> Also, that's a Branchable.com site and the bug, if any is +> in ikiwiki-hosting's plugin, not ikiwiki proper. Moved +> [here](http://ikiwiki-hosting.branchable.com/bugs/__34__Currently_enabled_SSH_keys:__34___shows_only_first_139_characters_of_each_key/) --[[Joey]] + +[[!tag done]] diff --git a/doc/bugs/aggregate_generates_long_filenames.mdwn b/doc/bugs/aggregate_generates_long_filenames.mdwn new file mode 100644 index 000000000..fae8333ab --- /dev/null +++ b/doc/bugs/aggregate_generates_long_filenames.mdwn @@ -0,0 +1,37 @@ +the [[plugins/aggregate]] plugin mashes the `title` of an aggregated post into a filename. This results in long filenames. I have hit a filesystem length limitation on several occasions. Some (ab)uses of RSS, e.g., twitter, +generate long titles. Especially once you throw escaping into the mix: + + $ ikiwiki --setup testsetup --aggregate --refresh + failed to write ./test/lifestream/Hidden_Features_Of_Perl__44___PHP__44___Javascript__44___C__44___C++__44___C__35____44___Java__44___Ruby___46____46____46__._aggregated.ikiwiki-new: File name too long + aggregation failed with code 9216 + $ echo $? + 25 + +It would also appear this abrubtly terminates aggregate processing (if not ikiwiki itself). Only after moving my test repo to `/tmp` to shorten the filename did I see newer RSS feeds (from a totally different source) picked up. + + +-- [[Jon]] + +> I have to wonder what filesystem you have there where 147 characters +> is a long filename. Ikiwiki already uses `POSIX::pathconf` on the srcdir +> to look up `_PC_NAME_MAX` +> to see if the filename is too long, and shortens it, so it seems +> that, in additional to having a rather antique long filename limit, your +> system also doesn't properly expose it via pathconf. Not sure what +> ikiwiki can do here. --[[Joey]] + +>> This is an ext4 filesystem with default settings (which appears to mean +>> 256 bytes for pathnames). Despite the error saying file name, it's +>> definitely a path issue since moving my test repo to `/tmp`from +>> `/home/jon/wd/mine/www` hides the problem. I note the following comment +>> in `aggregate.pm`: + + # Make sure that the file name isn't too long. + # NB: This doesn't check for path length limits. + +>> I don't fully grok the aggregate source yet, but I wouldn't rule out +>> a bug in the path length checking, personally. I'm happy to try and +>> find it myself though :) -- [[Jon]] + +>>> Path length seems unlikely, since the max is 4096 there. +>>> --[[Joey]] diff --git a/doc/bugs/argument_isn__39__t_numeric:_mixing_templates_and_creation__95__date.mdwn b/doc/bugs/argument_isn__39__t_numeric:_mixing_templates_and_creation__95__date.mdwn new file mode 100644 index 000000000..ff98ba55f --- /dev/null +++ b/doc/bugs/argument_isn__39__t_numeric:_mixing_templates_and_creation__95__date.mdwn @@ -0,0 +1,62 @@ +I get the following error when building my wiki + + Argument "\x{3c}\x{54}..." isn't numeric in numeric eq (==) at /usr/share/perl5/IkiWiki.pm line 2547. + Argument "\x{3c}\x{54}..." isn't numeric in numeric eq (==) at /usr/share/perl5/IkiWiki.pm line 2547. + +that line corresponds to + + sub match_creation_year ($$;@) { + if ((localtime($IkiWiki::pagectime{shift()}))[5] + 1900 == shift) { <-- this one + return IkiWiki::SuccessReason->new('creation_year matched'); + } + +A git bisect shows that the offending commit introduced this hunk + + + --- /dev/null + +++ b/templates/all_entry.mdwn + @@ -0,0 +1,23 @@ + +## <TMPL_VAR year> + + + +There + +<TMPL_IF current> + +have been + +<TMPL_ELSE> + +were + +</TMPL_IF> + +[[!pagecount pages=" + +log/* and !tagged(aggregation) and !*/Discussion and !tagged(draft) + +and creation_year(<TMPL_VAR year>) + +and !*.png and !*.jpg + +"]] posts + +<TMPL_IF current> + +so far + +</TMPL_IF> + +in <TMPL_VAR year>. + + + +[[!inline pages=" + + log/* and !tagged(aggregation) and !*/Discussion and !tagged(draft) + + and creation_year(<TMPL_VAR year>) + + and !*.png and !*.jpg + + " archive=yes feeds=no]] + +The lines which feature creation_year(<TMPL_VAR year>) are most likely the culprits. That would explain why the error was repeated twice, and would tally with the file in `templates/` being rendered, rather than the inclusionists. + +A workaround is to move the template outside of the srcdir into the external templates directory and include the file suffix when using it, e.g. + + \[[!template id=all_entry.tmpl year=2010 current=true]] + +I believed (until I tested) that the [[ikiwiki/directive/if]] directive, with the `included()` test, would be an option here, E.g. + + \[[!if test="included()" then=""" + ...template... + """ else=""" + Nothing to see here. + """]] + +However this doesn't work. I assume "included" in this context means e.g. via an `inline` or `map`, not template trans-clusion. -- [[Jon]] + +> As far as I know, this bug was fixed in +> 4a75dee651390b79ce4ceb1d951b02e28b3ce83a on October 20th. [[done]] --[[Joey]] + +>> Sorry Joey, I'll make sure to reproduce stuff against master in future. [[Jon]] diff --git a/doc/bugs/blog_spam_plugin_not_allowing_non-ASCII_chars__63__.mdwn b/doc/bugs/blog_spam_plugin_not_allowing_non-ASCII_chars__63__.mdwn new file mode 100644 index 000000000..59bf93d14 --- /dev/null +++ b/doc/bugs/blog_spam_plugin_not_allowing_non-ASCII_chars__63__.mdwn @@ -0,0 +1,15 @@ +Hi, + +I'm trying to add a comment, and ikiwiki fails with this error message: + + Error: HTTP::Message content must be bytes at /usr/share/perl5/RPC/XML/Client.pm line 308 + +This seems to happen because I had a non-ASCII character in the comment (an ellipse, …). +The interesting part is that the comment preview works fine, just the save fails. Probably +this means that the blogspam plugin is the culprit (hence the error in RPC::XML::Client library). +I'm using version 3.20100815~bpo50+. Thanks! + +> I've filed an upstream bug about this on RPC::XML: +> <https://rt.cpan.org/Ticket/Display.html?id=61333> +> +> Worked around it in blogspam by decoding. [[done]] --[[Joey]] diff --git a/doc/bugs/can__39__t_mix_template_vars_inside_directives.mdwn b/doc/bugs/can__39__t_mix_template_vars_inside_directives.mdwn new file mode 100644 index 000000000..e91a8923d --- /dev/null +++ b/doc/bugs/can__39__t_mix_template_vars_inside_directives.mdwn @@ -0,0 +1,61 @@ +I often find myself wrapping the same boiler plate around [[ikiwiki/directives/img]] img directives, so I tried to encapsulate it using the following [[ikiwiki/directives/template]]: + + + <div class="image"> + [\[!img <TMPL_VAR raw_href> + size="<TMPL_VAR raw_size>" + + <TMPL_IF alt> + alt="<TMPL_VAR raw_alt>" + <TMPL_ELSE> + <TMPL_IF caption> + alt="<TMPL_VAR raw_alt>" + <TMPL_ELSE> + alt="[pic]" + </TMPL_IF> + </TMPL_IF> + + ]] + <TMPL_IF caption> + <p><TMPL_VAR raw_caption></p> + </TMPL_IF> + </div> + +The result, even with htmlscrubber disabled, is mangled, something like + + <div class="image"> + <span class="createlink"><a href="http://jmtd.net/cgi? + page=size&from=log0.000000old_new_test&do=create" + rel="nofollow">?</a>size</span> + + </div> + +Any suggestions gladly received. -- [[Jon]] + +> Well, you *should* be able to do things like this, and in my testing, I +> *can*. I used your exact example above (removing the backslash escape) +> and invoked it as: +> \[[!template id=test href=himom.png size=100x]] +> +> And got just what you would expect. +> +> I don't know what went wrong for you, but I don't see a bug here. +> My guess, at the moment, is that you didn't specify the required href +> and size parameters when using the template. If I leave those off, +> I of course reproduce what you reported, since the img directive gets +> called with no filename, and so assumes the size parameter is the image +> to display.. [[done]]? --[[Joey]] + +>> Hmm, eek. Just double-checked, and done a full rebuild. No dice! Version 3.20100831. Feel free to leave this marked done, It probably *is* PEBKAC. I shall look again in day time. -- [[Jon]] + +>>> As always, if you'd like to mail me a larger test case that reproduces a +>>> problem for you, I can take a look at it. --[[Joey]] + +>>>> <s>Thank you for the offer. I might still take you up on it. I've just proven that this +>>>> does work for a clean repo / bare bones test case. -- [[Jon]]</s> Figured it out. The +>>>> problem was I'd copied a page (old_new) which had two images embedded in it to test. +>>>> I'd stored the images under a subdir "old_new". The new page was called "old_new_test" +>>>> and the images thus could not be found by a pagespec "some-image.jpg". Adjusting the +>>>> href argument to the template (consequently the src argument to img) to +>>>> "old_new/some-image.jpg" fixed it all. [[done]], PEBKAC. Thank you for your time :) +>>>> -- [[Jon]] diff --git a/doc/bugs/class_parameter_of_img_directive_behave_not_as_documented.mdwn b/doc/bugs/class_parameter_of_img_directive_behave_not_as_documented.mdwn new file mode 100644 index 000000000..e7797765f --- /dev/null +++ b/doc/bugs/class_parameter_of_img_directive_behave_not_as_documented.mdwn @@ -0,0 +1,31 @@ +On [[ikiwiki/directive/img/]] I read that + +> You can also pass alt, title, class, align, id, hspace, and vspace +> parameters. These are passed through unchanged to the html img tag. + +but when I pass `class="myclass"` to an img directive, I obtain + + <img class="myclass img" ... + +I found that this behaviour was added in commit f6db10d: + +> img: Add a margin around images displayed by this directive. +> +> Particularly important for floating images, which could before be placed +> uncomfortably close to text. + +which adds to img.pm: + + if (exists $params{class}) { + $params{class}.=" img"; + } + else { + $params{class}="img"; + } + +I would prefer if the `img` class were only added if no class attribute is +passed. + +If you keep the current behaviour, please document it. + +> [[done]] --[[Joey]] diff --git a/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn b/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn new file mode 100644 index 000000000..4b22fd06c --- /dev/null +++ b/doc/bugs/cutpaste.pm:_missing_filter_call.mdwn @@ -0,0 +1,55 @@ +Consider this: + + $ wget http://schwinge.homeip.net/~thomas/tmp/cutpaste_filter.tar.bz2 + $ wget http://schwinge.homeip.net/~thomas/tmp/cutpaste_filter.patch + + $ tar -xj < cutpaste_filter.tar.bz2 + $ cd cutpaste_filter/ + $ ./render_locally + $ find "$PWD".rendered/ -type f -print0 | xargs -0 grep -H -E 'FOO|BAR' + [notice one FOO in there] + $ rm -rf .ikiwiki "$PWD".rendered + + $ cp /usr/share/perl5/IkiWiki/Plugin/cutpaste.pm .library/IkiWiki/Plugin/ + $ patch -p0 < ../cutpaste_filter.patch + $ ./render_locally + $ find "$PWD".rendered/ -type f -print0 | xargs -0 grep -H -E 'FOO|BAR' + [correct; notice no more FOO] + +I guess this needs a general audit -- there are other places where `preprocess` +is being doing without `filter`ing first, for example in the same file, `copy` +function. + +--[[tschwinge]] + +> So, in English, page text inside a cut directive will not be filtered. +> Because the cut directive takes the text during the scan pass, before +> filtering happens. +> +> Commit 192ce7a238af9021b0fd6dd571f22409af81ebaf and +> [[bugs/po_vs_templates]] has to do with this. +> There I decided that filter hooks should *only* act on the complete +> text of a page. +> +> I also suggested that anything that wants to reliably +> s/FOO/BAR/ should probably use a sanitize hook, not a filter hook. +> I think that would make sense in this example. +> +> I don't see any way to make cut text be filtered while satisfying these +> constraints, without removing cutpaste's ability to have forward pastes +> of text cut laster in the page. (That does seems like an increasingly +> bad idea..) --[[Joey]] + +> > OK -- so the FOO/BAR thing was only a very stripped-down example, of +> > course, and the real thing is being observed with the +> > *[[plugins/contrib/getfield]]* plugin. This one needs to run *before* +> > `preprocess`ing, for its `{{$page#field}}` syntax is (a) meant to be usable +> > inside ikiwiki directives, and (b) the field values are meant to still be +> > `preprocess`ed before being embedded. That's why it's using the `filter` +> > hook instead of `sanitize`. + +> > Would adding another kind of hook be a way to fix this? My idea is that +> > *cut* (and others) would then take their data not during `scan`ning, but +> > *after* `filter`ing. + +> > --[[tschwinge]] diff --git a/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn b/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn new file mode 100644 index 000000000..5dc4250e3 --- /dev/null +++ b/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn @@ -0,0 +1,14 @@ +The _git_ module does not appear ever to prune obsolete remote branches in the _srcdir_ repository, leading to spurious errors when fetching. + +Pruning remote branches can be done automatically with the --prune option to "git fetch" or in a separate command "git remote prune". + +--[[blipvert]] + +> I'll need more information than that before I add extra processing +> work to the current git commands it uses. I don't see any errors here +> from obsolete remote branches. --[[Joey]] + +Suppose a remote repository contains a branch named "foo", and you fetch from it. Then, someone renames that branch to "foo/bar". The next time you fetch from that repository, you will get an error because the obsolete branch "foo" is blocking the branch "foo/bar" from being created (due to the way git stores refs for branches). Pruning gets around the problem. It doesn't really add much overhead to the fetch, and in fact it can *save* overhead since obsolete branches do consume resources (any commits they point to cannot be garbage collected). --[[blipvert]] + +> Ok, so git pull --prune can be used to do everything in one command. +> [[done]] --[[Joey]] diff --git a/doc/bugs/git_commit_adds_files_that_were_not_tracked.mdwn b/doc/bugs/git_commit_adds_files_that_were_not_tracked.mdwn new file mode 100644 index 000000000..587650c61 --- /dev/null +++ b/doc/bugs/git_commit_adds_files_that_were_not_tracked.mdwn @@ -0,0 +1,19 @@ +Commit 3650d0265bc501219bc6d5cd4fa91a6b6ecd793a seems to have been caused by +a bug in ikiwiki. recentchanges/* was added to the git repo incorrectly. + +Part of the problem seems to be that git's `rcs_commit` does a git add followed +by a `rcs_commit_staged`, and so calling `rcs_commit` on files that were +not checked in before adds them, incorrectly. + +I'm unsure yet why the recentchanges files were being committed. Possibly +because of the link fixup code run when renaming a page. --[[Joey]] + +> See also [[bugs/rename fixup not attributed to author]]. --[[smcv]] + +> Ok, there was a call to `rcs_commit` that was still using non-named +> parameters, which confused it thuroughly, and I think caused +> 'git add .' to be called. I've fixed that. +> +> I think there is still potential for the problem I described above to +> occur during a rename or possibly otherwise. Ok.. fixed `rcs_commit` +> to not add too. [[done]] --[[Joey]] diff --git a/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn b/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn new file mode 100644 index 000000000..92427065d --- /dev/null +++ b/doc/bugs/htmlbalance_fails_with_HTML-Tree_v4.mdwn @@ -0,0 +1,18 @@ +[[!template id=gitbranch branch=smcv/ready/htmlbalance author="[[smcv]]"]] +[[!tag patch]] + +My one-patch htmlbalance branch fixes incompatibility with HTML::Tree 4.0. +From the git commit: + + The HTML::Tree changelog says: + + [THINGS THAT MAY BREAK YOUR CODE OR TESTS] + ... + * Attribute names are now validated in as_XML and invalid names will + cause an error. + + and indeed the regression tests do get an error. + +--[[smcv]] + +[[done]] --[[Joey]] diff --git a/doc/bugs/httpauth_conflicts_with_git_anon_push.mdwn b/doc/bugs/httpauth_conflicts_with_git_anon_push.mdwn new file mode 100644 index 000000000..91507f57a --- /dev/null +++ b/doc/bugs/httpauth_conflicts_with_git_anon_push.mdwn @@ -0,0 +1,25 @@ +Someone tried to report a bug using IRC while I was on vacation. +--[[Joey]] + +<pre> +julm: [11:58:35] han, it's me the problem; I was generating a post-update hook instead of a pre-receive hook +julm: [12:03:59] why does the pre-receive hook return: "Status: 302 Found" and a "Location: <url>"? Is it normal? +julm: [00:08:44] it's Plugin/httpauth.pm which is outputing those Status and Location +julm: [00:09:12] problem is that it's an anonymous push via git:// +julm: [03:28:53] hacked my way to fix it somehow: http://git.internet.alpes.fr.eu.org/?p=web/ikiwiki.git;a=commitdiff;h=7211df4f7457c3afab53822a97cbd21825c473f4 +</pre> + +Analysis: + +* IkiWiki::Receive calls `check_canedit`. +* httpauth's canedit hook returns an error handler function + which redirects the browser through the cgiauthurl. + (Similarly, signinedit's hook may call needsignin, which + can display a signin form. +* That doesn't work well when doing a git anon push. :) +* Also, IkiWiki::Receive calls `check_canattach` and + `check_canremove`, which both also call `check_canedit`. + +So, all these calls need to avoid running the error handler +functions returned by canedit hooks, and just return error +messages. [[done]] --[[Joey]] diff --git a/doc/bugs/ikiwiki_ignores_PATH_environment.mdwn b/doc/bugs/ikiwiki_ignores_PATH_environment.mdwn new file mode 100644 index 000000000..6781d4b4b --- /dev/null +++ b/doc/bugs/ikiwiki_ignores_PATH_environment.mdwn @@ -0,0 +1,24 @@ +At the very top of the main ikiwiki executable script the `PATH` environment is set like this: + + $ENV{PATH}="/usr/local/bin:/usr/bin:/bin:/opt/local/bin"; + +This makes it a little hard to specify which specific binaries should be used, especially if there is more than one of them available (see c.f. <http://trac.macports.org/ticket/26333> where the MacPorts-supplied, up-to-date subversion should be used and not an arcane one from the base distro / OS). Is there a specific reason why ikiwiki wipes out `$PATH` like this or could that line be improved to + + $ENV{PATH}="$ENV{PATH}:/usr/local/bin:/usr/bin:/bin:/opt/local/bin"; + +? The alternative is of course to patch ikiwiki as suggested in the bug, but I wanted to ask here first :) + +> You can use the ENV setting in your setup file to set any environment +> variables you like. Since ikiwiki.cgi is run by the web browser, that +> is the best way to ensure ikiwiki always runs with a given variable set. +> +> As a suid program, the ikiwiki wrappers have to sanitize the environment. +> The ikiwiki script's own sanitization of PATH was done to make perl taint +> checking happy, but as taint checking is disabled anyway, I have removed +> that. [[done]] --[[Joey]] + +Question: Do ikiwiki.cgi and the RCS post-commit script sanitize the $PATH separately from bin/ikiwiki? If not, then bin/ikiwiki is probably right to sanitize the $PATH; otherwise you've created a security hole with access to the account that ikiwiki is SUID to. It'd be nice if /opt/local/bin were earlier in the $PATH, but that can be changed (as noted) in the setup file. [[Glenn|geychaner@mac.com]] (Also the person who started this by filing an issue with MacPorts; I'm experimenting with ikiwiki for collaborative documentation.) + +> The suid wrappers remove all environment variables except for a few used +> for CGI. PATH is not propigated by them, so when they run ikiwiki it will +> get the system's default path now. --[[Joey]] diff --git a/doc/bugs/img_plugin_and_class_attr.mdwn b/doc/bugs/img_plugin_and_class_attr.mdwn new file mode 100644 index 000000000..7e880b4fc --- /dev/null +++ b/doc/bugs/img_plugin_and_class_attr.mdwn @@ -0,0 +1,27 @@ +The [[plugins/img]] plugin is not generating the proper `class` +attribute in its HTML output. + +The plugin receives something like the following: + + \[[!img 129199047595759991.jpg class="centered"]] + +And is supossed to generate an HTML code like the following: + + <img src="129199047595759991.jpg" class="centered" /> + +But is generating the following + + <img src="129199047595759991.jpg" class="centered img" /> + +This seems to be happening with all images inserted using the plugin (that use +the `class=yaddayadda` argument to the `img` directive.) I remember it didn't +happen before, and I suspect an ikiwiki upgrade is to blame. I tested with a +blog created from scratch, and a single post, and the problem appeared there +too. + +This is happening with version 3.20100815 of ikiwiki. + +[[jerojasro]] + +> How is this a bug? It's perfectly legal html for a class attribute to +> put an element into multiple classes. [[notabug|done]] --[[Joey]] diff --git a/doc/bugs/inline_action_buttons_circumvent_exclude_criteria_from_edittemplate__39__s_match__61____34____34___pagespec.mdwn b/doc/bugs/inline_action_buttons_circumvent_exclude_criteria_from_edittemplate__39__s_match__61____34____34___pagespec.mdwn new file mode 100644 index 000000000..45481bf21 --- /dev/null +++ b/doc/bugs/inline_action_buttons_circumvent_exclude_criteria_from_edittemplate__39__s_match__61____34____34___pagespec.mdwn @@ -0,0 +1,13 @@ +ikiwiki verison: 3.20100815.2 + +If I instruct editemplate to only match the top level pages in a directory using + + match="foo/* and !foo/*/* and !foo/*/*/*" + +everything works as expected for pages created via links on other wiki pages. So, if I open foo/bar (or any other page on the wiki) and create a link to foo/bar/bug, edittemplate appropriately does not insert any text into the new page. + +However, if I use an inline directive like the following + + !inline pages="page(foo/bar/*)" rootpage="foo/bar" postform=yes actions=yes + +every page created via the action buttons incorrectly pulls in the text from the edittemplate registration. Changing the order of the conditions in the match="" pagespec has no impact. diff --git a/doc/bugs/logout_in_ikiwiki.mdwn b/doc/bugs/logout_in_ikiwiki.mdwn new file mode 100644 index 000000000..d9b6df677 --- /dev/null +++ b/doc/bugs/logout_in_ikiwiki.mdwn @@ -0,0 +1,31 @@ +It looks like there is no way to logout of ikiwiki at present, meaning that if you edit the ikiwiki in, say, a cybercafe, the cookie remains... is there some other security mechanism in place that can check for authorization, or should I hack in a logout routine into ikiwiki.cgi? + +> Click on "Preferences". There is a logout button there. --liw + +> It would be nice if it were not buried there, but putting it on the +> action bar statically would be confusing. The best approach might be to +> use javascript. --[[Joey]] + + +>> I agree that javascript seems to be a solution, but my brain falls +>> off the end of the world while looking at ways to manipulate the DOM. +>> (I'd argue also in favor of the openid_provider cookie expiring +>> in less time than it does now, and being session based) + +>>> (The `openid_provider` cookie is purely a convenience cookie to +>>> auto-select the user's openid provider the next time they log +>>> in. As such, it cannot be a session cookie. It does not provide any +>>> personally-identifying information so it should not really matter +>>> when it expires.) --[[Joey]] + +>> It would be nice to move navigational elements to the upper right corner +>> of the page... + +>> I have two kinds of pages (wiki and blog), and three classes of users + +>> anonymous users - display things like login, help, and recentchanges, + +>> non-admin users - on a per subdir basis (blog and !blog) display +>> logout, help, recentchanges, edit, comment + +>> admin users - logout, help, recentchanges, edit, comment, etc diff --git a/doc/bugs/monotone_backend_does_not_support_srcdir_in_subdir.mdwn b/doc/bugs/monotone_backend_does_not_support_srcdir_in_subdir.mdwn new file mode 100644 index 000000000..35f624f78 --- /dev/null +++ b/doc/bugs/monotone_backend_does_not_support_srcdir_in_subdir.mdwn @@ -0,0 +1,5 @@ +The [[rcs/monotone]] backend does not currently support putting the ikiwiki srcdir +in a subdirectory of the repository. It must be at the top. Git has +special code to handle this case. --[[Joey]] + +[[done]] diff --git a/doc/bugs/more_and_RSS_generation.mdwn b/doc/bugs/more_and_RSS_generation.mdwn new file mode 100644 index 000000000..00ab43fa2 --- /dev/null +++ b/doc/bugs/more_and_RSS_generation.mdwn @@ -0,0 +1,20 @@ +I'd like the more plugin and RSS to play better together. In the case of the html generation of the main page of a blog, I'd like to get the first paragraph out, but keep RSS as a full feed. + +Maybe there is a different plugin (I also tried toggle)? + +> I am not a fan of the more directive (thus the rant about it sucking +> embedded in its [[example|ikiwiki/directive/more]]). But I don't think +> that weakening it to not work in rss feeds is a good idea, if someone +> wants to force users to go somewhere to view their full content, +> they should be able to do it, even though it does suck. +> +> The toggle directive will degrade fairly well in an rss feed to +> display the full text. (There is an annoying toggle link that does +> nothing when embedded in an rss feed). --[[Joey]] + +I also note, that at least currently, more seems to break on a few pages, not being parsed at all when aggregated into the front page. + +> It's just a simple directive, it should work anywhere any directive will, +> and does as far as I can see. Details? --[[Joey]] + +see also: [[/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields/]] diff --git a/doc/bugs/po:_apache_config_serves_index.rss_for_index.mdwn b/doc/bugs/po:_apache_config_serves_index.rss_for_index.mdwn new file mode 100644 index 000000000..a2b68c4b1 --- /dev/null +++ b/doc/bugs/po:_apache_config_serves_index.rss_for_index.mdwn @@ -0,0 +1,36 @@ +The apache config documented in [[plugins/po]] has a subtle bug. It works +until a site gets an index.atom or index.rss file. (Acutally, with po +enabled, they're called index.en.atom or index.en.rss etc, but the result +is the same). + +Then, when wget, curl, or w3m is pointed at http://site/, apache serves +up the rss/atom file rather than the index page. + +Analysis: + +* /etc/mime.types gives mime types to .rss and .atom files +* `mod_negotiation`'s MultiViews allows any file with a mime type to be + served up via content negotiation, if the client requests that type. +* wget etc send `Accept: */*` to accept all content types. Compare + with firefox, which sends `Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*` +* So apache has a tie between a html encoded Enlish file, and a rss encoded + English file and the client has no preference. In a tie, apache will serve up the + *smallest* file, which tends to be the rss file. (Apache's docs say it uses that + strange criteria to break ties; see <http://httpd.apache.org/docs/2.0/mod/mod_mime.html#multiviewsmatch>) + +The only way I have found to work around this problem is to remove +atom and rss from /etc/mime.types. Of course, that has other undesirable +results. + +I wonder if it would be worth making the po plugin generate apache +[type map files](http://httpd.apache.org/docs/2.0/mod/mod_negotiation.html#typemaps). +That should avoid this problem. +--[[Joey]] + +Update: A non-intrusive fix is to add this to apache configuration. +This tunes the "quality" of the rss and atom files, in an apparently currently +undocumented way (though someone on #httpd suggested it should get documented). +Result is that apache will prefer serving index.html. --[[Joey]] [[done]] + + AddType application/rss+xml;qs=0.8 .rss + AddType application/atom+xml;qs=0.8 .atom diff --git a/doc/bugs/po:_markdown_link_parse_bug.mdwn b/doc/bugs/po:_markdown_link_parse_bug.mdwn new file mode 100644 index 000000000..10715001c --- /dev/null +++ b/doc/bugs/po:_markdown_link_parse_bug.mdwn @@ -0,0 +1,14 @@ +Apparently this is legal markdown, though unusual syntax for a link: + + [Branchable](http://www.branchable.com/ "Ikiwiki hosting") + +If that is put on a translatable page, the translations display it not as a +link, but as plain text. + +Probably a po4a bug, but I don't see the bug clearly in the gernerated po +file: + + "This was posted automatically by [Branchable](http://www.branchable.com/ " + "\"Ikiwiki hosting\") when I signed up." + +--[[Joey]] diff --git a/doc/bugs/po:_po_files_instead_of_html_files.mdwn b/doc/bugs/po:_po_files_instead_of_html_files.mdwn index 933e348c4..8238f50df 100644 --- a/doc/bugs/po:_po_files_instead_of_html_files.mdwn +++ b/doc/bugs/po:_po_files_instead_of_html_files.mdwn @@ -3,4 +3,20 @@ At the bottom of this page, there is the "Links" line: Links: index index.fr templates templates.fr When i click on "templates.fr", i get the po.file instead of html. - Sorry for the noise! I set "po_master_language" to fr and all was ok. [[done]]. + Sorry for the noise! I set "po_master_language" to fr and all was ok. + +> Any chance you could be a bit more verbose about what the +> misconfiguration was? I don't think the po plugin should behave like that +> in any configuration. Unless, perhaps, it was just not configured to +> support any languages at all, and so the po file was treated as a raw +> file. --[[Joey]] + +>> I can reproduce the bug with: + # po plugin + # master language (non-PO files) + po_master_language => { + code => 'en', + name => 'English' + }, + # slave languages (PO files) + po_slave_languages => [qw{fr|Français}], diff --git a/doc/bugs/po:broken_links_to_translatable_basewiki_pages_that_lack_po_fies.mdwn b/doc/bugs/po:broken_links_to_translatable_basewiki_pages_that_lack_po_fies.mdwn new file mode 100644 index 000000000..121d33807 --- /dev/null +++ b/doc/bugs/po:broken_links_to_translatable_basewiki_pages_that_lack_po_fies.mdwn @@ -0,0 +1,73 @@ +broken links to translatable basewiki pages that lack po files +-------------------------------------------------------------- + +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]] + +> Any simple testcase to reproduce it, please? I've never seen this +> happen yet. --[[intrigeri]] + +>> Sure, go here <http://l10n.ikiwiki.info/smiley/smileys/index.sv.html> +>> (Currently 0% translateed) and see the 'WikiLink' link at the bottom, +>> which goes to <http://l10n.ikiwiki.info/ikiwiki.cgi?page=ikiwiki/wikilink&from=smiley/smileys&do=create> +>> Compare with eg, the 100% translated Dansk version, where +>> the WikiLink link links to the English WikiLink page. --[[Joey]] + +>>> Seems not related to the page/string translation status: the 0% +>>> translated Spanish version has the correct link, just like the +>>> Dansk version => I'm changing the bug title accordingly. +>>> +>>> I tested forcing the sv html page to be rebuilt by translating a +>>> string in it, it did not fix the bug. I did the same for the +>>> Spanish page, it did not introduce the bug. So this is really +>>> weird. +>>> +>>> The smiley underlay seems to be the only place where the wrong +>>> thing happens: the basewiki underlay has similar examples +>>> that do not exhibit this bug. An underlay linking to another might +>>> be necessary to reproduce it. Going to dig deeper. --[[intrigeri]] + +>>>> After a few hours lost in the Perl debugger, I think I have found +>>>> the root cause of the problem: in l10n wiki's configured +>>>> `underlaydir`, the basewiki is present in every slave language +>>>> that is enabled for this wiki *but* Swedish. With such a +>>>> configuration, the `ikiwiki/wikilink` page indeed does not exist +>>>> in Swedish language: no `ikiwiki/wikilink.sv.po` can be found +>>>> where ikiwiki is looking. Have a look to +>>>> <http://l10n.ikiwiki.info/ikiwiki/>, the basewiki is not +>>>> available in Swedish language on this wiki. So this is not a po +>>>> bug, but a configuration or directories layout issue. This is +>>>> solved by adding the Swedish basewiki to the underlay dir, which +>>>> is I guess not a possibility in the l10n wiki context. I guess +>>>> this could be solved by adding `SRCDIR/basewiki` as an underlay +>>>> to your l10n wiki configuration, possibly using the +>>>> `add_underlays` configuration directive. --[[intrigeri]] + +>>>>> There is no complete Swedish underlay translation yet, so it is not +>>>>> shipped in ikiwiki. I don't think it's a misconfiguration to use +>>>>> a language that doesn't have translated underlays. --[[Joey]] + +>>>>>> Ok. The problem is triggered when using a language that doesn't +>>>>>> have translated underlays, *and* defining +>>>>>> `po_translatable_pages` in a way that renders the base wiki +>>>>>> pages translatable in po's view of things, which in turns makes +>>>>>> the po plugin act as if the translation pages did exist, +>>>>>> although they do not in this case. I still need to have a deep +>>>>>> look at the underlays-related code you added to `po.pm` a while +>>>>>> ago. Stay tuned. --[[intrigeri]] + +>>>>>>> Fixed in my po branch, along with other related small bugs that +>>>>>>> happen in the very same situation only. --[[intrigeri]] + +>>>>>>>> Merged. Not tested yet, but I trust you; [[done]] --[[Joey]] diff --git a/doc/bugs/rename_fixup_not_attributed_to_author.mdwn b/doc/bugs/rename_fixup_not_attributed_to_author.mdwn new file mode 100644 index 000000000..bcfafac22 --- /dev/null +++ b/doc/bugs/rename_fixup_not_attributed_to_author.mdwn @@ -0,0 +1,12 @@ +When I renamed `todo/transient_in-memory_pages` to [[todo/transient pages]], +`rename::fixlinks` was meant to blame me for the link-fixing commit, and title it +`update for rename of %s to %s`. Instead, it blamed Joey for the commit, +and didn't set a commit message. + +(It also committed a pile of recentchanges pages which shouldn't have +been committed, for which see [[bugs/git_commit_adds_files_that_were_not_tracked]].) + +--[[smcv]] + +> It was calling `rcs_commit` old-style, and so not passing the session +> object that is used to get the user's name. [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields.mdwn b/doc/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields.mdwn index 48c168997..0a435cea3 100644 --- a/doc/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields.mdwn +++ b/doc/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields.mdwn @@ -34,3 +34,19 @@ For Atom, at least, I believe adding `type="xhtml"` to the title element will wo > Update: Ok, I've fixed this for titles, as a special case, but the > underlying problem remains for other fields in rss feeds (such as > author), so I'm leaving this bug report open. --[[Joey]] + +>> I'm curious if there has been any progress on better RSS output? +>> I've been prototyping a new blog and getting good RSS out of it +>> seems important as the bulk of my current readers use RSS. +>> I note, in passing that the "more" plugin doesn't quite do what +>> I want either - I'd like to pass a full RSS feed of a post and only +>> have "more" apply to the front page of the blog. Is there a way to do that? +>> -- [[dtaht]] +>> +>>> To be clear, the RSS spec sucks to such an extent that, as far as +>>> I know, there is no sort of title escaping that will work in all +>>> RSS consumers. Titles are currently escaped in the way +>>> that tends to break the fewest according to what I've read. +>>> If you're unlucky enough to +>>> have a "&" or "<" in your **name**, then you may still run into +>>> problems with how that is escaped in rss feeds. --[[Joey]] diff --git a/doc/bugs/rst_fails_on_file_containing_only_a_number.mdwn b/doc/bugs/rst_fails_on_file_containing_only_a_number.mdwn index dab3b7e5b..99e46aac9 100644 --- a/doc/bugs/rst_fails_on_file_containing_only_a_number.mdwn +++ b/doc/bugs/rst_fails_on_file_containing_only_a_number.mdwn @@ -24,3 +24,6 @@ throwing code..): > No, still the same failure. I think it's failing parsing the input data, > (which perl probably transmitted as an int due to perl internals) > not writing out its response. --[[Joey]] + +> On second thought, this was a bug in ikiwiki, it should be transmitting +> that as a string. Fixed in external.pm --[[Joey]] diff --git a/doc/bugs/web_reversion_on_ikiwiki.info.mdwn b/doc/bugs/web_reversion_on_ikiwiki.info.mdwn new file mode 100644 index 000000000..6f18cfcba --- /dev/null +++ b/doc/bugs/web_reversion_on_ikiwiki.info.mdwn @@ -0,0 +1,14 @@ +I created [[sandbox/revert me]] and then tried the revert button on +[[recentchanges]], but I was not allowed to revert it. The specific error +was + + Error: you are not allowed to change sandbox/revert_me.mdwn + +I've just tried reading through the revert code, and I haven't figured out +what permission I am lacking. Perhaps the error message could be a little +clearer on that. The error might have been thrown by git_parse_changes in +git.pm or check_canchange in IkiWiki.pm, via IkiWiki::Receive. -- Jon + +[[fixed|done]] --[[Joey]] + +: Brilliant, many thanks. -- [[Jon]] diff --git a/doc/css.mdwn b/doc/css.mdwn index 35db57b0c..bc070cb99 100644 --- a/doc/css.mdwn +++ b/doc/css.mdwn @@ -9,7 +9,7 @@ defining brand new rendering rules. While ikiwiki's default use of stylesheets is intentionally quite plain and minimalistic, CSS allows creating any kind of look you can dream up. -The [[theme_plugin|plugins/theme]] provides some prepackaged themes in an +The [[theme_plugin|plugins/theme]] provides some prepackaged [[themes]] in an easy to use way. The [[css_market]] page is an attempt to collect user contributed local.css diff --git a/doc/css_market.mdwn b/doc/css_market.mdwn index 0e5a68740..1838b2f60 100644 --- a/doc/css_market.mdwn +++ b/doc/css_market.mdwn @@ -4,9 +4,11 @@ User contributed stylesheet files for ikiwiki. Unless otherwise noted, these style sheets can be installed by copying them into your wiki's source dir with a filename of `local.css`. +Some of stylesheets have developed into fullfledged [[themes]] that are +included in ikiwiki for easy use. + Feel free to add your own stylesheets here. (Upload as wiki pages; wiki -gnomes will convert them to css files..) Selected ones from here are -included in the [[theme_plugin|plugins/theme]]. +gnomes will convert them to css files..) * **[[css_market/zack.css]]**, contributed by [[StefanoZacchiroli]], customized mostly for *blogging purposes*, can be seen in action on @@ -46,15 +48,11 @@ included in the [[theme_plugin|plugins/theme]]. * **[contraste.css][4]**, contributed by [[Blanko]]. Can be seen on [Contraste Demo][5]. Local.css and templates available [here][6]. -* **[[css_market/actiontabs.css]]**, contributed by [[svend]]. This style sheet displays - the action list (Edit, RecentChanges, etc.) as tabs. - [[!meta stylesheet="actiontabs"]] - * **[wiki.css](http://cyborginstitute.net/includes/wiki.css)** by [[tychoish]]. I typically throw this in as `local.css` in new wikis as a slightly more clear and readable layout for wikis that need to be functional and elegant, but not necessarily uniquely designed. Currently in use by the [the outeralliance wiki](http://oa.criticalfutures.com/). - + If your web browser allows selecting between multiple stylesheets, this page can be viewed using many of the stylesheets above. For example, if diff --git a/doc/css_market/actiontabs.css b/doc/css_market/actiontabs.css deleted file mode 100644 index a1dc47e92..000000000 --- a/doc/css_market/actiontabs.css +++ /dev/null @@ -1,122 +0,0 @@ -/* ikiwiki local style sheet */ - -/* Add local styling here, instead of modifying style.css. */ - -a { - text-decoration: none; - color: #005a9c; -} - -a:hover { - text-decoration: underline; -} - - -hr { - border-style: none; - background-color: #999; - height: 1px; -} - -code, pre { - background: #eee; -} - -pre { - padding: .5em; -} - -body { - margin: 0; - padding: 0; - font-family: sans-serif; - color: black; - background: white; -} - -.pageheader { - margin: 0; - padding: 1em 2em 0 2em; - background: #eee; - border-color: #999; - border-style: none none solid none; - border-width: 1px; -} - -.header { - font-size: 100%; - font-weight: normal; -} - -.title { - display: block; - margin-top: .2em; - font: 140% sans-serif; - text-transform: capitalize; -} - -.actions { - text-align: right; - padding: 0; -} - -#content, #comments, #footer { - margin: 1em 2em; -} - -#pageinfo { - border-color: #999; -} - -.inlinepage { - margin: .4em 0; - padding: .4em 0; - border-style: none; - border-top: 1px solid #aaa; -} - -.inlineheader { - font-size: 120%; - font-weight: normal; -} - -h1 { font: 120% sans-serif } -h2 { font: bold 100% sans-serif } -h3 { font: italic 100% sans-serif } -h4, h5, h6 { font: small-caps 100% sans-serif } - -/* Smaller headings for inline pages */ -.inlinepage h1 { font-size: 110% } -.inlinepage h2 { font-size: 100% } -.inlinepage h3 { font-size: 100% } - -.pageheader .actions ul { - border-style: none -} - -.actions ul { - font-size: 75%; - padding: 0; - border-style: none; -} - -.actions ul li a { - text-decoration: none; -} - -.actions ul li { - margin: 0; - padding: .1em .5em 0 .5em; - background: white; - border-color: #999; - border-style: solid solid none solid; - border-width: 1px; -} - -div.recentchanges { - border-style: none; -} - -.pagecloud { - width: auto; -} diff --git a/doc/examples/blog.mdwn b/doc/examples/blog.mdwn index b25601227..5f8f6c3ce 100644 --- a/doc/examples/blog.mdwn +++ b/doc/examples/blog.mdwn @@ -10,8 +10,8 @@ Some additional configuration you might want to do, if not using * Make sure to configure ikiwiki to generate RSS or Atom feeds. -* Make sure you have the tag plugin enabled, and the `tagbase` set to - "tags". Tag pages will then automatically be created. +* Make sure you have the [[tag|plugins/tag]] plugin enabled, and the + `tagbase` set to "tags". Tag pages will then automatically be created. An example of how to tag a post is: \[[!tag life]] diff --git a/doc/features.mdwn b/doc/features.mdwn index 1f8168703..0dbdba5df 100644 --- a/doc/features.mdwn +++ b/doc/features.mdwn @@ -77,6 +77,8 @@ Ikiwiki aims to produce Ikiwiki generates html using [[templates]], and uses [[css]], so you can change the look and layout of all pages in any way you would like. +Ikiwiki ships with several ready to use [[themes]]. + ## [[Plugins]] Plugins can be used to add additional features to ikiwiki. The interface is diff --git a/doc/forum/404_-_not_found.mdwn b/doc/forum/404_-_not_found.mdwn new file mode 100644 index 000000000..dc3318901 --- /dev/null +++ b/doc/forum/404_-_not_found.mdwn @@ -0,0 +1,22 @@ +Hi, + +I've followed the tutorial to install ikiwiki. Once installed (on a Ubuntu +10.04 distro running under VirtualBox on a Windows XP, SP3 host), I can +access the **http://ubuntu1004/index.lighttpd.html** page without any +issues. + +But when I try to access the page **http://ubuntu1004/~geertvc/gwiki** (as +is mentioned at the end of the ikiwiki setup), I get the error message +"**404 - not found**". + +I've also followed the "dot-cgi" trick, but with the same negative result. +The web server I've installed, is lighttpd. + +What did I miss? + +Best rgds, + +--Geert + +> Perhaps your webserver is not exporting your `public_html` directory +> in `~geertvc`? Check its configuration. --[[Joey]] diff --git a/doc/forum/404_-_not_found/comment_1_3dea2600474f77fb986767da4d507d62._comment b/doc/forum/404_-_not_found/comment_1_3dea2600474f77fb986767da4d507d62._comment new file mode 100644 index 000000000..453419cf3 --- /dev/null +++ b/doc/forum/404_-_not_found/comment_1_3dea2600474f77fb986767da4d507d62._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://jmtd.livejournal.com/" + ip="188.222.50.68" + subject="comment 1" + date="2010-09-09T21:41:07Z" + content=""" +You probably need to run \"lighttpd-enable-mod userdir\" +"""]] diff --git a/doc/forum/404_-_not_found/comment_2_948e4678be6f82d9b541132405351a2c._comment b/doc/forum/404_-_not_found/comment_2_948e4678be6f82d9b541132405351a2c._comment new file mode 100644 index 000000000..c3fb72db5 --- /dev/null +++ b/doc/forum/404_-_not_found/comment_2_948e4678be6f82d9b541132405351a2c._comment @@ -0,0 +1,31 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawllEHb4oGNaUrl7vyziQGrxAlQFri_BfaE" + nickname="Geert" + subject="comment 2" + date="2010-09-12T06:45:27Z" + content=""" +After a re-installation of ikiwiki (first removed all old files), I get the following feedback: + + Successfully set up gwiki: + url: http://ubuntu1004/~geertvc/gwiki + srcdir: ~/gwiki + destdir: ~/public_html/gwiki + repository: ~/gwiki.git + To modify settings, edit ~/gwiki.setup and then run: + ikiwiki -setup ~/gwiki.setup + + +In the lighttpd config file (/etc/lighttpd/lighttpd.conf), I've now changed the item \"server.document-root\" from the default \"/var/www\" to (in my case) \"/home/geertvc/public_html/gwiki\". I've taken the destdir location (see above) as document root for lighttpd. + +When doing this, I can see the \"index.html\" page of ikiwiki (by typing the following URL in the address box of the browser: \"ubuntu1004/index.html\"). So, that seems to be the right modification, right? Or isn't it? + +Note: when I take the directory \"/home/geertvc/gwiki\" (= the URL given above), then things do not work. I can't see the content of \"index.html\", I get the error message I mentioned in my initial post (404 - not found). + +But when clicking, for instance, the \"Edit\" button, the link brings me to the following location: + + http://ubuntu1004/~geertvc/gwiki/ikiwiki.cgi?page=index&do=edit + +However, there's not at all a file called \"ikiwiki.cgi\" at that location. The location of the file \"ikiwiki.cgi\" is \"/home/geertvc/public_html/gwiki\", so why is the link \"Edit\" leading me to that (wrong?) location? + +Apparently, something is still wrong with my settings. Hope, with the above information, someone can put me on the right track... +"""]] diff --git a/doc/forum/404_-_not_found/comment_3_4c7b1fa88776815bbc6aa286606214c2._comment b/doc/forum/404_-_not_found/comment_3_4c7b1fa88776815bbc6aa286606214c2._comment new file mode 100644 index 000000000..9f606f04e --- /dev/null +++ b/doc/forum/404_-_not_found/comment_3_4c7b1fa88776815bbc6aa286606214c2._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://jmtd.livejournal.com/" + ip="78.105.191.131" + subject="Follow instructions" + date="2010-09-12T12:26:49Z" + content=""" +Please re-read my comment. If you enable usersdirs then /~user corresponds to ~/public_html. The change you have made has / corresponding instead, which is why the links don't work. +"""]] diff --git a/doc/forum/Asciidoc_plugin.mdwn b/doc/forum/Asciidoc_plugin.mdwn new file mode 100644 index 000000000..57d6fd91e --- /dev/null +++ b/doc/forum/Asciidoc_plugin.mdwn @@ -0,0 +1,14 @@ +I have completely overhauled the Asciidoc plugin for ikiwiki that was created by [[Karl Mowson|http://www.mowson.org/karl/colophon/]]. The source can be downloaded from my [[Dropbox|http://dl.dropbox.com/u/11256359/asciidoc.pm]]. + +### Features + +* Uses a filter hook to escape WikiLinks and Directives using Asciidoc `+++` passthrough macros, to avoid them being processed by Asciidoc. This behavior is configurable in the wiki setup file. +* Adds a preprocessor directive 'asciidoc' which allows extra Asciidoc command-line options to be passed on a per-page basis. Each parameter name is the option name (the leading `--` will be inserted automatically), and the parameter value is the option value. Currently, only 'conf-file' and 'doctype' are allowed (or even useful). +* Sets the page title from the first line in the Asciidoc file using a meta directive. This behavior is configurable in the wiki setup file. +* Searches for an Asciidoc configuration file named the same as the wiki if none is specified in the setup file. +* Asciidoc configuration files are stored in the wiki. They should be named `._conf` to avoid publishing them. + +### Problems + +* Escaping Directives is not optimal. It prevents markup from being used in Directives, and the passthrough macros have to include extra spaces to avoid having directives that return an empty string collapse to `++++++`. In addition, I had to borrow the regexps from the Ikiwiki source code; it would be nice if this were available as part of the API. +* Handling of Asciidoc errors is suboptimal; they are simply inserted into the returned page. This could be fixed in Perl 5.12 by using the run_forked() in IPC::Cmd. diff --git a/doc/forum/Blog_posting_times_and_ikiwiki_state.mdwn b/doc/forum/Blog_posting_times_and_ikiwiki_state.mdwn new file mode 100644 index 000000000..0c1da5b97 --- /dev/null +++ b/doc/forum/Blog_posting_times_and_ikiwiki_state.mdwn @@ -0,0 +1,28 @@ +What I wanted +------------- + +I thought to myself it would be nice to see from the console the dates that my ikiwiki blog posts were published. Especially as I would like to know the order of my todo list without having to view the webpage. + +What I discovered +----------------- + +Looked at the code and saw the functions for grabbing the ctime from git but couldn't reconcile them to the "Posted" date in the RSS feed. Some more reading and I figured out that the Posted time is taken from the UNIX ctime when first uploaded into the repository and this information is stored in the page state via a Perl storable database - indexdb. (I'm sure most know this but to be clear in UNIX ctime is *not* the actual creation time of a file. UNIX has no facility for recording the actual creation time - however on first upload to the wiki it's good enough). + +Wrote a Perl script to query and sort indexdb. Now I can list my todos or blog posts in the order they appear on the web. Handy. + +However the ikiwiki state is specifically excluded via '.gitignore'. I work a lot on trains and not having this file in my cloned wiki means I can't list published posts or my todos in the proper order. I can get an approximation from git logs but, dam it, I want it the same! + +What can I do? +-------------- + +Is it a spectacularly bad idea to include the ikiwiki state file in my cloned repo (I suspect it is). What else could be done? Can I disable pagestate somehow or force ikiwiki to always use git commit times for Posted times? + +> Have you tried running ikiwiki with the `--gettime` option on your laptop, +> to force it to retrieve initial commit times from git? You should only +> need to do that once, and it'll be cached in the pagestate thereafter. +> +> Because that functionality is slow on every supported VCS except git, +> ikiwiki tries to avoid using it unless it's really needed. [[rcs]] +> lists it as "fast" for git, though, so depending how fast it really is +> and how large your wiki is, you might be able to get away with running +> ikiwiki with `--gettime` all the time? --[[smcv]] diff --git a/doc/forum/Blog_posting_times_and_ikiwiki_state/comment_1_87304dfa2caea7e526cdb04917524e8c._comment b/doc/forum/Blog_posting_times_and_ikiwiki_state/comment_1_87304dfa2caea7e526cdb04917524e8c._comment new file mode 100644 index 000000000..62bae02b0 --- /dev/null +++ b/doc/forum/Blog_posting_times_and_ikiwiki_state/comment_1_87304dfa2caea7e526cdb04917524e8c._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmwYptyV5ptNt8LCbMYsmpcNkk9_DRt-EY" + nickname="Matt" + subject="comment 1" + date="2010-11-04T11:52:53Z" + content=""" +Perhaps I have a different setup from you but on my laptop I don't have ikiwiki installed - only a clone of the git repo. You mean to run --gettime on the post-update git hook? +"""]] diff --git a/doc/forum/Can__39__t_get_comments_plugin_working.mdwn b/doc/forum/Can__39__t_get_comments_plugin_working.mdwn index 06b7fdd84..f189d9b64 100644 --- a/doc/forum/Can__39__t_get_comments_plugin_working.mdwn +++ b/doc/forum/Can__39__t_get_comments_plugin_working.mdwn @@ -1,7 +1,16 @@ I feel like I must be missing something. -My blog is based on Ikiwiki, and uses /yyyy/mm/dd/title/ for blog posts. Because I use the plugin that generates index pages for subdirectories, I have to use /????/??/??/* to identify posts and avoid missing the index pages for years, months and days. +My blog is based on Ikiwiki, and uses /yyyy/mm/dd/title/ for blog posts. +Because I use the plugin that generates index pages for subdirectories, I +have to use /????/??/??/* to identify posts and avoid missing the index +pages for years, months and days. I've enabled the comments plugin, but no matter what I do, I can't seem to make the comment form appear on my posts. I've removed the entire site and have rebuilt. I've set the pagespec to /????/??/??/* and ./????/??/??/*, but neither seems to work. I don't see any output, or anything else to indicate that pages aren't working. Are there any other plugins that need to be enabled for this to work? I think I've locked things down such that anonymous users can't edit by enabling signinedit and setting a lock, but this may be blocking the ability to comment (though I don't recall seeing anything in the docs about needing additional plugins.) + +> Just use '????/??/??/*' , and it will work. +> [[Pagespecs|ikiwiki/pagespec]] are automatically matched absolute to the +> top of the site, and adding a leading "/" is not necessary and will +> make the PageSpec not match. (And the relative PageSpec with "./" is +> not right in this case either). --[[Joey]] diff --git a/doc/forum/Different_templates_for_subdirectories__63_____40__Blogging_and_Wiki_pages__41__.mdwn b/doc/forum/Different_templates_for_subdirectories__63_____40__Blogging_and_Wiki_pages__41__.mdwn new file mode 100644 index 000000000..8d6700651 --- /dev/null +++ b/doc/forum/Different_templates_for_subdirectories__63_____40__Blogging_and_Wiki_pages__41__.mdwn @@ -0,0 +1,7 @@ +I have been mucking about with ikiwiki for two whole days now. + +I like many things about it. Even though I've been spending most of my time wrestling with css I did manage to write a whole lot of blog posts and love what ikiwiki is doing for the "revise" part of my writing cycle. And I like the idea of integrating the wiki and the blog into one unifying architecture.... + +But... I would like very much to have different page templates for blogging and wiki-ing, some way of specifying that for stuff in the "/posts" directory I'd rather use blogpost.tmpl rather than page.tmpl. I just spent a few minutes looking at the perl for this (I assume Render.pm) and my mind dumped core... + +(generically, some way to specify output formatting on a subdirectory basis would be good) diff --git a/doc/forum/Different_templates_for_subdirectories__63_____40__Blogging_and_Wiki_pages__41__/comment_1_15651796492a6f04a19f4a481947c97c._comment b/doc/forum/Different_templates_for_subdirectories__63_____40__Blogging_and_Wiki_pages__41__/comment_1_15651796492a6f04a19f4a481947c97c._comment new file mode 100644 index 000000000..e92f4107d --- /dev/null +++ b/doc/forum/Different_templates_for_subdirectories__63_____40__Blogging_and_Wiki_pages__41__/comment_1_15651796492a6f04a19f4a481947c97c._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawlY5yDefnXSHvWGbJ9kvhnAyQZiAAttENk" + nickname="Javier" + subject="comment 1" + date="2010-10-21T15:00:50Z" + content=""" +You can do what you want with the [[ikiwiki/directive/pagetemplate]] directive, but in a slightly cumbersome way, because you have to say what template you want in every page that differs from the default. + +See also: [[templates]] + +And, a perhaps more proper solution to your problem, although I don't fully understand the way of tackling it, in [[todo/multiple_template_directories]]. + +If you could create a proper page in this wiki, centralizing all the knowledge dispersed in those pages, it would be nice ;) + +--[[jerojasro]] +"""]] diff --git a/doc/forum/Discussion_PageSpec__63__.mdwn b/doc/forum/Discussion_PageSpec__63__.mdwn new file mode 100644 index 000000000..2860d0d17 --- /dev/null +++ b/doc/forum/Discussion_PageSpec__63__.mdwn @@ -0,0 +1,3 @@ +I've looked around but haven't found it. Can you set a Discussion PageSpec so only certain pages allow discussion? + +> Not currently, sorry. --[[Joey]] diff --git a/doc/forum/Dump_plugin.mdwn b/doc/forum/Dump_plugin.mdwn new file mode 100644 index 000000000..ff3bfea90 --- /dev/null +++ b/doc/forum/Dump_plugin.mdwn @@ -0,0 +1,4 @@ +I have a second plugin that adds a directive 'dump', and dumps all sorts of information (env variables and template variables) about a page into the end of the page. It's cheesy, but it's available in my [[Dropbox|http://dl.dropbox.com/u/11256359/dump.pm]] as well as the Asciidoc plugin. + +### Issues +* It really ought to use some kind of template instead of HTML. In fact, it ought to embed its information in template variables of some kind rather than stuffing it into the end of the page. diff --git a/doc/forum/Dump_plugin/comment_1_bfce80b3f5be78ec28692330843d4ae1._comment b/doc/forum/Dump_plugin/comment_1_bfce80b3f5be78ec28692330843d4ae1._comment new file mode 100644 index 000000000..855b72bbb --- /dev/null +++ b/doc/forum/Dump_plugin/comment_1_bfce80b3f5be78ec28692330843d4ae1._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawngqGADV9fidHK5qabIzKN0bx1ZIfvaTqs" + nickname="Glenn" + subject="New dump plugin" + date="2010-10-03T00:45:47Z" + content=""" +I took my own advice and rewrote the dump plugin so that it uses a template. A sample template has been added to my [[Dropbox|http://dl.dropbox.com/u/11256359/dump.tmpl]]. + +### Issues: + +* Dumps appear at the end of the page rather than where the directive occurs. +* For some reason I haven't yet figured out, dumps don't appear in page previews. +* I haven't tested inlined content and the dump plugin. +"""]] diff --git a/doc/forum/Forward_slashes_being_escaped_as_252F.mdwn b/doc/forum/Forward_slashes_being_escaped_as_252F.mdwn new file mode 100644 index 000000000..5df81e561 --- /dev/null +++ b/doc/forum/Forward_slashes_being_escaped_as_252F.mdwn @@ -0,0 +1,33 @@ +When I try to edit a page that has a forward slash in the URL, I get "Error: +bad page name". I think the problem is because the forward slash is escaped as +`%252F` instead of `%2F`. + +For example, if I go to `http://ciffer.net/~svend/tech/hosts/` and click Edit, +I am sent to a page with the URL +`http://ciffer.net/~svend/ikiwiki.cgi?page=tech%252Fhosts&do=edit`. + +I am running ikiwiki 3.20100504~bpo50+1 on Debian Lenny. + + +> But on your page, the Edit link is escaped normally and correctly (using %2F). +> Look at the page source! +> +> The problem is that your web server is forcing a hard (302) redirect +> to the doubly-escaped url. In wireshark I see your web server send back: + + HTTP/1.1 302 Found\r\n + Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch + Location: http://ciffer.net/~svend/ikiwiki.cgi?page=tech%252Fhosts&do=edit + +> You'll need to investigate why your web server is doing that... --[[Joey]] + +>> Thanks for pointing me in the right direction. I have the following redirect +>> in my Apache config. + + RewriteEngine on + RewriteCond %{HTTP_HOST} ^www\.ciffer\.net$ + RewriteRule /(.*) http://ciffer.net/$1 [L,R] + +>> and my ikiwiki url setting contained `www.ciffer.net`, which was causing the +>> redirect. Correcting the url fixed the problem. I'm still not sure why +>> Apache was mangling the URL. --[[Svend]] diff --git a/doc/forum/How_to_list_new_pages__44___inline__63__.mdwn b/doc/forum/How_to_list_new_pages__44___inline__63__.mdwn new file mode 100644 index 000000000..f28e8b99b --- /dev/null +++ b/doc/forum/How_to_list_new_pages__44___inline__63__.mdwn @@ -0,0 +1,5 @@ +Hi, I'd love to include a "New posts" list into my front page, like at <http://danhixon.github.com/> for example. + +It should be different from recent changes in that it shouldn't show modifications of existing pages, and in that it would be inside a page with other content. + +Thanks, Thomas diff --git a/doc/forum/How_to_list_new_pages__44___inline__63__/comment_1_e989b18bade34a92a9c8fe7099036e15._comment b/doc/forum/How_to_list_new_pages__44___inline__63__/comment_1_e989b18bade34a92a9c8fe7099036e15._comment new file mode 100644 index 000000000..cf6f642d4 --- /dev/null +++ b/doc/forum/How_to_list_new_pages__44___inline__63__/comment_1_e989b18bade34a92a9c8fe7099036e15._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="http://joey.kitenet.net/" + nickname="joey" + subject="use an inline directive" + date="2010-11-29T20:39:37Z" + content=""" +This is what the [[ikiwiki/directive/inline]] directive is for. It's often used, to for example, show new posts to a blog. If you want to show new posts to anywhere in your site, or whatever, you can configure the [[ikiwiki/PageSpec]] in it to do that, too. + +For example, you could use this: + + The most recent 3 pages added to this site: + \[[!inline pages=\"*\" archive=yes show=4]] +"""]] diff --git a/doc/forum/Map_Plugin__44___would_like_to_add___63__updated_to_all_links.mdwn b/doc/forum/Map_Plugin__44___would_like_to_add___63__updated_to_all_links.mdwn new file mode 100644 index 000000000..fcffe690f --- /dev/null +++ b/doc/forum/Map_Plugin__44___would_like_to_add___63__updated_to_all_links.mdwn @@ -0,0 +1,3 @@ +Map Plugin, would like to add ?updated to all links created. + +When I edit a page and then click that page in a map in a sidebar Safari always shows me a cached page. diff --git a/doc/forum/Map_Plugin__44___would_like_to_add___63__updated_to_all_links/comment_1_3fe4c5967e704355f9b594aed46baf67._comment b/doc/forum/Map_Plugin__44___would_like_to_add___63__updated_to_all_links/comment_1_3fe4c5967e704355f9b594aed46baf67._comment new file mode 100644 index 000000000..ce1a78584 --- /dev/null +++ b/doc/forum/Map_Plugin__44___would_like_to_add___63__updated_to_all_links/comment_1_3fe4c5967e704355f9b594aed46baf67._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="justint" + ip="24.182.207.250" + subject="skip it" + date="2010-10-13T05:30:50Z" + content=""" +skip it, I added + + <meta http-equiv=\"expires\" value=\"Thu, 16 Mar 2000 11:00:00 GMT\" /> + <meta http-equiv=\"pragma\" content=\"no-cache\" /> + +to my page.tmpl and the problem went away. +"""]] diff --git a/doc/forum/Moving_wiki.git_folder__63__.mdwn b/doc/forum/Moving_wiki.git_folder__63__.mdwn new file mode 100644 index 000000000..77d1da1ee --- /dev/null +++ b/doc/forum/Moving_wiki.git_folder__63__.mdwn @@ -0,0 +1,17 @@ +Hi folks, I created a simple wiki to keep notes and references for projects, it's worked quite nice so far. I decided to use git as it's what I use daily to manage code, and it's available on all my machines. + +Anyway, I wanted to move all the wiki source stuff into a subfolder so that it stops cluttering up my ~ directory. However, there seems to be a problem with moving wiki.git (I moved wiki, wiki.git and wiki.setup) and I'm not sure where to tell ikiwiki that the git directory has been moved. I changed + + srcdir => '/home/pixel/.notebook/wiki', + git_wrapper => '/home/pixel/.notebook/wiki.git/hooks/post-update', + +and that seems to be fine. However when I go to run ikiwiki --setup things go wrong: + + pixel@tosh: [~ (ruby-1.9.2-p0)] ➔ ikiwiki -setup .notebook/wiki.setup + successfully generated /home/pixel/public_html/wiki/ikiwiki.cgi + successfully generated /home/pixel/.notebook/wiki.git/hooks/post-update + fatal: '/home/pixel/wiki.git' does not appear to be a git repository + fatal: The remote end hung up unexpectedly + 'git pull origin' failed: at /usr/share/perl5/IkiWiki/Plugin/git.pm line 193. + +I've gone through wiki.setup and nothing has jumped out as the place to set this, have I missed something? diff --git a/doc/forum/Moving_wiki.git_folder__63__/comment_1_05238461520613f4ed1b0d02ece663bd._comment b/doc/forum/Moving_wiki.git_folder__63__/comment_1_05238461520613f4ed1b0d02ece663bd._comment new file mode 100644 index 000000000..d654591c0 --- /dev/null +++ b/doc/forum/Moving_wiki.git_folder__63__/comment_1_05238461520613f4ed1b0d02ece663bd._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="http://users.itk.ppke.hu/~cstamas/openid/" + ip="212.183.140.47" + subject="comment 1" + date="2010-10-27T22:45:28Z" + content=""" +I think you want to edit + + .git/config + +"""]] diff --git a/doc/forum/Moving_wiki.git_folder__63__/comment_2_72b2b842dfa0cfaf899fe7af12977519._comment b/doc/forum/Moving_wiki.git_folder__63__/comment_2_72b2b842dfa0cfaf899fe7af12977519._comment new file mode 100644 index 000000000..f2e7ece18 --- /dev/null +++ b/doc/forum/Moving_wiki.git_folder__63__/comment_2_72b2b842dfa0cfaf899fe7af12977519._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://pixel.dreamwidth.org/" + ip="65.29.14.21" + subject="comment 2" + date="2010-10-28T02:54:15Z" + content=""" +That did it thanks! + +Should I make some sort of edit in the setup page? I've used git for a while and for whatever reason it never occurred to me that this was from git, not from ikiwiki itself. +"""]] diff --git a/doc/forum/Need_something_more_powerful_than_Exclude.mdwn b/doc/forum/Need_something_more_powerful_than_Exclude.mdwn new file mode 100644 index 000000000..5e8043258 --- /dev/null +++ b/doc/forum/Need_something_more_powerful_than_Exclude.mdwn @@ -0,0 +1,5 @@ +When I originally looked at the "exclude" option, I thought it meant that it excluded pages completely, but it apparently doesn't. What I've found in practice is that a file which matches the "exclude" regex is excluded from *processing*, but it is still copied over to the destination directory. Thus, for example, if I have "^Makefile$" as the exclude pattern, and I have a file `src/foo/Makefile`, then that file is copied unaltered into `dest/foo/Makefile`. However, what I want is for `src/foo/Makefile` to be completely ignored: that it is not only not processed, but not even *copied* into the destination directory. + +I'm not sure if the current behaviour is a bug or a feature, but I would like a "totally ignore this file" feature if it's possible to have one. + +-- [[KathrynAndersen]] diff --git a/doc/forum/Need_something_more_powerful_than_Exclude/comment_2_0019cd6b34c8d8678b2532de57a92d15._comment b/doc/forum/Need_something_more_powerful_than_Exclude/comment_2_0019cd6b34c8d8678b2532de57a92d15._comment new file mode 100644 index 000000000..7842caeac --- /dev/null +++ b/doc/forum/Need_something_more_powerful_than_Exclude/comment_2_0019cd6b34c8d8678b2532de57a92d15._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://smcv.pseudorandom.co.uk/" + nickname="smcv" + subject="expression anchored too closely?" + date="2010-11-23T10:43:21Z" + content=""" +It looks as though you might only be excluding a top-level Makefile, and not a Makefile in subdirectories. Try excluding `(^|/)Makefile$` instead, for instance? (See `wiki_file_prune_regexps` in `IkiWiki.pm` for hints.) + +The match operation in `&file_pruned` ends up a bit like this: + + \"foo/Makefile\" =~ m{…|…|…|(^|/)Makefile$} +"""]] diff --git a/doc/forum/Need_something_more_powerful_than_Exclude/comment_2_f577ab6beb9912471949d8d18c790267._comment b/doc/forum/Need_something_more_powerful_than_Exclude/comment_2_f577ab6beb9912471949d8d18c790267._comment new file mode 100644 index 000000000..bd964d540 --- /dev/null +++ b/doc/forum/Need_something_more_powerful_than_Exclude/comment_2_f577ab6beb9912471949d8d18c790267._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="http://kerravonsen.dreamwidth.org/" + ip="60.241.8.244" + subject="Missed It By That Much" + date="2010-11-25T02:55:20Z" + content=""" +I discovered that I not only needed to change the regexp, but I also needed to delete .ikiwiki/indexdb because `file_pruned` only gets called for files that aren't in the `%pagesources` hash, and since the file in question was already there because it had been put there before the exclude regex was changed, it wasn't even being checked! + +[[KathrynAndersen]] + +"""]] diff --git a/doc/forum/Need_something_more_powerful_than_Exclude/comment_3_1ed260b0083a290688425a006a83f603._comment b/doc/forum/Need_something_more_powerful_than_Exclude/comment_3_1ed260b0083a290688425a006a83f603._comment new file mode 100644 index 000000000..8b93acd79 --- /dev/null +++ b/doc/forum/Need_something_more_powerful_than_Exclude/comment_3_1ed260b0083a290688425a006a83f603._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joey.kitenet.net/" + nickname="joey" + subject="comment 3" + date="2010-11-29T20:41:49Z" + content=""" +`%pagesources` gets nuked when you rebuild the whole wiki with eg, ikiwiki -setup or ikiwiki -rebuild. So you shouldn't normally need to remove the indexdb, just rebuild when making this sort of change that affects the whole site. +"""]] diff --git a/doc/forum/Need_something_more_powerful_than_Exclude/comment_4_c39bdaf38e1e20db74eb26f0560bd673._comment b/doc/forum/Need_something_more_powerful_than_Exclude/comment_4_c39bdaf38e1e20db74eb26f0560bd673._comment new file mode 100644 index 000000000..15f1fecb8 --- /dev/null +++ b/doc/forum/Need_something_more_powerful_than_Exclude/comment_4_c39bdaf38e1e20db74eb26f0560bd673._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://kerravonsen.dreamwidth.org/" + ip="60.241.8.244" + subject="comment 4" + date="2010-11-30T02:35:43Z" + content=""" +One would think that would be the case, yes, but for some reason it didn't work for me. 8-( + +[[KathrynAndersen]] +"""]] diff --git a/doc/forum/PageSpec_results_from_independent_checkout.mdwn b/doc/forum/PageSpec_results_from_independent_checkout.mdwn new file mode 100644 index 000000000..693287d2b --- /dev/null +++ b/doc/forum/PageSpec_results_from_independent_checkout.mdwn @@ -0,0 +1,8 @@ +I'd like to be able to do PageSpec matches independent of the Ikiwiki checkout, but at best I'm currently restricted to copying over and using whatever is in the indexdb with this approach: + + perl -MIkiWiki -le '$config{wikistatedir}=".ikiwiki"; IkiWiki::loadindex(); print foreach pagespec_match_list("", shift)' "bugs/*" + +I get the impression there's a way to build up enough state to run pagespec matches without doing any rendering, but I don't know how. Any ideas? -- JoeRayhawk + +> It's not possible to build up enough state without at a minimum +> performing the scan pass of rendering on every page. --[[Joey]] diff --git a/doc/forum/cutpaste.pm_not_only_file-local.mdwn b/doc/forum/cutpaste.pm_not_only_file-local.mdwn index 3563e3e01..0c5221cc9 100644 --- a/doc/forum/cutpaste.pm_not_only_file-local.mdwn +++ b/doc/forum/cutpaste.pm_not_only_file-local.mdwn @@ -3,7 +3,7 @@ has \[[!cut id=foo text="foo"]], and fileB does \[[!absorb pagenames=fileA]], and can then use \[[!paste id=foo]]. Therefore, I've written an [*absorb* directive / -plugin](http://www.thomas.schwinge.homeip.net/tmp/absorb.pm), which is meant to +plugin](http://schwinge.homeip.net/~thomas/tmp/absorb.pm), which is meant to absorb pages in order to get hold of their *cut* and *copy* directives' contents. This does work as expected. But it also absorbs page fileA's *meta* values, like a *meta title*, etc. How to avoid / solve this? diff --git a/doc/forum/editing_a_comment.mdwn b/doc/forum/editing_a_comment.mdwn index 8bddab3fb..eb534365e 100644 --- a/doc/forum/editing_a_comment.mdwn +++ b/doc/forum/editing_a_comment.mdwn @@ -1 +1,11 @@ Is it possible to edit a comment? I did not find any button for it. + +> It was a design decision to not allow editing comments via the web +> interface. The thinking being that comments on blogs tend to not allow +> editing, and allowing wiki-style editing by anyone would sort of defeat +> the purpose of comments. +> +> I do think there is room to support more forum-style comments in ikiwiki. +> As long as the comment is not posted by an anonymous user, it would be +> possible to open up editing to the original commenter. One day, perhaps.. +> --[[Joey]] diff --git a/doc/forum/field_and_forms.mdwn b/doc/forum/field_and_forms.mdwn new file mode 100644 index 000000000..97fda1856 --- /dev/null +++ b/doc/forum/field_and_forms.mdwn @@ -0,0 +1,13 @@ +Dear ikiwiki users, and specially [[users/KathrynAndersen]] ([[users/rubykat]]): +have you considered some way of extending ikiwiki to allow some kind of +on-the-fly generation of web forms to create new pages? these web forms should +offer as many fields as one has defined in some [[page +template|plugins/contrib/ftemplate]], and, once POSTed, should create a page +using that template, with those fields already filled with the values the user +provided. + +I see this a a generalization of the `postform` option of the +[[ikiwiki/directive/inline]] directive. That option tells ikiwiki to create a +form with one field already filled (title). + +What are your ideas about this? diff --git a/doc/forum/field_and_forms/comment_1_a0e976cb79f03dcff5e9a4511b90d160._comment b/doc/forum/field_and_forms/comment_1_a0e976cb79f03dcff5e9a4511b90d160._comment new file mode 100644 index 000000000..3e10dbbd9 --- /dev/null +++ b/doc/forum/field_and_forms/comment_1_a0e976cb79f03dcff5e9a4511b90d160._comment @@ -0,0 +1,19 @@ +[[!comment format=mdwn + username="http://kerravonsen.dreamwidth.org/" + ip="60.241.8.244" + subject="Limitations" + date="2010-11-23T02:18:52Z" + content=""" +I'd already had a look at this idea before you posted this suggestion, and I ran into difficulties. +So far as I can see, it makes most sense to use the mechanisms already in place for editing pages, and enhance them. +Unfortunately, the whole edit-page setup expects a template file (by default, when editing pages, editpage.tmpl) +and anything apart from \"submit\" buttons must have a placeholder in the template file, or it doesn't get displayed at all in the form. +At least, that's what I've found - I could be mistaken. + +But if it's true, that rather puts the kybosh on dynamically generated forms, so far as I can see. +I mean, if you knew beforehand what all your fields were going to be, you could make a copy of editpage.tmpl, add in your fields where you want, and then make a plugin that uses that template instead of editpage.tmpl, but that's very limited. + +If someone could come up with a way of making dynamic forms, that would solve the problem, but I've come up against a brick wall myself. Joey? Anyone? + +-- [[KathrynAndersen]] +"""]] diff --git a/doc/forum/how_can_I_use___39____47____39___as_tagbase__63__.mdwn b/doc/forum/how_can_I_use___39____47____39___as_tagbase__63__.mdwn new file mode 100644 index 000000000..8a24152dc --- /dev/null +++ b/doc/forum/how_can_I_use___39____47____39___as_tagbase__63__.mdwn @@ -0,0 +1,13 @@ +I'd like tags to be top-level pages, like /some-tag. + +I achieve this most of the time by *not* defining `tagbase`. + +However, this goes wrong if the name of a tag matches the name of a page further down a tree. + +Example: + + * tag scm, corresponding page /scm + * a page /log/scm tagged 'scm' does not link to /scm + * a page /log/puppet tagged 'scm' links to /log/scm in the Tags: section + +Is this possible, or am I pushing tags too far (again)? -- [[Jon]] diff --git a/doc/forum/how_can_I_use___39____47____39___as_tagbase__63__/comment_1_e7897651ba8d9156526d36d6b7744eae._comment b/doc/forum/how_can_I_use___39____47____39___as_tagbase__63__/comment_1_e7897651ba8d9156526d36d6b7744eae._comment new file mode 100644 index 000000000..361c51b09 --- /dev/null +++ b/doc/forum/how_can_I_use___39____47____39___as_tagbase__63__/comment_1_e7897651ba8d9156526d36d6b7744eae._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joey.kitenet.net/" + nickname="joey" + subject="comment 1" + date="2010-12-05T20:15:28Z" + content=""" +From the code, it seems to me like setting tagbase to \"/\" would actually do what you want. Does it not work? +"""]] diff --git a/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn b/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn index 7686a7a08..d69b3801b 100644 --- a/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn +++ b/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn @@ -33,3 +33,14 @@ Puzzled a bit :-/ >>>> had its own history browser (somewhere down my todo list). --[[schmonz]] >>>> Yup, having a possibility to revert a single file would suffice. + +--- + +Perer Gammie and I are working on reversion over at [[todo/web_reversion]]. +--[[Joey]] + +Update: Web reversion is now supported by ikiwiki. Only changes committed +to your wiki after you upgrade to the version of ikiwiki that supports it +will get revert buttons on the RecentChanges page. If you want to force +adding buttons for older changes, you can delete `recentchanges/*._change` +from your srcdir, and rebuild the wiki. --[[Joey]] diff --git a/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__/comment_1_e4720e8e4fe74bd6cba746e8259832e6._comment b/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__/comment_1_e4720e8e4fe74bd6cba746e8259832e6._comment new file mode 100644 index 000000000..597cab2e4 --- /dev/null +++ b/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__/comment_1_e4720e8e4fe74bd6cba746e8259832e6._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmlZJCPogIE74m6GSCmkbJoMZiWNOlXcjI" + nickname="Ian" + subject="comment 1" + date="2010-09-24T19:01:08Z" + content=""" ++1 for a \"revert\" web plugin which at least handles the simple cases. -- Ian Osgood, The TOVA Company +"""]] diff --git a/doc/forum/ikiwiki_+_mathjax.mdwn b/doc/forum/ikiwiki_+_mathjax.mdwn new file mode 100644 index 000000000..1279a2c80 --- /dev/null +++ b/doc/forum/ikiwiki_+_mathjax.mdwn @@ -0,0 +1 @@ +Is it possible to use [mathjax](http://www.mathjax.org/) in ikiwiki to typeset math formulas? If so, is this compatible with the [wmd](http://ikiwiki.info/plugins/wmd/) plugin? diff --git a/doc/forum/ikiwiki_vim_integration.mdwn b/doc/forum/ikiwiki_vim_integration.mdwn new file mode 100644 index 000000000..4724807e8 --- /dev/null +++ b/doc/forum/ikiwiki_vim_integration.mdwn @@ -0,0 +1,17 @@ +Hi all. I upgraded the [ikiwiki-nav plugin](http://www.vim.org/scripts/script.php?script_id=2968) +so that now it supports: + + * Jumping to the file corresponding to the wikilink under the cursor. + * Creating the file corresponding to the wikilink under the cursor (including + directories if necessary.) + * Jumping to the previous/next wikilink in the current file. + * Autocomplete link names. + +Download it from [here](http://www.vim.org/scripts/script.php?script_id=2968) + +I've also created a new page unifying all the hints available here to use vim +with ikiwiki files, in [[tips/vim_and_ikiwiki]] + + +--[[jerojasro]] + diff --git a/doc/forum/link_autocompletion_in_vim.mdwn b/doc/forum/link_autocompletion_in_vim.mdwn index 7d3ed8b02..a46c7e4c1 100644 --- a/doc/forum/link_autocompletion_in_vim.mdwn +++ b/doc/forum/link_autocompletion_in_vim.mdwn @@ -1,5 +1,10 @@ +This page is deprecated. See [[tips/vim_and_ikiwiki]] for the most up to date +content. + +------ + I extended the functionality of the [ikiwiki-nav plugin](http://www.vim.org/scripts/script.php?script_id=2968) -(see [[here|tips/follow_wikilinks_from_inside_vim]]) to allow completion of +(see [[here|tips/vim_ikiwiki_ftplugin]]) to allow completion of wikilinks from inside vim, through the omnicompletion mechanism. It still has some bugs, but is usable, and will not destroy your data. It can diff --git a/doc/forum/recovering_original_title_with_meta_directive.mdwn b/doc/forum/recovering_original_title_with_meta_directive.mdwn new file mode 100644 index 000000000..ad0b02a9e --- /dev/null +++ b/doc/forum/recovering_original_title_with_meta_directive.mdwn @@ -0,0 +1 @@ +When using the \[[!meta title=""]] directive, the documentation states that a template variable is set when the title is overridden. However, how does one recover the original page title? --[[Glenn|geychaner@mac.com]] diff --git a/doc/forum/report_pagination.mdwn b/doc/forum/report_pagination.mdwn index d609fd502..03a77b16d 100644 --- a/doc/forum/report_pagination.mdwn +++ b/doc/forum/report_pagination.mdwn @@ -9,3 +9,10 @@ Approaches: 3. some other approach I haven't thought of. I'm afraid that whatever approach I take, it will end up being a kludge. + +> Well, it should be perfectly fine, and non-kludgy for a single page to +> generate multiple html files. Just make sure that html files have names +> that won't conflict with the html files generated by some other page. +> +> Of course the caveat is that since such files are not pages, you won't +> be able to use wikilinks to link directly to them, etc. --[[Joey]] diff --git a/doc/forum/using_l10n__39__d_basewiki.mdwn b/doc/forum/using_l10n__39__d_basewiki.mdwn new file mode 100644 index 000000000..a361d18c9 --- /dev/null +++ b/doc/forum/using_l10n__39__d_basewiki.mdwn @@ -0,0 +1,7 @@ +Hey there! + +I'm trying to get the translated version of basewiki activated in my wiki. Setting "locale => 'de_DE.UTF-8'" gave me some german messages on the CLI and a few changes in the wiki itself but the basewiki is still english. The files in /usr/share/ikiwiki/po/de/ are there. + +As I understand, [[plugins/po]] is just for translating. + +So, what am I doing wrong? diff --git a/doc/forum/using_l10n__39__d_basewiki/comment_1_eaab671848ee6129f6fe9399474eeac0._comment b/doc/forum/using_l10n__39__d_basewiki/comment_1_eaab671848ee6129f6fe9399474eeac0._comment new file mode 100644 index 000000000..1f21b485b --- /dev/null +++ b/doc/forum/using_l10n__39__d_basewiki/comment_1_eaab671848ee6129f6fe9399474eeac0._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joey.kitenet.net/" + nickname="joey" + subject="comment 1" + date="2010-12-05T20:12:17Z" + content=""" +The translated basewiki depends on the po plugin being enabled and configured with the language(s) to use. +"""]] diff --git a/doc/forum/using_l10n__39__d_basewiki/comment_2_d907676a1db1210ca59506673c564359._comment b/doc/forum/using_l10n__39__d_basewiki/comment_2_d907676a1db1210ca59506673c564359._comment new file mode 100644 index 000000000..c8d1e4e04 --- /dev/null +++ b/doc/forum/using_l10n__39__d_basewiki/comment_2_d907676a1db1210ca59506673c564359._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://xlogon.net/bacuh" + ip="93.182.190.4" + subject="comment 2" + date="2010-12-05T22:48:53Z" + content=""" +This works, thanks. + +But is there also a way to get \"Edit\" etc. and the buttons behind it translated? +"""]] diff --git a/doc/forum/using_l10n__39__d_basewiki/comment_3_5e9d5bc5ecaf63f9bfe3315b09a279aa._comment b/doc/forum/using_l10n__39__d_basewiki/comment_3_5e9d5bc5ecaf63f9bfe3315b09a279aa._comment new file mode 100644 index 000000000..f72bb37af --- /dev/null +++ b/doc/forum/using_l10n__39__d_basewiki/comment_3_5e9d5bc5ecaf63f9bfe3315b09a279aa._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joey.kitenet.net/" + nickname="joey" + subject="comment 3" + date="2010-12-05T22:53:12Z" + content=""" +That requires translating the templates, which has never quite been finished. [[todo/l10n]] discusses that. + +(You can edit the templates yourself of course and manually translate.) +"""]] diff --git a/doc/forum/using_svn+ssh_with_ikiwiki.mdwn b/doc/forum/using_svn+ssh_with_ikiwiki.mdwn new file mode 100644 index 000000000..8d9c27e46 --- /dev/null +++ b/doc/forum/using_svn+ssh_with_ikiwiki.mdwn @@ -0,0 +1,11 @@ +Just as an experiment, I tried running ikiwiki using a remote repository, i.e. via "svn+ssh". After setting up the repo and relocating the working copy, unfortunately, it doesn't work; editing a page gives the error: + +> Error: no element found at line 3, column 0, byte 28 at /opt/local/lib/perl5/vendor_perl/5.10.1/darwin-multi-2level/XML/Parser.pm line 187 + +I think this is because, despite a SetEnv directive in the apache configuration, the CGI wrapper is expunging SVN_SSH from the environment (based on perusing the source of Wrapper.pm and looking at "envsave" there at the top). Is this the case? --[[Glenn|geychaner@mac.com]] + +> That seems likely. You can edit Wrapper.pm and add SVN_SSH to the @envsave list and rebuild your wrappers to test it. --Joey + +A better way(?) would be to add a plugin to set the SVN_SSH variable at the appropriate moment (or even to add this to the SVN plugin). What kind of hook should this be; it needs to run just *after* the CGI script cleans its environment? --[[Glenn|geychaner@mac.com]] + +Actually, this probably doesn't need to be a plugin; setting SVN_SSH in ENV can probably be done through the setup file. (Right?) --[[Glenn|geychaner@mac.com]] diff --git a/doc/git.mdwn b/doc/git.mdwn index 88608d4b5..5943097e6 100644 --- a/doc/git.mdwn +++ b/doc/git.mdwn @@ -65,6 +65,7 @@ think about merging them. This is recommended. :-) * [[privat]] `git://github.com/privat/ikiwiki.git` * [[blipvert]] `git://github.com/blipvert/ikiwiki.git` * [[bzed|BerndZeimetz]] `git://git.recluse.de/users/bzed/ikiwiki.git` +* [[wtk]]: `git://github.com/wking/ikiwiki.git` ## branches diff --git a/doc/ikiwiki/directive/aggregate/discussion.mdwn b/doc/ikiwiki/directive/aggregate/discussion.mdwn new file mode 100644 index 000000000..ddece9746 --- /dev/null +++ b/doc/ikiwiki/directive/aggregate/discussion.mdwn @@ -0,0 +1,10 @@ +It would be awesome if table could aggregrate remote CSVs too. I want something like: + + !table file="http://cyclehireapp.com/cyclehirelive/cyclehire.csv" + +> Ok, but that has nothing to do with the aggregate plugin. File a +> [[todo]]? +> +> Anyway, it seems difficult, how would it know when the remote content +> had changed? Aggregate has its cron job support and has time stamps +> in rss feeds to rely on. --[[Joey]] diff --git a/doc/ikiwiki/directive/if.mdwn b/doc/ikiwiki/directive/if.mdwn index 2cbf70cdf..492adf499 100644 --- a/doc/ikiwiki/directive/if.mdwn +++ b/doc/ikiwiki/directive/if.mdwn @@ -43,6 +43,8 @@ with the following additional tests: * included() - Tests whether the page is being included onto another page. + Tests whether the page is being included onto another page, for example + via [[inline]] or [[map]]. Note that pages inserted into other pages + via [[template]] are not matched here. [[!meta robots="noindex, follow"]] diff --git a/doc/ikiwiki/directive/more.mdwn b/doc/ikiwiki/directive/more.mdwn index 506551910..bda1427f3 100644 --- a/doc/ikiwiki/directive/more.mdwn +++ b/doc/ikiwiki/directive/more.mdwn @@ -11,6 +11,11 @@ leads to the full version of the page. Use it like this: If the `linktext` parameter is omitted it defaults to just "more". +An optional `pages` parameter can be used to specify a +[[ikiwiki/PageSpec]], and then the "more" link will only be displayed +when the page is inlined into a page matching that PageSpec, and otherwise +the full content shown. + Note that you can accomplish something similar using a [[toggle]] instead. [[!meta robots="noindex, follow"]] diff --git a/doc/ikiwiki/directive/table/discussion.mdwn b/doc/ikiwiki/directive/table/discussion.mdwn new file mode 100644 index 000000000..87d2e0cd1 --- /dev/null +++ b/doc/ikiwiki/directive/table/discussion.mdwn @@ -0,0 +1 @@ +The problem I have in my tables, is that some fields contain example HTML that needs to be escaped. diff --git a/doc/ikiwiki/directive/template.mdwn b/doc/ikiwiki/directive/template.mdwn index 6c50fa32e..9e3ae54df 100644 --- a/doc/ikiwiki/directive/template.mdwn +++ b/doc/ikiwiki/directive/template.mdwn @@ -34,11 +34,15 @@ large chunks of marked up text to be embedded into a template: The template is a regular wiki page, located in the `templates/` subdirectory inside the source directory of the wiki. -(Alternatively, templates can be stored in a directory outside the wiki, +Alternatively, templates can be stored in a directory outside the wiki, as files with the extension ".tmpl". -By default, these are searched for in `/usr/share/ikiwiki/templates`; +By default, these are searched for in `/usr/share/ikiwiki/templates`, the `templatedir` setting can be used to make another directory be searched -first.) +first. When referring to templates outside the wiki source directory, the "id" +parameter is not interpreted as a pagespec, and you must include the full filename +of the template page, including the ".tmpl" extension. E.g.: + + \[[!template id=blogpost.tmpl]] The template uses the syntax used by the [[!cpan HTML::Template]] perl module, which allows for some fairly complex things to be done. Consult its diff --git a/doc/ikiwiki/pagespec.mdwn b/doc/ikiwiki/pagespec.mdwn index c66395f84..fe1af4c15 100644 --- a/doc/ikiwiki/pagespec.mdwn +++ b/doc/ikiwiki/pagespec.mdwn @@ -32,6 +32,7 @@ Some more elaborate limits can be added to what matches using these functions: tags matched by a glob) * "`backlink(page)`" - matches only pages that a given page links to * "`creation_month(month)`" - matches only files created on the given month + number * "`creation_day(mday)`" - or day of the month * "`creation_year(year)`" - or year * "`created_after(page)`" - matches only files created after the given page @@ -78,3 +79,7 @@ filenames of the pages in the wiki, so a pagespec "foo" used on page "a/b" will not match a page named "a/foo" or "a/b/foo". To match relative to the directory of the page containing the pagespec, you can use "./". For example, "./foo" on page "a/b" matches page "a/foo". + +To indicate the name of the page the PageSpec is used in, you can +use a single dot. For example, `link(.)` matches all the pages +linking to the page containing the PageSpec. diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn index e76d547cc..cd274c445 100644 --- a/doc/ikiwikiusers.mdwn +++ b/doc/ikiwikiusers.mdwn @@ -60,7 +60,7 @@ Projects & Organizations * [Serialist](http://serialist.net/)'s static pages (documentation, blog). We actually have ikiwiki generate its static content as HTML fragments using a modified page.tmpl template, and then the FastCGI powering our site grabs those fragments and embeds them in the standard dynamic site template. * [Apua IT](http://apua.se/) * [PDFpirate Community](http://community.pdfpirate.org/) -* [Banu](https://www.banu.com/) +* [Banu](https://banu.com/) uses Ikiwiki for its website, to convert static Markdown pages into PHP scripts which are served along with non-Ikiwiki PHP generated contents. The static contents benefit from use of Ikiwiki's plugins. Ikiwiki is purely used as a CMS and no wiki or web-based editing is allowed. Ikiwiki is run offline, and the resulting scripts are uploaded using rsync to the website. Personal sites and blogs ======================== @@ -154,10 +154,15 @@ Personal sites and blogs * [Ertug Karamatli](http://pages.karamatli.com) * [Jonatan Walck](http://jonatan.walck.i2p/) a weblog + wiki over [I2P](http://i2p2.de/). Also [mirrored](http://jonatan.walck.se/) to the Internet a few times per day. * [Daniel Wayne Armstrong](http://circuidipity.com/) -* [Mukund](https://www.mukund.org/) +* [Mukund](https://mukund.org/) * [Nicolas Schodet](http://ni.fr.eu.org/) * [weakish](http://weakish.github.com) * [Thomas Kane](http://planetkane.org/) +* [Marco Silva](http://marcot.eti.br/) a weblog + wiki using the [darcs](http://darcs.net) backend +* [NeX-6](http://nex-6.taht.net/) ikiwiki blog and wiki running over ipv6 +* [Jason Riedy](http://lovesgoodfood.com/jason/), which may occasionally look funny if I'm playing with my branch... +* [pmate](http://pmate.nfshost.com)'s homepage and [blog](http://pmate.nfshost.com/blog/) +* [tychoish.com](http://tychoish.com/) - a blog/wiki mashup. blog posts are "rhizomes." Please feel free to add your own ikiwiki site! diff --git a/doc/install.mdwn b/doc/install.mdwn index cc3a4c29f..f38ae2aab 100644 --- a/doc/install.mdwn +++ b/doc/install.mdwn @@ -41,5 +41,6 @@ If you're using a shared hosting provider, of the sort where you don't have root, you can still install ikiwiki. There are tutorials covering this for a few providers: + * [[tips/NearlyFreeSpeech]] * [[tips/DreamHost]] diff --git a/doc/install/discussion.mdwn b/doc/install/discussion.mdwn index 02cdb29c9..c06893ec1 100644 --- a/doc/install/discussion.mdwn +++ b/doc/install/discussion.mdwn @@ -269,3 +269,65 @@ Any suggestions? Whew! perl Makefile.PL INSTALL_BASE=$HOME PREFIX= make make install + +--- + +03 September 2010, Report on successful manual install in Debian 5 (Lenny) AMD64: + +note: Maybe much more easy using backports, but using this tools you get a plain user cpan :) + +This where my steps: + +As root (#): + + aptitude install build-essential curl perl + + +As plain user ($), I use to install user perl modules using local::lib + + mkdir -p "$HOME/downloads" + cd "$HOME/downloads/" + wget http://search.cpan.org/CPAN/authors/id/G/GE/GETTY/local-lib-1.006007.tar.gz + wget http://ftp.de.debian.org/debian/pool/main/i/ikiwiki/ikiwiki_3.20100831.tar.gz + tar -zxf local-lib-1.006007.tar.gz + cd local-lib-1.006007/ + perl Makefile.PL --bootstrap=~/.perl5 + make test && make install + echo 'eval $(perl -I$HOME/.perl5/lib/perl5 -Mlocal::lib=$HOME/.perl5)' >>~/.bashrc + . ~/.bashrc + curl -L http://cpanmin.us | perl - App::cpanminus + cpanm CGI::FormBuilder + cpanm CGI::Session + cpanm HTML::Parser + cpanm HTML::Template + cpanm HTML::Scrubber + cpanm Text::Markdown + cpanm URI + cd .. + tar -zxf ikiwiki_3.20100831.tar.gz + cd ikiwiki/ + perl Makefile.PL INSTALL_BASE= PREFIX=/home/$USER/.perl5 + make test # All tests successful. + make install INSTALL_BASE=/home/$USER/.perl5 + . ~/.bashrc + +Using cpan or cpanm with local::lib, you can install any other dependency, as plain user (in your home). XS modules may need -dev packages. + +After all, here it's: + + ikiwiki -version + ikiwiki version 3.20100831 + +It seems like this installation looses the /etc files (we're as plain user), but this can be used as a workaround: + + ikiwiki -setup ~/downloads/ikiwiki/auto.setup + +I've not investigated more the /etc files ussage, but does not seems like a good idea to be as plain user... + + /etc/ikiwiki/wikilist does not exist + ** Failed to add you to the system wikilist file. + ** (Probably ikiwiki-update-wikilist is not SUID root.) + ** Your wiki will not be automatically updated when ikiwiki is upgraded. + + +Iñigo diff --git a/doc/news/openid.mdwn b/doc/news/openid.mdwn index 4f1ee7bf7..87f640321 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 64 "Accept only OpenID for logins" 21 "Accept only password logins" 36 "Accept both"]] +[[!poll 67 "Accept only OpenID for logins" 21 "Accept only password logins" 41 "Accept both"]] diff --git a/doc/news/openid/discussion.mdwn b/doc/news/openid/discussion.mdwn index e611fa77b..bc9856ad9 100644 --- a/doc/news/openid/discussion.mdwn +++ b/doc/news/openid/discussion.mdwn @@ -80,3 +80,17 @@ which fails here? Or is something broken in Ikiwiki's implementation? > [[bugs/OpenID_delegation_fails_on_my_server]] --[[Joey]] Yes. I'd only recently set up my server as a delegate under wordpress, so still thought that perhaps the issue was on my end. But I'd since used my delegate successfully elsewhere, so I filed it as a bug against ikiwiki. + +---- +###Pretty Painless +I just tried logging it with OpenID and it Just Worked. Pretty painless. If you want to turn off password authentication on ikiwiki.info, I say go for it. --[[blipvert]] + +> I doubt I will. The new login interface basically makes password login +> and openid cooexist nicely. --[[Joey]] + +###LiveJournal openid +One caveat to the above is that, of course, OpenID is a distributed trust system which means you do have to think about the trust aspect. A case in point is livejournal.com whose OpenID implementation is badly broken in one important respect: If a LiveJournal user deletes his or her journal, and a different user registers a journal with the same name (this is actually quite a common occurrence on LiveJournal), they in effect inherit the previous journal owner's identity. LiveJournal does not even have a mechanism in place for a remote site even to detect that a journal has changed hands. It is an extremely dodgy situation which they seem to have *no* intention of fixing, and the bottom line is that the "identity" represented by a *username*.livejournal.com token should not be trusted as to its long-term uniqueness. Just FYI. --[[blipvert]] + +---- + +Submitting bugs in the OpenID components will be difficult if OpenID must be working first... diff --git a/doc/news/version_3.20100610.mdwn b/doc/news/version_3.20100610.mdwn deleted file mode 100644 index ee7c86d72..000000000 --- a/doc/news/version_3.20100610.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -ikiwiki 3.20100610 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * creation\_day() etc use local time, not gmtime. To match calendars, which - use local time. - * img: Fill in missing height or width when scaling image. - * Remove example blog tag pages; allow autotag creation to create them - when used. - * Fix support for globbing in tagged() pagespecs. - * Fix display of sidebar when previewing page edit. (Thanks, privat) - * relativedate: Fix problem with localised dates not working. - * editpage: Avoid storing accidental state changes when previewing pages. - * page.tmpl: Add a div around the page content, and comments, to aide in - sidebar styling. - * style.css: Improvements to make floating sidebar fit much better on - pages with inlines. - * calendar: Shorten day names, and improve styling of month calendar. - * style.css: Reduced sidebar width back to 20ex from 30; the month calendar - will now fit in the smaller width, and 30 was feeling too large."""]]
\ No newline at end of file diff --git a/doc/news/version_3.20100623.mdwn b/doc/news/version_3.20100623.mdwn deleted file mode 100644 index 684217e26..000000000 --- a/doc/news/version_3.20100623.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -ikiwiki 3.20100623 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * openid: Add openid\_realm and openid\_cgiurl configuration options, - useful in a few edge case setups. - * attachment: Show files from underlay in attachments list. - * img: Support hspace and vspace attributes. - * editpage: Rename "comments" field to avoid CSS conflict with the - comments div. - * edittemplate: Make silent mode not disable display when the template - page does not exist, so it can be easily created. - * edittemplate: Look for template pages under templates/ like everything - else (still looks in old location for backwards compatibility). - * attachment: When inserting links, insert img directives for images, - if that plugin is enabled. - * websetup: Allow enabling plugins listed in disable\_plugins. - * editpage, comments: Fix broken links in sidebar (due to forcebaseurl). - (Thanks, privat) - * calendar: Tune archive\_pagespec to only match pages, not other files. - * Fix issues with combining unicode srcdirs and source files. - (Workaround bug #586045) - * Make --gettime be honored after initial setup. - * git: Fix --gettime to properly support utf8 filenames. - * attachment: Support Windows paths when taking basename of client-supplied - file name. - * theme: New plugin, allows easily themeing a site via the underlay. - * Added actiontabs theme by Svend Sorensen. - * Added blueview theme by Bernd Zeimetz. - * mercurial: Fix buggy getctime code. Closes: #[586279](http://bugs.debian.org/586279) - * link: Enhanced to handle URLs and email addresses. (Bernd Zeimetz)"""]]
\ No newline at end of file diff --git a/doc/news/version_3.20100704.mdwn b/doc/news/version_3.20100704.mdwn deleted file mode 100644 index 9d2792ce6..000000000 --- a/doc/news/version_3.20100704.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -ikiwiki 3.20100704 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * Changes to avoid display of ugly google openids, by displaying - a username taken from openid. - * API: Add new optional field nickname to rcs\_recentchanges. - * API: rcs\_commit and rcs\_commit\_staged are now passed named - parameters. - * openid: Store nickname based on username or email provided from - openid provider. - * git: Record the nickname from openid in the git author email. - * comment: Record the username from openid in the comment page. - * Fixed some confusion and bugginess about whether - rcs\_getctime/rcs\_getmtime were passed absolute or relative filenames. - (Make it relative like everything else.) - * hnb: Fixed broken use of mkstemp that had caused dangling temp files, - and prevented actually rendering hnb files. - * Use comment template on comments page of example blog. - * comment.tmpl: Fix up display when inline uses it to display a non-comment - page. (Such as a discussion page.) - * git: Added git\_wrapper\_background\_command option. Can be used to eg, - make the git wrapper push to github in the background after ikiwiki - runs. - * po: Added needstranslation() pagespec. (intrigeri) - * po: Added support for .html source pages. (intrigeri) - * comment: Fix problem moderating comments of certian pages with utf-8 - in their name."""]]
\ No newline at end of file diff --git a/doc/news/version_3.20100722.mdwn b/doc/news/version_3.20100722.mdwn deleted file mode 100644 index 27ed1fd4d..000000000 --- a/doc/news/version_3.20100722.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -ikiwiki 3.20100722 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * img: Add a margin around images displayed by this directive. - * comments: Added commentmoderation directive for easy linking to the - comment moderation queue. - * aggregate: Write timestamp next aggregation can happen to - .ikiwiki/aggregatetime, to allow for more sophisticated cron jobs. - * Add --changesetup mode that allows easily changing options in a - setup file. - * openid: Fix handling of utf-8 nicknames. - * Clarified what the filter hook should be passed: Only be the raw, - complete text of a page. Not a snippet, or data read in from an - unrelated file. - * template: Do not pass filled in template through filter hook. - Avoids causing breakage in po plugin. - * color, comments, conditional, cutpaste, more, sidebar, toggle: Also - avoid unnecessary calls to filter hook. - * po: needstranslation() pagespec can have a percent specified. - * Drop Cache-Control must-revalidate (Firefox 3.5.10 does not seem to have - the caching problem that was added to work around). Closes: #[588623](http://bugs.debian.org/588623) - * Made much more robust in cases where multiple source files produce - conflicting files/directories in the destdir. - * Updated French translation from Philippe Batailler. Closes: #[589423](http://bugs.debian.org/589423) - * po: Fix selflink display on tranlsated pages. (intrigeri) - * Avoid showing 'Add a comment' link at the bottom of the comment post form."""]]
\ No newline at end of file diff --git a/doc/news/version_3.20100804.mdwn b/doc/news/version_3.20100804.mdwn deleted file mode 100644 index be85cb949..000000000 --- a/doc/news/version_3.20100804.mdwn +++ /dev/null @@ -1,14 +0,0 @@ -ikiwiki 3.20100804 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * template: Fix dependency tracking. Broken in version 3.20100427. - * po: The po\_slave\_languages setting is now a list, so the order of - translated languages can be controlled. (intrigeri) - * git: Fix gitweb historyurl examples so "diff to current" links work. - (Thanks jrayhawk) - * meta: Allow syntax closer to html meta to be used. - * Add new disable hook, allowing plugins to perform cleanup after they - have been disabled. - * Use Digest::SHA built into perl rather than external Digest::SHA1 - to simplify dependencies. Closes: #[591040](http://bugs.debian.org/591040) - * Fixes a bug that prevented matching deleted pages when using the page() - PageSpec."""]]
\ No newline at end of file diff --git a/doc/news/version_3.20100815.mdwn b/doc/news/version_3.20100815.mdwn deleted file mode 100644 index 1073933a1..000000000 --- a/doc/news/version_3.20100815.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -ikiwiki 3.20100815 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * Fix po test suite to not assume ikiwiki's underlay is already installed. - Closes: #[593047](http://bugs.debian.org/593047)"""]]
\ No newline at end of file diff --git a/doc/news/version_3.20100926.mdwn b/doc/news/version_3.20100926.mdwn new file mode 100644 index 000000000..b56e5770b --- /dev/null +++ b/doc/news/version_3.20100926.mdwn @@ -0,0 +1,6 @@ +ikiwiki 3.20100926 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * meta: Ensure that the url specified by xrds-location is absolute. + * attachment: Fix attachment file size display. + * Propigate PATH into wrapper. + * htmlbalance: Fix compatibility with HTML::Tree 4.0. (smcv)"""]]
\ No newline at end of file diff --git a/doc/news/version_3.20101019.mdwn b/doc/news/version_3.20101019.mdwn new file mode 100644 index 000000000..86c302e25 --- /dev/null +++ b/doc/news/version_3.20101019.mdwn @@ -0,0 +1,20 @@ +ikiwiki 3.20101019 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * Fix test suite failure on other side of date line. + * htmltidy: Allow configuring tidy parameters in setup file. + (W. Trevor King) + * Updated French program translation. Closes: #[598918](http://bugs.debian.org/598918) + * git: Added new rcs\_revert and rcs\_preprevert hooks. + * recentchanges: Add revert buttons to RecentChanges page, and + implement web-based reversion interface. + * Thanks to Peter Gammie for his assistance with the web-based reversion + feature. + * actiontabs: More consistent styling of Hn tags. + * websetup: Fix saving of advanced mode changes. + * websetup: Fix defaults of checkboxes in advanced mode. + * monotone: Fix recentchanges page when the srcdir is not at the top + of the monotone workspace. Thanks, tommyd. + * img: If a class is specified, don't also put the img in the img + class. + * auto-blog.setup: Don't enable opendiscussion by default; require users be + logged in to post comments."""]]
\ No newline at end of file diff --git a/doc/news/version_3.20101023.mdwn b/doc/news/version_3.20101023.mdwn new file mode 100644 index 000000000..44bed6be6 --- /dev/null +++ b/doc/news/version_3.20101023.mdwn @@ -0,0 +1,4 @@ +ikiwiki 3.20101023 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * Fix typo that broke anonymous git push. + * Fix web reversion when the srcdir is in a subdir of the git repo."""]]
\ No newline at end of file diff --git a/doc/news/version_3.20101112.mdwn b/doc/news/version_3.20101112.mdwn new file mode 100644 index 000000000..ad591445f --- /dev/null +++ b/doc/news/version_3.20101112.mdwn @@ -0,0 +1,17 @@ +ikiwiki 3.20101112 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * txt: Fix display when used inside a format directive. + * highlight: Ensure that other, more-specific format plugins, + like txt are used in preference to this one in case of ties. + * htmltidy, sortnaturally: Add missing checkconfig hook + registration. Closes: #[601912](http://bugs.debian.org/601912) + (Thanks, Craig Lennox and Tuomas Jormola) + * git: Use author date, not committer date. Closes: #[602012](http://bugs.debian.org/602012) + (Thanks, Tuomas Jormola) + * Fix htmlscrubber\_skip to be matched on the source page, not the page it is + inlined into. Should allow setting to "* and !comment(*)" to scrub + comments, but leave your blog posts unscrubbed, etc. + * comments: Make postcomment() pagespec work when previewing a comment, + including during moderation. + * comments: Make comment() pagespec also match comments that are being + posted."""]]
\ No newline at end of file diff --git a/doc/news/version_3.20101129.mdwn b/doc/news/version_3.20101129.mdwn new file mode 100644 index 000000000..366ad6e27 --- /dev/null +++ b/doc/news/version_3.20101129.mdwn @@ -0,0 +1,20 @@ +ikiwiki 3.20101129 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * websetup: Fix encoding problem when restoring old setup file. + * more: Add pages parameter to limit where the more is displayed. + (thanks, dark) + * Fix escaping of filenames in historyurl. (Thanks, aj) + * inline: Improve RSS url munging to use a proper html parser, + and support all elements that HTML::Tagset knows about. + (Which doesn't include html5 just yet, but then the old version + didn't either.) Bonus: 4 times faster than old regexp method. + * Optimise glob() pagespec. (Thanks, Kathryn and smcv) + * highlight: Support new format of filetypes.conf used by version 3.2 + of the highlight package. + * edittemplate: Fix crash if using a .tmpl file or other non-page file + as a template for a new page. + * git: Fix temp file location. + * rename: Fix to pass named parameters to rcs\_commit. + * git: Avoid adding files when committing, so as not to implicitly add + files like recentchanges files that are not normally checked in, + when fixing links after rename."""]]
\ No newline at end of file diff --git a/doc/news/version_3.20101201.mdwn b/doc/news/version_3.20101201.mdwn new file mode 100644 index 000000000..410640c75 --- /dev/null +++ b/doc/news/version_3.20101201.mdwn @@ -0,0 +1,5 @@ +ikiwiki 3.20101201 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * meta: Fix calling of htmlscrubber to pass the page parameter. + The change of the htmlscrubber to look at page rather than destpage + caused htmlscrubber\_skip to not work for meta directives."""]]
\ No newline at end of file diff --git a/doc/plugins/aggregate/discussion.mdwn b/doc/plugins/aggregate/discussion.mdwn index 1a9844577..a3336ee08 100644 --- a/doc/plugins/aggregate/discussion.mdwn +++ b/doc/plugins/aggregate/discussion.mdwn @@ -89,3 +89,35 @@ New bug: new posts aren't getting displayed (or cached for aggregation). After f >>> mind having a copy to investigate. --[[Joey]] >>>> Didn't think of that, will keep a copy if there's a next time. -- [[schmonz]] + +----- + +In a corporate environment where feeds are generally behind +authentication, I need to prime the aggregator's `LWP::UserAgent` +with some cookies. What I've done is write a custom plugin to populate +`$config{cookies}` with an `HTTP::Cookies` object, plus this diff: + + --- /var/tmp/pkg/lib/perl5/vendor_perl/5.10.0/IkiWiki/Plugin/aggregate.pm 2010-06-24 13:03:33.000000000 -0400 + +++ aggregate.pm 2010-06-24 13:04:09.000000000 -0400 + @@ -488,7 +488,11 @@ + } + $feed->{feedurl}=pop @urls; + } + - my $res=URI::Fetch->fetch($feed->{feedurl}); + + my $res=URI::Fetch->fetch($feed->{feedurl}, + + UserAgent => LWP::UserAgent->new( + + cookie_jar => $config{cookies}, + + ), + + ); + if (! $res) { + $feed->{message}=URI::Fetch->errstr; + $feed->{error}=1; + +It works, but I have to remember to apply the diff whenever I update +ikiwiki. Can you provide a more elegant means of allowing cookies and/or +the user agent to be programmatically manipulated? --[[schmonz]] + +> Ping -- is the above patch perhaps acceptable (or near-acceptable)? -- [[schmonz]] + +>> Pong.. I'd be happier with a more 100% solution that let cookies be used +>> w/o needing to write a custom plugin to do it. --[[Joey]] diff --git a/doc/plugins/autoindex/discussion.mdwn b/doc/plugins/autoindex/discussion.mdwn index 2d6b6f1f0..76d09cd3c 100644 --- a/doc/plugins/autoindex/discussion.mdwn +++ b/doc/plugins/autoindex/discussion.mdwn @@ -1,6 +1,13 @@ 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? +> Or better still, add a mechanism for ikiwiki to hold transient source +> pages in memory and render them as if they existed, without actually +> writing them out, as [[JoeRayhawk]] suggests below? I think +> add_autofile would be the way to do this. +> I've added this to [[todo]] as [[todo/autoindex should use add__95__autofile]] +> and [[todo/transient_pages]]. --[[smcv]] + 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. @@ -15,6 +22,8 @@ If you just don't want to clutter your git repo, below it's a patch does the fol * If you set autoindex_commit to 1 (this is the default), auto-generated index files will be put in the repo provided you enabled rcs backend. +[[!toggle id="patch-for-autoindex_commit" text="patch for autoindex_commit"]] +[[!toggleable id="patch-for-autoindex_commit" text=""" <pre> --- autoindex.pm.orig 2009-10-01 17:13:51.000000000 +0800 +++ autoindex.pm 2009-10-01 17:21:09.000000000 +0800 @@ -58,6 +67,18 @@ If you just don't want to clutter your git repo, below it's a patch does the fol gettext("automatic index generation"), undef, undef); </pre> - +"""]] Warning: I guess this patch may work, but I *haven't tested it yet*. -- [[weakish]] + +------ + +`autoindex_commit => 0` would be nice, but uncommited files are definitely not. +<pre> +remote: From /srv/git/test3 +remote: 3047077..1df636c master -> origin/master +remote: error: Untracked working tree file 'test.mdwn' would be overwritten by merge. Aborting +remote: 'git pull --prune origin' failed: at /usr/share/perl5/IkiWiki/Plugin/git.pm line 201. +</pre> + +It'd be nice if we were able to notice directories with no associated compilable markup files and compile a simple map directive straight to HTML without any intermediate markup file being involved at all. -- JoeRayhawk 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 b9ad3cc8e..16c147b68 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 @@ -6,9 +6,9 @@ Someone was just asking for it and I had written these two plugins already some months ago, so I'm now publishing them here. -[`copyright.pm`](http://www.schwinge.homeip.net/~thomas/tmp/copyright.pm) +[`copyright.pm`](http://schwinge.homeip.net/~thomas/tmp/copyright.pm) and -[`license.pm`](http://www.schwinge.homeip.net/~thomas/tmp/license.pm) +[`license.pm`](http://schwinge.homeip.net/~thomas/tmp/license.pm) Usage instructions are found inside the two plugin files. @@ -45,3 +45,10 @@ by ikiwiki are likewise fine. --[[tschwinge]] > and can extend beyond just copyright and license, but has the disadvantage > that it doesn't support setting defaults for a given "subdirectory" > only. --[[smcv]] + +[[!template id=gitbranch branch=smcv/contrib/defcopyright author="[[tschwinge]]"]] + +> For `./gitremotes` convenience (taking the Linus approach to backups :-) ) +> I've added this to my git repository as a branch. No review, approval or +> ownership is implied, feel free to replace this with a branch in any other +> repository --[[smcv]] diff --git a/doc/plugins/contrib/field/discussion.mdwn b/doc/plugins/contrib/field/discussion.mdwn index 191f8b27d..6161f80df 100644 --- a/doc/plugins/contrib/field/discussion.mdwn +++ b/doc/plugins/contrib/field/discussion.mdwn @@ -327,6 +327,81 @@ smcv's discuission of field author vs meta author above. --[[Joey]] ----- +I think the main point is: what is (or should be) the main point of the +field plugin? If it's essentially a way to present a consistent +interface to access page-related structured information, then it makes +sense to have it very general. Plugins registering with fields would +then present ways for recovering the structure information from the page +(`ymlfront`, `meta`, etc), ways to manipulate it (like `meta` does), +etc. + +In this sense, security should be entirely up to the plugins, although +the fields plugin could provide some auxiliary infrastructure (like +determining where the data comes from and raise or lower the security +level accoringly). + +Namespacing is important, and it should be considered at the field +plugin interface level. A plugin should be able to register as +responsible for the processing of all data belonging to a given +namespace, but plugins should be able to set data in any namespace. So +for example, `meta` register are `meta` fields processing, and whatever +method is used to set the data (`meta` directive, `ymlfront`, etc) it +gets a say on what to do with data in its namespace. + +What I'm thinking of is something you could call fieldsets. The nice +thing about them is that, aside from the ones defined by plugins (like +`meta`), it would be possible to define custom ones (with a generic, +default processor) in an appropriate file (like smileys and shortcuts) +with a syntax like: + + [[!fieldset book namespace=book + fields="author title isbn" + fieldtype="text text text"]] + +after which, you coude use + + [[!book author="A. U. Thor" + title="Fields of Iki"]] + +and the data would be available under the book namespace, and thus +as BOOK_AUTHOR, BOOK_TITLE etc in templates. + +Security, in this sense, would be up to the plugin responsible for the +namespace processing (the default handler would HTML-escape text fields +scrub, html fields, safeurl()ify url fields, etc.) + +> So, are you saying that getting a field value is sort of a two-stage process? Get the value from anywhere, and then call the "security processor" for that namespace to "secure" the value? I think "namespaces" are really orthogonal to this issue. What the issue seems to be is: + + * what form do we expect the raw field to be in? (text, URL, HTML) + * what form do we expect the "secured" output to be in? (raw HTML, scrubbed HTML, escaped HTML, URL) + +> Only if we know both these things will we know what sort of security processing needs to be done. + +>> Fieldsets are orthogonal to the security issue in the sense that you can use +>> them without worrying about the field security issue, but they happen to be +>> a rather clean way of answering those two questions, by allowing you to +>> attach preprocessing attributes to a field in a way that the user +>> (supposedly) cannot mingle with. + +> There is also a difference between field values that are used inside pagetemplate, and field values which are used as part of a page's content (e.g. with ftemplate). If you have a TITLE, you want it to be HTML-escaped if you're using it inside pagetemplate, but you don't want it to be HTML-escaped if you're using it inside a page's content. On the other hand, if you have, say, FEEDLINKS used inside pagetemplate, you don't wish it to be HTML-escaped at all, or your page content will be completely stuffed. + +>> Not to talk about the many different ways date-like fields might be need +>> processing. It has already been proposed to solve this problem by exposing +>> the field values under different names depending on the kind or amout of +>> postprocessing they had (e.g. RAW_SOMEFIELD, SOMEFIELD, to which we could add +>> HTML_SOMEFIELD, URL_SOMEFIELD or whatever). Again, fieldsets offer a simple way +>> of letting Ikiwiki know what kind of postprocessing should be offered for +>> that particular field. + +> So, somehow, we have to know the meaning of a field before we can use it properly, which kind of goes against the idea of having something generic. + +>> We could have a default field type (text, for example), and a way to set a +>> different field type (which is what my fieldset proposal was about). + +> --[[KathrynAndersen]] + +----- + I was just looking at HTML5 and wondered if the field plugin should generate the new Microdata tags (as well as the internal structures)? <http://slides.html5rocks.com/#slide19> -- [[Will]] > This could just as easily be done as a separate plugin. Feel free to do so. --[[KathrynAndersen]] diff --git a/doc/plugins/contrib/headinganchors/discussion.mdwn b/doc/plugins/contrib/headinganchors/discussion.mdwn index 91fe04a6d..151af8d92 100644 --- a/doc/plugins/contrib/headinganchors/discussion.mdwn +++ b/doc/plugins/contrib/headinganchors/discussion.mdwn @@ -1 +1,33 @@ Isn't this functionality a part of what [[plugins/toc]] needs and does? Then probably the [[plugins/toc]] plugin's code could be split into the part that implements the [[plugins/contrib/headinganchors]]'s functionality and the TOC generation itself. That will bring more order into the code and the set of available plugins. --Ivan Z. + +--- + +A patch to make it more like MediaWiki: + +<pre>--- headinganchors.pm ++++ headinganchors.pm +@@ -5,6 +5,7 @@ + use warnings; + use strict; + use IkiWiki 2.00; ++use URI::Escape; + + sub import { + hook(type => "sanitize", id => "headinganchors", call => \&headinganchors); +@@ -14,9 +15,11 @@ + my $str = shift; + $str =~ s/^\s+//; + $str =~ s/\s+$//; +- $str = lc($str); +- $str =~ s/[&\?"\'\.,\(\)!]//mig; +- $str =~ s/[^a-z]/_/mig; ++ $str =~ s/\s/_/g; ++ $str =~ s/"//g; ++ $str =~ s/^[^a-zA-Z]/z-/; # must start with an alphabetical character ++ $str = uri_escape_utf8($str); ++ $str =~ s/%/./g; + return $str; + } + </pre> + +--Changaco diff --git a/doc/plugins/contrib/ikiwiki/directive/ymlfront.mdwn b/doc/plugins/contrib/ikiwiki/directive/ymlfront.mdwn index bb4a58fc6..1a01834f8 100644 --- a/doc/plugins/contrib/ikiwiki/directive/ymlfront.mdwn +++ b/doc/plugins/contrib/ikiwiki/directive/ymlfront.mdwn @@ -14,4 +14,4 @@ There is one argument to this directive. The YAML-format data. This should be enclosed inside triple-quotes to preserve the data correctly. If more than one ymlfront directive is given per page, the result is undefined. -Likewise, it is inadvisable to try to mix the "---" ymlfront format with the directive form of the data. +Likewise, it is inadvisable to try to mix the non-directive ymlfront format with the directive form of the data. diff --git a/doc/plugins/contrib/imailhide.mdwn b/doc/plugins/contrib/imailhide.mdwn new file mode 100644 index 000000000..6009aa012 --- /dev/null +++ b/doc/plugins/contrib/imailhide.mdwn @@ -0,0 +1,65 @@ +[[!template id=plugin name=imailhide author="Peter_Vizi"]] +[[!tag type/widget type/html]] + +# Mailhide Plugin for Ikiwiki + +This plugin provides the directive mailhide, that uses the [Mailhide +API][1] to protect email addresses from spammers. + +## Dependencies + +The [Captcha::reCAPTCHA::Mailhide][2] perl module is required for this +plugin. + +## Download + +You can get the source code from [github][3]. + +## Installation + +Copy `imailhide.pm` to `/usr/share/perl/5.10.0/IkiWiki/Plugin` or +`~/.ikiwiki/IkiWiki/Plugin`, and enable it in your `.setup` file + + add_plugins => [qw{goodstuff imailhide ....}], + mailhide_public_key => "8s99vSA99fF11mao193LWdpa==", + mailhide_private_key => "6b5e4545326b5e4545326b5e45453223", + mailhide_default_style => "short", + +## Configuration + +### `mailhide_public_key` + +This is your personal public key that you can get at [Google][4]. + +### `mailhide_private_key` + +This is your personal private key that you can get at [Google][4]. + +### `mailhide_default_style` + +As per the recommendation of the [Mailhide API documentation][5], you +can define this as `short` or `long`. The `short` parameter will +result in `<a href="...">john</a>` links, while the `long` parameter +will result in `joh<a href="...">...</a>@example.com`. + +## Parameters + +### `email` + +*Required.* This is the email addres that you want to hide. + +### `style` + +*Optional.* You can set the style parameter individually for each + `mailhide` call. See `mailhide_default_style` for details. + +## Known Issues + +1. [opening new window when displaying email address][6] + +[1]: http://www.google.com/recaptcha/mailhide/ +[2]: http://search.cpan.org/perldoc?Captcha::reCAPTCHA::Mailhide +[3]: http://github.com/petervizi/imailhide +[4]: http://www.google.com/recaptcha/mailhide/apikey +[5]: http://code.google.com/apis/recaptcha/docs/mailhideapi.html +[6]: http://github.com/petervizi/imailhide/issues#issue/1 diff --git a/doc/plugins/contrib/report/ikiwiki/directive/report.mdwn b/doc/plugins/contrib/report/ikiwiki/directive/report.mdwn index 8f8e6b4e8..df88b33ad 100644 --- a/doc/plugins/contrib/report/ikiwiki/directive/report.mdwn +++ b/doc/plugins/contrib/report/ikiwiki/directive/report.mdwn @@ -30,6 +30,11 @@ them work as wiki pages. **pages**: A PageSpec to determine the pages to report on. +**pagenames**: If given instead of pages, this is interpreted as a +space-separated list of links to pages, and they are shown in exactly the order +given: the sort and pages parameters cannot be used in conjunction with this +one. If they are used, they will be ignored. + **trail**: A page or pages to use as a "trail" page. When a trail page is used, the matching pages are limited to (a subset @@ -45,6 +50,11 @@ For example: This will take the links from both the "animals/cats" page and the "animals/dogs" page as the set of pages to apply the PageSpec to. +**start**: Start the report at the given page-index; the index starts +from zero. + +**count**: Report only on N pages where count=N. + **sort**: A SortSpec to determine how the matching pages should be sorted. **here_only**: Report on the current page only. @@ -86,7 +96,19 @@ The "mood_summary" template might be like this: ### <TMPL_VAR NAME="TITLE"> (<TMPL_VAR NAME="DATE">) \[[<TMPL_VAR NAME="PAGE">]] <TMPL_VAR NAME="DESCRIPTION"> - + +### Multi-page Reports + +Reports can now be split over multiple pages, so that there aren't +too many items per report-page. + +**per_page**: how many items to show per report-page. + +**first_page_is_index**: If true, the first page of the report is just +an index which contains links to the other report pages. +If false, the first page will contain report-content as well as links +to the other pages. + ### Advanced Options The following options are used to improve efficiency when dealing diff --git a/doc/plugins/contrib/texinfo.mdwn b/doc/plugins/contrib/texinfo.mdwn index 595bd27aa..a2769166d 100644 --- a/doc/plugins/contrib/texinfo.mdwn +++ b/doc/plugins/contrib/texinfo.mdwn @@ -8,7 +8,7 @@ This plugin is not neccessarily meant to enable people to write arbitrary wiki pages in the Texinfo format (even though that is possible, of course), but rather to ease collaboration on existing Texinfo documents. -The plugin is available at <http://www.schwinge.homeip.net/~thomas/tmp/texinfo.pm>. +The plugin is available at <http://schwinge.homeip.net/~thomas/tmp/texinfo.pm>. It's very basic at the moment, but will be improved over time. diff --git a/doc/plugins/contrib/ymlfront.mdwn b/doc/plugins/contrib/ymlfront.mdwn index a2c649044..2805be04f 100644 --- a/doc/plugins/contrib/ymlfront.mdwn +++ b/doc/plugins/contrib/ymlfront.mdwn @@ -10,6 +10,9 @@ IkiWiki::Plugin::ymlfront - add YAML-format data to a page # activate the plugin add_plugins => [qw{goodstuff ymlfront ....}], + # configure the plugin + ymlfront_delim => [qw(--YAML-- --YAML--)], + ## DESCRIPTION This plugin provides a way of adding arbitrary meta-data (data fields) to any @@ -25,23 +28,57 @@ This plugin is meant to be used in conjunction with the [[field]] plugin. ## DETAILS -If one is not using the ymlfront directive, the YAML-format data in a page -must be placed at the start of the page and delimited by lines containing -precisely three dashes. The "normal" content of the page then follows. +There are three formats for adding YAML data to a page. These formats +should not be mixed - the result is undefined. -For example: +1. ymlfront directive + + See [[ikiwiki/directive/ymlfront]] for more information. - --- - title: Foo does not work - Urgency: High - Status: Assigned - AssignedTo: Fred Nurk - Version: 1.2.3 - --- - When running on the Sprongle system, the Foo function returns incorrect data. +2. default YAML-compatible delimiter + + By default, the YAML-format data in a page is placed at the start of + the page and delimited by lines containing precisely three dashes. + This is what YAML itself uses to delimit multiple documents. + The "normal" content of the page then follows. + + For example: + + --- + title: Foo does not work + Urgency: High + Status: Assigned + AssignedTo: Fred Nurk + Version: 1.2.3 + --- + When running on the Sprongle system, the Foo function returns incorrect data. + + What will normally be displayed is everything following the second line of dashes. That will be htmlized using the page-type of the page-file. + +3. user-defined delimiter + + Instead of using the default "---" delimiter, the user can define, + in the configuration file, the **ymlfront_delim** value, which is an + array containing two strings. The first string defines the markup for + the start of the YAML data, and the second string defines the markip + for the end of the YAML data. These two strings can be the same, or + they can be different. In this case, the YAML data section is not + required to be at the start of the page, but as with the default, it + is expected that only one data section will be on the page. + + For example: + + --YAML-- + title: Foo does not work + Urgency: High + Status: Assigned + AssignedTo: Fred Nurk + Version: 1.2.3 + --YAML-- + When running on the Sprongle system, the Foo function returns incorrect data. -What will normally be displayed is everything following the second line of dashes. -That will be htmlized using the page-type of the page-file. + What will normally be displayed is everything outside the delimiters, + both before and after. That will be htmlized using the page-type of the page-file. ### Accessing the Data diff --git a/doc/plugins/contrib/ymlfront/discussion.mdwn b/doc/plugins/contrib/ymlfront/discussion.mdwn index b1fd65fff..b122294bb 100644 --- a/doc/plugins/contrib/ymlfront/discussion.mdwn +++ b/doc/plugins/contrib/ymlfront/discussion.mdwn @@ -4,3 +4,28 @@ Now that I have implemented a \[[!ymlfront ...]] directive, I would like to remo * it is non-standard Any objections? + +> Well, I don't have much standing since I have been too lame to integrate +> ymlfront into ikiwiki yet. Buy, my opinion is, I liked the old +> format of putting the YAML literally at the front of the file. It +> seemed to allow parsing the file as YAML, using any arbitrary YAML +> processer. And it was nice how it avoided boilerplate. --[[Joey]] + +>> The old delimited format also has the advantage of being remarkably similar to the +>> [MultiMarkDown](http://fletcherpenney.net/multimarkdown/users_guide/multimarkdown_syntax_guide/) +>> way of including metadata in documents. The only difference is that MMD doesn't expect the +>> triple-dash separators, but I'm thinking about submitting a patch to MMD to actually support +>> that syntax. --GB + +>>> Yes, the idea was to allow the file to be parsed as YAML, you're right. I just found that I tended to have problems when people used "---" for horizontal rules. However, I have also found that trying to keep it solely as an IkiWiki directive doesn't work either, since sometimes the meta-data I need also contained "]]" which broke the parsing of the directive. +>>> So I have decided to go for a compromise, and make the delimiter configurable, rather than hardcoded as "---"; the triple-dash is the default, but it can be configured to be something else instead. I haven't pushed the change yet, but I have written it, and it seems to work. -- [[KathrynAndersen]] + +>>>> I'm not sure about what kind of problems you're meeting with "---" being used +>>>> for horizontal rules: isn't it sufficient to just check that (1) the triple-dash +>>>> is the first thing in the page and (2) there are only YAML-style assignments +>>>> (and no blank lines) between the two markers? Check #2 would also be enough to +>>>> support MMD-style metadata, which means (a) no start marker and (b) empty line +>>>> to mark the end of the metadata block. Would this be supported by the plugin? +>>>> --GB + +>>>>> Since I allow all legal YAML, the only way to check if it is legal YAML is to use the YAML parser, by which time one is already parsing the YAML, so it seems a bit pointless to check before one does so. -- KA diff --git a/doc/plugins/htmlscrubber.mdwn b/doc/plugins/htmlscrubber.mdwn index c59b46e14..080575c46 100644 --- a/doc/plugins/htmlscrubber.mdwn +++ b/doc/plugins/htmlscrubber.mdwn @@ -32,10 +32,11 @@ other HTML-related functionality, such as whether [[meta]] allows potentially unsafe HTML tags. The `htmlscrubber_skip` configuration setting can be used to skip scrubbing -of some pages. Set it to a [[ikiwiki/PageSpec]], such as "!*/Discussion", -and pages matching that can have all the evil CSS, JavsScript, and unsafe -html elements you like. One safe way to use this is to use [[lockedit]] to -lock those pages, so only admins can edit them. +of some pages. Set it to a [[ikiwiki/PageSpec]], such as +"posts/* and !comment(*) and !*/Discussion", and pages matching that can have +all the evil CSS, JavsScript, and unsafe html elements you like. One safe +way to use this is to use [[lockedit]] to lock those pages, so only admins +can edit them. ---- diff --git a/doc/plugins/po.mdwn b/doc/plugins/po.mdwn index 91273ba98..f91e44ea3 100644 --- a/doc/plugins/po.mdwn +++ b/doc/plugins/po.mdwn @@ -49,7 +49,7 @@ Supported languages `po_master_language` is used to set the "master" language in `ikiwiki.setup`, such as: - po_master_language => { 'code' => 'en', 'name' => 'English' } + po_master_language => 'en|English' `po_slave_languages` is used to set the list of supported "slave" languages, such as: @@ -117,12 +117,13 @@ serve any page in the client's preferred language, if available. 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. +When `usedirs` is enabled, you should also set `DirectoryIndex index`. -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`. +These settings are also recommended, in order to avoid serving up rss files +as index pages: + + AddType application/rss+xml;qs=0.8 .rss + AddType application/atom+xml;qs=0.8 .atom For details, see [Apache's documentation](http://httpd.apache.org/docs/2.2/content-negotiation.html). @@ -246,75 +247,3 @@ TODO [[!inline pages="todo/po:* and !todo/done and !link(todo/done) and !todo/*/*" feeds=no actions=no archive=yes show=0]] - -broken links to translatable basewiki pages that lack po files --------------------------------------------------------------- - -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]] - -> Any simple testcase to reproduce it, please? I've never seen this -> happen yet. --[[intrigeri]] - ->> Sure, go here <http://l10n.ikiwiki.info/smiley/smileys/index.sv.html> ->> (Currently 0% translateed) and see the 'WikiLink' link at the bottom, ->> which goes to <http://l10n.ikiwiki.info/ikiwiki.cgi?page=ikiwiki/wikilink&from=smiley/smileys&do=create> ->> Compare with eg, the 100% translated Dansk version, where ->> the WikiLink link links to the English WikiLink page. --[[Joey]] - ->>> Seems not related to the page/string translation status: the 0% ->>> translated Spanish version has the correct link, just like the ->>> Dansk version => I'm changing the bug title accordingly. ->>> ->>> I tested forcing the sv html page to be rebuilt by translating a ->>> string in it, it did not fix the bug. I did the same for the ->>> Spanish page, it did not introduce the bug. So this is really ->>> weird. ->>> ->>> The smiley underlay seems to be the only place where the wrong ->>> thing happens: the basewiki underlay has similar examples ->>> that do not exhibit this bug. An underlay linking to another might ->>> be necessary to reproduce it. Going to dig deeper. --[[intrigeri]] - ->>>> After a few hours lost in the Perl debugger, I think I have found ->>>> the root cause of the problem: in l10n wiki's configured ->>>> `underlaydir`, the basewiki is present in every slave language ->>>> that is enabled for this wiki *but* Swedish. With such a ->>>> configuration, the `ikiwiki/wikilink` page indeed does not exist ->>>> in Swedish language: no `ikiwiki/wikilink.sv.po` can be found ->>>> where ikiwiki is looking. Have a look to ->>>> <http://l10n.ikiwiki.info/ikiwiki/>, the basewiki is not ->>>> available in Swedish language on this wiki. So this is not a po ->>>> bug, but a configuration or directories layout issue. This is ->>>> solved by adding the Swedish basewiki to the underlay dir, which ->>>> is I guess not a possibility in the l10n wiki context. I guess ->>>> this could be solved by adding `SRCDIR/basewiki` as an underlay ->>>> to your l10n wiki configuration, possibly using the ->>>> `add_underlays` configuration directive. --[[intrigeri]] - ->>>>> There is no complete Swedish underlay translation yet, so it is not ->>>>> shipped in ikiwiki. I don't think it's a misconfiguration to use ->>>>> a language that doesn't have translated underlays. --[[Joey]] - ->>>>>> Ok. The problem is triggered when using a language that doesn't ->>>>>> have translated underlays, *and* defining ->>>>>> `po_translatable_pages` in a way that renders the base wiki ->>>>>> pages translatable in po's view of things, which in turns makes ->>>>>> the po plugin act as if the translation pages did exist, ->>>>>> although they do not in this case. I still need to have a deep ->>>>>> look at the underlays-related code you added to `po.pm` a while ->>>>>> ago. Stay tuned. --[[intrigeri]] - ->>>>>>> Fixed in my po branch, along with other related small bugs that ->>>>>>> happen in the very same situation only. --[[intrigeri]] diff --git a/doc/plugins/recentchanges.mdwn b/doc/plugins/recentchanges.mdwn index 823f68502..6fff18e8a 100644 --- a/doc/plugins/recentchanges.mdwn +++ b/doc/plugins/recentchanges.mdwn @@ -6,6 +6,8 @@ generates a page describing each recent change made to the wiki. These pages can be joined together with [[inline]] to generate the [[RecentChanges]] page. +This plugin also currently handles web-based reversion of changes. + Typically only the RecentChanges page will use the pages generated by this plugin, but you can use it elsewhere too if you like. It's used like this: diff --git a/doc/plugins/theme.mdwn b/doc/plugins/theme.mdwn index 7149cc163..ebbb0be8e 100644 --- a/doc/plugins/theme.mdwn +++ b/doc/plugins/theme.mdwn @@ -4,8 +4,8 @@ The theme plugin allows easily applying a theme to your wiki, by configuring the `theme` setting in the setup file with the name of a theme to use. The themes you can choose from are all subdirectories, typically -inside `/usr/share/ikiwiki/themes/`. +inside `/usr/share/ikiwiki/themes/`. See [[themes]] for an overview +of the themes included in ikiwiki. -A theme provides, via the underlay, an enhanced version of the regular -[[style.css]]. This leaves [[local.css]] free for you to further -customise. Themes can also provide header and background images. +You can set the theme via the **theme** option in your config file (after +enabling the plugin). Refresh the wiki after changing it to see the changes. diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn index 10b4df835..3cab7588e 100644 --- a/doc/plugins/write.mdwn +++ b/doc/plugins/write.mdwn @@ -1,4 +1,4 @@ -Ikiwiki's plugin interface allows all kinds of useful [[plugins]] to be +lkiwiki's plugin interface allows all kinds of useful [[plugins]] to be written to extend ikiwiki in many ways. Despite the length of this page, it's not really hard. This page is a complete reference to everything a plugin might want to do. There is also a quick [[tutorial]]. @@ -177,10 +177,15 @@ function is passed no values. hook(type => "needsbuild", id => "foo", call => \&needsbuild); -This allows a plugin to manipulate the list of files that need to be -built when the wiki is refreshed. The function is passed a reference to an -array of files that will be rebuilt, and can modify the array, either -adding or removing files from it. +This allows a plugin to observe or even manipulate the list of files that +need to be built when the wiki is refreshed. + +As its first parameter, the function is passed a reference to an array of +files that will be built. It should return an array reference that is a +modified version of its input. It can add or remove files from it. + +The second parameter passed to the function is a reference to an array of +files that have been deleted. ### scan @@ -735,6 +740,8 @@ with no ".tmpl" extension. Template pages are normally looked for in the templates/ directory. If the page name starts with "/", a page elsewhere in the wiki can be used. +If the template is not found, or contains a syntax error, an error is thrown. + ### `template_depends($$;@)` Use this instead of `template()` if the content of a template is being @@ -975,14 +982,19 @@ This is the standard gettext function, although slightly optimised. This is the standard ngettext function, although slightly optimised. -### `urlto($$;$)` +### `urlto($;$$)` Construct a relative url to the first parameter from the page named by the second. The first parameter can be either a page name, or some other destination file, as registered by `will_render`. -If the third parameter is passed and is true, an absolute url will be -constructed instead of the default relative url. +If the second parameter is not specified (or `undef`), the URL will be +valid from any page on the wiki, or from the CGI; if possible it'll +be a path starting with `/`, but an absolute URL will be used if +the wiki and the CGI are on different domains. + +If the third parameter is passed and is true, the url will be a fully +absolute url. This is useful when generating an url to publish elsewhere. ### `newpagefile($$)` @@ -1147,8 +1159,6 @@ context, and the whole diff in scalar context. This is used to get the page creation time for a file from the RCS, by looking it up in the history. -It's ok if this is not implemented, and throws an error. - If the RCS cannot determine a ctime for the file, return 0. #### `rcs_getmtime($)` @@ -1169,9 +1179,9 @@ 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: +removes, and changes. If something bad is found, it should die, 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 @@ -1184,6 +1194,28 @@ files that were changed, in the form: The list will then be checked to make sure that each change is one that is allowed to be made via the web interface. +#### `rcs_preprevert($)` + +This is called by the revert web interface. It is passed a RCS-specific +change ID, and should determine what the effects would be of reverting +that change, and return the same data structure as `rcs_receive`. + +Like `rcs_receive`, it should do whatever sanity checks are appropriate +for the RCS to limit changes to safe changes, and die if a change would +be unsafe to revert. + +#### `rcs_revert($)` + +This is called by the revert web interface. It is passed a named +parameter rev that is the RCS-specific change ID to revert. + +It should try to revert the specified rev, and leave the reversion staged +so `rcs_commit_staged` will complete it. It should return undef on _success_ +and an error message on failure. + +This hook and `rcs_preprevert` are optional, if not implemented, no revert +web interface will be available. + ### PageSpec plugins It's also possible to write plugins that add new functions to diff --git a/doc/plugins/write/external.mdwn b/doc/plugins/write/external.mdwn index e30bf2ff3..a3fbe8a2c 100644 --- a/doc/plugins/write/external.mdwn +++ b/doc/plugins/write/external.mdwn @@ -1,7 +1,7 @@ External plugins are standalone, executable programs, that can be written in any language. When ikiwiki starts up, it runs the program, and -communicates with it using [XML RPC][xmlrpc]. If you want to [[write]] an external -plugin, read on.. +communicates with it using [XML RPC][xmlrpc]. If you want to [[write]] an +external plugin, read on.. [xmlrpc]: http://www.xmlrpc.com/ @@ -85,8 +85,8 @@ language as part of their XML RPC interface. XML RPC has a limitation that it does not have a way to pass undef/NULL/None. There is an extension to the protocol that supports this, -but it is not yet available in the [[!cpan XML::RPC]] library used by -ikiwiki. +but it is not yet available in all versions of the [[!cpan XML::RPC]] library +used by ikiwiki. Until the extension is available, ikiwiki allows undef to be communicated over XML RPC by passing a sentinal value, a hash with a single key "null" diff --git a/doc/rcs.mdwn b/doc/rcs.mdwn index 83c6910d0..06af9807c 100644 --- a/doc/rcs.mdwn +++ b/doc/rcs.mdwn @@ -23,6 +23,8 @@ auto.setup |yes |yes |incomplete|yes |incomplete |yes `rcs_diff` |yes |yes |yes |yes |no |yes |yes |yes `rcs_getctime` |fast |slow |slow |slow |slow |slow |slow |slow `rcs_getmtime` |fast |slow |slow |no |no |no |no |no +`rcs_preprevert` |yes |no |no |no |no |no |no |no +`rcs_revert` |yes |no |no |no |no |no |no |no anonymous push |yes |no |no |no |no |no |no |no conflict handling |yes |yes |yes |buggy |yes |yes |yes |yes openid username |yes |no |no |no |no |no |no |no diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn index 01308dae4..e0bdb6d03 100644 --- a/doc/sandbox.mdwn +++ b/doc/sandbox.mdwn @@ -1,4 +1,7 @@ -This is the [[SandBox]], a page anyone can edit to try out ikiwiki (version [[!version ]]). +Hello, world! + +This is the [[SandBox]], a page anyone can edit to try out ikiwiki +(version [[!version ]]). > This is a blockquote. > @@ -11,11 +14,17 @@ This is the [[SandBox]], a page anyone can edit to try out ikiwiki (version [[!v > > Back to the first level. +1. Hot Items that are hot + 1. Daves Insanity Sauce + 2. Marie Sharps + 1. Blazing Inferno +1. Not so Hot Items + 1. Tabasco + Numbered list 1. First item. 1. Sub item. - 2. bar 1. Another. 1. And another.. 1. foo @@ -46,9 +55,12 @@ Bulleted list * [[different_name_for_a_WikiLink|ikiwiki/WikiLink]] * <http://www.gnu.org/> * [GNU](http://www.gnu.org/) -* <test.html> +* <a href="http://kitenet.net/~joey/">Joey's blog</a> + +testing 123 + +I wonder how org-mode would look once formatted with ikiwiki.. -<google.de> ---- This **SandBox** is also a [[blog]]! diff --git a/doc/sandbox/Fantasia.mdwn b/doc/sandbox/Fantasia.mdwn new file mode 100644 index 000000000..8845ec967 --- /dev/null +++ b/doc/sandbox/Fantasia.mdwn @@ -0,0 +1,10 @@ +>> Block +>>> Two Block + +[[blog]] blog + +* one +* two + +# one +# two diff --git a/doc/sandbox/Mooooo.mdwn b/doc/sandbox/Mooooo.mdwn new file mode 100644 index 000000000..6f11d357c --- /dev/null +++ b/doc/sandbox/Mooooo.mdwn @@ -0,0 +1 @@ +Hrm. diff --git a/doc/sandbox/Nur_so..mdwn b/doc/sandbox/Nur_so..mdwn new file mode 100644 index 000000000..32c9f2397 --- /dev/null +++ b/doc/sandbox/Nur_so..mdwn @@ -0,0 +1 @@ +Das ist ein Test. diff --git a/doc/sandbox/Post.mdwn b/doc/sandbox/Post.mdwn deleted file mode 100644 index 7ae61669b..000000000 --- a/doc/sandbox/Post.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -Ikiwiki is a **wiki compiler**. It converts wiki pages into HTML pages -suitable for publishing on a website. Ikiwiki stores pages and history in a -[[revision_control_system|rcs]] such as [[Subversion|rcs/svn]] or [[rcs/Git]]. -There are many other [[features]], including support for -[[blogging|blog]], as well as a large array of [[plugins]]. diff --git a/doc/sandbox/Testing_blog_entry.mdwn b/doc/sandbox/Testing_blog_entry.mdwn new file mode 100644 index 000000000..aa5fa5b20 --- /dev/null +++ b/doc/sandbox/Testing_blog_entry.mdwn @@ -0,0 +1,7 @@ +# Be cool, this is a test! + +Hello guys, this is *just a test* entry. + +* Did I say +* that I love +* bulleted lists? diff --git a/doc/sandbox/bullet_list_and_code_test.mdwn b/doc/sandbox/bullet_list_and_code_test.mdwn new file mode 100644 index 000000000..a17729c90 --- /dev/null +++ b/doc/sandbox/bullet_list_and_code_test.mdwn @@ -0,0 +1,12 @@ +paragraph. + + code + + * bullet list + * bullet list + + more code + + * bullet list continued + + tailing code diff --git a/doc/sandbox/hey.mdwn b/doc/sandbox/hey.mdwn new file mode 100644 index 000000000..a955185ef --- /dev/null +++ b/doc/sandbox/hey.mdwn @@ -0,0 +1 @@ +* Hello diff --git a/doc/sandbox/prova_blog.html b/doc/sandbox/prova_blog.html deleted file mode 100644 index d69937ea8..000000000 --- a/doc/sandbox/prova_blog.html +++ /dev/null @@ -1,8 +0,0 @@ -Questa è una prova. -Vediamo se funziona - -<pre> -#!/bin/bash - -echo "ciao" -</pre> diff --git a/doc/sandbox/revert_me.mdwn b/doc/sandbox/revert_me.mdwn new file mode 100644 index 000000000..2b1cd2f94 --- /dev/null +++ b/doc/sandbox/revert_me.mdwn @@ -0,0 +1 @@ +this looks good diff --git a/doc/security.mdwn b/doc/security.mdwn index 34a005239..4fa531eb1 100644 --- a/doc/security.mdwn +++ b/doc/security.mdwn @@ -440,3 +440,16 @@ with the release of ikiwiki 3.20100312. A fix was also backported to Debian etch, as version 2.53.5. I recommend upgrading to one of these versions if your wiki can be edited by third parties. + +## javascript insertation via insufficient htmlscrubbing of comments + +Kevin Riggle noticed that it was not possible to configure +`htmlscrubber_skip` to scrub comments while leaving unscubbed the text +of eg, blog posts. Confusingly, setting it to "* and !comment(*)" did not +scrub comments. + +Additionally, it was discovered that comments' html was never scrubbed during +preview or moderation of comments with such a configuration. + +These problems were discovered on 12 November 2010 and fixed the same +hour with the release of ikiwiki 3.20101112. ([[!cve CVE-2010-1673]]) diff --git a/doc/setup.mdwn b/doc/setup.mdwn index 266222cc3..40581eb72 100644 --- a/doc/setup.mdwn +++ b/doc/setup.mdwn @@ -22,6 +22,8 @@ Or, set up a blog with ikiwiki, run this command instead. % ikiwiki -setup /etc/ikiwiki/auto-blog.setup +`librpc-xml-perl` and `python-docutils` dependencies are needed. + Either way, it will ask you a couple of questions. What will the wiki be named? foo @@ -68,6 +70,7 @@ source. (Remember to replace "foo" with the real directory name.) cvs -d `pwd`/foo get -P ikiwiki bzr clone foo foo.src hg clone foo foo.src + darcs get foo.darcs foo.src # TODO monotone, tla Now to edit pages by hand, go into the directory you checked out (ie, @@ -129,7 +132,7 @@ old location won't work, and the easiest way to deal with this is to delete them and re-checkout from the new repository location. % rm -rf foo - % git clone /src/git/foo.git + % git clone /srv/git/foo.git Finally, edit the setup file. Modify the settings for `srcdir`, `destdir`, `url`, `cgiurl`, `cgi_wrapper`, `git_wrapper`, etc to reflect where diff --git a/doc/setup/byhand.mdwn b/doc/setup/byhand.mdwn index 86cff5af4..75a5648d5 100644 --- a/doc/setup/byhand.mdwn +++ b/doc/setup/byhand.mdwn @@ -104,7 +104,7 @@ is ok, run `ikiwiki --setup ikiwiki.setup`, and you're done! There are lots of other configuration options in ikiwiki.setup that you can uncomment, configure, and enable by re-running `ikiwiki --setup ikiwiki.setup`. Be sure to browse through all the -[[plugins]].. +[[plugins]]. ## Put your wiki in revision control. diff --git a/doc/setup/discussion.mdwn b/doc/setup/discussion.mdwn index 74f7740db..f0eeea8ee 100644 --- a/doc/setup/discussion.mdwn +++ b/doc/setup/discussion.mdwn @@ -258,3 +258,10 @@ precicely breaks without it? -- [[Jon]] > I don't remember what was the specific problem with perl 5.8.8. All I can > find is some taint checking bugs, which are currently worked around by > taint checking being disabled. --[[Joey]] + +--- + +Did anyone tried to install ikiwiki under a vhost setup ? +ikiwiki is installed under a debian lenny system. but without write acces to /etc/ikiwiki (obvious) i am coming not far. +Or do i miss something which is probably hidden deeper in the documentation ? + diff --git a/doc/shortcuts.mdwn b/doc/shortcuts.mdwn index 54dd0fdb1..cafe3f573 100644 --- a/doc/shortcuts.mdwn +++ b/doc/shortcuts.mdwn @@ -11,13 +11,13 @@ Some examples of using shortcuts include: This page controls what shortcut links the wiki supports. -* [[!shortcut name=google url="http://www.google.com/search?q=%s"]] +* [[!shortcut name=google url="https://encrypted.google.com/search?q=%s"]] * [[!shortcut name=archive url="http://web.archive.org/*/%S"]] * [[!shortcut name=gmap url="http://maps.google.com/maps?q=%s"]] * [[!shortcut name=gmsg url="http://groups.google.com/groups?selm=%s"]] -* [[!shortcut name=wikipedia url="http://en.wikipedia.org/wiki/%s"]] -* [[!shortcut name=wikitravel url="http://wikitravel.org/en/%s"]] -* [[!shortcut name=wiktionary url="http://en.wiktionary.org/wiki/%s"]] +* [[!shortcut name=wikipedia url="https://secure.wikimedia.org/wikipedia/en/wiki/%s"]] +* [[!shortcut name=wikitravel url="https://wikitravel.org/en/%s"]] +* [[!shortcut name=wiktionary url="https://secure.wikimedia.org/wiktionary/en/wiki/%s"]] * [[!shortcut name=debbug url="http://bugs.debian.org/%S" desc="Debian bug #%s"]] * [[!shortcut name=deblist url="http://lists.debian.org/debian-%s" desc="debian-%s@lists.debian.org"]] * [[!shortcut name=debpkg url="http://packages.debian.org/%s"]] diff --git a/doc/shortcuts/discussion.mdwn b/doc/shortcuts/discussion.mdwn new file mode 100644 index 000000000..aac98457e --- /dev/null +++ b/doc/shortcuts/discussion.mdwn @@ -0,0 +1,13 @@ +# Suggestions for multi-language links + +Sites like Wikipedia have different URLs for each language. The shortcut for Wikipedia `!wikipedia` points to `https://secure.wikimedia.org/wikipedia/en/wiki/%s` which is the English version. + +Do you have a suggestion on how to make that shortcut also be used to point to a different language. + +1. The option to just adapt the shortcut (`s/en/de/`) is quite cumbersome for non English speakers and also has the disadvantage of always updating the shortcut links manually after each modification in the upstream ikiwiki shortcut list to stay in sync. +1. Adding an extra shortcut for every language, e. g. `!wikipediade`, with for example the country TLD in it is an option but would make the shortcut list quite big. +1. Adding a `lang` parameter comes also to my mind, but I do not know how feasible that is. + +Thanks. --[[PaulePanter]] + +> Does anyone have an opinion on the shortcuts for google/wikipedia pointing at the HTTPS services? Introduced by [this edit by Paul Panter](http://git.ikiwiki.info/?p=ikiwiki;a=blobdiff;f=doc/shortcuts.mdwn;h=cafe3f573ef5cfd4811bee9688afa1675302aca9;hp=54dd0fdb1eadfac386b31b2dd2f014349a54184a;hb=704038db298c0f3a8039dcfe8d3a801c26fadf15;hpb=2a1077f8869ca65b49e09d99a76b595d90b28499). Personally, I think they should be separate shortcut keys. Most of my google/WP usage is such that I would prefer it over HTTP (faster, less resource usage at client side). However, I never use the shortcuts feature in ikiwiki anyway... -- [[Jon]] diff --git a/doc/smileys/icon-error.png b/doc/smileys/icon-error.png Binary files differindex 53b1055f6..c39e65c33 100644 --- a/doc/smileys/icon-error.png +++ b/doc/smileys/icon-error.png diff --git a/doc/style.css b/doc/style.css index fa4b2a38a..aa27d8866 100644 --- a/doc/style.css +++ b/doc/style.css @@ -172,7 +172,8 @@ div.recentchanges { width: 35%; font-size: small; } -.recentchanges .pagelinks { +.recentchanges .pagelinks, +.recentchanges .revert { float: right; margin: 0; width: 60%; diff --git a/doc/templates.mdwn b/doc/templates.mdwn index bfb6a439a..4fd2bf501 100644 --- a/doc/templates.mdwn +++ b/doc/templates.mdwn @@ -74,7 +74,7 @@ html out of ikiwiki and in the templates. * `editpage.tmpl`, `editconflict.tmpl`, `editcreationconflict.tmpl`, `editfailedsave.tmpl`, `editpagegone.tmpl`, `pocreatepage.tmpl`, `editcomment.tmpl` `commentmoderation.tmpl`, `renamesummary.tmpl`, - `passwordmail.tmpl`, `openid-selector.tmpl` - Parts of ikiwiki's user + `passwordmail.tmpl`, `openid-selector.tmpl`, `revert.tmpl` - Parts of ikiwiki's user interface; do not normally need to be customised. [[!meta robots="noindex, follow"]] diff --git a/doc/templates/discussion.mdwn b/doc/templates/discussion.mdwn index 4ddc48ac3..efeedf448 100644 --- a/doc/templates/discussion.mdwn +++ b/doc/templates/discussion.mdwn @@ -7,6 +7,9 @@ note and popups are templates? But they're not in the templates directory, and i > installed there, typically in `/usr/share/ikiwiki/basewiki/templates/` > --[[Joey]] +> > And how am I able to use e.g. links? It's not listed in `/usr/share/ikiwiki/basewiki/templates`. +> > I intend do (mis)use links for a horizontal navigation. Or may I be better off altering page.tmpl? +> > --z3ttacht Is there a list of the TMPL_VAR-Variables that are defined by ikiwiki? diff --git a/doc/themes.mdwn b/doc/themes.mdwn new file mode 100644 index 000000000..57f899677 --- /dev/null +++ b/doc/themes.mdwn @@ -0,0 +1,27 @@ +A theme provides a style.css file, and any associated images to give +ikiwiki a nice look and feel. The local.css [[CSS]] file is left +free for you to further customize. + +Ikiwiki now comes with several themes contributed by users. +You can enable the [[theme_plugin|plugins/theme]] to use any of these: + +[[!img actiontabs_small.png align=left]] The **actiontabs** theme, contributed by +[[svend]]. This style sheet displays the action list +(Edit, RecentChanges, etc.) as tabs. + +<br clear="both" /> + +[[!img blueview_small.png align=left]] The **blueview** theme, contributed by +[[BerndZeimetz]], featuring a tiling panoramic photo he took. + +<br clear="both" /> + +[[!img goldtype_small.png align=left]] The **goldtype** theme, based on +blueview and featuring the photography of Lars Wirzenius. + +<br clear="both" /> + +[[!img none_small.png align=left]] For completeness, ikiwiki's default +anti-theme. + +<br clear="both" /> diff --git a/doc/themes/actiontabs_small.png b/doc/themes/actiontabs_small.png Binary files differnew file mode 100644 index 000000000..4b05ad3dc --- /dev/null +++ b/doc/themes/actiontabs_small.png diff --git a/doc/themes/blueview_small.png b/doc/themes/blueview_small.png Binary files differnew file mode 100644 index 000000000..74972c4c3 --- /dev/null +++ b/doc/themes/blueview_small.png diff --git a/doc/themes/goldtype_small.png b/doc/themes/goldtype_small.png Binary files differnew file mode 100644 index 000000000..a011bb200 --- /dev/null +++ b/doc/themes/goldtype_small.png diff --git a/doc/themes/none_small.png b/doc/themes/none_small.png Binary files differnew file mode 100644 index 000000000..8272ae606 --- /dev/null +++ b/doc/themes/none_small.png diff --git a/doc/tips/convert_mediawiki_to_ikiwiki/discussion.mdwn b/doc/tips/convert_mediawiki_to_ikiwiki/discussion.mdwn index d67a9131b..4a7163eae 100644 --- a/doc/tips/convert_mediawiki_to_ikiwiki/discussion.mdwn +++ b/doc/tips/convert_mediawiki_to_ikiwiki/discussion.mdwn @@ -6,6 +6,10 @@ ---- +I wrote a script that will download all the latest revisions of a mediawiki site. In short, it does a good part of the stuff required for the migration: it downloads the goods (ie. the latest version of every page, automatically) and commits the resulting structure. There's still a good few pieces missing for an actual complete conversion to ikiwiki, but it's a pretty good start. It only talks with mediawiki through HTTP, so no special access is necessary. The downside of that is that it will not attempt to download every revision for performance reasons. The code is here: http://anarcat.ath.cx/software/mediawikigitdump.git/ See header of the file for more details and todos. -- [[users/Anarcat]] 2010-10-15 + +---- + The u32 page is excellent, but I wonder if documenting the procedure here would be worthwhile. Who knows, the remote site might disappear. But also there are some variations on the approach that might be useful: diff --git a/doc/tips/dot_cgi.mdwn b/doc/tips/dot_cgi.mdwn index da55c1f1c..42a0aa7bf 100644 --- a/doc/tips/dot_cgi.mdwn +++ b/doc/tips/dot_cgi.mdwn @@ -26,6 +26,8 @@ configuration changes should work anywhere. Or, if you've put it in a `~/public_html`, edit `/etc/apache2/mods-available/userdir.conf`. + You may also want to install some dependencies to enable CGI in apache2 setup as: `libcgi-formbuilder-perl` and `libcgi-session-perl`. + * You may also want to enable the [[plugins/404]] plugin. To make apache use it, the apache config file will need a further modification to make it use ikiwiki's CGI as the apache 404 handler. diff --git a/doc/tips/html5.mdwn b/doc/tips/html5.mdwn index 945efc4bc..8fbbb2ebb 100644 --- a/doc/tips/html5.mdwn +++ b/doc/tips/html5.mdwn @@ -15,7 +15,8 @@ No care is taken to add backwards compatability hacks for browsers that are not html5 aware (like MSIE). If you want to include the javascript with those hacks, you can edit `page.tmpl` to do so. [Dive Into HTML5](http://diveintohtml5.org/) is a good reference for -current compatability issues and workarounds with html5. +current compatability issues and workarounds with html5. And a remotely-loadable +JS shiv for enabling HTML5 elements in IE is available through [html5shiv at Google Code](http://code.google.com/p/html5shiv/). --- diff --git a/doc/tips/ikiwiki_on_Mac_OS_X_Snow_Leopard.mdwn b/doc/tips/ikiwiki_on_Mac_OS_X_Snow_Leopard.mdwn new file mode 100644 index 000000000..8b649156d --- /dev/null +++ b/doc/tips/ikiwiki_on_Mac_OS_X_Snow_Leopard.mdwn @@ -0,0 +1,184 @@ +These are some notes on installing ikiwiki on Mac OS X Snow Leopard. I have a three year old machine with a lot of stuff on it so it took quite a while, YMMV. + +The best part of installing ikiwiki was learning how to use git. I never used source control before but its pretty slick. + + +## installing git: + +cd /opt/ikiwiki/install + +curl http://kernel.org/pub/software/scm/git/git-(latest version).tar.gz -O + +tar xzvf git-(latest version).tar.gz + +cd git-(latest version) + +./configure --prefix=/usr/local + +make prefix=/usr/local all + +sudo make install + + +git config --global user.name "firstname lastname" + +git config --global user.email "email here" + +git config --global color.ui "auto" + + +curl http://www.kernel.org/pub/software/scm/git/git-manpages-1.7.3.1.tar.gz | sudo tar -xzC /usr/local/share/man/ + + +## installing ikiwiki: +I had terrible trouble installing ikiwiki. It turned out I had accidentally installed Perl through ports. Uninstalling that made everything install nicely. +I got an error on msgfmt. Turns out this is a program in gettext. I installed that and it fixed the error. + +cd .. + +git clone git://git.ikiwiki.info/ + +cd git.ikiwiki.info/ + +perl Makefile.PL LIB=/Library/Perl/5.10.0 + +make + +sudo make install + +when you make ikiwiki it gives you a .git folder with the ikiwiki files. Stay out of this folder. You want to learn how to create a clone and make all your changes in the clone. When you push the changes ikiwiki will update. I moved a file in this folder by accident because I named my working file the same and I couldn't get into the setup page. I had apparently messed up my ikiwiki git repository. I did a pull into my clone, deleted the repository and webserver/ cgi folders and ran a new setup. Then I did a git clone and dragged all my old files into the new clone. Did the git dance and did git push. Then the angels sang. + + +## using git from inside a git folder: + +start with git clone, then learn to do the git dance like this. + +git pull + +make your changes to your clone + +git commit -a -m "message here" + +git push + + +When you can't get into the setup page or you get strange behavior after a setup update the Utilities > Console app is your friend. + +## installing gitweb + +cd ../git-1.7.3.1/gitweb + +make GITWEB_PROJECTROOT="/opt/ikiwiki/" GITWEB_CSS="/gitweb.css" GITWEB_LOGO="/git-logo.png" GITWEB_FAVICON="/git-favicon.png" + +cp gitweb.cgi /Library/WebServer/CGI-Executables/ + +cp /usr/local/share/gitweb/static/git-favicon.png /Library/WebServer/Documents/ + +cp /usr/local/share/gitweb/static/git-logo.png /Library/WebServer/Documents/ + +cp /usr/local/share/gitweb/static/gitweb.css /Library/WebServer/Documents/ + +cp /usr/local/share/gitweb/static/gitweb.js /Library/WebServer/Documents/ + + +sudo chmod 2755 /Library/WebServer/CGI-Executables/gitweb.cgi + +sudo chmod 2755 /Library/WebServer/Documents/git-favicon.png + +sudo chmod 2755 /Library/WebServer/Documents/git-logo.png + +sudo chmod 2755 /Library/WebServer/Documents/gitweb.css + +sudo chmod 2755 /Library/WebServer/Documents/gitweb.js + + +## installing xapian: + +download xapian and omega + +I needed pcre: sudo ports install pcre + +./configure + +make + +sudo make install + + +## installing omega: + +I had a build error do to libiconv undefined symbols. sudo port deactivate libiconv took care of it. After install I had trouble with ikiwiki so I did a sudo port install libiconv and ikiwiki came back. + +./configure + +make + +sudo make install + + +## installing Search::Xapian from CPAN + +for some reason this wouldn't install using CPAN console so I went to CPAN online and downloaded the source. + +perl Makefile.PL + +make + +make test + +sudo make install + +it installed without issue so I'm baffled why it didn't install from command line. + + + ## setup file + _!/usr/bin/perl + _ Ikiwiki setup automator. + + _ This setup file causes ikiwiki to create a wiki, check it into revision + _ control, generate a setup file for the new wiki, and set everything up. + + _ Just run: ikiwiki -setup /etc/ikiwiki/auto.setup + + _By default, it asks a few questions, and confines itself to the user's home + _directory. You can edit it to change what it asks questions about, or to + _modify the values to use site-specific settings. + require IkiWiki::Setup::Automator; + + our $wikiname="your wiki"; + our $wikiname_short="yourwiki"; + our $rcs="git"; + our $admin="your name"; + use Net::Domain q{hostfqdn}; + our $domain="your.domain"; + + IkiWiki::Setup::Automator->import( + wikiname => $wikiname, + adminuser => [$admin], + rcs => $rcs, + srcdir => "/opt/ikiwiki/$wikiname_short", + destdir => "/Library/WebServer/Documents/$wikiname_short", + repository => "/opt/ikiwiki/$wikiname_short.".($rcs eq "monotone" ? "mtn" : $rcs), + dumpsetup => "/opt/ikiwiki/$wikiname_short.setup", + url => "http://$domain/$wikiname_short", + cgiurl => "http://$domain/cgi-bin/$wikiname_short/ikiwiki.cgi", + cgi_wrapper => "/Library/WebServer/CGI-Executables/$wikiname_short/ikiwiki.cgi", + adminemail => "your\@email.com", + add_plugins => [qw{goodstuff websetup}], + disable_plugins => [qw{}], + libdir => "/opt/ikiwiki/.ikiwiki", + rss => 1, + atom => 1, + syslog => 1, + ) + + +## turning on search plugin: + +I turned on the plugin from the setup page in ikiwiki but it gave an error when I went to search. Error "Error: /usr/lib/cgi-bin/omega/omega failed: No such file or directory". +I did a "find / -name "omega" -print" and found the omega program in "/usr/local/lib/xapian-omega/bin/omega". + +Then I went into the 2wiki.setup file and replaced the bad path, updated and badda-boom badda-bing. + + + diff --git a/doc/tips/ikiwiki_on_Mac_OS_X_Snow_Leopard/discussion.mdwn b/doc/tips/ikiwiki_on_Mac_OS_X_Snow_Leopard/discussion.mdwn new file mode 100644 index 000000000..ae3969879 --- /dev/null +++ b/doc/tips/ikiwiki_on_Mac_OS_X_Snow_Leopard/discussion.mdwn @@ -0,0 +1 @@ +If you want do a bunch of manual labor, this is good, but most people probably want to get ikiwiki via a package system. My Mac laptop's ikiwiki is installed from pkgsrc. --[[schmonz]] diff --git a/doc/tips/nearlyfreespeech.mdwn b/doc/tips/nearlyfreespeech.mdwn index 4b3b02eac..a3d1ec678 100644 --- a/doc/tips/nearlyfreespeech.mdwn +++ b/doc/tips/nearlyfreespeech.mdwn @@ -14,7 +14,8 @@ After you [get an account](https://www.nearlyfreespeech.net/about/start.php), create a site using their web interface. Mine is named `ikiwiki-test` and I used their DNS instead of getting my -own, resulting in <http://ikiwiki-test.nfshost.com/> +own, resulting in <http://ikiwiki-test.nfshost.com/>. (Not being kept up +anymore.) They gave me 2 cents free funding for signing up, which is enough to pay for 10 megabytes of bandwidth, or about a thousand typical page views, at diff --git a/doc/tips/nearlyfreespeech/discussion.mdwn b/doc/tips/nearlyfreespeech/discussion.mdwn index a003760b9..b76432566 100644 --- a/doc/tips/nearlyfreespeech/discussion.mdwn +++ b/doc/tips/nearlyfreespeech/discussion.mdwn @@ -9,3 +9,14 @@ BEGIN failed--compilation aborted at (eval 19) line 2. perl is 5.8.9 > This is fixed in 3.1415926. --[[Joey]] + + +Hi!<br /> +How can i upgrade my nearlyfreespeech installation of ikiwiki? To install it i have followed your instructions here.<br> +But now if I want to upgrade it to a newer version?<br /> +Thanks for your incredible work! + +> You can move `~/ikiwiki` out of the way and then re-download and install +> it ikiwiki. --[[Joey]] + +Thanks a lot Joey. :-) diff --git a/doc/tips/psgi.mdwn b/doc/tips/psgi.mdwn new file mode 100644 index 000000000..0d2eeefc8 --- /dev/null +++ b/doc/tips/psgi.mdwn @@ -0,0 +1,21 @@ +Here's the app.psgi file if you want to run ikiwiki with [PSGI](http://plackperl.org) instead of apache or other web servers: + + use Plack::App::CGIBin; + use Plack::Builder; + use Plack::App::File; + + builder { + mount '/ikiwiki.cgi' => Plack::App::CGIBin->new(file => './ikiwiki.cgi')->to_app; + enable "Plack::Middleware::Static", + path => sub { s!(^(?:/[^.]*)?/?$)!${1}/index.html! }, + root => '.'; + mount '/' => Plack::App::File->new(root => ".")->to_app; + }; + +Put it in your destdir and now your can run `plackup -p <port>`. + +Note that you should configure your `url` and `cgiurl` to point to the listening address of plackup. + +Also, the app.psgi residing in the destdir means that /app.psgi is accessible from the web server. + +Hopefully some day ikiwiki web ui will speak psgi natively. diff --git a/doc/tips/spam_and_softwaresites/discussion.mdwn b/doc/tips/spam_and_softwaresites/discussion.mdwn new file mode 100644 index 000000000..21f0a5d7e --- /dev/null +++ b/doc/tips/spam_and_softwaresites/discussion.mdwn @@ -0,0 +1,8 @@ +In the cleanup spam section: + +> Caveat: if there are no commits you want to keep (i.e. all the commits since the last merge into master are either spam or spam reverts) then git rebase will abort. + +Wouldn't it be enough then to use `git reset --hard` to the desired last good commit? + +regards, +iustin diff --git a/doc/tips/untrusted_git_push.mdwn b/doc/tips/untrusted_git_push.mdwn index 3573a0ddf..b74e0e9d9 100644 --- a/doc/tips/untrusted_git_push.mdwn +++ b/doc/tips/untrusted_git_push.mdwn @@ -112,11 +112,3 @@ 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_and_ikiwiki.mdwn b/doc/tips/vim_and_ikiwiki.mdwn new file mode 100644 index 000000000..e4136aa5d --- /dev/null +++ b/doc/tips/vim_and_ikiwiki.mdwn @@ -0,0 +1,28 @@ +# Vim and ikiwiki + +## Syntax highlighting + +[ikiwiki-syntax](http://www.vim.org/scripts/script.php?script_id=3156) is a vim +syntax highlighting file for ikiwiki [[ikiwiki/markdown]] files. It highlights +directives and wikilinks. It only supports prefixed directives, i.e., +\[[!directive foo=bar baz]], not the old format with spaces. + +------ + +The previous syntax definition for ikiwiki links is at [[vim_syntax_highlighting/ikiwiki.vim]]; however, +it seems to not be [[maintained +anymore|forum/navigation_of_wiki_pages_on_local_filesystem_with_vim#syn-maintenance]], +and it has some [[issues|forum/ikiwiki_vim_syntaxfile]]. + +## Page creation and navigation + +The [ikiwiki-nav](http://www.vim.org/scripts/script.php?script_id=2968) package +is a vim plugin that enables you to do the following from inside vim: + + * Jumping to the file corresponding to the wikilink under the cursor. + * Creating the file corresponding to the wikilink under the cursor (including + directories if necessary.) + * Jumping to the previous/next wikilink in the current file. + * Autocomplete link names. + +Download it from [here](http://www.vim.org/scripts/script.php?script_id=2968) diff --git a/doc/tips/vim_syntax_highlighting.mdwn b/doc/tips/vim_syntax_highlighting.mdwn index bf7104aec..8f2fdc1f0 100644 --- a/doc/tips/vim_syntax_highlighting.mdwn +++ b/doc/tips/vim_syntax_highlighting.mdwn @@ -1,3 +1,8 @@ +This page is deprecated. See [[tips/vim_and_ikiwiki]] for the most up to date +content + +-------- + [ikiwiki-syntax](http://www.vim.org/scripts/script.php?script_id=3156) is a vim syntax highlighting file for ikiwiki [[ikiwiki/markdown]] files. It highlights directives and wikilinks. It only supports prefixed directives, i.e., diff --git a/doc/todo/Add_nicer_math_formatting.mdwn b/doc/todo/Add_nicer_math_formatting.mdwn index 041eaee11..3a5e94a14 100644 --- a/doc/todo/Add_nicer_math_formatting.mdwn +++ b/doc/todo/Add_nicer_math_formatting.mdwn @@ -1,5 +1,26 @@ -It would be nice to add nicer math formatting. I currently use the [[plugins/teximg]] plugin, but I wonder if [jsMath](http://www.math.union.edu/~dpvc/jsMath/) wouldn't be a better option. +It would be nice to add nicer math formatting. I currently use the +[[plugins/teximg]] plugin, but I wonder if +[jsMath](http://www.math.union.edu/~dpvc/jsMath/) wouldn't be a better option. [[Will]] +> I've looked at jsmath (which is nicely packaged in Debian), and +> I agree that this is nicer than TeX images. That text-mode browsers +> get to see LaTeX as a fallback is actually a nice feature (better +> than nothing, right? :) That browsers w/o javascript will not be able to +> see the math either is probably ok. +> +> A plugin would probably be a pretty trivial thing to write. +> It just needs to include the javascript files, +> and slap a `<div class="math"> avound the user's code`, then +> call `jsMath.Process(document);` at the end of the page. +> +> My only concern is security: Has jsMath's parser been written +> to be safe when processing untrusted input? Could a user abuse the +> parser to cause it to emit/run arbitrary javascript code? +> I've posted a question about this to its forum: --[[Joey]] +> <https://sourceforge.net/projects/jsmath/forums/forum/592273/topic/3831574> + +I think [mathjax](http://www.mathjax.org/) would be the best option. This is the math rendering engine used in mathoverflow. + [[!tag wishlist]] diff --git a/doc/todo/Improving_the_efficiency_of_match__95__glob.mdwn b/doc/todo/Improving_the_efficiency_of_match__95__glob.mdwn new file mode 100644 index 000000000..4e1df3381 --- /dev/null +++ b/doc/todo/Improving_the_efficiency_of_match__95__glob.mdwn @@ -0,0 +1,228 @@ +[[!template id=gitbranch branch=smcv/ready/glob-cache + author="[[KathrynAndersen]], [[smcv]]"]] +[[!tag patch]] + +I've been profiling my IkiWiki to try to improve speed (with many pages makes speed even more important) and I've written a patch to improve the speed of match_glob. This matcher is a good one to improve the speed of, because it gets called so many times. + +Here's my patch - please consider it! -- [[KathrynAndersen]] + +> It seems to me as though changing `glob2re` to return qr/$re/, and calling +> `memoize(glob2re)` next to the other memoize calls, would be a less +> verbose way to do this? --[[smcv]] + +>> I think so, yeah. Anyway, do you have any benchmark results handy, +>> Kathryn? --[[Joey]] + +>>> See below. +>>> Also, would it make more sense for glob2re to return qr/^$re$/i rather than qr/$re/? Everything that uses glob2re seems to use + $foo =~ /^$re$/i +>>> rather than /$re/ so I think that would make sense. +>>> -- [[KathrynAndersen]] + +>>>> Git branch `smcv/ka-glob-cache` has Kathryn's patch. Git +>>>> branch `smcv/memoize-glob2re` does as I suggested, which +>>>> is less verbose than Kathryn's patch but also not as +>>>> fast; I'm not sure why, tbh. --[[smcv]] + +>>>>> I think it's because my patch focuses on match_glob while the memoize patch focuses on `glob2re`, and `glob2re` is called in `filecheck`, `meta` and `po` as well as in `match_glob` and `match_user`; thus the memoized `glob2re` is dealing with a bigger set of globs to look up, and thus could be just that little bit slower. -- [[KathrynAndersen]] + +>>>>>> What may be going on is that glob2re is already a fairly fast +>>>>>> function, so the overhead of memoizing it with the very generic +>>>>>> `_memoizer` (see its source) swamps the memoization gain. Note +>>>>>> that the few functions memoized with the Memoizer before were much +>>>>>> more expensive, so that little overhead was acceptable then. +>>>>>> +>>>>>> It also may be that Kathryn's patch is slightly faster due to using +>>>>>> the construct `$foo =~ $regexp` rather than `$foo =~ /$regexp/` +>>>>>> (probably avoids a copy or something like that internally) -- +>>>>>> this despite checking both `exists` and `defined` on the hash, which +>>>>>> should be reundant AFAICS. +>>>>>> +>>>>>> My guess is that the best of both worlds would be to move +>>>>>> the byhand memoization to glob2re and have it return a compiled +>>>>>> `/^/i` regexp that can be used without further modifiction in most +>>>>>> cases. --[[Joey]] + +>>>>>>> Done, see `smcv/ready/glob-cache` and `smcv/glob-cache-too-far`. +>>>>>>> +>>>>>>> Kathryn's patch is a significant improvement; my first patch on top of +>>>>>>> that is a trivial cleanup that speeds it up a little, and the next two +>>>>>>> patches (using precompiled regexes) have surprisingly little effect +>>>>>>> (they don't slow it down either though, so either omit them or merge +>>>>>>> them, whichever). Detailed benchmark results below. +>>>>>>> +>>>>>>> Moving the memoization to `glob2re` actually seems to slow things down +>>>>>>> again - I suspect the docwiki has few enough mentions of `user()` etc. +>>>>>>> that caching them is a waste of time, but perhaps it's not the most +>>>>>>> representative. +>>>>>>> --[[smcv]] + +[[done]] --[[Joey]] + +-------------------------------------------------------------- + +[[!toggle id="smcv-benchmark" text="current benchmarks"]] + +[[!toggleable id="smcv-benchmark" text=""" +master at time of branch: + + time elapsed (wall): 29.6348 + time running program: 24.9212 (84.09%) + time profiling (est.): 4.7136 (15.91%) + number of calls: 1360181 + number of exceptions: 13 + + %Time Sec. #calls sec/call F name + 13.24 3.2986 3408 0.000968 Text::Balanced::_match_tagged + 10.94 2.7253 79514 0.000034 IkiWiki::PageSpec::match_glob + 3.19 0.7952 59454 0.000013 <anon>:IkiWiki/Plugin/inline.pm:223 + +`Improve the speed of match_glob`: + + time elapsed (wall): 27.9755 + time running program: 23.5293 (84.11%) + time profiling (est.): 4.4461 (15.89%) + number of calls: 1280875 + number of exceptions: 13 + + %Time Sec. #calls sec/call F name + 14.56 3.4257 3408 0.001005 Text::Balanced::_match_tagged + 7.82 1.8403 79514 0.000023 IkiWiki::PageSpec::match_glob + 3.27 0.7698 59454 0.000013 <anon>:IkiWiki/Plugin/inline.pm:223 + +`match_glob: streamline glob cache slightly`: + + time elapsed (wall): 27.5753 + time running program: 23.1714 (84.03%) + time profiling (est.): 4.4039 (15.97%) + number of calls: 1280875 + number of exceptions: 13 + + %Time Sec. #calls sec/call F name + 14.09 3.2637 3408 0.000958 Text::Balanced::_match_tagged + 7.74 1.7926 79514 0.000023 IkiWiki::PageSpec::match_glob + 3.30 0.7646 59454 0.000013 <anon>:IkiWiki/Plugin/inline.pm:223 + +`glob2re: return a precompiled, anchored case-insensitiv...`: + + time elapsed (wall): 27.5656 + time running program: 23.1464 (83.97%) + time profiling (est.): 4.4192 (16.03%) + number of calls: 1282189 + number of exceptions: 13 + + %Time Sec. #calls sec/call F name + 14.21 3.2891 3408 0.000965 Text::Balanced::_match_tagged + 7.72 1.7872 79514 0.000022 IkiWiki::PageSpec::match_glob + 3.32 0.7678 59454 0.000013 <anon>:IkiWiki/Plugin/inline.pm:223 + +`make use of precompiled regex objects`: + + time elapsed (wall): 27.5357 + time running program: 23.1289 (84.00%) + time profiling (est.): 4.4068 (16.00%) + number of calls: 1281981 + number of exceptions: 13 + + %Time Sec. #calls sec/call F name + 14.17 3.2776 3408 0.000962 Text::Balanced::_match_tagged + 7.70 1.7814 79514 0.000022 IkiWiki::PageSpec::match_glob + 3.35 0.7756 59454 0.000013 <anon>:IkiWiki/Plugin/inline.pm:223 + +`move memoization from match_glob to glob2re`: + + time elapsed (wall): 28.7677 + time running program: 23.9473 (83.24%) + time profiling (est.): 4.8205 (16.76%) + number of calls: 1360181 + number of exceptions: 13 + + %Time Sec. #calls sec/call F name + 13.98 3.3469 3408 0.000982 Text::Balanced::_match_tagged + 8.85 2.1194 79514 0.000027 IkiWiki::PageSpec::match_glob + 3.24 0.7750 59454 0.000013 <anon>:IkiWiki/Plugin/inline.pm:223 + +--[[smcv]] +"""]] + +-------------------------------------------------------------- + +[[!toggle id="ka-benchmarks" text="Kathryn's benchmarks"]] + +[[!toggleable id="ka-benchmarks" text=""" +Benchmarks done with Devel::Profile on the same testbed IkiWiki setup. I'm just showing the start of the profile output, since that's what's relevant. + +Before: +<pre> +time elapsed (wall): 27.4173 +time running program: 22.5909 (82.40%) +time profiling (est.): 4.8264 (17.60%) +number of calls: 1314729 +number of exceptions: 65 + +%Time Sec. #calls sec/call F name +11.05 2.4969 62333 0.000040 IkiWiki::PageSpec::match_glob + 4.10 0.9261 679 0.001364 Text::Balanced::_match_tagged + 2.72 0.6139 59812 0.000010 IkiWiki::SuccessReason::merge_influences +</pre> + +After: +<pre> +time elapsed (wall): 26.1843 +time running program: 21.5673 (82.37%) +time profiling (est.): 4.6170 (17.63%) +number of calls: 1252433 +number of exceptions: 65 + +%Time Sec. #calls sec/call F name + 7.66 1.6521 62333 0.000027 IkiWiki::PageSpec::match_glob + 4.33 0.9336 679 0.001375 Text::Balanced::_match_tagged + 2.81 0.6057 59812 0.000010 IkiWiki::SuccessReason::merge_influences +</pre> + +Note that the seconds per call for match_glob in the "after" case has gone down by about a third. + +K.A. +"""]] + +-------------------------------------------------------------- + +[[!toggle id="ka-patch" text="Kathryn's original patch"]] + +[[!toggleable id="ka-patch" text=""" + +<pre> +diff --git a/IkiWiki.pm b/IkiWiki.pm +index 08a3d78..c187b98 100644 +--- a/IkiWiki.pm ++++ b/IkiWiki.pm +@@ -2482,6 +2482,8 @@ sub derel ($$) { + return $path; + } + ++my %glob_cache; ++ + sub match_glob ($$;@) { + my $page=shift; + my $glob=shift; +@@ -2489,8 +2491,15 @@ sub match_glob ($$;@) { + + $glob=derel($glob, $params{location}); + +- my $regexp=IkiWiki::glob2re($glob); +- if ($page=~/^$regexp$/i) { ++ # Instead of converting the glob to a regex every time, ++ # cache the compiled regex to save time. ++ if (!exists $glob_cache{$glob} ++ or !defined $glob_cache{$glob}) ++ { ++ my $re=IkiWiki::glob2re($glob); ++ $glob_cache{$glob} = qr/^$re$/i; ++ } ++ if ($page =~ $glob_cache{$glob}) { + if (! IkiWiki::isinternal($page) || $params{internal}) { + return IkiWiki::SuccessReason->new("$glob matches $page"); + } +</pre> +"""]] +-------------------------------------------------------------- diff --git a/doc/todo/__42__forward__42__ing_functionality_for_the_meta_plugin.mdwn b/doc/todo/__42__forward__42__ing_functionality_for_the_meta_plugin.mdwn index 61b19d302..b3804d652 100644 --- a/doc/todo/__42__forward__42__ing_functionality_for_the_meta_plugin.mdwn +++ b/doc/todo/__42__forward__42__ing_functionality_for_the_meta_plugin.mdwn @@ -4,7 +4,7 @@ to the [[`meta`_plugin|plugins/meta]]. > [[done]], with some changes --[[Joey]] Find the most recent version at -<http://www.schwinge.homeip.net/~thomas/tmp/meta_forward.patch>. +<http://schwinge.homeip.net/~thomas/tmp/meta_forward.patch>. I can't use `scrub(...)`, as that will strip out the forwarding HTML command. How to deal with that? diff --git a/doc/todo/alias_directive.mdwn b/doc/todo/alias_directive.mdwn new file mode 100644 index 000000000..71a2efc76 --- /dev/null +++ b/doc/todo/alias_directive.mdwn @@ -0,0 +1,72 @@ +An alias directive could work like an inverse redirect, but in a more +maintainable way. Currently, a page might have several redirects leading to it, +without an easy way of enumerating them. Therefore, the following directive is +suggested for addition (possibly by means of a plugin): + +> The `alias` and `aliastext` directives implicitly create +> redirect pages to the page they are used on. If two or more pages claim a +> non-existing page to be an alias, a disambiguation page will automatically +> generated. If an existing page is claimed as an alias, it will be prefixed +> with a note that its topic is also an alias for other pages. +> +> All aliases to a page are automatically listed below the backlink and tag +> lists at the bottom of a page by default. This can be configured globally by +> setting the `alias_list` configuration option to `false`, or set explicitly +> per alias by specifying `list=true` or `list=false`. +> +> Similar to the `taglink` directive, `aliastext` produces the alias name as +> well as registering it. +> +> ## Usage example +> +> `Greece.mdwn`: +> +> > Greece, also known as \[[!aliastext Hellas]] and officially the +> > \[[!aliastext "Hellenic Republic"]], is a … +> > +> > <!-- there are so many people who misspell this, let's create a redirect --> +> > \[[!alias Grece list=false]] +> +> This page by itself will redirect from the "Hellas", "Hellenic Republic" and +> "Grece" pages as if they both contained just: +> +> > \[[!meta redir="Greece"]] +> +> If, on the other hand, `Hellas Planitia` also claims `[[!alias Hellas]]`, the +> Hellas page will look like this: +> +> > **Hellas** is an alias for the following pages: +> > +> > * \[[Greece]] +> > * \[[Hellas Planitia]] + +The proposed plugin/directive could be extended, eg. by also including +old-style redirects in the alias list, but that might introduce unwanted +coupling with the meta directive. + +----------------- + +On second thought, implementing this might have similarities with +[[todo/auto-create tag pages according to a template]] -- the auto-created +pages would, if the way of the alias directive is followed, not create physical +files, though, but be created just when someone edits them. + +If multiple plugins do such a trick, they would have to fight over who comes +first. If, for example, we have a setup where not yet created tag pages are +automatically generated as "\[[!inline pages="link(<TMPL_VAR TAG>)" +archive="yes"]]" and aliases are enabled, and a non-tag pages grabs a tag as an +alias (as to redirect all taglinks of the tag to itself), there are two +possibilities: + +* The autotag plugin comes first: + * autotag sees the missing tag and creates its "\[[!inline" stuff + * alias sees that there is already content and adds its prefix +* The alias plugin comes first (this is the prefered way): + * alias sees the empty page, sees it is not contested by other alias + directives and creates its "\[[!meta" redirect + * autotag sees there is already content and doesn't do anything + +That issue could be handled with "priority number" on the hook, with plugins +with a lower number being called first. + +[[!tag wishlist]] diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index 7eb404910..16dc78fb2 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -248,4 +248,20 @@ I've tested it fairly thouroughly. --[[Joey]] [a358d74bef51dae31332ff27e897fe04834571e6]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=a358d74bef51dae31332ff27e897fe04834571e6 (commitdiff for a358d74bef51dae31332ff27e897fe04834571e6) [981400177d68a279f485727be3f013e68f0bf691]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=981400177d68a279f485727be3f013e68f0bf691 (commitdiff for 981400177d68a279f485727be3f013e68f0bf691) +------------------- + +Even if this is already marked as done, I'd like to suggest an alternative +solution: + +Instead of creating a file that gets checked in into the RCS, the source files +could be left out and the output files be written as long as there is no +physical source file (think of a virtual underlay). Something similar would be +required to implement [[todo/alias directive]], which couldn't be easily done +by writing to the RCS as the page's contents can change depending on which +other pages claim it as an alias. --[[chrysn]] + +I agree with [[chrysn]]. In fact, is there any good reason that the core tag plugin doesn't do this? The current usability is horrible, to the point that I have gone 2.5 years with Ikiwiki and haven't yet started using tags. -- + +> See [[todo/transient_pages]] for progress on this. --[[smcv]] + [[!tag done]] diff --git a/doc/todo/autoindex_should_use_add__95__autofile.mdwn b/doc/todo/autoindex_should_use_add__95__autofile.mdwn new file mode 100644 index 000000000..19c5004f8 --- /dev/null +++ b/doc/todo/autoindex_should_use_add__95__autofile.mdwn @@ -0,0 +1,4 @@ +`add_autofile` is a generic version of [[plugins/autoindex]]'s code, +so the latter should probably use the former. --[[smcv]] + +> See [[todo/transient_pages]] for progress on this. --[[smcv]] diff --git a/doc/todo/capitalize_title.mdwn b/doc/todo/capitalize_title.mdwn new file mode 100644 index 000000000..3e8366dd3 --- /dev/null +++ b/doc/todo/capitalize_title.mdwn @@ -0,0 +1,31 @@ +Here I propose an option (with a [[patch]]) to capitalize the first letter (ucfirst) of default titles : filenames and urls can be lowercase but title are displayed with a capital first character (filename = "foo.mdwn", pagetitle = "Foo"). Note that \[[!meta title]] are unaffected (no automatic capitalization). Comments please :) --[[JeanPrivat]] +<pre><code> +diff --git a/IkiWiki.pm b/IkiWiki.pm +index 6da2819..fd36ec4 100644 +--- a/IkiWiki.pm ++++ b/IkiWiki.pm +@@ -281,6 +281,13 @@ sub getsetup () { + safe => 0, + rebuild => 1, + }, ++ capitalize => { ++ type => "boolean", ++ default => undef, ++ description => "capitalize the first letter of page titles", ++ safe => 1, ++ rebuild => 1, ++ }, + userdir => { + type => "string", + default => "", +@@ -989,6 +996,10 @@ sub pagetitle ($;$) { + $page=~s/(__(\d+)__|_)/$1 eq '_' ? ' ' : "&#$2;"/eg; + } + ++ if ($config{capitalize}) { ++ $page = ucfirst $page; ++ } ++ + return $page; + } +</code></pre> diff --git a/doc/todo/configurable_tidy_command_for_htmltidy.mdwn b/doc/todo/configurable_tidy_command_for_htmltidy.mdwn new file mode 100644 index 000000000..e317184b5 --- /dev/null +++ b/doc/todo/configurable_tidy_command_for_htmltidy.mdwn @@ -0,0 +1,8 @@ +[[!tag patch patch]] + +I was trying to get htmltidy to [play nicely with MathML][play]. Unfortunately, I couldn't construct a command line that I was happy with, but along the way I altered htmltidy to allow a configurable command line. This seemed like a generally useful thing, so I've published my [patch][] as a Git branch. + +[play]: http://lists.w3.org/Archives/Public/html-tidy/2006JanMar/0052.html +[patch]: http://www.physics.drexel.edu/~wking/code/git/git.php?p=ikiwiki.git&a=commitdiff&h=408ee89fd7c1dc70510385a7cf263a05862dda97&hb=e65ce4f0937eaf622846c02a9d39fa7aebe4af12 + +> Thanks, [[done]] --[[Joey]] diff --git a/doc/todo/countdown_directive.mdwn b/doc/todo/countdown_directive.mdwn new file mode 100644 index 000000000..61c36204c --- /dev/null +++ b/doc/todo/countdown_directive.mdwn @@ -0,0 +1,5 @@ +I'd love to have a countdown directive, which would take a timestamp to count down to and generate a JavaScript timer in the page. + +Ideally I'd also like to either have parameters providing content to show before and after the time passes, or integration with existing conditional directives to do the same thing. + +[[!tag wishlist]] diff --git a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn index 8721277aa..77e46049f 100644 --- a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn +++ b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn @@ -42,3 +42,11 @@ browsers emulate it. [[done]] Wouldn't it be possible to just implement an integer-valued setting for this, accessible via the "Setup" wiki page? This would require a wiki regen, but such a setting would not be changed frequently I suppose. Also, Mediawiki has this implemented as a per-user setting (two settings, actually, -- number of rows and columns of the edit area); such a per-user setting would be the best possible implementation, but I'm not sure if ikiwiki already supports per-user settings. Please consider implementing this as the current 20 rows is a great PITA for any non-trivial page. > I don't think it would need a wiki rebuild, as the textarea is generated dynamically by the CGI when you perform a CGI action, and (as far as I know) is not cooked into any static content. -- [[Jon]] + +>> There is no need for a configuration setting for this -- to change +>> the default height from 20 rows to something else, you can just put +>> something like this in your `local.css`: --[[Joey]] + + #editcontent { + height: 50em; + } diff --git a/doc/todo/inline_raw_files.mdwn b/doc/todo/inline_raw_files.mdwn new file mode 100644 index 000000000..100c07288 --- /dev/null +++ b/doc/todo/inline_raw_files.mdwn @@ -0,0 +1,61 @@ +[[!template id=gitbranch branch=wtk/master author="[[wtk]]"]] + +summary +======= + +Extend inlining to handle raw files (files with unrecognized extensions). + +Also raise an error in `IkiWiki::pagetype($file)` if `$file` is blank, which avoids trying to do much with missing files, etc. + +I'm using the new code in my [blog][]. + +[blog]: http://www.physics.drexel.edu/~wking/unfolding-disasters/posts/yacc2dot/ + +usage +===== + + \[[!inline pagenames="somefile.txt" template="raw" feeds="no"]] + + +> But inline already supports raw files in two ways: +> +> * setting raw=yes will cause a page to be inlined raw without +> using any template, as if it were part of the page at the location +> of the inline +> * otherwise, the file becomes an enclosure in the rss feed, for use with +> podcasting. +> +> So I don't see the point of your patch. Although since your text +> editor seems to like to make lots of whitespace changes, it's possible +> I missed something in the large quantity of noise introduced by it. +> --[[Joey]] + +>> As I understand it, setting `raw=yes` causes the page to be inlined +>> as if the page contents had appeared in place of the directive. The +>> content is then processed by whatever `htmlize()` applies to the +>> inlining page. I want the inlined page to be unprocessed, and +>> wrapped in `<pre><code>...</code></pre>` (as they are on the blog +>> post I link to above). +>> +>> Enclosures do not include the page contents at all, just a link to +>> them. I'm trying to inline the content so I can comment on it from +>> the inlining page. +>> +>> Apologies for my cluttered version history, I should have branched my +>> earlier changes off to make things clearer. I tried to isolate my +>> whitespace changes (fixes?) in c9ae012d245154c3374d155958fcb0b60fda57ce. +>> 157389355d01224b2d3c3f6e4c1eb42a20ec8a90 should hold all the content +>> changes. +>> +>> A list of other things globbed into my master branch that should have +>> been separate branches: +>> +>> * Make it easy to select a Markdown executable for mdwn.pm. +>> * Included an updated form of +>> [[Javier Rojas' linktoimgonly.pm|forum/link_to_an_image_inside_the_wiki_without_inlining_it]]. +>> * Included an updated form of +>> [Jason Blevins' mdwn_itex.pm](http://jblevins.org/git/ikiwiki/plugins.git/plain/mdwn_itex.pm). +>> * Assorted minor documentation changes. +>> +>> --[[wtk]] + diff --git a/doc/todo/latex.mdwn b/doc/todo/latex.mdwn index 4363003c1..76bb69c9e 100644 --- a/doc/todo/latex.mdwn +++ b/doc/todo/latex.mdwn @@ -9,6 +9,8 @@ of the ikiwiki [[/logo]]. > [[users/JasonBlevins]] has also a plugin for including [[LaTeX]] expressions (by means of `itex2MML`) -- [[plugins/mdwn_itex]] (look at his page for the link). --Ivan Z. +>> I've [updated](http://www.physics.drexel.edu/~wking/unfolding-disasters/posts/mdwn_itex/) Jason's plugin for ikiwiki 3.x. --W. Trevor King + ---- ikiwiki could also support LaTeX as a document type, again rendering to HTML. diff --git a/doc/todo/mirrorlist_with_per-mirror_usedirs_settings.mdwn b/doc/todo/mirrorlist_with_per-mirror_usedirs_settings.mdwn index 6ca9962ba..88c82f66c 100644 --- a/doc/todo/mirrorlist_with_per-mirror_usedirs_settings.mdwn +++ b/doc/todo/mirrorlist_with_per-mirror_usedirs_settings.mdwn @@ -21,4 +21,54 @@ and decided this time it was really needed to implement this feature. --[[intrigeri]] +> Ping. --[[intrigeri]] + [[!tag patch]] + +>> (I'm not an ikiwiki committer, opinions may vary.) +>> +>>> In my opinion, you're an ikiwiki committer! --[[Joey]] +>> +>> This would be easier to review if there weren't a million merges from +>> master; perhaps either leave a branch as-is, or rebase it, or merge +>> only at "significant" times like after a release? +>> +>> I believe Joey's main objection to complex $config entries is that +>> it's not at all clear what [[plugins/websetup]] would do with them. +>> Would something like this make a reasonable alternative? +>> +>> $config{mirrorlist} = ["nousedirs|file:///home/intrigeri/wiki", +>> "usedirs|http://example.com/wiki", "http://example.net"]; +>> +>> From how I understand tainting, this: +>> +>> $untainted{$_} = possibly_foolish_untaint($tainted->{$_}) +>> +>> probably needs to untaint the key too: +>> +>> my $key = possibly_foolish_untaint($_); +>> $untainted{$key} = possibly_foolish_untaint($tainted->{key}); +>> +>> --[[smcv]] + +>>> You are fully right about the complex `$config` entries. I'll +>>> convert this to use what you are suggesting, i.e. what we ended up +>>> choosing for the `po_slave_languages` setting. +>>> +>>> About the merges in this branch: Joey told me once he did not care +>>> about this; moreover the `--no-merges` git log option makes it +>>> easy to filter these out. I'll try merging tagged releases only in +>>> the future, though. +>>> +>>> --[[intrigeri]] + +>>>> FWIW, I don't care about merge commits etc because I review +>>>> `git diff ...intrigeri/mirrorlist` -- and if I want to dig deeper +>>>> into the why of some code, I'll probably checkout the branch and +>>>> use git blame. +>>>> +>>>> I agree with what smcv said, my other concern though is that +>>>> this is such an edge case, that supporting it just adds clutter. +>>>> Have to wonder if it wouldn't perhaps be better to do something +>>>> using the goto plugin and cgiurl, so that the mirror doesn't have +>>>> to know about the configuration of the other mirror. --[[Joey]] diff --git a/doc/todo/passwordauth:_sendmail_interface.mdwn b/doc/todo/passwordauth:_sendmail_interface.mdwn index 29f28ca32..556240964 100644 --- a/doc/todo/passwordauth:_sendmail_interface.mdwn +++ b/doc/todo/passwordauth:_sendmail_interface.mdwn @@ -35,7 +35,7 @@ in the ikiwiki source code, where emailing is done. OK, so I'll have a look at replacing all email handling with *Email::Send*. [[!tag patch]] -*<http://www.thomas.schwinge.homeip.net/tmp/ikiwiki-sendmail.patch>* +*<http://schwinge.homeip.net/~thomas/tmp/ikiwiki-sendmail.patch>* Remaining TODOs: diff --git a/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn b/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn index 402f70b79..9bb9c72c4 100644 --- a/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn +++ b/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn @@ -43,3 +43,18 @@ Re the meta title escaping issue worked around by `change`. >>>>>> did not dare to. I'll try this. --[[intrigeri]] >>>>>>> Done in my po branch, please have a look. --[[intrigeri]] + +>>>>>>>> I've merged it. Didn't look at the po.pm changes closely; +>>>>>>>> assume they're ok. [[done]] --[[Joey]] +>>>>>>>> +>>>>>>>> My thinking about the reordering being safe is that +>>>>>>>> the relative ordering of scan and preprocess in scan mode hooks +>>>>>>>> has not been defined before, so it should be ok to define it. :) +>>>>>>>> +>>>>>>>> And as to possible breakage from things that assumed the old +>>>>>>>> ordering, such a thing would need to have a scan hook and a +>>>>>>>> preprocess in scan mode hook, and the two hooks would need to +>>>>>>>> populate the same data structure with conflicting information, +>>>>>>>> in order for there to be a problem. That seems highly unlikely +>>>>>>>> and would be pretty broken on its own. And no plugin in ikiwiki +>>>>>>>> itself has both types of hooks. --[[Joey]] diff --git a/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn b/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn index 0801f7fcd..5d0318ae1 100644 --- a/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn +++ b/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn @@ -9,3 +9,5 @@ files from the source repository when it has been disabled? >> in most cases, it is not, thanks to .gitignore or similar, but we >> can't be sure. So I just can't decide it is needed to call >> `rcs_remove` rather than a good old `unlink`. --[[intrigeri]] + +>>> I guess you could call `rcs_remove` followed by `unlink`. --[[Joey]] diff --git a/doc/todo/po:_rethink_pagespecs.mdwn b/doc/todo/po:_rethink_pagespecs.mdwn index 50c10c5db..98c7ff655 100644 --- a/doc/todo/po:_rethink_pagespecs.mdwn +++ b/doc/todo/po:_rethink_pagespecs.mdwn @@ -9,3 +9,32 @@ default when locking pages.) --[[Joey]] > list must be restricted to pages in the master (or current?) > language, and the ones that should not. The only solution I can see > to this surprising behaviour is: documentation. --[[intrigeri]] + +>> Well, a sorting criteria might be that if a PageSpec is used +>> with a specified locaction, as happens whenever a PageSpec is +>> used on a page, then it should match only `currentlang()`. If it +>> is used without a location, as in the setup file, then no such limit. + +>>> Ok. --[[intrigeri]] + +>> Note that +>> `match_currentlang` currently dies if called w/o a location -- if +>> it instead was always true w/o a location, this would just mean that +>> all pagespecs should have `and currentlang()` added to them. How to +>> implement that? All I can think of doing is wrapping +>> `pagespec_translate`. + +>>> Seems doable. --[[intrigeri]] + +>> The only case I've found where it does make sense to match other +>> language pages is on `l10n.ikiwiki.info` when listing pages that +>> need translation. +>> +>> Otherwise, it can be documented, but that's not really enough; +>> a user who makes a site using auto-blog.setup and enables po will +>> get a really screwed up blog that lists translations as separate posts +>> and needs significant work to fix. I have thought about making +>> `match_currentlang` a stub in IkiWiki (done in my currentlang branch), +>> so I can use it in all the PageSpecs in the example blog etc, but I +>> can't say I love the idea. +>> --[[Joey]] diff --git a/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn b/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn index c4e78ca0b..d55fc0aa8 100644 --- a/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn +++ b/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn @@ -5,9 +5,14 @@ features and thus makes it rather hard to give an ikiwiki site a consistent look. If you browse the templates provided in the tarball, you'll notice that more than one of them contain the `<html>` tag, which is unnecessary. +> Note that is no longer true, and I didn't have to do such an intrusive +> change to fix it either. --[[Joey]] + Maybe it's just me, I also find HTML::Template cumbersome to use, due in part to its use of capital letters. +> Its entirely optional use of capital letters? --[[Joey]] + Finally, the software seems unmaintained: the mailing list and searchable archives linked from <http://html-template.sourceforge.net/html_template.html#frequently%20asked%20questions> @@ -58,3 +63,25 @@ Yes, Template::Toolkit is very powerful. But I think it's somehow overkill for a I'd have to agree that Template::Toolkit is overkill and personally I'm not a fan, but it is very popular (there is even a book) and the new version (3) is alleged to be much more nimble than current version. --[[ajt]] HTML::Template's HTML-like markup prevents me from editing templates in KompoZer or other WYSIWYG HTML editors. The editor tries to render the template markup rather than display it verbatim, and large parts of the template become invisible. A markup syntax that doesn't confuse editors (such as Template::Toolkit's "[% FOO %]") may promote template customization. The ability to replace the template engine would be within the spirit of ikiwiki's extensibility. --Rocco + + +I agree that being able to replace the template toolkit would be a great piece of modularity, and one I would use. If I could use the slot-based filling and the conditional logic from Template::Toolkit, we could build much more flexible inline and archivepage templates that would look different depending on where in the wiki we use them. Some of this can currently be accomplished with separate templates for each use case and a manual call to the right template in the !inline directive, but this is limited, cumbersome, and makes it difficult to reuse bits of formatting by trapping all of that information in multiple template files. -Ian + +> I don't wish HTML::Template to be *replaced* by Template::Toolkit - as +> others have said above, it's overkill for my needs. However, I also +> agree that HTML::Template has its own problems too. The idea of making +> the template system modular, with a choice of which backend to use - I +> really like that idea. It would enable me to use some other template +> system I like better, such as Text::Template or Text::NeatTemplate. But I +> think it would be a lot of work to implement, though perhaps no more work +> than making the revision-control backend modular, I guess. One would +> need to write an IkiWiki template interface that didn't care what the +> backend was, and yet is somehow still flexible enough to take advantage +> of special features of different backends. There are an *awful lot* of +> things that use templates - not just the `pagetemplate` and `template` +> plugins, but a number of others which have specialized templates of their +> own. -- [[KathrynAndersen]]a + +>> A modular template system in ikiwiki is unlikely, as template objects +>> are part of the API, notably the `pagetemplate` hook. Unless the other +>> system has a compatible template object. --[[Joey]] diff --git a/doc/todo/selective_more_directive.mdwn b/doc/todo/selective_more_directive.mdwn new file mode 100644 index 000000000..2a9998205 --- /dev/null +++ b/doc/todo/selective_more_directive.mdwn @@ -0,0 +1,28 @@ +I'm setting up a blog for NaNoWriMo and other story-writing, which means long posts every day. I want to have excerpts on the front page, which link to the full length story posts. I also want a dedicated page for each story which inlines the story in full and in chronological order. I can use the "more" directive to achieve this effect on the front page but then it spoils the story page. My solution was to add a pages= parameter to the more directive to make it more selective. + + --- /usr/share/perl5/IkiWiki/Plugin/more.pm 2010-10-09 00:09:24.000000000 +0000 + +++ .ikiwiki/IkiWiki/Plugin/more.pm 2010-11-01 20:24:59.000000000 +0000 + @@ -26,7 +26,10 @@ + + $params{linktext} = $linktext unless defined $params{linktext}; + + - if ($params{page} ne $params{destpage}) { + + if ($params{page} ne $params{destpage} && + + (! exists $params{pages} || + + pagespec_match($params{destpage}, $params{pages}, + + location => $params{page}))) { + return "\n". + htmllink($params{page}, $params{destpage}, $params{page}, + linktext => $params{linktext}, + +I can now call it as + + \[[!more pages="index" linktext="Chapter 1" text=""" + etc + """]] + +I'm not entirely happy with the design, since I would rather put this information in the inline directive instead of in every story post. Unfortunately I found no way to pass parameters from the inline directive to the inlined page. + +-- [[dark]] + +> Me neither, but nor do I see a better way, so [[applied|done]]. --[[Joey]] diff --git a/doc/todo/support_link__40__.__41___in_pagespec.mdwn b/doc/todo/support_link__40__.__41___in_pagespec.mdwn index 79809662a..653db1ff2 100644 --- a/doc/todo/support_link__40__.__41___in_pagespec.mdwn +++ b/doc/todo/support_link__40__.__41___in_pagespec.mdwn @@ -11,3 +11,11 @@ IkiWiki.pm is the best way to do it". > I implemented this suggestion in the simplest possible way, [[!taglink patch]] available [[here|http://git.oblomov.eu/ikiwiki/patch/f4a52de556436fdee00fd92ca9a3b46e876450fa]]. > An alternative approach, very similar, would be to make the empty page parameter mean current page (e.g. `link()` would mean pages linking here). The patch would be very similar. > -- GB + +>> Thanks for this, and also for your recent spam-fighting. +>> Huh, I was right about changing derel, didn't realize it would be +>> so obvious a change. :) Oh well, I managed to complicate it +>> some in optimisation pass.. ;) +>> +>> Note that your git-daemon on git.oblomov.eu seems down. +>> I pulled the patch from gitweb, [[done]] --[[Joey]] diff --git a/doc/todo/transient_pages.mdwn b/doc/todo/transient_pages.mdwn new file mode 100644 index 000000000..642114d97 --- /dev/null +++ b/doc/todo/transient_pages.mdwn @@ -0,0 +1,110 @@ +On [[todo/auto-create_tag_pages_according_to_a_template]], [[chrysn]] +suggests: + +> Instead of creating a file that gets checked in into the RCS, the +> source files could be left out and the output files be written as +> long as there is no physical source file (think of a virtual underlay). +> Something similar would be required to implement alias directive, +> which couldn't be easily done by writing to the RCS as the page's +> contents can change depending on which other pages claim it as an alias. + +`add_autofile` could be adapted to do this, or a similar API could be +added. + +This would also be useful for autoindex, as suggested on +[[plugins/autoindex/discussion]]. I'd also like to use it for +[[plugins/contrib/album]]. + +One refinement I'd suggest is that if the transient page is edited, +its transient contents are evaluated and used as the initial +content for the edit box; after that, it'd become a static page. --[[smcv]] + +-------------------------- + +[[!template id=gitbranch branch=smcv/ready/transient author="[[smcv]]"]] +[[!tag patch]] + +I think this branch is now enough to be useful. It adds the following: + +If the `transient` plugin is loaded, `$srcdir/.ikiwiki/transient` is added +as an underlay. + +Pages with the default extension in the transient underlay are automatically +deleted if a page of the same name is created in the srcdir (or an underlay +closer to the srcdir in stacking order). + +`tag` enables `transient`, and if `tag_autocreate_commit` is set to 0 +(default 1), autocreated tags are written to the transient underlay. + +`autoindex` uses autofiles. It also enables `transient`, and if +`autoindex_commit` is set to 0 (default 1), autoindexes are written to +the transient underlay. + +autoindex ignores pages in the transient underlay when deciding whether +to generate an index. + +Not done yet: + +`remove` can't remove transient pages: this turns out to be harder than +I'd hoped, because I don't want to introduce a vulnerability in the +non-regular-file detection... + +Transient tags that don't match any pages aren't deleted: I'm not sure +that that's a good idea anyway, though. Similarly, transient autoindexes +of directories that become empty aren't deleted. + +Recent changes and aggregated files could conceivably go in the transient +underlay too. + +-------------------------- + +## An earlier version + +I had a look at implementing this. It turns out to be harder than I thought +to have purely in-memory pages (several plugins want to be able to access the +source file as a file), but I did get this proof-of-concept branch +to write tag and autoindex pages into an underlay. + +This loses the ability to delete the auto-created pages (although they don't +clutter up git this way, at least), and a lot of the code in autoindex is +probably now redundant, so this is probably not quite ready for merge, but +I'd welcome opinions. + +Usage: set `tag_underlay` and/or `autoindex_underlay` to an absolute path, +which you must create beforehand. I suggest *srcdir* + `/.ikiwiki/transient`. + +Refinements that could be made if this approach seems reasonable: + +* make these options boolean, and have the path always be `.ikiwiki/transient` +* improve the `remove` plugin so it also deletes from this special underlay + +>> Perhaps it should be something more generic, so that other plugins could use it (such as "album" mentioned above). +>> The `.ikiwiki/transient` would suit this, but instead of saying "tag_underlay" or "autoindex_underlay" have "use_transient_underlay" or something like that? +>> Or to make it more flexible, have just one option "transient_underlay" which is set to an absolute path, and if it is set, then one is using a transient-underlay. +>> --[[KathrynAndersen]] + +>>> What I had in mind was more like `tag_autocreate_transient => 1` or +>>> `autoindex_transient => 1`; you might conceivably want tags to be +>>> checked in but autoindices to be transient, and it's fine for each +>>> plugin to make its own decision. Going from that to one boolean +>>> (or just always-transient if people don't think that's too +>>> astonishing) would be trivial, though. +>>> +>>> I don't think relocating the transient underlay really makes sense, +>>> except for prototyping: you only want one, and `.ikiwiki` is as good +>>> a place as any (ikiwiki already needs to be able to write there). +>>> +>>> For [[plugins/contrib/album]] I think I'd just make the photo viewer +>>> pages always-transient - you can always make a transient page +>>> permanent by editing it, after all. +>>> +>>> Do you think this approach has enough potential that I should +>>> continue to hack on it? Any thoughts on the implementation? --[[smcv]] + +>>>> Ah, now I understand what you're getting at. Yes, it makes sense to put transient pages under `.ikiwiki`. +>>>> I haven't looked at the code, but I'd be interested in seeing whether it's generic enough to be used by other plugins (such as `album`) without too much fuss. +>>>> The idea of a transient underlay gives us a desirable feature for free: that if someone edits the transient page, it is made permanent and added to the repository. +>>>> +>>>> I think the tricky thing with removing these transient underlay pages is the question of how to prevent whatever auto-generated the pages in the first place from generating them again - or, conversely, how to force whatever auto-generated those pages to regenerate them if you've changed your mind. +>>>> I think you'd need something similar to `will_render` so that transient pages would be automatically removed if whatever auto-generated them is no longer around. +>>>> -- [[KathrynAndersen]] diff --git a/doc/todo/untrusted_git_push_hooks.mdwn b/doc/todo/untrusted_git_push_hooks.mdwn new file mode 100644 index 000000000..313078ce5 --- /dev/null +++ b/doc/todo/untrusted_git_push_hooks.mdwn @@ -0,0 +1,12 @@ +Re the canrename, canremove, and canedit hooks: + +Of the three, only canremove is currently checked during an untrusted +git push (a normal git push is assumed to be from a trusted user and +bypasses all checks). + +It would probably make sense to add the canedit hook to the checks done +there. Calling the canrename hook is tricky, because after all, git does +not record explicit file moves. + +The checkcontent hook is another hook not currently called there, that +probably should be. diff --git a/doc/todo/use_secure_cookies_for_ssl_logins.mdwn b/doc/todo/use_secure_cookies_for_ssl_logins.mdwn new file mode 100644 index 000000000..194db2f36 --- /dev/null +++ b/doc/todo/use_secure_cookies_for_ssl_logins.mdwn @@ -0,0 +1,36 @@ +[[!template id=gitbranch branch=smcv/ready/sslcookie-auto author="[[smcv]]"]] +[[!tag patch]] + +At the moment `sslcookie => 0` never creates secure cookies, so if you log in +with SSL, your browser will send the session cookie even over plain HTTP. +Meanwhile `sslcookie => 1` always creates secure cookies, so you can't +usefully log in over plain http. + +This branch adds `sslcookie => 0, sslcookie_auto => 1` as an option; this +uses the `HTTPS` environment variable, so if you log in over SSL you'll +get a secure session cookie, but if you log in over HTTP, you won't. +(The syntax for the setup file is pretty rubbish - any other suggestions?) + +> Does this need to be a configurable option at all? The behavior could +> just be changed in the sslcookie = 0 case. It seems sorta reasonable +> that, once I've logged in via https, I need to re-login if I then +> switch to http. + +>> Even better. I've amended the branch to have this behaviour, which +>> turns it into a one-line patch. --[[smcv]] + +> And, if your change is made, the sslcookie option could probably itself +> be dropped too -- at least I don't see a real use case for it if ikiwiki +> is more paranoid about cookies by default. + +>> I haven't done that; it might make sense to do so, but I think it'd be +>> better to leave it in as a safety-catch (or in case someone's +>> using a webserver that doesn't put `$HTTPS` in the environment). --s + +> Might be best to fix +> [[todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both]] +> first, so that dual https/http sites can better be set up. --[[Joey]] + +>> Thanks for merging that! :-) --s + +[[merged|done]] --[[Joey]] diff --git a/doc/todo/use_templates_for_the_img_plugin.mdwn b/doc/todo/use_templates_for_the_img_plugin.mdwn new file mode 100644 index 000000000..1cee1b535 --- /dev/null +++ b/doc/todo/use_templates_for_the_img_plugin.mdwn @@ -0,0 +1,29 @@ +[[!template id=gitbranch branch=jmtd/img_use_template author="[[Jon]]"]] + +Not finished! :-) + +The patches in <http://github.com/jmtd/ikiwiki/tree/img_use_template> convert the `img.pm` plugin to use a template (by default, `img.tmpl`, varied using a `template=` parameter) rather than hard-code the generated HTML. + +I originally thought of this to solve the problem outlined in [[bugs/can't mix template vars inside directives]], before I realised I could wrap the `img` call in my pages with a template to achieve the same thing. I therefore sat on it. + +However, I since thought of another use for this, and so started implementing it. (note to self: explain this other use) + +---- + +Ok, I have managed to achieve what I wanted with stock ikiwiki, this branch might not have any more life left in it (but it has proven an interesting experiment to see how much logic could be moved from `img.pm` into a template relatively easily. Although the template is not terribly legible.) + +My ikiwiki page has a picture on the front page. I've changed that picture just once, but I would like to change it again from time to time. I also want to keep a "gallery", or at least a list, of previous pictures, and perhaps include text alongside each picture, but not on the front page. + +I've achieved this as follows + + * each index picture gets a page under "indexpics". + * the "indexpics" page has a raw inline to include them all[1] + * the front page has more-or-less the same inline, with show=1 + * each index picture page has a [[plugins/conditional]]: + * if you are being included, show the resized picture only, and link the picture to the relevant indexpic page + * else, show the picture with the default link to a full-size image, and include explanatory text. + * most of the boilerplate is hidden inside a template + +It is not quite as I envisaged it: the explanatory text would probably make sense on the indexpics "gallery" page, but since that includes the page, the wrong trouser-leg of the conditional is used. But it works quite well. Introducing a new index picture involves creating an appropriate page under indexpics and the rest happens automatically. + +[1] lie #1: the pagespec is a lot more complex as it has to exclude raw image filetypes diff --git a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn index 5f17e3ae0..f7938b061 100644 --- a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn +++ b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn @@ -12,20 +12,312 @@ It would be good if relative paths could be used instead, so the transport metho > "../../", and "../". The only absolute links are to CGIs and the w3c DTD. > --[[Joey]] ->> The problem is within the CGI script. The links within the HTML page are all absolute, including links to the css file. ->> Having a http links within a HTML page retrieved using https upset most browsers (I think). Also if I push cancel on the edit page in https, I end up at at http page. -- Brian May +>> The problem is within the CGI script. The links within the HTML page are all +>> absolute, including links to the css file. Having a http links within a HTML +>> page retrieved using https upset most browsers (I think). Also if I push cancel +>> on the edit page in https, I end up at at http page. -- Brian May >>> Ikiwiki does not hardcode http links anywhere. If you don't want >>> it to use such links, change your configuration to use https >>> consistently. --[[Joey]] -Errr... That is not a solution, that is a work around. ikiwiki does not hard code the absolute paths, but absolute paths are hard coded in the configuration file. If you want to serve your website so that the majority of users can see it as http, including in rss feeds (this allows proxy caches to cache the contents and has reduced load requirements), but editing is done via https for increased security, it is not possible. I have some ideas how this can be implemented (as ikiwiki has the absolute path to the CGI script and the absolute path to the destination, it should be possible to generate a relative path from one to the other), although some minor issues still need to be resolved. -- Brian May +Errr... That is not a solution, that is a work around. ikiwiki does not hard +code the absolute paths, but absolute paths are hard coded in the configuration +file. If you want to serve your website so that the majority of users can see +it as http, including in rss feeds (this allows proxy caches to cache the +contents and has reduced load requirements), but editing is done via https for +increased security, it is not possible. I have some ideas how this can be +implemented (as ikiwiki has the absolute path to the CGI script and the +absolute path to the destination, it should be possible to generate a relative +path from one to the other), although some minor issues still need to be +resolved. -- Brian May -I noticed the links to the images on <http://ikiwiki.info/recentchanges/> are also absolute, that is <http://ikiwiki.info/wikiicons/diff.png>; this seems surprising, as the change.tmpl file uses <TMPL_VAR BASEURL> -which seems to do the right thing in page.tmpl, but not for change.tmpl. Where is BASEURL set? -- Brian May +I noticed the links to the images on <http://ikiwiki.info/recentchanges/> are +also absolute, that is <http://ikiwiki.info/wikiicons/diff.png>; this seems +surprising, as the change.tmpl file uses <TMPL_VAR BASEURL> which seems +to do the right thing in page.tmpl, but not for change.tmpl. Where is BASEURL +set? -- Brian May > The use of an absolute baseurl in change.tmpl is a special case. --[[Joey]] -So I'm facing this same issue. I have a wiki which needs to be accessed on three different URLs(!) and the hard coding of the URL from the setup file is becoming a problem for me. Is there anything I can do here? --[[Perry]] +So I'm facing this same issue. I have a wiki which needs to be accessed on +three different URLs(!) and the hard coding of the URL from the setup file is +becoming a problem for me. Is there anything I can do here? --[[Perry]] + +> I remain puzzled by the problem that Brian is discussing. I don't see +> why you can't just set the cgiurl and url to a https url, and serve +> the site using both http and https. +> +> Just for example, <https://kitenet.net/> is an ikiwiki, and it is accessible +> via https or http, and if you use https, links will remain on https (except +> for links using the cgi, which I could fix by changing the cgiurl to https). +> +> I think it's possible ikiwiki used to have some +> absolute urls that have been fixed since Brian filed the bug. --[[Joey]] [[wishlist]] + +---- + +[[!toggle id="smcv-https" text="Some discussion of a rejected implementation, smcv/https."]] +[[!toggleable id="smcv-https" text=""" + +[[!template id=gitbranch branch=smcv/https author="[[smcv]]"]] + +For a while I've been using a configuration where each wiki has a HTTP and +a HTTPS mirror, and updating one automatically updates the other, but +that seems unnecessarily complicated. My `https` branch adds `https_url` +and `https_cgiurl` config options which can be used to provide a HTTPS +variant of an existing site; the CGI script automatically detects whether +it was accessed over HTTPS and switches to the other one. + +This required some refactoring, which might be worth merging even if +you don't like my approach: + +* change `IkiWiki::cgiurl` to return the equivalent of `$config{cgiurl}` if + called with no parameters, and change all plugins to indirect through it + (then I only need to change that one function for the HTTPS hack) + +* `IkiWiki::baseurl` already has similar behaviour, so change nearly all + references to the `$config{url}` to call `baseurl` (a couple of references + specifically wanted the top-level public URL for Google or Blogspam rather + than a URL for the user's browser, so I left those alone) + +--[[smcv]] + +> The justification for your patch seems to be wanting to use a different +> domain, like secure.foo.com, for https? Can you really not just configure +> both url and cgiurl to use `https://secure.foo.com/...` and rely on +> relative links to keep users of `http://insecure.foo.com/` on http until +> they need to use the cgi? + +>> My problem with that is that uses of the CGI aren't all equal (and that +>> the CA model is broken). You could put CGI uses in two classes: +>> +>> - websetup and other "serious" things (for the sites I'm running, which +>> aren't very wiki-like, editing pages is also in this class). +>> I'd like to be able to let privileged users log in over +>> https with httpauth (or possibly even a client certificate), and I don't +>> mind teaching these few people how to do the necessary contortions to +>> enable something like CACert. +>> +>> - Random users making limited use of the CGI: do=goto, do=404, and +>> commenting with an OpenID. I don't think it's realistic to expect +>> users to jump through all the CA hoops to get CACert installed for that, +>> which leaves their browsers being actively obstructive, unless I either +>> pay the CA tax (per subdomain) to get "real" certificates, or use plain +>> http. +>> +>> On a more wiki-like wiki, the second group would include normal page edits. +>> +>>> I see your use case. It still seems to me that for the more common +>>> case where CA tax has been paid (getting a cert that is valid for +>>> multiple subdomains should be doable?), having anything going through the +>>> cgiurl upgrade to https would be ok. In that case, http is just an +>>> optimisation for low-value, high-aggregate-bandwidth type uses, so a +>>> little extra https on the side is not a big deal. --[[Joey]] +>> +>> Perhaps I'm doing this backwards, and instead of having the master +>> `url`/`cgiurl` be the HTTP version and providing tweakables to override +>> these with HTTPS, I should be overriding particular uses to plain HTTP... +>> +>> --[[smcv]] +>>> +>>> Maybe, or I wonder if you could just use RewriteEngine for such selective +>>> up/downgrading. Match on `do=(edit|create|prefs)`. --[[Joey]] + +> I'm unconvinced. +> +> `Ikiwiki::baseurl()."foo"` just seems to be asking for trouble, +> ie being accidentially written as `IkiWiki::baseurl("foo")`, +> which will fail when foo is not a page, but some file. + +>> That's a good point. --s + +> I see multiple places (inline.pm, meta.pm, poll.pm, recentchanges.pm) +> where it will now put the https url into a static page if the build +> happens to be done by the cgi accessed via https, but not otherwise. +> I would rather not have to audit for such problems going forward. + +>> Yes, that's a problem with this approach (either way round). Perhaps +>> making it easier to run two mostly-synched copies like I was previously +>> doing is the only solution... --s + +"""]] + +---- + +[[!template id=gitbranch branch=smcv/ready/localurl author="[[smcv]]"]] +[[!tag patch]] + +OK, here's an alternative approach, closer in spirit to what was initially +requested. I included a regression test for `urlto`, `baseurl` and `cgiurl`, +now that they have slightly more complex behaviour. + +The idea is that in the common case, the CGI and the pages will reside on the +same server, so they can use "semi-absolute" URLs (`/ikiwiki.cgi`, `/style.css`, +`/bugs/done`) to refer to each other. Most redirects, form actions, links etc. +can safely use this form rather than the fully-absolute URL. + +The initial version of the branch had config options `local_url` and +`local_cgiurl`, but they're now automatically computed by checking +whether `url` and `cgiurl` are on the same server with the the same URL +scheme. In theory you could use things like `//static.example.com/wiki/` +and `//dynamic.example.com/ikiwiki.cgi` to preserve choice of http/https +while switching server, but I don't know how consistently browsers +support that. + +"local" here is short for "locally valid", because these URLs are neither +fully relative nor fully absolute, and there doesn't seem to be a good name +for them... + +I've tested this on a demo website with the CGI enabled, and it seemed to +work nicely (there might be bugs in some plugins, I didn't try all of them). +The branch at [[todo/use secure cookies for SSL logins]] goes well with +this one. + +The `$config{url}` and `$config{cgiurl}` are both HTTP, but if I enable +`httpauth`, set `cgiauthurl` to a HTTPS version of the same site and log +in via that, links all end up in the HTTPS version. + +New API added by this branch: + +* `urlto(x, y, 'local')` uses `$local_url` instead of `$config{url}` + + > Yikes. I see why you wanted to keep it to 3 parameters (4 is too many, + > and po overrides it), but I dislike overloading the third parameter + > like that. + > + > There are fairly few calls to `urlto($foo, $bar)`, so why not + > make that always return the semi-local url form, and leave the third + > parameter for the cases that need a true fully-qualified url. + > The new form for local urls will typically be only a little bit longer, + > except in the unusual case where the cgiurl is elsewhere. --[[Joey]] + + >> So, have urlto(x, y) use `$local_url`? There are few calls, but IMO + >> they're for the most important things - wikilinks, img, map and + >> other ordinary hyperlinks. Using `$local_url` would be fine for + >> webserver-based use, but it does stop you browsing your wiki's + >> HTML over `file:///` (unless you set that as the base URL, but + >> then you can't move it around), and stops you moving simple + >> outputs (like the docwiki!) around. + >> + >> I personally think breaking the docwiki is enough to block that. + >> + >>> Well, the docwiki doesn't have an url configured at all, so I assumed + >>> it would need to fall back to current behavior in that case. I had + >>> not thought about browsing wiki's html files though, good point. + >> + >> How about this? + >> + >> * `urlto($link, $page)` with `$page` defined: relative + >> * `urlto($link, undef)`: local, starts with `/` + >> * `urlto($link)`: also local, as a side-effect + >> * `urlto($link, $anything, 1)` (but idiomatically, `$anything` is + >> normally undef): absolute, starts with `http[s]://` + >> + >> --[[smcv]] + >> + >>> That makes a great deal of sense, bravo for actually removing + >>> parameters in the common case while maintaining backwards + >>> compatability! --[[Joey]] + >>> + >>>> Done in my `localurl` branch; not tested in a whole-wiki way + >>>> yet, but I did add a regression test. I've used + >>>> `urlto(x, undef)` rather than `urlto(x)` so far, but I could + >>>> go back through the codebase using the short form if you'd + >>>> prefer. --[[smcv]] + >>> + >>> It does highlight that it would be better to have a + >>> `absolute_urlto($link)` (or maybe `absolute(urlto($link))` ) + >>> rather than the 3 parameter form. --[[Joey]] + >>> + >>> Possibly. I haven't added this. + +* `IkiWiki::baseurl` has a new second argument which works like the + third argument of `urlto` + + > I assume you have no objection to this --[[smcv]] + + >> It's so little used that I don't really care if it's a bit ugly. + >> (But I assume changes to `urlto` will follow through here anyway.) + >> --[[Joey]] + + >>> I had to use it a bit more, as a replacement for `$config{url}` + >>> when doing things like referencing stylesheets or redirecting to + >>> the top of the wiki. + >>> + >>> I ended up redoing this without the extra parameter. Previously, + >>> `baseurl(undef)` was the absolute URL; now, `baseurl(undef)` is + >>> the local path. I know you objected to me using `baseurl()` in + >>> an earlier branch, because `baseurl().$x` looks confusingly + >>> similar to `baseurl($x)` but has totally different semantics; + >>> I've generally written it `baseurl(undef)` now, to be more + >>> explicit. --[[smcv]] + +* `IkiWiki::cgiurl` uses `$local_cgiurl` if passed `local_cgiurl => 1` + + > Now changed to always use the `$local_cgiurl`. --[[smcv]] + +* `IkiWiki::cgiurl` omits the trailing `?` if given no named parameters + except `cgiurl` and/or `local_cgiurl` + + > I assume you have no objection to this --[[smcv]] + > + >> Nod, although I don't know of a use case. --[[Joey]] + + >>> The use-case is that I can replace `$config{cgiurl}` with + >>> `IkiWiki::cgiurl()` for things like the action attribute of + >>> forms. --[[smcv]] + +Fixed bugs: + +* I don't think anything except `openid` calls `cgiurl` without also + passing in `local_cgiurl => 1`, so perhaps that should be the default; + `openid` uses the `cgiurl` named parameter anyway, so there doesn't even + necessarily need to be a way to force absolute URLs? Any other module + that really needs an absolute URL could use + `cgiurl(cgiurl => $config{cgiurl}, ...)`, + although that does look a bit strange + + > I agree that makes sense. --[[Joey]] + + >> I'm not completely sure whether you're agreeing with "perhaps do this" + >> or "that looks too strange", so please disambiguate: + >> would you accept a patch that makes `cgiurl` default to a local + >> (starts-with-`/`) result? If you would, that'd reduce the diff. --[[smcv]] + + >>> Yes, I absolutely think it should default to local. (Note that + >>> if `absolute()` were implemented as suggested above, it could also + >>> be used with cgiurl if necessary.) --[[Joey]] + + >>>> Done (minus `absolute()`). --[[smcv]] + +Potential future things: + +* It occurs to me that `IkiWiki::cgiurl` could probably benefit from being + exported? Perhaps also `IkiWiki::baseurl`? + + > Possibly, see [[firm_up_plugin_interface]]. --[[Joey]] + + >> Not really part of this branch, though, so wontfix (unless you ask me + >> to do so). --[[smcv]] + +* Or, to reduce use of the unexported `baseurl` function, it might make + sense to give `urlto` a special case that references the root of the wiki, + with a trailing slash ready to append stuff: perhaps `urlto('/')`, + with usage like this? + + do_something(baseurl => urlto('/', undef, local)`); + do_something_else(urlto('/').'style.css'); + IkiWiki::redirect(urlto('/', undef, 1)); + + > AFACIS, `baseurl` is only called in 3 places so I don't think that's + > needed. --[[Joey]] + + >> OK, wontfix. For what it's worth, my branch has 6 uses in IkiWiki + >> core code (IkiWiki, CGI, Render and the pseudo-core part of editpage) + >> and 5 in plugins, since I used it for things like redirection back + >> to the top of the wiki --[[smcv]] + +[[merged|done]] --[[Joey]] diff --git a/doc/todo/web_reversion.mdwn b/doc/todo/web_reversion.mdwn new file mode 100644 index 000000000..736d674fe --- /dev/null +++ b/doc/todo/web_reversion.mdwn @@ -0,0 +1,73 @@ +Goal: Web interface to allow reverting of changes. + +Interface: + +At least at first, it will be exposed via the recentchanges +page, with revert icons next to each change. We may want a dynamic +per-page interface that goes back more than 100 changes later. + +Limiting assumptions: + +* No support for resolving conflicts in reverts; such a revert would just + fail and not happen. +* No support for reset-to-this-point; initially the interface would only + revert a single commit, and if a bunch needed to go, the user would have + to drive that one at a time. + +Implementation plan: + +* `rcs_revert` hook that takes a revision to revert. +* CGI: `do=revert&rev=foo` +* recentchanges plugin adds above to recentchanges page +* prompt user to confirm (to avoid spiders doing reverts), + check that user is allowed to make the change, commit reversion, + and refresh site. + +Peter Gammie has done an initial implementation of the above. +[[!template id=gitbranch branch=peteg/revert author="[[peteg]]"]] + +>> It is on a separate branch now. --[[peteg]] + +> Review: --[[Joey]] +> +> The revert commit will not currently say what web user did the revert. +> This could be fixed by doing a --no-commit revert first and then using +> rcs_commit_staged. +>> Fixed, I think. --[[peteg]] +> +> So I see one thing I completly forgot about is `check_canedit`. Avoiding users +> using reverting to make changes they would normally not be allowed to do is +> tricky. I guess that a easy first pass would be to only let admins do it. +> That would be enough to get the feature out there.. +> +> I'm thinking about having a `rcs_preprevert`. It would take a rev and look +> at what changes reverting it would entail, and return the same data +> structure that `rcs_recieve` does. This could be done by using `git revert +> --no-commit`, and then examining the changes, and then `git reset` to drop +> them. +>> We can use the existing `git_commit_info` with the patch ID - no need to touch the working directory. -- [[peteg]] +> +> Then the code that is currently in IkiWiki/Receive.pm, that calls +> `check_canedit` and `check_canremove` to test the change, can be +> straightforwardly refactored out, and used for checking reverts too. +>> Wow, that was easy. :-) -- [[peteg]] +> +> (The data from `rcs_preprevert` could also be used for a confirmation +> prompt -- it doesn't currently include enough info for diffs, but at +> least could have a list of changed files.) +> +> Note that it's possible for a git repo to have commits that modify wiki +> files in a subdir, and code files elsewhere. `rcs_preprevert` should +> detect changes outside the wiki dir, and fail, like `rcs_receive` does. +>> Taken care of by refactoring `rcs_receive` in `git.pm` +>> I've tested it lightly in my single-user setup. It's a little nasty that the `attachment` plugin +>> gets used to check whether attachments are allowed -- there really should be a hook for that. +>>> I agree, but have not figured out a way to make a hook work yet. +>>> --[[Joey]] +>> +>> Please look it over and tell me what else needs fixing... -- [[peteg]] + +>>> I have made my own revert branch and put a few^Wseveral fixes in there. +>>> All merged to master now! --[[Joey]] + +[[done]] diff --git a/doc/usage.mdwn b/doc/usage.mdwn index 840d105d2..2325b6502 100644 --- a/doc/usage.mdwn +++ b/doc/usage.mdwn @@ -350,7 +350,7 @@ also be configured using a setup file. * ikiwiki --setup my.setup - Completly (re)build the wiki using the specified setup file. + Completely (re)build the wiki using the specified setup file. * ikiwiki --setup my.setup --refresh diff --git a/doc/users/Remy.mdwn b/doc/users/Remy.mdwn new file mode 100644 index 000000000..5cde4c43d --- /dev/null +++ b/doc/users/Remy.mdwn @@ -0,0 +1 @@ +Test page diff --git a/doc/users/anarcat.wiki b/doc/users/anarcat.wiki new file mode 100644 index 000000000..7ef474ed6 --- /dev/null +++ b/doc/users/anarcat.wiki @@ -0,0 +1 @@ +Hello! I'm anarcat. See [[https://wiki.koumbit.net/TheAnarcat]] to know more about me. diff --git a/doc/users/chrysn.mdwn b/doc/users/chrysn.mdwn new file mode 100644 index 000000000..0daa3b2b9 --- /dev/null +++ b/doc/users/chrysn.mdwn @@ -0,0 +1,4 @@ +* **name**: chrysn +* **website**: <http://christian.amsuess.com/> +* **uses ikiwiki for**: a bunch of internal documentation / organization projects +* **likes ikiwiki because**: it is a distributed organization tool that pretends to be a web app for the non-programmers out there diff --git a/doc/users/dark.mdwn b/doc/users/dark.mdwn new file mode 100644 index 000000000..e1d06d0b0 --- /dev/null +++ b/doc/users/dark.mdwn @@ -0,0 +1,3 @@ +[[!meta title="Richard Braakman"]] + +Lars Wirzenius convinced me to try ikiwiki for blogging :) diff --git a/doc/users/harishcm.mdwn b/doc/users/harishcm.mdwn index 164711022..292a3bfad 100644 --- a/doc/users/harishcm.mdwn +++ b/doc/users/harishcm.mdwn @@ -1 +1 @@ -Using ikiwiki for my yet to be published personal website :) +Using ikiwiki for my personal website <http://harish.19thsc.com> diff --git a/doc/users/tschwinge.mdwn b/doc/users/tschwinge.mdwn index 414612aff..435208a71 100644 --- a/doc/users/tschwinge.mdwn +++ b/doc/users/tschwinge.mdwn @@ -1,8 +1,8 @@ [[!meta title="Thomas Schwinge"]] # Thomas Schwinge -<tschwinge@gnu.org> -<http://www.thomas.schwinge.homeip.net/> +<thomas@schwinge.name> +<http://schwinge.homeip.net/~thomas/> I have converted the [GNU Hurd](http://www.gnu.org/software/hurd/)'s previous web pages and previous wiki pages to a *[[ikiwiki]]* system; and all that while @@ -35,10 +35,6 @@ Markdown rendering, for example). <http://www.gnu.org/software/hurd/purify_html> -## Tags -- [[bugs/tagged__40____41___matching_wikilinks]] - -Tags should be a separate concept from wikilinks. - ### \[[!map]] behavior The \[[!map]] on, for example, @@ -142,6 +138,7 @@ discussed in *N-to-M Mapping of Input and Output Files* on ([[plugins/cutpaste]]) in RSS feed (only; not Atom?) under some conditions (refresh only, but not rebuild?). Perhaps missing to read in / parse some files? + [[Reported|bugs/Error:_no_text_was_copied_in_this_page_--_missing_page_dependencies]]. * [[plugins/recentchanges]] diff --git a/doc/wikiicons/revert.png b/doc/wikiicons/revert.png Binary files differnew file mode 100644 index 000000000..c39e65c33 --- /dev/null +++ b/doc/wikiicons/revert.png |
