diff options
-rw-r--r-- | doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn | 5 | ||||
-rw-r--r-- | doc/bugs/nested_raw_included_inlines.mdwn | 8 | ||||
-rw-r--r-- | doc/bugs/openid_no_longer_pretty-prints_OpenIDs.mdwn | 22 | ||||
-rw-r--r-- | doc/bugs/prettydate_with_weekday-date_inconsistency.mdwn | 2 | ||||
-rw-r--r-- | doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn | 2 | ||||
-rw-r--r-- | doc/plugins/anonok.mdwn | 2 | ||||
-rw-r--r-- | doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn | 24 |
7 files changed, 47 insertions, 18 deletions
diff --git a/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn b/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn index b1f8ed2b3..4ce257252 100644 --- a/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn +++ b/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn @@ -33,3 +33,8 @@ Patch[[!tag patch]]: -- [[Jon]] + +> Strictly speaking, a `<ul>` with no `<li>`s isn't valid HTML either... +> could `map` instead delay emitting the first `<ul>` until it determines that +> it will have at least one item? Perhaps refactoring that function into +> something easier to regression-test would be useful. --[[smcv]] diff --git a/doc/bugs/nested_raw_included_inlines.mdwn b/doc/bugs/nested_raw_included_inlines.mdwn index 792bc843c..33433e235 100644 --- a/doc/bugs/nested_raw_included_inlines.mdwn +++ b/doc/bugs/nested_raw_included_inlines.mdwn @@ -24,3 +24,11 @@ In my real world situation, page1 is actually listing all pages that match a cer Whenever a page got tagged, it will appear on page1 but not on page0. Am I missing something? Is this a bug or Ikiwiki not supposed to support this use case? + +> Perhaps the inline plugin isn't being clever enough about dependencies - +> strictly speaking, when a page is inlined with full content, the inlining +> page should probably inherit all the inlined page's dependencies. +> That might be prohibitively slow in practise due to the way IkiWiki +> currently merges pagespecs, though - maybe the patches I suggested for +> [[separating_and_uniquifying_pagespecs|todo/should_optimise_pagespecs]] +> would help? --[[smcv]] diff --git a/doc/bugs/openid_no_longer_pretty-prints_OpenIDs.mdwn b/doc/bugs/openid_no_longer_pretty-prints_OpenIDs.mdwn index 1e2030b23..85a206bc0 100644 --- a/doc/bugs/openid_no_longer_pretty-prints_OpenIDs.mdwn +++ b/doc/bugs/openid_no_longer_pretty-prints_OpenIDs.mdwn @@ -8,22 +8,10 @@ The git commit (in my `openid` branch) says it all: This bug affects ikiwiki.info (my commits show up in [[RecentChanges]] as http://smcv.pseudorandom.co.uk/ rather than smcv [pseudorandom.co.uk]). -> Cherry picked, thanks. --[[Joey]] +> Cherry picked, thanks. --[[Joey]] -Relatedly, the other commit on the same branch would be nice to have: +Relatedly, the other commit on the same branch would be nice to have +(edited to add: I've now moved it, and its discussion, to +[[todo/pretty-print_OpenIDs_even_if_not_enabled]]). --[[smcv]] - Allow the openid plugin to be loaded but disabled, for its side-effect of defining IkiWiki::openiduser - - On various sites I have two IkiWiki instances running from the same - repository: one accessible via http and only accepting openid logins, - and one accessible via authenticated https and only accepting httpauth. - Ideally, the https version should still pretty-print OpenIDs seen in - git history. - ---[[smcv]] - -> I wonder if an option is the best approach. Maybe it would be better to -> simply move `openiduser` into `userlink`, and thus always support openid -> usernames whether the plugin is enabled or not. --[[Joey]] - -[[!tag patch]] +[[!tag done]] diff --git a/doc/bugs/prettydate_with_weekday-date_inconsistency.mdwn b/doc/bugs/prettydate_with_weekday-date_inconsistency.mdwn index 111ade8dd..430d65a3f 100644 --- a/doc/bugs/prettydate_with_weekday-date_inconsistency.mdwn +++ b/doc/bugs/prettydate_with_weekday-date_inconsistency.mdwn @@ -28,3 +28,5 @@ Prettydate creates strings like this: _Last edited in the wee hours of Tuesday n > --[[Joey]] >> fair enough, I think I can get converted to a warped time perspective. --ulrik + +>>> Perhaps we can consider this [[done]], then? --[[smcv]] diff --git a/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn b/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn index ca80c93f4..7599e71e5 100644 --- a/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn +++ b/doc/forum/Can_OpenID_users_be_adminusers__63__.mdwn @@ -65,3 +65,5 @@ index 0bf100a..77b467a 100644 >>>> If the end if "1" you should see the "Wiki Setup" button, if not the >>>> problem is not in determining if you're an admin, but elsewhere.. >>>> --[[Joey]] + +I was being incredibly stupid and missed that websetup is a **plugin** and thus needed to be enabled. Many thanks for your patient assistance, by helping me eliminate the unlikely it eventually led me to the obvious. Cheers. -- [[Adam]] diff --git a/doc/plugins/anonok.mdwn b/doc/plugins/anonok.mdwn index a3fec4d89..497ca07c8 100644 --- a/doc/plugins/anonok.mdwn +++ b/doc/plugins/anonok.mdwn @@ -6,7 +6,7 @@ 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_pagespec`. This -[[PageSpec]] can be used to allow anonymous editing of matching pages. +[[ikiwiki/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: diff --git a/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn b/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn new file mode 100644 index 000000000..373c120a6 --- /dev/null +++ b/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn @@ -0,0 +1,24 @@ +A feature I originally requested on +[[a_related_bug|bugs/openid_no_longer_pretty-prints_OpenIDs]]: + + Allow the openid plugin to be loaded but disabled, for its side-effect of defining IkiWiki::openiduser + + On various sites I have two IkiWiki instances running from the same + repository: one accessible via http and only accepting openid logins, + and one accessible via authenticated https and only accepting httpauth. + Ideally, the https version should still pretty-print OpenIDs seen in + git history. + +--[[smcv]] + +> I wonder if an option is the best approach. Maybe it would be better to +> simply move `openiduser` into `userlink`, and thus always support openid +> usernames whether the plugin is enabled or not. --[[Joey]] + +>> OK, implemented that as 'smcv/always-openid'; if you don't think that's +>> bloating the IkiWiki core too much, please consider merging. The poll on +>> [[news/openid]] indicates fairly strong support for *only* accepting OpenID +>> logins, so I think recognising OpenIDs can reasonably be considered core +>> functionality! --[[smcv]] + +[[!tag patch]] |