Merge branch 'prv/po' into pub/po

7 files changed, 117 insertions, 2 deletions

diff --git a/doc/bugs/SVG_files_not_recognized_as_images.mdwn b/doc/bugs/SVG_files_not_recognized_as_images.mdwn
new file mode 100644
index 000000000..207edd426
--- /dev/null
+++ b/doc/bugs/SVG_files_not_recognized_as_images.mdwn
@@ -0,0 +1,29 @@
+In ikiwiki 2.66, SVG images are not recognized as images. In ikiwiki.pm,
+the hardcoded list of image file extensions does not include ".svg", which
+it probably should unless there's some other issue about rendering SVGs?
+
+The 'img' plugin also seems to not support SVGs.
+
+> SVG images can only be included via an `<object>`, `<embed>`, or
+> `<iframe>` tag. Or, perhaps as [inline SVG](http://wiki.svg.org/Inline_SVG). 
+> The [[plugins/htmlscrubber]] strips all three tags since they can easily
+> be used maliciously. If doing inline SVG, I'd worry that the svg file
+> could be malformed and mess up the html, or even inject javascript. So,
+> the only options seem to be only supporting svgs on wikis that do not
+> sanitize their html, or assuming that svgs are trusted content and
+> embedding them inline. None of which seem particularly palatable.
+> 
+> I suppose the other option would be converting the svg file to a static
+> image (png). The img plugin could probably do that fairly simply.
+> --[[Joey]]
+
+>> I'm working on inline SVG and MathML support in ikiwiki and I've
+>> modified my htmlscrubber to sanitize SVG and MathML using the
+>> whitelists from html5lib.  Here's a [patch][].  I've also made some
+>> notes about this here: [[todo/svg]].
+>> 
+>> I suspect that this bug may have caught the eye of anyone interested
+>> in this sort of thing.  I'll elaborate a bit on my user page to avoid
+>> getting off-topic here. --[[JasonBlevins]], October 21, 2008
+
+ [patch]: http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blobdiff;f=IkiWiki/Plugin/htmlscrubber.pm;h=3c0ddc8f25bd8cb863634a9d54b40e299e60f7df;hp=3bdaccea119ec0e1b289a0da2f6d90e2219b8d66;hb=fe333c8e5b4a5f374a059596ee698dacd755182d;hpb=be0b4f603f918444b906e42825908ddac78b7073
diff --git a/doc/bugs/cannot_preview_shortcuts.mdwn b/doc/bugs/cannot_preview_shortcuts.mdwn
new file mode 100644
index 000000000..d7045b2dc
--- /dev/null
+++ b/doc/bugs/cannot_preview_shortcuts.mdwn
@@ -0,0 +1,17 @@
+Shortcuts such as \[[!google foo]] do not work when previewing pages.
+--[[JasonBlevins]]
+
+> Broken during the setup dumping changes, now fixed. --[[Joey]] [[done]]
+
+>> Just a quick note that this fix interacts with the way the `listdirectives`
+>> directive gets its list of non-shortcut directives.  At the moment it
+>> still works, but it relies on the fact that the `listdirectives` `checkconfig`
+>> hook is called before the `shortcut` `checkconfig` hook.
+>> -- [[Will]]
+
+>> The order plugins are loaded is effectively random. (`keys %hooks`).
+>> So I've made shortcuts pass a 'shortcut' parameter when registering
+>> them, which listdirectives can grep out of the full list of directives.
+>> That may not be the best name to give it, especially if other plugins
+>> generate directives too. Seemed better than forcing shortcut's
+>> checkconfig hook to run last tho. --[[Joey]]
diff --git a/doc/bugs/disabling_backlinks.mdwn b/doc/bugs/disabling_backlinks.mdwn
index ba96a4e2b..415708a50 100644
--- a/doc/bugs/disabling_backlinks.mdwn
+++ b/doc/bugs/disabling_backlinks.mdwn
@@ -28,3 +28,5 @@ auto-generated index is insufficient.
 > tagged, I think you have larger problems than tags and backlinks being
 > the same. Like keeping that list of links up to date as tags are added
 > and changed. --[[Joey]]
+
+I see your point, Joey. I need to maintain that list manually, though, because the automatically generated list is too brief. \[[!map ...]] generates just a list of titles or descriptions. I need a list that contains both. See [[this_posting|ikiwiki/directive/map/discussion]] for more details. Until \[[!map]] can do that, I'm stuck with a manually maintained list. Which means that every link shows up in the backlinks.
diff --git a/doc/bugs/http_proxy_for_openid.mdwn b/doc/bugs/http_proxy_for_openid.mdwn
index e8f87f9c4..3d0c99b83 100644
--- a/doc/bugs/http_proxy_for_openid.mdwn
+++ b/doc/bugs/http_proxy_for_openid.mdwn
@@ -6,10 +6,42 @@ I have found if I add:
 
     newenviron[i++]="HTTPS_PROXY=http://host.domain.com:3128";
 
-to IkiWiki/Wrapper.pm it solves the problem for https requests, however it obviously would be preferred if the proxy name is not configured.
+to IkiWiki/Wrapper.pm it solves the problem for https requests, however it obviously would be preferred if the proxy name is not hard coded.
 
 Also, the ability to set HTTPS\_CA\_FILE and HTTPS\_CA\_DIR might benefit some people. Then again, it I can't see any evidence that the SSL certificate of the server is being checked. See the [[bug_report|ssl_certificates_not_checked_with_openid]] I filed on this separate issue.
 
 Unfortunately, HTTP\_PROXY doesn't work for http requests, it looks like that library is different.
 
+---
+
+Update 2008-10-26:
+
+Better solution, one that works for both http and https, and uses config options. It appears to work...
+
+Note that using $ua->proxy(['https'], ...); won't work, you get a "Not Implemented" error, see <http://community.activestate.com/forum-topic/lwp-https-requests-proxy>. Also see [[!debbug 129528]].
+
+Also note that the proxy won't work with liblwpx-paranoidagent-perl, I had to remove liblwpx-paranoidagent-perl first.
+
+Please get the patch from the *.mdwn source.
+
+louie:/usr/share/perl5/IkiWiki/Plugin# diff -u openid.pm.old openid.pm
+--- openid.pm.old	2008-10-26 12:18:58.094489360 +1100
++++ openid.pm	2008-10-26 12:40:05.763429880 +1100
+@@ -165,6 +165,14 @@
+ 	        $ua=LWP::UserAgent->new;
+ 	}
+ 
++	if (defined($config{"http_proxy"})) {
++		$ua->proxy(['http'], $config{"http_proxy"});
++	}
++
++	if (defined($config{"https_proxy"})) {
++		$ENV{HTTPS_PROXY} = $config{"https_proxy"};
++	}
++
+ 	# Store the secret in the session.
+ 	my $secret=$session->param("openid_secret");
+ 	if (! defined $secret) {
+
+
 Brian May
diff --git a/doc/bugs/rst_tweak.mdwn b/doc/bugs/rst_tweak.mdwn
index 8c7d8134d..9d433e24e 100644
--- a/doc/bugs/rst_tweak.mdwn
+++ b/doc/bugs/rst_tweak.mdwn
@@ -27,3 +27,17 @@ Does the Perl version of this plugin still exist?  There appears to be no "rst.p
 
 > No, only the python version exists. It does have `raw_enabled` set.
 > --[[Joey]]
+
+I am sorry, but I am confused. Does this mean that I can use Ikiwiki
+features that translate to HTML in rst files? For example, when I use a
+\[[pagename]]-style link in a rst file, the page generated by Ikiwiki's rst
+plugin says &lt;a href="./../pagename/">pagename&lt;/a> as text. The link
+is expanded correctly, but the result isn't interpreted as HTML. Is that
+what is supposed to happen? --Peter
+
+> `raw_enabled` allows you to use the
+> [raw directive](http://docutils.sourceforge.net/docs/ref/rst/directives.html),
+> but this is not used by ikiwiki for wikilinks or anything else. 
+> That's why the [[plugin_page|plugins/rst]] has its note about 
+> issues with wikilinks and directives. You'd have to put those inside
+> raw directives yourself to avoid rst escaping their result. --[[Joey]]
diff --git a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn
index 2dc74a984..04ece0ae8 100644
--- a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn
+++ b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn
@@ -65,4 +65,21 @@ significantly harder than the network based attacks."
 
 With regards to implementation, I am surprised that the libraries don't seem to
 do this checking, already, and by default. Unfortunately, I am not sure how to test
-this adequately, see <http://bugs.debian.org/466055>. -- Brian May
+this adequately, see [[!debbug 466055]]. -- Brian May
+
+--- 
+
+I think [[!cpan Crypt::SSLeay]] already supports checking the certificate. The trick
+is to get [[!cpan LWP::UserAgent]], which is used by [[!cpan LWPx::ParanoidAgent]] to
+enable this checking.
+
+I think the trick is to set one of the the following environment variables before retrieving
+the data:
+
+$ENV{HTTPS\_CA\_DIR} = "/etc/ssl/certs/";  
+$ENV{HTTPS\_CA\_FILE} = "/etc/ssl/certs/file.pem";  
+
+Unfortunately I get weird results if the certificate verification fails, see [[!debbug 503440]].
+It still seems to work though, regardless.
+
+-- Brian May
diff --git a/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn b/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn
index 5d5e90f7a..472597c46 100644
--- a/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn
+++ b/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn
@@ -11,6 +11,10 @@ Replacing "·" with "-" in `wikiname` fixed this login issue.
 > issues too.) Seems like I will have to possibly break some sessions and
 > entity-encode the wikiname in the cookie.. [[done]]. --[[Joey]]
 
+>> I confirm it fixes the bug for me. --[[intrigeri]]
+
 (BTW, such a char was replaced by -I don't remember what encoding thingie- in my setup file, when running `ikiwiki-transition setupformat`.)
 
 > Thanks for the heads up, fixed that too. --[[Joey]]
+
+>> I confirm it fixes the bug for me. --[[intrigeri]]