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/contrib | |
parent | 9db2438b3a0366738ba2e1b6e23ad3d8ae2fe36e (diff) | |
parent | 2cc3f5d057c5882e08d16746985c49a7dd1a4c01 (diff) |
Merge commit 'upstream/master' into pub/po
Conflicts:
debian/changelog
debian/control
Diffstat (limited to 'doc/plugins/contrib')
-rw-r--r-- | doc/plugins/contrib/po.mdwn | 51 | ||||
-rw-r--r-- | doc/plugins/contrib/unixauth.mdwn | 20 |
2 files changed, 50 insertions, 21 deletions
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"]] |