diff options
author | intrigeri <intrigeri@boum.org> | 2009-04-20 12:21:18 +0200 |
---|---|---|
committer | intrigeri <intrigeri@boum.org> | 2009-04-20 12:21:18 +0200 |
commit | 4558457402a4ab6bc795589a2e400fa66144f76e (patch) | |
tree | 8368320617a8febc3c9c9708f688b6591801f4c0 /doc/plugins | |
parent | 9db2438b3a0366738ba2e1b6e23ad3d8ae2fe36e (diff) | |
parent | 2cc3f5d057c5882e08d16746985c49a7dd1a4c01 (diff) | |
download | ikiwiki-4558457402a4ab6bc795589a2e400fa66144f76e.tar ikiwiki-4558457402a4ab6bc795589a2e400fa66144f76e.tar.gz |
Merge commit 'upstream/master' into pub/po
Conflicts:
debian/changelog
debian/control
Diffstat (limited to 'doc/plugins')
-rw-r--r-- | doc/plugins/anonok.mdwn | 4 | ||||
-rw-r--r-- | doc/plugins/comments/discussion.mdwn | 2 | ||||
-rw-r--r-- | doc/plugins/contrib/po.mdwn | 51 | ||||
-rw-r--r-- | doc/plugins/contrib/unixauth.mdwn | 20 |
4 files changed, 53 insertions, 24 deletions
diff --git a/doc/plugins/anonok.mdwn b/doc/plugins/anonok.mdwn index ab2f744e2..a3fec4d89 100644 --- a/doc/plugins/anonok.mdwn +++ b/doc/plugins/anonok.mdwn @@ -5,10 +5,10 @@ By default, anonymous users cannot edit the wiki. This plugin allows anonymous web users, who have not signed in, to edit any page in the wiki by default. -The plugin also has a configuration setting, `anonok_pages`. This +The plugin also has a configuration setting, `anonok_pagespec`. This [[PageSpec]] can be used to allow anonymous editing of matching pages. If you're using the [[comments]] plugin, you can allow anonymous comments to be posted by setting: - anonok_pages => "postcomment(*)" + anonok_pagespec => "postcomment(*)" diff --git a/doc/plugins/comments/discussion.mdwn b/doc/plugins/comments/discussion.mdwn index 2a87a3d93..3d7452b9a 100644 --- a/doc/plugins/comments/discussion.mdwn +++ b/doc/plugins/comments/discussion.mdwn @@ -60,7 +60,7 @@ spam problems. So, use `check_canedit` as at least a first-level check? > have postcomment(blog/*) or something. (Perhaps instead of taking a glob, postcomment > should take a pagespec, so you can have postcomment(link(tags/commentable))?) > -> This is why `anonok_pages => 'postcomment(*)'` and `locked_pages => '!postcomment(*)'` +> This is why `anonok_pagespec => 'postcomment(*)'` and `locked_pages => '!postcomment(*)'` > are necessary to allow anonymous and logged-in editing (respectively). > >> I changed that to move the flag out of the page name, and into a variable that the `match_postcomment` diff --git a/doc/plugins/contrib/po.mdwn b/doc/plugins/contrib/po.mdwn index a5e3375ce..61ec53ea8 100644 --- a/doc/plugins/contrib/po.mdwn +++ b/doc/plugins/contrib/po.mdwn @@ -330,12 +330,57 @@ daring a timid "please pull"... or rather, please review again :) --[[intrigeri]] > Ok, I've reviewed and merged into my own po branch. It's looking very -> mergeable. I would still like to go over the `po.pm` code in detail and -> review it, but it's very complex, and I'm happy with all the changes -> outside `po.pm`. +> mergeable. > > * Is it worth trying to fix compatability with `indexpages`? +>> +>> Supporting `usedirs` being enabled or disabled was already quite +>> hard IIRC, so supporting all four combinations of `usedirs` and +>> `indexpages` settings will probably be painful. I propose we forget +>> about it until someone reports he/she badly needs it, and then +>> we'll see what can be done. +>> > * Would it make sense to go ahead and modify `page.tmpl` to use > OTHERLANGUAGES and PERCENTTRANSLATED, instead of documenting how to modify it? +>> +>> Done in my branch. +>> +> * Would it be better to disable po support for pages that use unsupported +> or poorly-supported markup languages? +> +>> I prefer keeping it enabled, as: +>> +>> * most wiki markups "almost work" +>> * when someone needs one of these to be fully supported, it's not +>> that hard to add dedicated support for it to po4a; if it were +>> disabled, I fear the ones who could do this would maybe think +>> it's blandly impossible and give up. +>> + +> * What's the reasoning behind checking that the link plugin +> is enabled? AFAICS, the same code in the scan hook should +> also work when other link plugins like camelcase are used. +> * In `pagetemplate` there is a comment that claims the code +> relies on `genpage`, but I don't see how it does; it seems +> to always add a discussion link? +> * Is there any real reason not to allow removing a translation? +> I'm imagining a spammy translation, which an admin might not +> be able to fix, but could remove. +> * Re the meta title escaping issue worked around by `change`. +> I suppose this does not only affect meta, but other things +> at scan time too. Also, handling it only on rebuild feels +> suspicious -- a refresh could involve changes to multiple +> pages and trigger the same problem, I think. Also, exposing +> this rebuild to the user seems really ugly, not confidence inducing. +> +> So I wonder if there's a better way. Such as making po, at scan time, +> re-run the scan hooks, passing them modified content (either converted +> from po to mdwn or with the escaped stuff cheaply de-escaped). (Of +> course the scan hook would need to avoid calling itself!) > +> (This doesn't need to block the merge, but I hope it can be addressed +> eventually..) +> > --[[Joey]] +>> +>> --[[intrigeri]] diff --git a/doc/plugins/contrib/unixauth.mdwn b/doc/plugins/contrib/unixauth.mdwn index 76a847744..6108ebfae 100644 --- a/doc/plugins/contrib/unixauth.mdwn +++ b/doc/plugins/contrib/unixauth.mdwn @@ -14,25 +14,9 @@ Config variables that affect the behavior of `unixauth`: __Security__: [As with passwordauth](/security/#index14h2), be wary of sending usernames and passwords in cleartext. Unlike passwordauth, sniffing `unixauth` credentials can get an attacker much further than mere wiki access. Therefore, this plugin defaults to not even _displaying_ the login form fields unless we're running under SSL. Nobody should be able to do anything remotely dumb until the admin has done at least a little thinking. After that, dumb things are always possible. ;-) -`unixauth` tests for the presence of the `HTTPS` environment variable. `Wrapper.pm` needs to be tweaked to pass it through; without that, the plugin fails closed. +`unixauth` needs the `HTTPS` environment variable, available in ikiwiki 2.67 or later (fixed in #[502047](http://bugs.debian.org/502047)), without which it fails closed. -[[!toggle id="diff" text="Wrapper.pm.diff"]] - -[[!toggleable id="diff" text=""" - - --- Wrapper.pm.orig 2008-07-29 00:09:10.000000000 -0400 - +++ Wrapper.pm - @@ -28,7 +28,7 @@ sub gen_wrapper () { - my @envsave; - push @envsave, qw{REMOTE_ADDR QUERY_STRING REQUEST_METHOD REQUEST_URI - CONTENT_TYPE CONTENT_LENGTH GATEWAY_INTERFACE - - HTTP_COOKIE REMOTE_USER} if $config{cgi}; - + HTTP_COOKIE REMOTE_USER HTTPS} if $config{cgi}; - my $envsave=""; - foreach my $var (@envsave) { - $envsave.=<<"EOF" - -"""]] +The plugin has not been tested with newer versions of ikiwiki. [[schmonz]] hopes to have time to polish this plugin soon. [[!toggle id="code" text="unixauth.pm"]] |