diff options
| -rw-r--r-- | doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn | 1 | ||||
| -rw-r--r-- | doc/bugs/http_proxy_for_openid.mdwn | 2 | ||||
| -rw-r--r-- | doc/bugs/img_plugin_causes_taint_failure.mdwn | 2 | ||||
| -rw-r--r-- | doc/bugs/img_plugin_renders___60__img__62___tag_without_src_attribute_post-2.20.mdwn | 1 | ||||
| -rw-r--r-- | doc/bugs/links_from_sidebars.mdwn | 9 | ||||
| -rw-r--r-- | doc/bugs/links_from_sidebars/discussion.mdwn | 5 | ||||
| -rw-r--r-- | doc/bugs/relative_links.mdwn | 9 | ||||
| -rw-r--r-- | doc/bugs/ssl_certificates_not_checked_with_openid.mdwn | 9 | ||||
| -rw-r--r-- | doc/contact.mdwn | 2 | ||||
| -rw-r--r-- | doc/news/openid.mdwn | 2 | ||||
| -rw-r--r-- | doc/news/version_2.20.mdwn | 2 | ||||
| -rw-r--r-- | doc/sandbox.mdwn | 3 | ||||
| -rw-r--r-- | doc/sandbox/blech.mdwn | 1 | ||||
| -rw-r--r-- | doc/templates.mdwn | 2 |
14 files changed, 39 insertions, 11 deletions
diff --git a/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn b/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn new file mode 100644 index 000000000..2311656ce --- /dev/null +++ b/doc/bugs/No_link_for_blog_items_when_filename_contains_a_colon.mdwn @@ -0,0 +1 @@ +Since upgrading from Ikiwiki 2.20 to 2.32.3 (from Debian Lenny), I don't get hyperlinks to items which have a colon in their name anymore. This applies to both the normal and the archive view. Before the update, the links have been created as relative links, so they weren't usable either as the browser tried to take the part before the colon as protocol specification (as in e.g. `http:`). Iirc, this applied to the archive view only, links in the normal view were ok (will check this out again if it's important). Is there a way to quote each colon as %xy in the hyperlinks? Perhaps it's only a problem with my config, and not an actual bug...? diff --git a/doc/bugs/http_proxy_for_openid.mdwn b/doc/bugs/http_proxy_for_openid.mdwn index ec2c3cb27..e8f87f9c4 100644 --- a/doc/bugs/http_proxy_for_openid.mdwn +++ b/doc/bugs/http_proxy_for_openid.mdwn @@ -8,7 +8,7 @@ I have found if I add: to IkiWiki/Wrapper.pm it solves the problem for https requests, however it obviously would be preferred if the proxy name is not configured. -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. +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. diff --git a/doc/bugs/img_plugin_causes_taint_failure.mdwn b/doc/bugs/img_plugin_causes_taint_failure.mdwn index f8def19a0..f012a87a0 100644 --- a/doc/bugs/img_plugin_causes_taint_failure.mdwn +++ b/doc/bugs/img_plugin_causes_taint_failure.mdwn @@ -13,3 +13,5 @@ Seen with ikiwiki 2.30 > Also, the debian build of ikiwiki has taint checking disabled to avoid > this perl bug. Did you build your own? Set NOTAINT=1 when building.. > --[[Joey]] + +>> perl-5.8.8, I've created a package for openSUSE. Will file perl bug there as well then. diff --git a/doc/bugs/img_plugin_renders___60__img__62___tag_without_src_attribute_post-2.20.mdwn b/doc/bugs/img_plugin_renders___60__img__62___tag_without_src_attribute_post-2.20.mdwn new file mode 100644 index 000000000..cad9ebbc2 --- /dev/null +++ b/doc/bugs/img_plugin_renders___60__img__62___tag_without_src_attribute_post-2.20.mdwn @@ -0,0 +1 @@ +I upgraded from 2.18 to 2.32.3 and my \[[img]] links became `<img>` tags without `src` attributes. Reverting to 2.18 fixes the problem again. I assume this is 2.20, which is the only revision between 2.19 and 2.32.3 to mention img in the changelog. diff --git a/doc/bugs/links_from_sidebars.mdwn b/doc/bugs/links_from_sidebars.mdwn new file mode 100644 index 000000000..c3a201cf8 --- /dev/null +++ b/doc/bugs/links_from_sidebars.mdwn @@ -0,0 +1,9 @@ +If you use sidebars for navigation the Links section of a page ends up looking like: + +Links: blog/posts blog/sidebar sidebar + +instead of what I would expect: + +Links: blog/posts blog index + +I'm not sure what the bug actually is, or if there even is one, this just seems odd. diff --git a/doc/bugs/links_from_sidebars/discussion.mdwn b/doc/bugs/links_from_sidebars/discussion.mdwn new file mode 100644 index 000000000..9cb84328a --- /dev/null +++ b/doc/bugs/links_from_sidebars/discussion.mdwn @@ -0,0 +1,5 @@ +In the meantime I have configured nginx to redirect any requests for .../sidebar/ up to the parent page. + + rewrite ^(.*/)sidebar/$ $1 redirect; + +This appears to work well. diff --git a/doc/bugs/relative_links.mdwn b/doc/bugs/relative_links.mdwn index df203c651..824632ed0 100644 --- a/doc/bugs/relative_links.mdwn +++ b/doc/bugs/relative_links.mdwn @@ -12,10 +12,5 @@ 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]] ->> Something weird going on here, most of the links *are* relative. Maybe I was just too rushed. However there are still problems: - ->> Links at the top of the edit page; they are absolute (understandably). e.g. at the top of this page there is the header "ikiwiki/ editing bugs/relative links" where ikiwiki is an absolute link to the top of the page. - ->> If I push cancel on the edit page, I end up at http://..., although I am not sure how this occurs. - ->> -- 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 diff --git a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn new file mode 100644 index 000000000..802ab16a7 --- /dev/null +++ b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn @@ -0,0 +1,9 @@ +As far as I can tell, ikiwiki is not checking the SSL certificate of the remote host when using openid authentication. If so, this would allow for man-in-the-middle type attacks. Alternatively, maybe I am getting myself confused. + +Test #1: Enter URL as openid server that cannot be verified (either because the certificate is self signed or signed by an unknown CA). I get no SSL errors. + +Test #2: Download net\_ssl\_test from dodgy source (it uses the same SSL perl library, and test again. It seems to complain (on same site ikiwiki worked with) when it can't verify the signature. Although there is other breakage with the version I managed to download (eg. argument parsing is broken; also if I try to connect to a proxy server, it instructs the proxy server to connect to itself for some weird reason). + +For now, I want to try and resolve the issues with net\_ssl\_test, and run more tests. However, in the meantime, I thought I would document the issue here. + +-- Brian May diff --git a/doc/contact.mdwn b/doc/contact.mdwn index 1a8a0bbf9..7d628fa76 100644 --- a/doc/contact.mdwn +++ b/doc/contact.mdwn @@ -7,3 +7,5 @@ developers monitor RecentChanges closely, via the webpage, email, You could also drop by the IRC channel `#ikiwiki` on [OFTC](http://www.oftc.net/) (`irc.oftc.net`). + +... does not having a mailing list really encourage people to "collaborate through ikiwiki itself"? Personally, I strongly prefer to participate in mailing lists via my mail/nntp client. I follow over 50 mailing lists, so if I can't participate in a mailing list mail or nntp, I'll probably just not participate at all. I suspect there are others in my situation. I think that by not having an SMTP-driven mailing list, ikiwiki is passing up a big opportunity to build community. -- AdamMegacz diff --git a/doc/news/openid.mdwn b/doc/news/openid.mdwn index ef00765ed..72cacf95f 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 44 "Accept only OpenID for logins" 17 "Accept only password logins" 31 "Accept both"]] +[[poll 44 "Accept only OpenID for logins" 17 "Accept only password logins" 32 "Accept both"]] diff --git a/doc/news/version_2.20.mdwn b/doc/news/version_2.20.mdwn index 4bf0a02fe..b36ef4b8b 100644 --- a/doc/news/version_2.20.mdwn +++ b/doc/news/version_2.20.mdwn @@ -1,6 +1,6 @@ News for ikiwiki 2.20: - The template plugin has begin to htmlize the variables passed to templates. + The template plugin has begun to htmlize the variables passed to templates. This is normally what you want, but to get the old behavior and get at the raw value, you can use `<TMPL_VAR raw_variable>` in a template. diff --git a/doc/sandbox.mdwn b/doc/sandbox.mdwn index 69d7a217b..464e8f1a6 100644 --- a/doc/sandbox.mdwn +++ b/doc/sandbox.mdwn @@ -53,6 +53,9 @@ Bulleted list * five ---- +Its a WikiWikiWorld!! + +---- [[template id=note text="this is generated by the [[plugins/haiku]] plugin"]] [[haiku hint="sandbox play"]] diff --git a/doc/sandbox/blech.mdwn b/doc/sandbox/blech.mdwn new file mode 100644 index 000000000..1ec2727fd --- /dev/null +++ b/doc/sandbox/blech.mdwn @@ -0,0 +1 @@ +This just a test, but I am impressed. diff --git a/doc/templates.mdwn b/doc/templates.mdwn index 24da881c7..101b69763 100644 --- a/doc/templates.mdwn +++ b/doc/templates.mdwn @@ -41,7 +41,7 @@ large chunks of marked up text to be embedded into a template: To create a template, simply add a template directive to a page, and page will provide a link that can be used to create the template. The template is a -regular wiki page, located in the `templates/` directory. +regular wiki (.mdwn) page, **located in the `templates/` directory** under source control. Nothing to do with **templatedir** from your ikiwiki configuration. 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 |