aboutsummaryrefslogtreecommitdiff
path: root/doc/plugins
diff options
context:
space:
mode:
authorintrigeri <intrigeri@boum.org>2009-04-20 12:21:18 +0200
committerintrigeri <intrigeri@boum.org>2009-04-20 12:21:18 +0200
commit4558457402a4ab6bc795589a2e400fa66144f76e (patch)
tree8368320617a8febc3c9c9708f688b6591801f4c0 /doc/plugins
parent9db2438b3a0366738ba2e1b6e23ad3d8ae2fe36e (diff)
parent2cc3f5d057c5882e08d16746985c49a7dd1a4c01 (diff)
downloadikiwiki-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.mdwn4
-rw-r--r--doc/plugins/comments/discussion.mdwn2
-rw-r--r--doc/plugins/contrib/po.mdwn51
-rw-r--r--doc/plugins/contrib/unixauth.mdwn20
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"]]