From 8e77b66aaee796a05109e78c67f647b924e17363 Mon Sep 17 00:00:00 2001 From: Plareplane Date: Wed, 1 Oct 2008 17:01:58 -0400 Subject: --- ...from_field_empty_if_rootpage_doesn__39__t_exist.mdwn | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 doc/bugs/inline_from_field_empty_if_rootpage_doesn__39__t_exist.mdwn (limited to 'doc/bugs') diff --git a/doc/bugs/inline_from_field_empty_if_rootpage_doesn__39__t_exist.mdwn b/doc/bugs/inline_from_field_empty_if_rootpage_doesn__39__t_exist.mdwn new file mode 100644 index 000000000..995f0836f --- /dev/null +++ b/doc/bugs/inline_from_field_empty_if_rootpage_doesn__39__t_exist.mdwn @@ -0,0 +1,17 @@ +If I put something like the below in my index.mdwn + + <> + +But posts doesn't exist, I get the following in index.html + + + + + +When I create posts (touch posts.mdwn), I get the following in index.html + + + + + +Bug? -- cgit v1.2.3 From bf386e22f5fb65999c38668cb011bdf4ae26d72c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 1 Oct 2008 17:29:03 -0400 Subject: inline: Fix handling of rootpage that doesn't exist. It makes sense to use bestlink to determine which page rootpage refers to, but if no page matches, just use the raw value. --- IkiWiki/Plugin/inline.pm | 3 +++ debian/changelog | 1 + doc/bugs/inline_from_field_empty_if_rootpage_doesn__39__t_exist.mdwn | 3 +++ 3 files changed, 7 insertions(+) (limited to 'doc/bugs') diff --git a/IkiWiki/Plugin/inline.pm b/IkiWiki/Plugin/inline.pm index e0f33ef31..5d2ef5681 100644 --- a/IkiWiki/Plugin/inline.pm +++ b/IkiWiki/Plugin/inline.pm @@ -266,6 +266,9 @@ sub preprocess_inline (@) { #{{{ my $rootpage; if (exists $params{rootpage}) { $rootpage=bestlink($params{page}, $params{rootpage}); + if (!length $rootpage) { + $rootpage=$params{rootpage}; + } } else { $rootpage=$params{page}; diff --git a/debian/changelog b/debian/changelog index 1320e4f41..6c6eea205 100644 --- a/debian/changelog +++ b/debian/changelog @@ -32,6 +32,7 @@ ikiwiki (2.66) UNRELEASED; urgency=low (Sponsored by The TOVA Company.) * httpauth: Document that ikiwiki.cgi has to be in a directory subject to authentication. Closes: #500524 + * inline: Fix handling of rootpage that doesn't exist. -- Joey Hess Thu, 25 Sep 2008 13:45:55 -0400 diff --git a/doc/bugs/inline_from_field_empty_if_rootpage_doesn__39__t_exist.mdwn b/doc/bugs/inline_from_field_empty_if_rootpage_doesn__39__t_exist.mdwn index 995f0836f..61aeff244 100644 --- a/doc/bugs/inline_from_field_empty_if_rootpage_doesn__39__t_exist.mdwn +++ b/doc/bugs/inline_from_field_empty_if_rootpage_doesn__39__t_exist.mdwn @@ -15,3 +15,6 @@ When I create posts (touch posts.mdwn), I get the following in index.html Bug? + +> Yes, thanks for reminding me I need to do something about that... [[done]] +> --[[Joey]] -- cgit v1.2.3 From d30a7b12685d44312d89a2a1f7e24bb750556135 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 2 Oct 2008 14:48:35 -0400 Subject: fix bug closure --- ...n_causes_websetup_to_change_timeformat__44___even_when_disabled.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/bugs') diff --git a/doc/bugs/ddate_plugin_causes_websetup_to_change_timeformat__44___even_when_disabled.mdwn b/doc/bugs/ddate_plugin_causes_websetup_to_change_timeformat__44___even_when_disabled.mdwn index b195f48ee..a74f6fcc7 100644 --- a/doc/bugs/ddate_plugin_causes_websetup_to_change_timeformat__44___even_when_disabled.mdwn +++ b/doc/bugs/ddate_plugin_causes_websetup_to_change_timeformat__44___even_when_disabled.mdwn @@ -4,4 +4,4 @@ Presumably this is because websetup loads all plugins, so IkiWiki::plugin::ddate (This bug seems oddly appropriate. Hail Eris) -[[done fnord|done]] +[[done_fnord|done]] -- cgit v1.2.3 From 5c2309ada8d969bb4556e8d76d9d53668d7f9a83 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 2 Oct 2008 14:49:40 -0400 Subject: typo --- doc/bugs/Cannot_inline_pages_with_apostrophes_in_title.mdwn | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'doc/bugs') diff --git a/doc/bugs/Cannot_inline_pages_with_apostrophes_in_title.mdwn b/doc/bugs/Cannot_inline_pages_with_apostrophes_in_title.mdwn index a95378851..7daf52f2a 100644 --- a/doc/bugs/Cannot_inline_pages_with_apostrophes_in_title.mdwn +++ b/doc/bugs/Cannot_inline_pages_with_apostrophes_in_title.mdwn @@ -1,3 +1,5 @@ -If I create a page whose title contains an apostrophe, then inlining that page produces nothing. It looks like the inline plugin is failing to do the translation from apostrophe to "_39_" that other parts of the system do, so although one can make wikilinks to such pages and have them detected as existing (for instance, by the conditional plugin), inline looks in the wrong place and doesn't see the page. +If I create a page whose title contains an apostrophe, then inlining that +page produces nothing. It looks like the inline plugin is failing to do +the translation from apostrophe to `_39_` that other parts of the system do, so although one can make wikilinks to such pages and have them detected as existing (for instance, by the conditional plugin), inline looks in the wrong place and doesn't see the page. > I can't reproduce that (btw, an apostrophe would be `__39__`) --[[Joey]] -- cgit v1.2.3 From 605ce027109fa2f3a9fe227d4e7e172ae2d6f7af Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 2 Oct 2008 14:51:21 -0400 Subject: move to todo, response --- doc/bugs/Tags_list_in_page_footer_uses_basename.mdwn | 5 ----- doc/todo/Tags_list_in_page_footer_uses_basename.mdwn | 8 ++++++++ 2 files changed, 8 insertions(+), 5 deletions(-) delete mode 100644 doc/bugs/Tags_list_in_page_footer_uses_basename.mdwn create mode 100644 doc/todo/Tags_list_in_page_footer_uses_basename.mdwn (limited to 'doc/bugs') diff --git a/doc/bugs/Tags_list_in_page_footer_uses_basename.mdwn b/doc/bugs/Tags_list_in_page_footer_uses_basename.mdwn deleted file mode 100644 index 65406680a..000000000 --- a/doc/bugs/Tags_list_in_page_footer_uses_basename.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -Page footers contain a list of links to the page and a list of tags applied to the page. The link list uses the full path to pages. However, the tag list contains only the basename of the tag pages. For instance, if I tag a page with person1/foo and person2/bar, the tag list will just list foo and bar without the necessary disambiguating prefixes. - -I think the tag list should always contain the full path to the tag, with the tagbase value removed. - ---[[JoshTriplett]] diff --git a/doc/todo/Tags_list_in_page_footer_uses_basename.mdwn b/doc/todo/Tags_list_in_page_footer_uses_basename.mdwn new file mode 100644 index 000000000..e2221bb84 --- /dev/null +++ b/doc/todo/Tags_list_in_page_footer_uses_basename.mdwn @@ -0,0 +1,8 @@ +Page footers contain a list of links to the page and a list of tags applied to the page. The link list uses the full path to pages. However, the tag list contains only the basename of the tag pages. For instance, if I tag a page with person1/foo and person2/bar, the tag list will just list foo and bar without the necessary disambiguating prefixes. + +I think the tag list should always contain the full path to the tag, with the tagbase value removed. + +--[[JoshTriplett]] + +> What if tagbase is not used? I know this would clutter up the display of +> my tags on several wikis, including this one. --[[Joey]] -- cgit v1.2.3 From 6055dd3ef2390c4a4655f3a1de1ae71bec72508b Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 2 Oct 2008 14:53:11 -0400 Subject: close --- ...38__uuml__59___in_markup_makes_ikiwiki_not_un-escape_HTML_at_all.mdwn | 1 + 1 file changed, 1 insertion(+) (limited to 'doc/bugs') diff --git a/doc/bugs/__38__uuml__59___in_markup_makes_ikiwiki_not_un-escape_HTML_at_all.mdwn b/doc/bugs/__38__uuml__59___in_markup_makes_ikiwiki_not_un-escape_HTML_at_all.mdwn index 94a0e5445..eb3450a7e 100644 --- a/doc/bugs/__38__uuml__59___in_markup_makes_ikiwiki_not_un-escape_HTML_at_all.mdwn +++ b/doc/bugs/__38__uuml__59___in_markup_makes_ikiwiki_not_un-escape_HTML_at_all.mdwn @@ -44,3 +44,4 @@ unless that has security implications. >> >> I hope that's just a minor blemish. --liw +>>> Sounds like this is [[done]] --[[Joey]] -- cgit v1.2.3 From a1f4a9c5c9b93a93923d4dcd3a471bf409abd1a3 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 2 Oct 2008 14:54:52 -0400 Subject: ping --- doc/bugs/aggregate_plugin_should_honour_a_post__39__s_mctime.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/bugs') diff --git a/doc/bugs/aggregate_plugin_should_honour_a_post__39__s_mctime.mdwn b/doc/bugs/aggregate_plugin_should_honour_a_post__39__s_mctime.mdwn index 61f6f733a..865637ea4 100644 --- a/doc/bugs/aggregate_plugin_should_honour_a_post__39__s_mctime.mdwn +++ b/doc/bugs/aggregate_plugin_should_honour_a_post__39__s_mctime.mdwn @@ -11,3 +11,5 @@ appropriately, so that ikiwiki reflects the actual time of the post via the if defined $mtime && $mtime <= time; >> I'll have to debug this, it's not working here... and this is an ikiwiki aggregator scraping another ikiwiki site. + +>>> Any news about this? --[[Joey]] -- cgit v1.2.3 From 0b1b72b2ee714c470b28426c875bcd6887b386c8 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 2 Oct 2008 15:01:03 -0400 Subject: thoughts --- ...lert_user_about_an_invalid_pagespec_in_preferences.mdwn | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'doc/bugs') diff --git a/doc/bugs/lockedit_plugin_should_alert_user_about_an_invalid_pagespec_in_preferences.mdwn b/doc/bugs/lockedit_plugin_should_alert_user_about_an_invalid_pagespec_in_preferences.mdwn index 63c5b5e08..c835d9f98 100644 --- a/doc/bugs/lockedit_plugin_should_alert_user_about_an_invalid_pagespec_in_preferences.mdwn +++ b/doc/bugs/lockedit_plugin_should_alert_user_about_an_invalid_pagespec_in_preferences.mdwn @@ -1,3 +1,17 @@ [[plugins/lockedit]] adds the form fields for a [[pagespec]] to preferences. This pagespec should be supplied "raw"; i.e., without quotes around it. Inexperienced users (such as [[myself|jondowland]]) may provide an invalid pagespec, such as one with quotes on it. This will be merrily accepted by the form, but will cause no locking to take place. Perhaps some validation should be performed on the pagespec and the form-submission return include "warning: this pagespec is invalid" or "warning: this pagespec does not match any existing pages" or similar. + +> The pagespec is no longer in the preferences and instead in the setup +> file now. That makes warning about a problem with it harder. +> +> Ikiwiki could try to detect this problem and warn at setup time to +> stderr, I guess. +> +> Main problem is I see little way to actually detect the problem you +> described. A pagespec with quotes around it is valid. For example, the +> pagespec `"foo or bar"` matches a page named `"foo` or a page named `bar"`. +> +> There are small classes of invalid pagespecs. For example, `(foo or bar` +> is invalid due to having unbalanced parens, while `foo or and bar` +> has invalid syntax. It's possible to detect these, I guess ... --[[Joey]] -- cgit v1.2.3 From c22c010e16ea36f9dc6b9f178812387e9fb1421f Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 2 Oct 2008 15:11:17 -0400 Subject: response --- doc/bugs/blog_posts_not_added_to_mercurial_repo.mdwn | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'doc/bugs') diff --git a/doc/bugs/blog_posts_not_added_to_mercurial_repo.mdwn b/doc/bugs/blog_posts_not_added_to_mercurial_repo.mdwn index c57c20065..eead716d5 100644 --- a/doc/bugs/blog_posts_not_added_to_mercurial_repo.mdwn +++ b/doc/bugs/blog_posts_not_added_to_mercurial_repo.mdwn @@ -28,3 +28,23 @@ If I then edit the blog post, **then** the file gets commited and I can see the >>>> However, the part that seems a bit wrong to me, is this: even if my locale is utf8, I have to explicitly set a utf8 locale in the wiki's setup file, or the commit fails. It looks like ikiwiki is not using this machine's default locale, which is utf8. Also, I'm not getting any errors on apache's error log. >>>> Wouldn't it make sense to use the machine's default locale if 'locale' is commented out in the setup file? + +>>>>> Ikiwiki wrappers only allow whitelisted environment variables +>>>>> through, and the locale environment variables are not included +>>>>> currently. +>>>>> +>>>>> But that's not the whole story, because "machine's default locale" +>>>>> is not very well defined. For example, my laptop is a Debian system. +>>>>> It has a locale setting in /etc/environment (`LANG="en_US.UTF-8"`). +>>>>> But even if I start apache, making sure that LANG is set and exported +>>>>> in the environment, CGI scripts apache runs do not see LANG in their +>>>>> environment. (I notice that `/etc/init.d/apache` explocitly +>>>>> forces LANG=C. But CGI scripts don't see the C value either.) +>>>>> Apache simply does not propigate its runtime environment to CGI +>>>>> scripts, and this is probably to comply with the CGI specification +>>>>> (although it doesn't seem to completly rule out CGI's being passed +>>>>> other variables). +>>>>> +>>>>> If mercurial needs a utf-8 locale, I guess the mercurial plugin needs +>>>>> to check if it's not in one, and do something sane (either fail +>>>>> earlier, or complain, or strip utf-8 out of comments). --[[Joey]] -- cgit v1.2.3 From c885a0107bf3f0fbedc53ec22e359942e6c8170a Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 2 Oct 2008 15:12:57 -0400 Subject: this is a wishlist todo item, rename too --- doc/bugs/relative_links.mdwn | 27 -------------------- ...ttp_or_https_in_urls_to_allow_serving_both.mdwn | 29 ++++++++++++++++++++++ 2 files changed, 29 insertions(+), 27 deletions(-) delete mode 100644 doc/bugs/relative_links.mdwn create mode 100644 doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn (limited to 'doc/bugs') diff --git a/doc/bugs/relative_links.mdwn b/doc/bugs/relative_links.mdwn deleted file mode 100644 index a1dc8f373..000000000 --- a/doc/bugs/relative_links.mdwn +++ /dev/null @@ -1,27 +0,0 @@ -It looks like all links in websites are absolute paths, this has some limitations: - -* If connecting to website via https://... all links will take you back to http:// -* Makes it harder to mirror website via HTML version, as all links have to be updated. - -It would be good if relative paths could be used instead, so the transport method isn't changed unless specifically requested. - --- Brian May - -> Er, which absolute links are you talking about? If you view the source -> to this page, you'll find links such as "../favicon.ico", "../style.css", -> "../../", and "../". The only absolute links are to CGIs and the w3c DTD. -> --[[Joey]] - ->> 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 - ->>> Ikiwiki does not hardcode http links anywhere. If you don't want ->>> it to use such links, change your configuration to use https ->>> consistently. --[[Joey]] - -Errr... That is not a solution, that is a work around. ikiwiki does not hard code the absolute paths, but absolute paths are hard coded in the configuration file. If you want to serve your website so that the majority of users can see it as http, including in rss feeds (this allows proxy caches to cache the contents and has reduced load requirements), but editing is done via https for increased security, it is not possible. I have some ideas how this can be implemented (as ikiwiki has the absolute path to the CGI script and the absolute path to the destination, it should be possible to generate a relative path from one to the other), although some minor issues still need to be resolved. -- Brian May - -I noticed the links to the images on are also absolute, that is ; this seems surprising, as the change.tmpl file uses <TMPL_VAR BASEURL> -which seems to do the right thing in page.tmpl, but not for change.tmpl. Where is BASEURL set? -- Brian May - -> The use of an absolute baseurl in change.tmpl is a special case. --[[Joey]] diff --git a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn new file mode 100644 index 000000000..65b7cd96a --- /dev/null +++ b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn @@ -0,0 +1,29 @@ +It looks like all links in websites are absolute paths, this has some limitations: + +* If connecting to website via https://... all links will take you back to http:// +* Makes it harder to mirror website via HTML version, as all links have to be updated. + +It would be good if relative paths could be used instead, so the transport method isn't changed unless specifically requested. + +-- Brian May + +> Er, which absolute links are you talking about? If you view the source +> to this page, you'll find links such as "../favicon.ico", "../style.css", +> "../../", and "../". The only absolute links are to CGIs and the w3c DTD. +> --[[Joey]] + +>> 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 + +>>> Ikiwiki does not hardcode http links anywhere. If you don't want +>>> it to use such links, change your configuration to use https +>>> consistently. --[[Joey]] + +Errr... That is not a solution, that is a work around. ikiwiki does not hard code the absolute paths, but absolute paths are hard coded in the configuration file. If you want to serve your website so that the majority of users can see it as http, including in rss feeds (this allows proxy caches to cache the contents and has reduced load requirements), but editing is done via https for increased security, it is not possible. I have some ideas how this can be implemented (as ikiwiki has the absolute path to the CGI script and the absolute path to the destination, it should be possible to generate a relative path from one to the other), although some minor issues still need to be resolved. -- Brian May + +I noticed the links to the images on are also absolute, that is ; this seems surprising, as the change.tmpl file uses <TMPL_VAR BASEURL> +which seems to do the right thing in page.tmpl, but not for change.tmpl. Where is BASEURL set? -- Brian May + +> The use of an absolute baseurl in change.tmpl is a special case. --[[Joey]] + +[[wishlist]] -- cgit v1.2.3 From 0b89d442331bd62b4dc2da4f7fcbca59d5ca21eb Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 2 Oct 2008 17:42:33 -0400 Subject: rename --- doc/bugs/ikiwiki_is_not_truly_localizable.mdwn | 47 ---------------------- .../some_strings_are_not_internationalized.mdwn | 47 ++++++++++++++++++++++ 2 files changed, 47 insertions(+), 47 deletions(-) delete mode 100644 doc/bugs/ikiwiki_is_not_truly_localizable.mdwn create mode 100644 doc/bugs/some_strings_are_not_internationalized.mdwn (limited to 'doc/bugs') diff --git a/doc/bugs/ikiwiki_is_not_truly_localizable.mdwn b/doc/bugs/ikiwiki_is_not_truly_localizable.mdwn deleted file mode 100644 index a1b38257a..000000000 --- a/doc/bugs/ikiwiki_is_not_truly_localizable.mdwn +++ /dev/null @@ -1,47 +0,0 @@ -A lot of strings in ikiwiki are hardcoded and not taken for locales resources through gettext. This is bad because ikiwiki is thus difficult to spread for non-english users. - -I mean that, for instance in CGI.pm, line like: - -`my @buttons=("Save Page", "Preview", "Cancel");` - -should be written as - -`my @buttons=(gettext("Save Page"), gettext("Preview"), gettext("Cancel"));` - -> Yes, these need to be fixed. But note that the localised texts come back -> into ikiwiki and are used in various places, including plugins. -> Including, possibly, third-party plugins. So localising the buttons would -> seem to require converting from the translations back into the C locale -> when the form is posted. --[[Joey]] - ->> Wouldn't it be more easy to change all calls to the corrects ones (including in plugins) ? ->> For instance in the same file (CGI.pm): `elsif ($form->submitted eq gettext("Save Page")) {`. ->> That way no conversion to the C locale is needed. ->> gettext use should just be publicized in documentation (at least in [[plugins/write]]). --[[bbb]] - ->>> It would be easy, but it could break third-party plugins that hardcode ->>> the english strings. It's also probably less efficient to run gettext ->>> over and over. --[[Joey]] - -In standards templates things seems wrongly written too. For instance in page.tmpl line like: - -`

` - -should be written as - -`

` - -with EDITURL_TEXT variable initialized in Render.pm through a gettext call. - -Am I wrong ? - -> No, that's not a sane way to localise the templates. The templates can be -> translated by making a copy and modifying it, or by using a tool to -> generate .mo files from the templates, and generate translated templates -> from .po files. (See [[todo/l10n]] for one attempt.) But pushing the -> localisation of random strings in the templates through the ikiwiki -> program defeats the purpose of having templates at all. --[[Joey]] - -If not I can spend some time preparing patches for such corrections if it can help. - --- [[/users/bbb]] diff --git a/doc/bugs/some_strings_are_not_internationalized.mdwn b/doc/bugs/some_strings_are_not_internationalized.mdwn new file mode 100644 index 000000000..a1b38257a --- /dev/null +++ b/doc/bugs/some_strings_are_not_internationalized.mdwn @@ -0,0 +1,47 @@ +A lot of strings in ikiwiki are hardcoded and not taken for locales resources through gettext. This is bad because ikiwiki is thus difficult to spread for non-english users. + +I mean that, for instance in CGI.pm, line like: + +`my @buttons=("Save Page", "Preview", "Cancel");` + +should be written as + +`my @buttons=(gettext("Save Page"), gettext("Preview"), gettext("Cancel"));` + +> Yes, these need to be fixed. But note that the localised texts come back +> into ikiwiki and are used in various places, including plugins. +> Including, possibly, third-party plugins. So localising the buttons would +> seem to require converting from the translations back into the C locale +> when the form is posted. --[[Joey]] + +>> Wouldn't it be more easy to change all calls to the corrects ones (including in plugins) ? +>> For instance in the same file (CGI.pm): `elsif ($form->submitted eq gettext("Save Page")) {`. +>> That way no conversion to the C locale is needed. +>> gettext use should just be publicized in documentation (at least in [[plugins/write]]). --[[bbb]] + +>>> It would be easy, but it could break third-party plugins that hardcode +>>> the english strings. It's also probably less efficient to run gettext +>>> over and over. --[[Joey]] + +In standards templates things seems wrongly written too. For instance in page.tmpl line like: + +`

Edit

` + +should be written as + +`