+----
--
cgit v1.2.3
From 470712618401fb3cd322c84d1c57e4b8835850d5 Mon Sep 17 00:00:00 2001
From: "http://kaizer.se/"
Date: Thu, 17 Sep 2009 12:07:23 -0400
Subject: The page is rST-parsed once in 'scan' and once in 'htmlize' (the
first to generate backlinks). Can the parse output be safely reused?
---
doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index c90261dc3..7adcb5c09 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -7,7 +7,7 @@ Design issues of the patch:
Right now it changes rendering so that undefined pages (previous errors) are resolved to either ikiwiki pages or link to "#". It could be changed (trivially) so that undefined pages give the same error as before. Since it only resolves links that would previously error out, impact on current installations should be minimal.
-I don't know why backlinks don't show up with the patch as it is; they are registered, but not rendered on the linked-to page.
+The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to generate backlinks). Can the parse output be safely reused?
Desing issues in general:
--
cgit v1.2.3
From 356188f7c65c0e9b78e8be1e477acb785d48d3c2 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Thu, 17 Sep 2009 12:42:40 -0400
Subject: response
---
doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 5 +++++
1 file changed, 5 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index 7adcb5c09..c98723f2d 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -9,6 +9,11 @@ Right now it changes rendering so that undefined pages (previous errors) are res
The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to generate backlinks). Can the parse output be safely reused?
+> The page content fed to htmlize may be different than that fed to scan,
+> as directives can change the content. If you cached the input and output
+> at scan time, you could reuse the cached data at htmlize time for inputs
+> that are the same -- but that could be a very big cache! --[[Joey]]
+
Desing issues in general:
We resolve rST links without definition, we don't help resolving defined relative links, so we don't support specifying link name and target separately.
--
cgit v1.2.3
From fc1cc57cdca9a7bdab41f0d63e34a98a2d7c78e5 Mon Sep 17 00:00:00 2001
From: "http://kaizer.se/"
Date: Thu, 17 Sep 2009 15:38:40 -0400
Subject: about replacements in rst (renaming links)
---
...Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 10 ++++++++++
1 file changed, 10 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index c98723f2d..642382b47 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -18,6 +18,16 @@ Desing issues in general:
We resolve rST links without definition, we don't help resolving defined relative links, so we don't support specifying link name and target separately.
+> I found out this is possible by using rST subsitutions. So to do [[Version history...|releases]]
+> you would use:
+>
+> `|releases|_`
+> `.. |releases| replace:: Version history...`
+> Which does not seem to have an inline replacement. Using non-resolved links there is the alternative:
+>
+> ``Version history `_`. --ulrik [kaizer.se]
+
+
Many other issues with rST are of course unresolved, but some might be solved by implementing custom rST directives (which is a supported extension mechanism).
Patch follows:
--
cgit v1.2.3
From b7db2ca37f400e09a663b01800e3bc5477a304df Mon Sep 17 00:00:00 2001
From: "http://kaizer.se/"
Date: Thu, 17 Sep 2009 15:42:34 -0400
Subject: word use, equivalent is better.
---
doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index 642382b47..aa96fc431 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -23,7 +23,7 @@ We resolve rST links without definition, we don't help resolving defined relativ
>
> `|releases|_`
> `.. |releases| replace:: Version history...`
-> Which does not seem to have an inline replacement. Using non-resolved links there is the alternative:
+> Which does not seem to have an inline equivalent. Using non-resolved links there is the alternative:
>
> ``Version history `_`. --ulrik [kaizer.se]
--
cgit v1.2.3
From e19d0c5bbdcd45d810688f990381b639485434bb Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup
Date: Fri, 18 Sep 2009 16:08:16 +0200
Subject: on caching
---
.../Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 6 ++++++
1 file changed, 6 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index aa96fc431..c8d7ba5ed 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -14,6 +14,12 @@ The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to genera
> at scan time, you could reuse the cached data at htmlize time for inputs
> that are the same -- but that could be a very big cache! --[[Joey]]
+>> I would propose using a simple heuristic: If you see `[[` anywhere on the
+>> page, don't cache it. It would be an effective cache for pure-rst wikis
+>> (without any ikiwiki directives or wikilinks).
+>> However, I think that if the cache does not work for a big load, it should
+>> not work at all; small loads are small so they don't matter. --ulrik
+
Desing issues in general:
We resolve rST links without definition, we don't help resolving defined relative links, so we don't support specifying link name and target separately.
--
cgit v1.2.3
From 5cd338fe16ede5aa1dbbf80cdfe027f8bfa09cd3 Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup
Date: Fri, 18 Sep 2009 16:10:43 +0200
Subject: escape markup (oops)
---
doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index c8d7ba5ed..682229469 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -14,7 +14,7 @@ The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to genera
> at scan time, you could reuse the cached data at htmlize time for inputs
> that are the same -- but that could be a very big cache! --[[Joey]]
->> I would propose using a simple heuristic: If you see `[[` anywhere on the
+>> I would propose using a simple heuristic: If you see \[[ anywhere on the
>> page, don't cache it. It would be an effective cache for pure-rst wikis
>> (without any ikiwiki directives or wikilinks).
>> However, I think that if the cache does not work for a big load, it should
--
cgit v1.2.3
From 25eafa8522a9480ca2abb6df45a613ac3d0b9880 Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup
Date: Fri, 18 Sep 2009 16:46:41 +0200
Subject: Refactor, and Propose :wiki: syntax for rST wikilinks
---
...ve_reStructuredText_links_to_ikiwiki_pages.mdwn | 112 +++++++++++++++++----
1 file changed, 94 insertions(+), 18 deletions(-)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index 682229469..49be3f30a 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -1,28 +1,84 @@
-I have a working minimal implementation letting the rst renderer resolve undefined native rST links to ikiwiki pages. I have posted it as one patch at:
+_NB! this page has been refactored, hopefully it is clearer now_
+_I propose putting discussion posts somewhere in the vincity of
+the secttion Individual reStructuredText Issues_
-Preview commit: http://github.com/engla/ikiwiki/commit/486fd79e520da1d462f00f40e7a90ab07e9c6fdf
-Repository: git://github.com/engla/ikiwiki.git
+**Goal**
-Design issues of the patch:
+To be able to use rst as a first-class markup language in ikiwiki. I think
+most believe this is almost impossible (ikiwiki is built around markdown).
-Right now it changes rendering so that undefined pages (previous errors) are resolved to either ikiwiki pages or link to "#". It could be changed (trivially) so that undefined pages give the same error as before. Since it only resolves links that would previously error out, impact on current installations should be minimal.
+**Design**
-The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to generate backlinks). Can the parse output be safely reused?
+**WikiLinks**, first and foremost, are needed for a wiki. rST already allows
+specifying absolue and relative URL links, and relative links can be used to
+tie together wiki of rst documents.
-> The page content fed to htmlize may be different than that fed to scan,
-> as directives can change the content. If you cached the input and output
-> at scan time, you could reuse the cached data at htmlize time for inputs
-> that are the same -- but that could be a very big cache! --[[Joey]]
+1. Below are links to a small, working implementation for resolving
+ undefined rST references using ikiwiki's mechanism. This is **Proposal 1**
+ for rst WikiLinks.
->> I would propose using a simple heuristic: If you see \[[ anywhere on the
->> page, don't cache it. It would be an effective cache for pure-rst wikis
->> (without any ikiwiki directives or wikilinks).
->> However, I think that if the cache does not work for a big load, it should
->> not work at all; small loads are small so they don't matter. --ulrik
+2. Looking over at rST-using systems such as trac and MoinMoin; I think it
+ would be wiser to implement wikilinks by the `:role:` mechanism, together
+ with allowing a custom URL scheme to point to wiki links. This is
+ **Proposal 2**.
+
+ This is a simple wiki page, with :wiki:`WikiLinks` and other_ links
+
+ .. _other: wiki:wikilink
+
+Benefits of using a `:role:` and a `wiki: page/subpage` URL scheme are
+following:
+
+1. rST documents taken out of the context (the wiki) will not fail as bad as
+ if they have lots of Proposal-1 links: They look just the same as valid
+ references, and you have to edit them all.
+ In contrast, should the `:wiki:` role disappear, one line is enough
+ to redefined it and silence all the warnings for the document:
+
+ .. role:: wiki (title)
+
+*Implementation* there is no implementation of Proposal 2 but it should be
+doable; adding a local role is trivial. Rewriting `wiki:` links could be
+done in the format phase(?).
+
+Now **Directives**: As it is now, ikiwiki goes though (roughly):
+filter, preprocess, htmlize, format as major stages of content
+transformation. rST has major problems to work with any HTML that enters the
+picture before it.
+
+1. Formatting rST in `htmlize` (as is done now): Raw html can be escaped by
+ raw blocks:
+
+ .. raw:: html
+
+ \[[!inline and do stuff]]
+
+ (This can be simplified to alias the above as `.. ikiwiki::`)
+ This escape method works, if ikwiki can be persuaded to maintain the
+ indent when inserting html, so that it stays inside the raw block.
+
+2. Formatting rST in `filter` (idea)
+ 1. rST does not have to see any HTML (raw not needed)
+ 2. rST directives can alias ikiwiki syntax:
+
+ ..ikiwiki:: inline pages= ...
-Desing issues in general:
+ 3. Using rST directives as ikiwiki directives can be complicated;
+ but rST directives allow a direct line (after :: on first line),
+ an option list, and a content block.
-We resolve rST links without definition, we don't help resolving defined relative links, so we don't support specifying link name and target separately.
+
+**Discussion**
+
+I guess you (or someone) has been through this before and knows why it
+simply won't work. But I hoped there was something original in the above;
+and I know there are wiki installations where rST works. --ulrik
+
+**Individual reStructuredText Issues**
+
+* We resolve rST links without definition, we don't help resolving defined
+ relative links, so we don't support specifying link name and target
+ separately.
> I found out this is possible by using rST subsitutions. So to do [[Version history...|releases]]
> you would use:
@@ -33,8 +89,28 @@ We resolve rST links without definition, we don't help resolving defined relativ
>
> ``Version history `_`. --ulrik [kaizer.se]
+**A first implementation: Resolving unmatched links**
+
+I have a working minimal implementation letting the rst renderer resolve
+undefined native rST links to ikiwiki pages. I have posted it as one patch at:
+
+Preview commit: http://github.com/engla/ikiwiki/commit/486fd79e520da1d462f00f40e7a90ab07e9c6fdf
+Repository: git://github.com/engla/ikiwiki.git
+
+Design issues of the patch:
+
+The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to generate backlinks). Can the parse output be safely reused?
+
+> The page content fed to htmlize may be different than that fed to scan,
+> as directives can change the content. If you cached the input and output
+> at scan time, you could reuse the cached data at htmlize time for inputs
+> that are the same -- but that could be a very big cache! --[[Joey]]
-Many other issues with rST are of course unresolved, but some might be solved by implementing custom rST directives (which is a supported extension mechanism).
+>> I would propose using a simple heuristic: If you see \[[ anywhere on the
+>> page, don't cache it. It would be an effective cache for pure-rst wikis
+>> (without any ikiwiki directives or wikilinks).
+>> However, I think that if the cache does not work for a big load, it should
+>> not work at all; small loads are small so they don't matter. --ulrik
Patch follows:
--
cgit v1.2.3
From 18151b8152f01421bb42ab62d9fabd56038126e1 Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup
Date: Fri, 18 Sep 2009 20:07:18 +0200
Subject: about default-role
---
.../Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index 49be3f30a..ba9440b43 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -23,9 +23,16 @@ tie together wiki of rst documents.
**Proposal 2**.
This is a simple wiki page, with :wiki:`WikiLinks` and other_ links
-
+
.. _other: wiki:wikilink
+ We can get rid of the role part as well for WikiLinks::
+
+ .. default-role:: wiki
+
+ Enables `WikiLinks` but does not impact references such as ``other``
+ This can be made the default for ikiwiki.
+
Benefits of using a `:role:` and a `wiki: page/subpage` URL scheme are
following:
--
cgit v1.2.3
From 254046edcb4c2ed66bf14dbe3526d39acac9cfe3 Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup
Date: Mon, 21 Sep 2009 23:50:42 +0200
Subject: Posting patch series for rst Wikilinks and Preproc indent
---
...ve_reStructuredText_links_to_ikiwiki_pages.mdwn | 163 ++++++---------------
1 file changed, 42 insertions(+), 121 deletions(-)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index ba9440b43..54d9a6c4b 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -2,12 +2,14 @@ _NB! this page has been refactored, hopefully it is clearer now_
_I propose putting discussion posts somewhere in the vincity of
the secttion Individual reStructuredText Issues_
+## Design ##
+
**Goal**
To be able to use rst as a first-class markup language in ikiwiki. I think
most believe this is almost impossible (ikiwiki is built around markdown).
-**Design**
+## Wikilinks ##
**WikiLinks**, first and foremost, are needed for a wiki. rST already allows
specifying absolue and relative URL links, and relative links can be used to
@@ -44,9 +46,37 @@ following:
.. role:: wiki (title)
-*Implementation* there is no implementation of Proposal 2 but it should be
-doable; adding a local role is trivial. Rewriting `wiki:` links could be
-done in the format phase(?).
+### Implementation ###
+
+Implementation of Proposal-2 wikilinks are in the branch
+[rst-wikilinks][rst-wl]
+
+
+ This is a simple wiki page, with :wiki:`WikiLinks` and |named| links
+
+ .. |named| wiki:: Some Page
+
+ We can get rid of the role part as well for WikiLinks::
+
+ .. default-role:: wiki
+
+ Enables `WikiLinks` but does not impact references such as ``named``
+ This can be made the default for ikiwiki.
+
+[rst-wl]: http://github.com/engla/ikiwiki/commits/rst-wikilinks
+
+On top of **rst-wikilinks** is [rst-customize][rst-custom] which adds two
+power user features: Global (python) file to read in custom directives
+(unsafe), and a wikifile as "header" file for all parsed .rst files (safe,
+but disruptive since all .rst depend on it). Well, the customizations have
+to be picked and chosen from this, but at least the global python file can
+be very convenient.
+
+Some rst-custom [examples are here](http://kaizer.se/wiki/rst_examples/)
+
+[rst-custom]: http://github.com/engla/ikiwiki/commits/rst-customize
+
+## Directives ##
Now **Directives**: As it is now, ikiwiki goes though (roughly):
filter, preprocess, htmlize, format as major stages of content
@@ -74,8 +104,13 @@ picture before it.
but rST directives allow a direct line (after :: on first line),
an option list, and a content block.
+### Implementation ###
+
+Preserving indents in the preprocessor are in branch [pproc-indent][ppi]
-**Discussion**
+[ppi]: http://github.com/engla/ikiwiki/commits/pproc-indent
+
+## Discussion ##
I guess you (or someone) has been through this before and knows why it
simply won't work. But I hoped there was something original in the above;
@@ -86,15 +121,8 @@ and I know there are wiki installations where rST works. --ulrik
* We resolve rST links without definition, we don't help resolving defined
relative links, so we don't support specifying link name and target
separately.
-
-> I found out this is possible by using rST subsitutions. So to do [[Version history...|releases]]
-> you would use:
->
-> `|releases|_`
-> `.. |releases| replace:: Version history...`
-> Which does not seem to have an inline equivalent. Using non-resolved links there is the alternative:
->
-> ``Version history `_`. --ulrik [kaizer.se]
+
+ * Resolved by |replacement| links with the wiki:: directive.
**A first implementation: Resolving unmatched links**
@@ -119,110 +147,3 @@ The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to genera
>> However, I think that if the cache does not work for a big load, it should
>> not work at all; small loads are small so they don't matter. --ulrik
-Patch follows:
-
-----
-
-----
--
cgit v1.2.3
From c399f65b627064de80107f8ee695a9a811604bcd Mon Sep 17 00:00:00 2001
From: "http://kaizer.se/"
Date: Mon, 21 Sep 2009 19:39:03 -0400
Subject: a remark about pproc-indent: I'm not a perl coder.
---
doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 3 +++
1 file changed, 3 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index 54d9a6c4b..d5c92ed6f 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -108,6 +108,9 @@ picture before it.
Preserving indents in the preprocessor are in branch [pproc-indent][ppi]
+(These simple patches come with a warning: _Those are the first lines of
+Perl I've ever written!_)
+
[ppi]: http://github.com/engla/ikiwiki/commits/pproc-indent
## Discussion ##
--
cgit v1.2.3
From d163b06cd6c4a3018a10ced73ec2e74108c3da2a Mon Sep 17 00:00:00 2001
From: "http://kaizer.se/"
Date: Tue, 22 Sep 2009 07:52:10 -0400
Subject: What is missing: Create-links, htmllink
---
doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 4 ++++
1 file changed, 4 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index d5c92ed6f..4bde25bd2 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -76,6 +76,10 @@ Some rst-custom [examples are here](http://kaizer.se/wiki/rst_examples/)
[rst-custom]: http://github.com/engla/ikiwiki/commits/rst-customize
+**What is missing?** links to nonexistant pages are not resolved.
+Perhaps the "link resolver" part should use Ikiwiki's htmllink instead
+of its simple subsitutions.
+
## Directives ##
Now **Directives**: As it is now, ikiwiki goes though (roughly):
--
cgit v1.2.3
From 92b3be2f3ef4123f2e5d9afb761cfd7251c2511d Mon Sep 17 00:00:00 2001
From: "http://kaizer.se/"
Date: Tue, 22 Sep 2009 17:17:11 -0400
Subject: rst-wikilinks uses 'htmllink'
---
.../Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index 4bde25bd2..1782af824 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -65,6 +65,11 @@ Implementation of Proposal-2 wikilinks are in the branch
[rst-wl]: http://github.com/engla/ikiwiki/commits/rst-wikilinks
+**rst-wikilinks** patch series includes changes at the end to use ikiwiki's
+'htmllink' for the links (which is the only sane thing to do to work in all configurations).
+This means a :wiki:`Link` should render just exactly like [[Link]] whether
+the target exists or not.
+
On top of **rst-wikilinks** is [rst-customize][rst-custom] which adds two
power user features: Global (python) file to read in custom directives
(unsafe), and a wikifile as "header" file for all parsed .rst files (safe,
@@ -76,10 +81,6 @@ Some rst-custom [examples are here](http://kaizer.se/wiki/rst_examples/)
[rst-custom]: http://github.com/engla/ikiwiki/commits/rst-customize
-**What is missing?** links to nonexistant pages are not resolved.
-Perhaps the "link resolver" part should use Ikiwiki's htmllink instead
-of its simple subsitutions.
-
## Directives ##
Now **Directives**: As it is now, ikiwiki goes though (roughly):
--
cgit v1.2.3
From 2aa93377e8845b4dd19af5a470e270c23e4e7e15 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Wed, 30 Sep 2009 13:57:36 -0400
Subject: comments and some code review
---
...ve_reStructuredText_links_to_ikiwiki_pages.mdwn | 33 ++++++++++++++++++++++
1 file changed, 33 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index 1782af824..5f21b2272 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -109,6 +109,25 @@ picture before it.
but rST directives allow a direct line (after :: on first line),
an option list, and a content block.
+> You've done a lot of work already, but ...
+>
+> The filter approach seems much simpler than the other approaches
+> for users to understand, since they can just use identical ikiwiki
+> markup on rst pages as they would use anywhere else. This is very desirable
+> if the wiki allows rst in addition to mdwn, since then users don't have
+> to learn two completly different ways of doing wikilinks and directives.
+> I also wonder if even those familiar with rst would find entirely natural
+> the ways you've found to shoehorn in wikilinks, named wikilinks, and ikiwiki
+> directives?
+>
+> Htmlize in filter avoids these problems. It also leaves open the possibility
+> that ikiwiki could become smarter about the rendering chain later, and learn
+> to use a better order for rst (ie, htmlize first). If that later happened,
+> the htmlize in filter hack could go away. --[[Joey]]
+
+> (BTW, the [[plugins/txt]] plugin already does html formatting
+> in filter, for similar reasons.) --[[Joey]]
+
### Implementation ###
Preserving indents in the preprocessor are in branch [pproc-indent][ppi]
@@ -116,6 +135,20 @@ Preserving indents in the preprocessor are in branch [pproc-indent][ppi]
(These simple patches come with a warning: _Those are the first lines of
Perl I've ever written!_)
+> This seems like a good idea, since it solves issues for eg, indented
+> directives in mdwn as well. But, looking at the diff, I see a clear bug:
+>
+> - return "[[!$command ".
+> + $result = "[[!$command ".
+>
+> That makes it go on and parse an infinitely nested directive chain, instead
+> of immediatly throwing an error.
+>
+> Also, it seems that the "indent" matching in the regexps may be too broad,
+> wouldn't it also match whitespace before a directive that was not at the beginning
+> of a line, and treat it as an indent? With some bad luck, that could cause mdwn
+> to put the indented output in a pre block. --[[Joey]]
+
[ppi]: http://github.com/engla/ikiwiki/commits/pproc-indent
## Discussion ##
--
cgit v1.2.3
From 4f37413050d4c17cb428820991541595e4645c66 Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup
Date: Wed, 30 Sep 2009 20:54:21 +0200
Subject: Comment, type, discuss and otherwise type wayy to much sorry!!
---
...ve_reStructuredText_links_to_ikiwiki_pages.mdwn | 71 ++++++++++++++++++++++
1 file changed, 71 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index 5f21b2272..4468ce1e9 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -128,6 +128,54 @@ picture before it.
> (BTW, the [[plugins/txt]] plugin already does html formatting
> in filter, for similar reasons.) --[[Joey]]
+>> Thank you for the comments! Forget the work, it's not so much.
+>> I'd rank the :wiki: link addition pretty high, and the other changes way
+>> behind that:
+>>
+>> The :wiki:`Wiki Link` syntax is *very* appropriate as rst syntax
+>> since it fits well with other uses of roles (notice that :RFC:`822`
+>> inserts a link to RFC822 etc, and that the default role is a *title* role
+>> (title of some work); thus very appropriate for medium-specific links like
+>> wiki links. So I'd rank :wiki: links a worthwhile addition regardless of
+>> outcome here, since it's a very rst-like alternative for those who wish to
+>> use more rst-like syntax (and documents degrades better outside the wiki as
+>> noted).
+>>
+>> The named link syntax (just like the :wiki: role) are inspired from trac
+>> and a good fit, but only if the wiki is committed to using only rst,
+>> which I don't think is the case.
+>>
+>> The rst-customize changes are very useful for custom directive
+>> installations (like the sourcecode directive, or shortcut roles I show
+>> in the examples page), but there might be a way for the user to inject
+>> docutils addons that I'm missing (one very ugly way would be to stick
+>> them in sitecustomize.py which affects all Python programs).
+>>
+>> With the presented changes, I already have a working RestructuredText
+>> wiki, but I'm admitting that using .. raw:: html around all directives is
+>> very ugly (I use few directives: inline, toggle, meta, tag, map)
+>>
+>> On filter/htmlize: Well **rst** is clearly antisocial: It can't see HTML,
+>> and ikiwiki directives are wrappend in paragraph tags. (For wikilinks
+>> this is probably no problem). So the suggestion about `.. ikiwiki:` is
+>> partly because it looks good in rst syntax, but also since it would emit
+>> a div to wrap around the element instead of a paragraph.
+>>
+>> I don't know if you mean that rst could be reordered to do htmlize before
+>> other phases? rst must be before any preprocess hook to avoid seeing any
+>> HTML.
+>>
+>> With the presented changes, I already have a working RestructuredText
+>> wiki, but I'm admitting that using .. raw:: html around all directives is
+>> very ugly (I use few directives: inline, toggle, meta, tag, map)
+>>
+>> If I'm thinking right, processing to HTML already in filter means any
+>> processing in scan can be reused directly (or skipped if it's legal to
+>> emit 'add_link' in filter.)
+>>
+>> -- [[ulrik]]
+
+
### Implementation ###
Preserving indents in the preprocessor are in branch [pproc-indent][ppi]
@@ -148,6 +196,29 @@ Perl I've ever written!_)
> wouldn't it also match whitespace before a directive that was not at the beginning
> of a line, and treat it as an indent? With some bad luck, that could cause mdwn
> to put the indented output in a pre block. --[[Joey]]
+>
+>> You are probably right about the bug. I'm not quite sure what the nested
+>> directives examples looks like, but I must have overlooked how the
+>> recursion counter works; I thought simply changing if to elif the next
+>> few lines would solve that. I'm sorry for that!
+>>
+>> We don't have to change the `$handle` function at all, if it is possible
+>> to do the indent substitution all in one line instead of passing it to
+>> handle, I don't know if it is possible to turn:
+>>
+>> $content =~ s{$regex}{$handle->($1, $2, $3, $4, $5)}eg;
+>>
+>> into
+>>
+>> $content =~ s{$regex}{s/^/$1/gm{$handle->($2, $3, $4, $5)}}eg;
+>>
+>> Well, no idea how that would be expressed, but I mean, replace the indent
+>> directly in $handle's return value.
+>>
+>> The indent-catching regex is wrong in the way you mention, it has been
+>> nagigng my mind a bit as well; I think matching start of line + spaces
+>> and tabs is the only thing we want.
+>> -- [[ulrik]]
[ppi]: http://github.com/engla/ikiwiki/commits/pproc-indent
--
cgit v1.2.3
From e04e9ccea930aefb3b1dbeb8203dce8c6f8bef13 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Wed, 30 Sep 2009 15:39:51 -0400
Subject: response
---
..._native_reStructuredText_links_to_ikiwiki_pages.mdwn | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index 4468ce1e9..0f8e63aae 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -77,6 +77,9 @@ but disruptive since all .rst depend on it). Well, the customizations have
to be picked and chosen from this, but at least the global python file can
be very convenient.
+> Did you consider just including the global rst header text into an item
+> in the setup file? --[[Joey]]
+
Some rst-custom [examples are here](http://kaizer.se/wiki/rst_examples/)
[rst-custom]: http://github.com/engla/ikiwiki/commits/rst-customize
@@ -141,6 +144,11 @@ picture before it.
>> use more rst-like syntax (and documents degrades better outside the wiki as
>> noted).
>>
+>>> Unsure about the degredation argument. It will work some of
+>>> the time, but ikiwiki's [[ikiwiki/subpage/linkingrules]]
+>>> are sufficiently different from normal html relative link
+>>> rules that it often won't work. --[[Joey]]
+>>
>> The named link syntax (just like the :wiki: role) are inspired from trac
>> and a good fit, but only if the wiki is committed to using only rst,
>> which I don't think is the case.
@@ -165,9 +173,11 @@ picture before it.
>> other phases? rst must be before any preprocess hook to avoid seeing any
>> HTML.
>>
->> With the presented changes, I already have a working RestructuredText
->> wiki, but I'm admitting that using .. raw:: html around all directives is
->> very ugly (I use few directives: inline, toggle, meta, tag, map)
+>>> One of my long term goals is to refactor all the code in ikiwiki
+>>> that manually runs the various stages of the render pipeline,
+>>> into one centralized place. Once that's done, that place can get
+>>> smart about what order to run the stages, and use a different
+>>> order for rst. --[[Joey]]
>>
>> If I'm thinking right, processing to HTML already in filter means any
>> processing in scan can be reused directly (or skipped if it's legal to
@@ -175,6 +185,7 @@ picture before it.
>>
>> -- [[ulrik]]
+>>> Seems it could be, yes. --[[Joey]]
### Implementation ###
--
cgit v1.2.3
From e7de3f0762d9b9ae64bd40d9fe07b00d9d6dc4d7 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Wed, 30 Sep 2009 15:45:16 -0400
Subject: furthermore
---
.../Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 6 ++++++
1 file changed, 6 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index 0f8e63aae..bee57f7e7 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -226,10 +226,16 @@ Perl I've ever written!_)
>> Well, no idea how that would be expressed, but I mean, replace the indent
>> directly in $handle's return value.
>>
+>> Yes, in effect just `indent($1, handle->($2,$,4))` --[[Joey]]
+>>
>> The indent-catching regex is wrong in the way you mention, it has been
>> nagigng my mind a bit as well; I think matching start of line + spaces
>> and tabs is the only thing we want.
>> -- [[ulrik]]
+>>
+>>> Well, seems you want to match the indent at the start of the line containing
+>>> the directive, even if the directive does not start the line. That would
+>>> be quite hard to make a regexp do, though. --[[Joey]]
[ppi]: http://github.com/engla/ikiwiki/commits/pproc-indent
--
cgit v1.2.3
From f8ad5988da8676bfeff6db9375f2518a12f79a48 Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup
Date: Wed, 30 Sep 2009 21:59:11 +0200
Subject: clarifications. and indent one of joey's oneliner responses.
---
...ative_reStructuredText_links_to_ikiwiki_pages.mdwn | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index bee57f7e7..084f03304 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -79,6 +79,14 @@ be very convenient.
> Did you consider just including the global rst header text into an item
> in the setup file? --[[Joey]]
+>
+>> Then `rst_header` would not be much different from the python script
+>> `rst_customize`. rst_header is as safe as other files (though disruptive
+>> as noted), so it should/could be a editable file in the Wiki. A Python
+>> script of course can not be. There is nothing you can do in the
+>> rst_header (that you sensibly would do, I think) that couldn't be done in
+>> the Python script. `rst_header` has very limited use, but it is another
+>> possibility, mainly for the user-editable aspect. --[[ulrik]]
Some rst-custom [examples are here](http://kaizer.se/wiki/rst_examples/)
@@ -148,6 +156,15 @@ picture before it.
>>> the time, but ikiwiki's [[ikiwiki/subpage/linkingrules]]
>>> are sufficiently different from normal html relative link
>>> rules that it often won't work. --[[Joey]]
+>>>
+>>>> With degradation I mean that if you take a file out of the wiki; the
+>>>> links degrade to stylized text. If using default role, they degrade to
+>>>> :title: which renders italicized text (which I find is exactly
+>>>> appropriate). There is no way for them to degrade into links, except of
+>>>> course if you reimplement the :wiki: role. You can also respecify
+>>>> either the default role (the `wikilink` syntax) or the :wiki: role (the
+>>>> :wiki:`wikilink` syntax) to any other markup, for example None.
+>>>> --[[ulrik]]
>>
>> The named link syntax (just like the :wiki: role) are inspired from trac
>> and a good fit, but only if the wiki is committed to using only rst,
@@ -226,7 +243,7 @@ Perl I've ever written!_)
>> Well, no idea how that would be expressed, but I mean, replace the indent
>> directly in $handle's return value.
>>
->> Yes, in effect just `indent($1, handle->($2,$,4))` --[[Joey]]
+>>> Yes, in effect just `indent($1, handle->($2,$,4))` --[[Joey]]
>>
>> The indent-catching regex is wrong in the way you mention, it has been
>> nagigng my mind a bit as well; I think matching start of line + spaces
--
cgit v1.2.3
From 9584dfddd89a0b65632201c6aa280b7c5bc964f2 Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup
Date: Thu, 1 Oct 2009 14:55:36 +0200
Subject: Link to trac's Wiki-RestructuredText syntax description
---
.../Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index 084f03304..afe50cf07 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -166,9 +166,9 @@ picture before it.
>>>> :wiki:`wikilink` syntax) to any other markup, for example None.
>>>> --[[ulrik]]
>>
->> The named link syntax (just like the :wiki: role) are inspired from trac
->> and a good fit, but only if the wiki is committed to using only rst,
->> which I don't think is the case.
+>> The named link syntax (just like the :wiki: role) are inspired from
+>> [trac][tracrst] and a good fit, but only if the wiki is committed to
+>> using only rst, which I don't think is the case.
>>
>> The rst-customize changes are very useful for custom directive
>> installations (like the sourcecode directive, or shortcut roles I show
@@ -204,6 +204,8 @@ picture before it.
>>> Seems it could be, yes. --[[Joey]]
+[tracrst]: http://trac.edgewall.org/wiki/WikiRestructuredText
+
### Implementation ###
Preserving indents in the preprocessor are in branch [pproc-indent][ppi]
--
cgit v1.2.3
From 009f7ffded7446f1b3954ab1973faed5b96acf4d Mon Sep 17 00:00:00 2001
From: Ulrik Sverdrup
Date: Fri, 2 Oct 2009 15:03:14 +0200
Subject: link to docutils mailing list discussion. also ask about
+
+Any idea when this is going to be finished? If you want, I am happy to beta test.
--
cgit v1.2.3
From 98c00730f6455cce03c2dc7486cdc75c150baa69 Mon Sep 17 00:00:00 2001
From: "http://weakish.pigro.net/"
Date: Thu, 24 Dec 2009 07:46:42 +0000
Subject: use `SomePage <>` for wikilink?
---
.../Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 9 +++++++++
1 file changed, 9 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index ca7b282fa..6219f1d14 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -322,3 +322,12 @@ The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to genera
>> However, I think that if the cache does not work for a big load, it should
>> not work at all; small loads are small so they don't matter. --ulrik
+-----
+
+Another possiblity is use empty url for wiki pages (gitit uses this approach), for example:
+
+ `SomePage <>`_
+
+Since it uses *empty* url, I would like to call it *proposal 0* :-) --[weakish]
+
+[weakish]: http://weakish.pigro.net
--
cgit v1.2.3
From 7e0d5aa1fd912cc933c613eab9d3d58d7d71f6d3 Mon Sep 17 00:00:00 2001
From: "http://weakish.pigro.net/"
Date: Thu, 24 Dec 2009 07:47:50 +0000
Subject: typo
---
doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
index 6219f1d14..6e0f32fd5 100644
--- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
+++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn
@@ -324,7 +324,7 @@ The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to genera
-----
-Another possiblity is use empty url for wiki pages (gitit uses this approach), for example:
+Another possiblity is using empty url for wikilinks (gitit uses this approach), for example:
`SomePage <>`_
--
cgit v1.2.3
From 6e632de82550e5d028391e74beb302b80bd9f7a6 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
Date: Fri, 25 Dec 2009 19:40:59 +0000
Subject: patch in diff -u format
---
...iling___40__opposite_of_levels__61____41__.mdwn | 47 +++++++++++++++-------
1 file changed, 33 insertions(+), 14 deletions(-)
(limited to 'doc/todo')
diff --git a/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn b/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn
index ce51d90a3..53cb0dd7c 100644
--- a/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn
+++ b/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn
@@ -10,19 +10,38 @@ Currently, the levels=X parameter lets you tweak how deep it will go for small h
> > projects prefer to receive changes as unified diffs (or as
> > branches in their chosen VCS, which is [[git]] here). --[[smcv]]
- 56,57c56,57
- < my $curlevel;
- < my $startlevel=0;
- ---
- > my $startlevel=($params{startlevel} ? $params{startlevel} : 0);
- > my $curlevel=$startlevel-1;
- 69a70
- > # unless we're given startlevel as a parameter
- 73a75,79
- > elsif (defined $params{startlevel}
- > and $level < $params{startlevel})
- > {
- > return;
- > }
+> > > Done. -- [[KathrynAndersen]]
+
+
+ --- /files/git/other/ikiwiki/IkiWiki/Plugin/toc.pm 2009-11-16 12:44:00.352050178 +1100
+ +++ toc.pm 2009-12-26 06:36:06.686512552 +1100
+ @@ -53,8 +53,8 @@
+ my $page="";
+ my $index="";
+ my %anchors;
+ - my $curlevel;
+ - my $startlevel=0;
+ + my $startlevel=($params{startlevel} ? $params{startlevel} : 0);
+ + my $curlevel=$startlevel-1;
+ my $liststarted=0;
+ my $indent=sub { "\t" x $curlevel };
+ $p->handler(start => sub {
+ @@ -67,10 +67,16 @@
+
+ # Take the first header level seen as the topmost level,
+ # even if there are higher levels seen later on.
+ + # unless we're given startlevel as a parameter
+ if (! $startlevel) {
+ $startlevel=$level;
+ $curlevel=$startlevel-1;
+ }
+ + elsif (defined $params{startlevel}
+ + and $level < $params{startlevel})
+ + {
+ + return;
+ + }
+ elsif ($level < $startlevel) {
+ $level=$startlevel;
+ }
[[!tag patch]]
--
cgit v1.2.3
From 8e0f45ae670985a0ffde8180776dd8ce5821c7d8 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Fri, 25 Dec 2009 15:12:05 -0500
Subject: add example
---
doc/todo/ACL.mdwn | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/ACL.mdwn b/doc/todo/ACL.mdwn
index 4c3062427..d40701d60 100644
--- a/doc/todo/ACL.mdwn
+++ b/doc/todo/ACL.mdwn
@@ -70,4 +70,9 @@ Here is how I see it:
\[[!acl user=* page=/subsite/* acl=/subsite/acl.mdwn]]
-Any idea when this is going to be finished? If you want, I am happy to beta test.
+Any idea when this is going to be finished? If you want, I am happy to beta test.
+
+> It's already done, though that is sorta hidden in the above. :-)
+> Example of use to only allow two users to edit the tipjar page:
+> locked_pages => 'tipjar and !(user(joey) or user(bob))',
+> --[[Joey]]
--
cgit v1.2.3
From 8a51384297c66dd1216088ceb5def61d09af021e Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/"
Date: Sun, 27 Dec 2009 12:40:11 +0000
Subject: note as merged
---
...lugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn | 1 +
1 file changed, 1 insertion(+)
(limited to 'doc/todo')
diff --git a/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn b/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn
index 53cb0dd7c..07d2d383c 100644
--- a/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn
+++ b/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn
@@ -12,6 +12,7 @@ Currently, the levels=X parameter lets you tweak how deep it will go for small h
> > > Done. -- [[KathrynAndersen]]
+> > > > Looks like Joey has now [[merged|done]] this. Thanks! --[[smcv]]
--- /files/git/other/ikiwiki/IkiWiki/Plugin/toc.pm 2009-11-16 12:44:00.352050178 +1100
+++ toc.pm 2009-12-26 06:36:06.686512552 +1100
--
cgit v1.2.3
From 87c84515e96ac991a67571b26d90a4f2ed58c757 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Mon, 28 Dec 2009 13:03:39 -0500
Subject: idea
---
doc/todo/conflict_free_comment_merges.mdwn | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 doc/todo/conflict_free_comment_merges.mdwn
(limited to 'doc/todo')
diff --git a/doc/todo/conflict_free_comment_merges.mdwn b/doc/todo/conflict_free_comment_merges.mdwn
new file mode 100644
index 000000000..e0e8acb34
--- /dev/null
+++ b/doc/todo/conflict_free_comment_merges.mdwn
@@ -0,0 +1,14 @@
+Currently, new comments are named with an incrementing ID (comment_N). So
+if a wiki has multiple disconnected servers, and comments are made to the
+same page on both, merging is guaranteed to result in conflicts.
+
+I propose avoiding such merge problems by naming a comment with a sha1sum
+of its (full) content. Keep the incrementing ID too, so there is an
+-ordering. And so duplicate comments are allowed..)
+So, "comment_N_SHA1".
+
+Note: The comment body will need to use meta title in the case where no
+title is specified, to retain the current behavior of the default title
+being "comment N".
+
+What do you think [[smcv]]? --[[Joey]]
--
cgit v1.2.3
From 2143cfcc3d0dc03fe3a67a5cab612fac041c2c9f Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Mon, 28 Dec 2009 13:14:54 -0500
Subject: thoughts
---
doc/todo/tagging_with_a_publication_date.mdwn | 31 +++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/tagging_with_a_publication_date.mdwn b/doc/todo/tagging_with_a_publication_date.mdwn
index 80240ec5a..39fc4e220 100644
--- a/doc/todo/tagging_with_a_publication_date.mdwn
+++ b/doc/todo/tagging_with_a_publication_date.mdwn
@@ -38,3 +38,34 @@ on vacation".
> >
> > I no longer have the original wiki for which I wanted this feature, but I can
> > see using it on future ones. -- [[DonMarti]]
+
+>>> FWIW, for the case where one wants to update a site offline,
+>>> using an ikiwiki instance on a laptop, and include some deffered
+>>> posts in the push, the ad-hoc cron job type approach will be annoying.
+>>>
+>>> In modern ikiwiki, I guess the way to accomplish this would be to
+>>> add a pagespec that matches only pages posted in the present or past.
+>>> Then a page can have its post date set to the future, using meta date,
+>>> and only show up when its post date rolls around.
+>>>
+>>> Ikiwiki will need to somehow notice that a pagespec began matching
+>>> a page it did not match previously, despite said page not actually
+>>> changing. I'm not sure what the best way is.
+>>>
+>>> * One way could be to
+>>> use a needsbuild hook and some stored data about which pagespecs
+>>> exclude pages in the future. (But I'm not sure how evaluating the
+>>> pagespec could lead to that metadata and hook being set up.)
+>>> * Another way would be to use an explicit directive to delay a
+>>> page being posted. Then the directive stores the metadata and
+>>> sets up the needsbuild hook.
+>>> * Another way would be for ikiwiki to remember the last
+>>> time it ran. It could then easily find pages that have a post
+>>> date after that time, and treat them the same as it treats actually
+>>> modified files. Or a plugin could do this via a needsbuild hook,
+>>> probably. (Only downside to this is it would probably need to do
+>>> a O(n) walk of the list of pages -- but only running an integer
+>>> compare per page.)
+>>>
+>>> You'd still need a cron job to run ikiwiki -refresh every hour, or
+>>> whatever, so it can update. --[[Joey]]
--
cgit v1.2.3
From 6af6c89df314cf2f9c9e053c04aa2bd492072ab1 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Wed, 30 Dec 2009 15:41:17 -0500
Subject: comments: Add a checksum to the name of comment pages, to avoid merge
conflicts when comments are posted to two branches of a site.
---
IkiWiki/Plugin/comments.pm | 32 ++++++++++++++++++++++--------
debian/changelog | 3 +++
doc/todo/conflict_free_comment_merges.mdwn | 9 +++++++++
3 files changed, 36 insertions(+), 8 deletions(-)
(limited to 'doc/todo')
diff --git a/IkiWiki/Plugin/comments.pm b/IkiWiki/Plugin/comments.pm
index 517e16f9f..6340fc2cb 100644
--- a/IkiWiki/Plugin/comments.pm
+++ b/IkiWiki/Plugin/comments.pm
@@ -377,8 +377,6 @@ sub editcomment ($$) {
IkiWiki::check_canedit($page, $cgi, $session);
$postcomment=0;
- my $location=unique_comment_location($page, $config{srcdir});
-
my $content = "[[!comment format=$type\n";
# FIXME: handling of double quotes probably wrong?
@@ -410,8 +408,11 @@ sub editcomment ($$) {
my $subject = $form->field('subject');
if (defined $subject && length $subject) {
$subject =~ s/"/"/g;
- $content .= " subject=\"$subject\"\n";
}
+ else {
+ $subject = "comment ".(num_comments($page, $config{srcdir}) + 1);
+ }
+ $content .= " subject=\"$subject\"\n";
$content .= " date=\"" . decode_utf8(strftime('%Y-%m-%dT%H:%M:%SZ', gmtime)) . "\"\n";
@@ -421,6 +422,8 @@ sub editcomment ($$) {
$editcontent =~ s/"/\\"/g;
$content .= " content=\"\"\"\n$editcontent\n\"\"\"]]\n";
+ my $location=unique_comment_location($page, $content, $config{srcdir});
+
# This is essentially a simplified version of editpage:
# - the user does not control the page that's created, only the parent
# - it's always a create operation, never an edit
@@ -458,7 +461,7 @@ sub editcomment ($$) {
if (! $ok) {
my $penddir=$config{wikistatedir}."/comments_pending";
- $location=unique_comment_location($page, $penddir);
+ $location=unique_comment_location($page, $content, $penddir);
writefile("$location._comment", $penddir, $content);
IkiWiki::printheader($session);
print IkiWiki::misctemplate(gettext(gettext("comment stored for moderation")),
@@ -554,7 +557,7 @@ sub commentmoderation ($$) {
if ($action eq 'Accept') {
my $content=eval { readfile($file) };
next if $@; # file vanished since form was displayed
- my $dest=unique_comment_location($page, $config{srcdir})."._comment";
+ my $dest=unique_comment_location($page, $content, $config{srcdir})."._comment";
writefile($dest, $config{srcdir}, $content);
if ($config{rcs} and $config{comments_commit}) {
IkiWiki::rcs_add($dest);
@@ -813,15 +816,28 @@ sub pagetemplate (@) {
}
}
-sub unique_comment_location ($) {
+sub num_comments ($$) {
my $page=shift;
my $dir=shift;
+ my @comments=glob("$dir/$page/$config{comments_pagename}*._comment");
+ return @comments;
+}
+
+sub unique_comment_location ($$$) {
+ my $page=shift;
+
+ eval q{use Digest::MD5 'md5_hex'};
+ error($@) if $@;
+ my $content_md5=md5_hex(shift);
+
+ my $dir=shift;
+
my $location;
- my $i = 0;
+ my $i = num_comments($page, $dir);
do {
$i++;
- $location = "$page/$config{comments_pagename}$i";
+ $location = "$page/$config{comments_pagename}${i}_${content_md5}";
} while (-e "$dir/$location._comment");
return $location;
diff --git a/debian/changelog b/debian/changelog
index ee6f9adfb..984351415 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -8,6 +8,9 @@ ikiwiki (3.20091219) UNRELEASED; urgency=low
can be generated at any time using ikiwiki --dumpsetup so I do
not see a reason to ship it. Closes: #562183
* Use env hack in python scripts.
+ * comments: Add a checksum to the name of comment pages, to
+ avoid merge conflicts when comments are posted to two branches of a
+ site.
-- Joey Hess Fri, 25 Dec 2009 14:31:22 -0500
diff --git a/doc/todo/conflict_free_comment_merges.mdwn b/doc/todo/conflict_free_comment_merges.mdwn
index e0e8acb34..2cef0ee8c 100644
--- a/doc/todo/conflict_free_comment_merges.mdwn
+++ b/doc/todo/conflict_free_comment_merges.mdwn
@@ -12,3 +12,12 @@ title is specified, to retain the current behavior of the default title
being "comment N".
What do you think [[smcv]]? --[[Joey]]
+
+> I had to use md5sums, as sha1sum perl module may not be available and I
+> didn't want to drag it in. But I think that's ok; this doesn't need to be
+> cryptographically secure and even the chances of being able to
+> purposefully cause a md5 collision and thus an undesired merge conflict
+> are quite low since it modifies the input text and adds a date stamp to
+> it.
+>
+> Anyway, I think it's good, [[[done]] --[[Joey]]
--
cgit v1.2.3
From 387e1cc141e474513dcc4429381ffdb147c59e38 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Sat, 2 Jan 2010 16:49:42 -0500
Subject: html5 note
---
doc/todo/Add_label_to_search_form_input_field.mdwn | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/Add_label_to_search_form_input_field.mdwn b/doc/todo/Add_label_to_search_form_input_field.mdwn
index e4e83428c..51b34927d 100644
--- a/doc/todo/Add_label_to_search_form_input_field.mdwn
+++ b/doc/todo/Add_label_to_search_form_input_field.mdwn
@@ -47,4 +47,8 @@ The patch below adds a label for the field to improve usability:
> to get it to appear higher up is to put it first, or to use Evil absolute
> positioning. (CSS sucks.) --[[Joey]]
-[[!tag done wishlist]]
+> Update: html5 allows just adding `placeholder="Search"` to the input
+> element. already works in eg, chromium. However, ikiwiki does not use
+> html5 yet. --[[Joey]]
+
+[[!tag wishlist html5]]
--
cgit v1.2.3
From 436e29731026194e961ed0f11e85517308a400d9 Mon Sep 17 00:00:00 2001
From: Jon Dowland
Date: Thu, 7 Jan 2010 09:40:10 +0000
Subject: seasons greatings, polite nudge
---
doc/todo/allow_site-wide_meta_definitions.mdwn | 5 +++++
1 file changed, 5 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn
index 62317ba1a..99a9cf1e2 100644
--- a/doc/todo/allow_site-wide_meta_definitions.mdwn
+++ b/doc/todo/allow_site-wide_meta_definitions.mdwn
@@ -178,3 +178,8 @@ definitions essentially.
* title
-- [[Jon]]
+
+>>> Merry Christmas/festive season/happy new year folks. I've been away from
+>>> ikiwiki for the break, and now I've returned to watching recentchanges.
+>>> Hopefully I'll be back in the mix soon, too. In the meantime, Joey, have
+>>> you had a chance to look at this yet? -- [[Jon]]
--
cgit v1.2.3
From 6257a714077712e818127ed0c68d9a9611d7628f Mon Sep 17 00:00:00 2001
From: intrigeri
Date: Thu, 7 Jan 2010 23:22:48 +0100
Subject: selflink detection is suboptimal when using the po plugin
---
doc/todo/Fix_selflink_in_po_plugin.mdwn | 4 ++++
1 file changed, 4 insertions(+)
create mode 100644 doc/todo/Fix_selflink_in_po_plugin.mdwn
(limited to 'doc/todo')
diff --git a/doc/todo/Fix_selflink_in_po_plugin.mdwn b/doc/todo/Fix_selflink_in_po_plugin.mdwn
new file mode 100644
index 000000000..ae59e14c2
--- /dev/null
+++ b/doc/todo/Fix_selflink_in_po_plugin.mdwn
@@ -0,0 +1,4 @@
+Using the po plugin, a link to /bla is present in the sidebar.
+When viewing /bla in the default language, this link is detected as
+a selflink. When viewing a translation of /bla, it
+isn't. --[[intrigeri]]
--
cgit v1.2.3
From cf7d03ec80e168ad18d65a90842773da353ee060 Mon Sep 17 00:00:00 2001
From: intrigeri
Date: Sat, 9 Jan 2010 22:57:11 +0100
Subject: fixed bug in my po branch, please pull
---
doc/todo/Fix_selflink_in_po_plugin.mdwn | 2 ++
1 file changed, 2 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/Fix_selflink_in_po_plugin.mdwn b/doc/todo/Fix_selflink_in_po_plugin.mdwn
index ae59e14c2..55968e3d7 100644
--- a/doc/todo/Fix_selflink_in_po_plugin.mdwn
+++ b/doc/todo/Fix_selflink_in_po_plugin.mdwn
@@ -2,3 +2,5 @@ Using the po plugin, a link to /bla is present in the sidebar.
When viewing /bla in the default language, this link is detected as
a selflink. When viewing a translation of /bla, it
isn't. --[[intrigeri]]
+
+Fixed in my po branch => [[!tag patch]]. --[[intrigeri]]
--
cgit v1.2.3
From 62a67e161bccba431b8b8a501967ba7acf6e197a Mon Sep 17 00:00:00 2001
From: intrigeri
Date: Sat, 9 Jan 2010 22:59:46 +0100
Subject: wiki syntax fix
---
doc/todo/Fix_selflink_in_po_plugin.mdwn | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/Fix_selflink_in_po_plugin.mdwn b/doc/todo/Fix_selflink_in_po_plugin.mdwn
index 55968e3d7..87fa38911 100644
--- a/doc/todo/Fix_selflink_in_po_plugin.mdwn
+++ b/doc/todo/Fix_selflink_in_po_plugin.mdwn
@@ -3,4 +3,6 @@ When viewing /bla in the default language, this link is detected as
a selflink. When viewing a translation of /bla, it
isn't. --[[intrigeri]]
-Fixed in my po branch => [[!tag patch]]. --[[intrigeri]]
+Fixed in my po branch. --[[intrigeri]]
+
+[[!tag patch]]
--
cgit v1.2.3
From 1ddef7da7b170bb4bd7c816cba03e3e6338a50b2 Mon Sep 17 00:00:00 2001
From: "http://edrex.myopenid.com/"
Date: Sun, 17 Jan 2010 07:22:03 +0000
Subject:
---
doc/todo/svg.mdwn | 1 +
1 file changed, 1 insertion(+)
(limited to 'doc/todo')
diff --git a/doc/todo/svg.mdwn b/doc/todo/svg.mdwn
index 0a15af4cd..f264f4107 100644
--- a/doc/todo/svg.mdwn
+++ b/doc/todo/svg.mdwn
@@ -3,6 +3,7 @@ We should support SVG. In particular:
* We could support rendering SVGs to PNGs when compiling the wiki. Not all browsers support SVG yet.
* We could support editing SVGs via the web interface. SVG can contain unsafe content such as scripting, so we would need to whitelist safe markup.
+ * I am interested in seeing [svg-edit](http://code.google.com/p/svg-edit/) integrated --[EricDrechsel]]
--[[JoshTriplett]]
--
cgit v1.2.3
From 5588abc2befbde83e43cf79f9717e323aa69da11 Mon Sep 17 00:00:00 2001
From: "http://edrex.myopenid.com/"
Date: Sun, 17 Jan 2010 07:22:54 +0000
Subject:
---
doc/todo/svg.mdwn | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/svg.mdwn b/doc/todo/svg.mdwn
index f264f4107..89b183db6 100644
--- a/doc/todo/svg.mdwn
+++ b/doc/todo/svg.mdwn
@@ -3,7 +3,7 @@ We should support SVG. In particular:
* We could support rendering SVGs to PNGs when compiling the wiki. Not all browsers support SVG yet.
* We could support editing SVGs via the web interface. SVG can contain unsafe content such as scripting, so we would need to whitelist safe markup.
- * I am interested in seeing [svg-edit](http://code.google.com/p/svg-edit/) integrated --[EricDrechsel]]
+ * I am interested in seeing [svg-edit](http://code.google.com/p/svg-edit/) integrated -- [[EricDrechsel]]
--[[JoshTriplett]]
--
cgit v1.2.3
From deb0bc8bd57bc74709ecb12de36a9cb96c684a93 Mon Sep 17 00:00:00 2001
From: Josh Triplett
Date: Tue, 2 Feb 2010 02:56:06 -0800
Subject: New todo item for wrapperuser configuration option
---
doc/todo/wrapperuser.mdwn | 7 +++++++
1 file changed, 7 insertions(+)
create mode 100644 doc/todo/wrapperuser.mdwn
(limited to 'doc/todo')
diff --git a/doc/todo/wrapperuser.mdwn b/doc/todo/wrapperuser.mdwn
new file mode 100644
index 000000000..4c42b046f
--- /dev/null
+++ b/doc/todo/wrapperuser.mdwn
@@ -0,0 +1,7 @@
+ikiwiki's .setup file can specify wrappergroup, and ikiwiki will set the group
+of the wrappers accordingly. Having had people encounter difficulty before
+when trying to do the same thing with users (for instance, making all wrappers
+6755 ikiwiki:ikiwiki), I think it would help to have "wrapperuser". This could
+only actually take effect if building the wrappers as root (not really the best
+plan), but ikiwiki could at least warn if wrapperuser does not match the user
+the wrapper will end up with.
--
cgit v1.2.3
From 05b99e3cfa8c9044d18d5b07aec24fff555f2889 Mon Sep 17 00:00:00 2001
From: David Riebenbauer
Date: Tue, 2 Feb 2010 13:54:51 +0100
Subject: Document git branch for automatically creating tag pages.
---
...o-create_tag_pages_according_to_a_template.mdwn | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index f1d33114f..95710ced0 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -123,3 +123,40 @@ On the second extra pass, it doesn't notice that it has to update the "?"-link.
}
is not satisfied for the newly created tag page. I shall put debug msgs into Render.pm to find out better how it works. --Ivan Z.
+
+---
+
+I've made another attempt at fixiing this
+
+The current progress can be found at my [git repository][gitweb] on branch
+`autotag`:
+
+ git://git.liegesta.at/git/ikiwiki
+
+[gitweb]: http://git.liegesta.at/?p=ikiwiki.git;a=shortlog;h=refs/heads/autotag (gitweb for branch autotag)
+
+It's not entirely finished yet, but already quite usable. Testing and comments
+on code quality, implementation details, as well as other patches would be
+appreciated.
+
+Here's what it does right now:
+
+* enabled by setting `tag_autocreate=1` in the configuration.
+* Tag pages will be created in `tagbase` from the template `autotag.tmpl`.
+* Will correctly render all links, and dependencies. Well, AFAIK.
+* When a tag page is deleted it will automatically recreated from template. (I
+consider this a feature, not a bug)
+* Requires a rebuild on first use.
+* Adds a function `add_autofile()` to the plugin API, to do all this.
+
+Todo/Bugs:
+
+* Will still create a page even if there's a page other than `$tag` under
+`tagbase` satisfying the tag link.
+* Call from `IkiWiki.pm` to `Render.pm`, which adds a module dependency in the
+wrong direction.
+* Add files to RCS.
+* Unit tests.
+* Proper documentation.
+
+--[[David_Riebenbauer]]
--
cgit v1.2.3
From 1febfda911d29a52b4c4aa1bb286f4c9e1862c5c Mon Sep 17 00:00:00 2001
From: David Riebenbauer
Date: Tue, 2 Feb 2010 14:50:01 +0100
Subject: also tag 'patch/core', considering that over half of the changes are
there
---
doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 95710ced0..8c586d706 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -4,7 +4,7 @@ Tags are mainly specific to the object to which they’re stuck. However, I ofte
Also see: and
-[[!tag wishlist plugins/tag patch]]
+[[!tag wishlist plugins/tag patch patch/core]]
I would love to see this as well. -- dato
--
cgit v1.2.3
From 6b98269aa310abc121875753ded37042f3a95988 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Tue, 2 Feb 2010 13:31:07 -0500
Subject: partial review
---
...o-create_tag_pages_according_to_a_template.mdwn | 32 ++++++++++++++++++++++
1 file changed, 32 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 8c586d706..a0e76fd48 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -160,3 +160,35 @@ wrong direction.
* Proper documentation.
--[[David_Riebenbauer]]
+
+> Starting review of this. Some of your commits are to very delicate,
+> optimised, and security-sensitive ground, so I have to look at them very
+> carefully. --[[Joey]]
+>
+> * In the refactoring in f3abeac919c4736429bd3362af6edf51ede8e7fe,
+> you introduced at least 2 bugs, one a possible security hole.
+> Now one part of the code tests `if ($file)` and the other
+> caller tests `if ($f)`. These two tests both tested `if (! defined $f)`
+> before. Notice that the variable needs to be the untainted variable
+> for both. Also notice that `if ($f)` fails if `$f` contains `0`,
+> which is a very common perl gotcha.
+> * Your refactored code changes `-l $_ || -d _` to `-l $file || -d $file`.
+> The latter makes one more stat system call; note the use of a
+> bare `_` in the first to make perl reuse the stat buffer.
+> * (As a matter of style, could you put a space after the commas in your
+> perl?)
+>
+> I'd like to cherry-pick the above commit, once it's in shape, before
+> looking at the rest in detail. So just a few other things that stood out.
+>
+> * Commit 4af4d26582f0c2b915d7102fb4a604b176385748 seems unnecessary.
+> `srcfile($file, 1)` already is documented to return undef if the
+> file does not exist. (But without the second parameter, it throws
+> an error.)
+>
+> * Commit f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 adds a line
+> that is intented by a space, not a tab.
+>
+> * Commit f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 says that auto-added
+> files will be recreated if the user deletes them. That seems bad.
+> `autoindex` goes to some trouble to not recreate deleted files.
--
cgit v1.2.3
From fb6e73b3698089f47ae63d1569225938699d84e1 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Mon, 8 Feb 2010 13:46:49 -0500
Subject: move to correct location
---
doc/todo/http_bl_support.mdwn | 61 +++++++++++++++++++++++++++++++++++++++
doc/wishlist/http_bl_support.mdwn | 61 ---------------------------------------
2 files changed, 61 insertions(+), 61 deletions(-)
create mode 100644 doc/todo/http_bl_support.mdwn
delete mode 100644 doc/wishlist/http_bl_support.mdwn
(limited to 'doc/todo')
diff --git a/doc/todo/http_bl_support.mdwn b/doc/todo/http_bl_support.mdwn
new file mode 100644
index 000000000..024c770d8
--- /dev/null
+++ b/doc/todo/http_bl_support.mdwn
@@ -0,0 +1,61 @@
+[Project Honeypot](http://projecthoneypot.org/) has an HTTP:BL API available to subscribed (it's free, accept donations) people/orgs. There's a basic perl package someone wrote, I'm including a copy here.
+
+[from here](http://projecthoneypot.org/board/read.php?f=10&i=112&t=112)
+
+
+package Honeypot;
+
+use Socket qw/inet_ntoa/;
+
+my $dns = 'dnsbl.httpbl.org';
+my %types = (
+0 => 'Search Engine',
+1 => 'Suspicious',
+2 => 'Harvester',
+4 => 'Comment Spammer'
+);
+sub query {
+my $key = shift || die 'You need a key for this, you get one at http://www.projecthoneypot.org';
+my $ip = shift || do {
+warn 'no IP for request in Honeypot::query().';
+return;
+};
+
+my @parts = reverse split /\./, $ip;
+my $lookup_name = join'.', $key, @parts, $dns;
+
+my $answer = gethostbyname ($lookup_name);
+return unless $answer;
+$answer = inet_ntoa($answer);
+my(undef, $days, $threat, $type) = split /\./, $answer;
+my @types;
+while(my($bit, $typename) = each %types) {
+push @types, $typename if $bit & $type;
+}
+return {
+days => $days,
+threat => $threat,
+type => join ',', @types
+};
+
+}
+1;
+
+
+From the page:
+
+> The usage is simple:
+
+> use Honeypot;
+> my $key = 'XXXXXXX'; # your key
+> my $ip = '....'; the IP you want to check
+> my $q = Honeypot::query($key, $ip);
+
+> use Data::Dumper;
+> print Dumper $q;
+
+Any chance of having this as a plugin?
+
+I could give it a go, too. Would be fun to try my hand at Perl. --[[simonraven]]
+
+[[!tag wishlist]]
diff --git a/doc/wishlist/http_bl_support.mdwn b/doc/wishlist/http_bl_support.mdwn
deleted file mode 100644
index 024c770d8..000000000
--- a/doc/wishlist/http_bl_support.mdwn
+++ /dev/null
@@ -1,61 +0,0 @@
-[Project Honeypot](http://projecthoneypot.org/) has an HTTP:BL API available to subscribed (it's free, accept donations) people/orgs. There's a basic perl package someone wrote, I'm including a copy here.
-
-[from here](http://projecthoneypot.org/board/read.php?f=10&i=112&t=112)
-
-
-package Honeypot;
-
-use Socket qw/inet_ntoa/;
-
-my $dns = 'dnsbl.httpbl.org';
-my %types = (
-0 => 'Search Engine',
-1 => 'Suspicious',
-2 => 'Harvester',
-4 => 'Comment Spammer'
-);
-sub query {
-my $key = shift || die 'You need a key for this, you get one at http://www.projecthoneypot.org';
-my $ip = shift || do {
-warn 'no IP for request in Honeypot::query().';
-return;
-};
-
-my @parts = reverse split /\./, $ip;
-my $lookup_name = join'.', $key, @parts, $dns;
-
-my $answer = gethostbyname ($lookup_name);
-return unless $answer;
-$answer = inet_ntoa($answer);
-my(undef, $days, $threat, $type) = split /\./, $answer;
-my @types;
-while(my($bit, $typename) = each %types) {
-push @types, $typename if $bit & $type;
-}
-return {
-days => $days,
-threat => $threat,
-type => join ',', @types
-};
-
-}
-1;
-
-
-From the page:
-
-> The usage is simple:
-
-> use Honeypot;
-> my $key = 'XXXXXXX'; # your key
-> my $ip = '....'; the IP you want to check
-> my $q = Honeypot::query($key, $ip);
-
-> use Data::Dumper;
-> print Dumper $q;
-
-Any chance of having this as a plugin?
-
-I could give it a go, too. Would be fun to try my hand at Perl. --[[simonraven]]
-
-[[!tag wishlist]]
--
cgit v1.2.3
From 4ce14aa621be4c6b8551555395b80b68fbcc1ffe Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Mon, 8 Feb 2010 13:49:34 -0500
Subject: nte blogspam
---
doc/todo/http_bl_support.mdwn | 6 ++++++
1 file changed, 6 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/http_bl_support.mdwn b/doc/todo/http_bl_support.mdwn
index 024c770d8..f7a46ee6c 100644
--- a/doc/todo/http_bl_support.mdwn
+++ b/doc/todo/http_bl_support.mdwn
@@ -2,6 +2,12 @@
[from here](http://projecthoneypot.org/board/read.php?f=10&i=112&t=112)
+> The [[plugins/blogspam]] service already checks urls against
+> the surbl, and has its own IP blacklist. The best way to
+> support the HTTP:BL may be to add a plugin
+> [there](http://blogspam.repository.steve.org.uk/file/cc858e497cae/server/plugins/).
+> --[[Joey]]
+
package Honeypot;
--
cgit v1.2.3
From 172dfa9f64b5a248042af7c4b741fdd4c71813ec Mon Sep 17 00:00:00 2001
From: "http://seeitcoming.myopenid.com/"
Date: Sat, 13 Feb 2010 15:16:09 +0000
Subject: Added information about python implementation for reference
---
doc/todo/abbreviation.mdwn | 2 ++
1 file changed, 2 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/abbreviation.mdwn b/doc/todo/abbreviation.mdwn
index d24166710..f2880091c 100644
--- a/doc/todo/abbreviation.mdwn
+++ b/doc/todo/abbreviation.mdwn
@@ -2,4 +2,6 @@ We might want some kind of abbreviation and acronym plugin. --[[JoshTriplett]]
* Not sure if this is what you mean, but I'd love a way to make works which match existing page names automatically like (eg. if there is a page called "MySQL" then any time the word MySQL is mentioned it should become a link to that page). -- [[AdamShand]]
+ * The python-markdown-extras package has support for [abbreviations](http://www.freewisdom.org/projects/python-markdown/Abbreviations), with the syntax that you just use the abbreviation in text (e.g. HTML) and then define the abbreviations at the end (like "footnote-style" links). For consistency, it might be good to use the same syntax, which apparently derives from [PHP-markdown-extra](http://michelf.com/projects/php-markdown/extra/#abbr).
+
[[wishlist]]
--
cgit v1.2.3
From a38418a8a3652bad60c83a0dd7502f7afb991512 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Sat, 13 Feb 2010 14:07:56 -0500
Subject: close
---
doc/todo/openid_user_filtering.mdwn | 4 ++++
1 file changed, 4 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/openid_user_filtering.mdwn b/doc/todo/openid_user_filtering.mdwn
index 8b2d0082e..7f8b2a55e 100644
--- a/doc/todo/openid_user_filtering.mdwn
+++ b/doc/todo/openid_user_filtering.mdwn
@@ -7,3 +7,7 @@ So I suggest an ikiwiki configuration like:
users => ["*.webvm.net"],
Would only allow edits from openIDs of that form.
+
+> This kind of thing can be [[done]] now: --[[Joey]]
+>
+> locked_pages => "user(http://*.webvm.net/)"
--
cgit v1.2.3
From 6fc25c8df79c4ce9afde256be5d377ee82562c31 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Sat, 13 Feb 2010 14:13:30 -0500
Subject: clarify
---
doc/todo/openid_user_filtering.mdwn | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/openid_user_filtering.mdwn b/doc/todo/openid_user_filtering.mdwn
index 7f8b2a55e..6a318c4c0 100644
--- a/doc/todo/openid_user_filtering.mdwn
+++ b/doc/todo/openid_user_filtering.mdwn
@@ -10,4 +10,4 @@ Would only allow edits from openIDs of that form.
> This kind of thing can be [[done]] now: --[[Joey]]
>
-> locked_pages => "user(http://*.webvm.net/)"
+> locked_pages => "* and !user(http://*.webvm.net/)"
--
cgit v1.2.3
From ce8bb219586332032110da8835fde8dd5f0ed91f Mon Sep 17 00:00:00 2001
From: nil
Date: Tue, 16 Feb 2010 18:42:11 +0000
Subject: whishlist
---
doc/todo/cdate_and_mdate_available_for_templates.mdwn | 15 +++++++++++++++
1 file changed, 15 insertions(+)
create mode 100644 doc/todo/cdate_and_mdate_available_for_templates.mdwn
(limited to 'doc/todo')
diff --git a/doc/todo/cdate_and_mdate_available_for_templates.mdwn b/doc/todo/cdate_and_mdate_available_for_templates.mdwn
new file mode 100644
index 000000000..29c36b9f7
--- /dev/null
+++ b/doc/todo/cdate_and_mdate_available_for_templates.mdwn
@@ -0,0 +1,15 @@
+[[!tag whishlist]]
+
+`CDATE_3339`, `CDATE_822`, `MDATE_3339` and `MDATE_822` template variables would be useful for evey page, at least for my templates with Dublin Core metadata.
+
+I tried to pick the relevant lines of the [[inline|plugins/inline]] plugin and hack it into a custom plugin, but it failed miserably because of my obvious lack of perl litteracy...
+
+Anyway, I'm sure this is almost nothing...
+
+* `sub date_822 ($) {}`
+* `sub date_3339 ($) {}`
+* and something like `$template->param('cdate_822' => date_822($IkiWiki::pagectime{$page}));`
+
+Anyone can fill the missing lines?
+
+-- [[nil]]
--
cgit v1.2.3
From d4bc6e25e43f0cb2f12d7e9d954cbfc227c1686d Mon Sep 17 00:00:00 2001
From: nil
Date: Tue, 16 Feb 2010 18:43:10 +0000
Subject: typo
---
doc/todo/cdate_and_mdate_available_for_templates.mdwn | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/cdate_and_mdate_available_for_templates.mdwn b/doc/todo/cdate_and_mdate_available_for_templates.mdwn
index 29c36b9f7..70d8fc8c9 100644
--- a/doc/todo/cdate_and_mdate_available_for_templates.mdwn
+++ b/doc/todo/cdate_and_mdate_available_for_templates.mdwn
@@ -1,4 +1,4 @@
-[[!tag whishlist]]
+[[!tag wishlist]]
`CDATE_3339`, `CDATE_822`, `MDATE_3339` and `MDATE_822` template variables would be useful for evey page, at least for my templates with Dublin Core metadata.
--
cgit v1.2.3
From 34d6403a4b12c9578e7b0ea3fb765e1c5e72520f Mon Sep 17 00:00:00 2001
From: "http://jmtd.livejournal.com/"
Date: Wed, 17 Feb 2010 11:54:26 +0000
Subject: new feature request: identifying trivial edits
---
...trivial__44___identify__47__filter_on_trivial_changes.mdwn | 11 +++++++++++
1 file changed, 11 insertions(+)
create mode 100644 doc/todo/mark_edit_as_trivial__44___identify__47__filter_on_trivial_changes.mdwn
(limited to 'doc/todo')
diff --git a/doc/todo/mark_edit_as_trivial__44___identify__47__filter_on_trivial_changes.mdwn b/doc/todo/mark_edit_as_trivial__44___identify__47__filter_on_trivial_changes.mdwn
new file mode 100644
index 000000000..2b2b0242e
--- /dev/null
+++ b/doc/todo/mark_edit_as_trivial__44___identify__47__filter_on_trivial_changes.mdwn
@@ -0,0 +1,11 @@
+One feature of mediawiki which I quite like is the ability to mark a change as 'minor', or 'trivial'. This can then be used to filter the 'recentchanges' page, to only show substantial edits.
+
+The utility of this depends entirely on whether the editors use it properly.
+
+I currently use an inline on the front page of my personal homepage to show the most recent pages (by creation date) within a subsection of my site (a blog). Blog posts are rarely modified much after they are 'created' (or published - I bodge the creation time via meta when I publish a post. It might sit in draft form indefinitely), so this effectively shows only non-trivial changes.
+
+I would like to have a short list of the most recent modifications to the site on the front page. I therefore want to sort by modified time rather than creation time, but exclude edits that I self-identify as minor. I also only want to take a short number of items, the top 5, and display only their titles (which may be derived from filename, or set via meta again).
+
+I'm still thinking through how this might be achieved in an ikiwiki-suitable fashion, but I think I need a scheme to identify certain edits as trivial. This would have to work via web edits (easier: could add a check box to the edit form) and plain changes in the VCS (harder: scan for keywords in a commit message? in a VCS-agnostic fashion?)
+
+[[!tag wishlist]]
--
cgit v1.2.3
From d1137697a80ca5e90bfc9d1c1f00b455871b99c5 Mon Sep 17 00:00:00 2001
From: "http://jmtd.livejournal.com/"
Date: Fri, 19 Feb 2010 14:00:52 +0000
Subject: fix 'done' link
---
doc/todo/conflict_free_comment_merges.mdwn | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/conflict_free_comment_merges.mdwn b/doc/todo/conflict_free_comment_merges.mdwn
index 2cef0ee8c..e84400c17 100644
--- a/doc/todo/conflict_free_comment_merges.mdwn
+++ b/doc/todo/conflict_free_comment_merges.mdwn
@@ -20,4 +20,4 @@ What do you think [[smcv]]? --[[Joey]]
> are quite low since it modifies the input text and adds a date stamp to
> it.
>
-> Anyway, I think it's good, [[[done]] --[[Joey]]
+> Anyway, I think it's good, [[done]] --[[Joey]]
--
cgit v1.2.3
From 59017c6ae19f661761d0ae3f143fbda643ca1e8d Mon Sep 17 00:00:00 2001
From: "http://jmtd.livejournal.com/"
Date: Fri, 19 Feb 2010 14:02:29 +0000
Subject: prevent keyboard mashing
---
doc/todo/double-click_protection_for_form_buttons.mdwn | 1 +
1 file changed, 1 insertion(+)
create mode 100644 doc/todo/double-click_protection_for_form_buttons.mdwn
(limited to 'doc/todo')
diff --git a/doc/todo/double-click_protection_for_form_buttons.mdwn b/doc/todo/double-click_protection_for_form_buttons.mdwn
new file mode 100644
index 000000000..4c0d95bd6
--- /dev/null
+++ b/doc/todo/double-click_protection_for_form_buttons.mdwn
@@ -0,0 +1 @@
+A small piece of JS to prevent double-submitting forms would be quite nice. I seem to have developed a habit of doing this and having to resolve a merge conflict for two initial commits. -- [[Jon]]
--
cgit v1.2.3
From ef537ed3553c590abbc302a97299ae5082471fea Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Fri, 19 Feb 2010 13:38:37 -0500
Subject: response
---
doc/todo/double-click_protection_for_form_buttons.mdwn | 4 ++++
1 file changed, 4 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/double-click_protection_for_form_buttons.mdwn b/doc/todo/double-click_protection_for_form_buttons.mdwn
index 4c0d95bd6..501be4498 100644
--- a/doc/todo/double-click_protection_for_form_buttons.mdwn
+++ b/doc/todo/double-click_protection_for_form_buttons.mdwn
@@ -1 +1,5 @@
A small piece of JS to prevent double-submitting forms would be quite nice. I seem to have developed a habit of doing this and having to resolve a merge conflict for two initial commits. -- [[Jon]]
+
+> By the time you see that merge conflict, the first commit has
+> already successfully happened, so you can just hit cancel
+> and throw away the second submit. --[[Joey]]
--
cgit v1.2.3
From f0b0bb5894e056eeb67c50cf096f950f1fbc718a Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Fri, 19 Feb 2010 14:27:42 -0500
Subject: ctime idea
---
doc/todo/auto_getctime_on_fresh_build.mdwn | 9 +++++++++
1 file changed, 9 insertions(+)
create mode 100644 doc/todo/auto_getctime_on_fresh_build.mdwn
(limited to 'doc/todo')
diff --git a/doc/todo/auto_getctime_on_fresh_build.mdwn b/doc/todo/auto_getctime_on_fresh_build.mdwn
new file mode 100644
index 000000000..ea95fb8c9
--- /dev/null
+++ b/doc/todo/auto_getctime_on_fresh_build.mdwn
@@ -0,0 +1,9 @@
+[[!tag wishlist]]
+
+It might be a good idea to enable --getctime when `.ikiwiki` does not
+exist. This way a new checkout of a `srcdir` would automatically get
+ctimes right. (Running --getctime whenever a rebuild is done would be too
+slow.) --[[Joey]]
+
+Could this be too annoying in some cases, eg, checking out a large wiki
+that needs to get set up right away? --[[Joey]]
--
cgit v1.2.3
From 100636afa253c9808654b5db45feabc4ca1c6f8c Mon Sep 17 00:00:00 2001
From: "http://privat.myopenid.com/"
Date: Sat, 27 Feb 2010 15:12:39 +0000
Subject: patch for multiple sidebars
---
..._up_sidebar_to_allow_for_multiple_sidebars.mdwn | 52 ++++++++++++++++++++++
1 file changed, 52 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
index fb942a495..02b83244e 100644
--- a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
+++ b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
@@ -13,5 +13,57 @@ those contents instead.
> In mine I just copied sidebar out and made some extra "sidebars", but they go elsewhere. Ugly hack, but it works. --[[simonraven]]
+>> Here a simple [[patch]] for multiple sidebars. Not too fancy but better than having multiple copies of the sidebar plugin. --[[jeanprivat]]
+
+
+--- /usr/share/perl5/IkiWiki/Plugin/sidebar.pm 2010-02-11 22:53:17.000000000 -0500
++++ plugins/IkiWiki/Plugin/sidebar.pm 2010-02-27 09:54:12.524412391 -0500
+@@ -19,12 +19,20 @@
+ safe => 1,
+ rebuild => 1,
+ },
++ active_sidebars => {
++ type => "string",
++ example => qw(sidebar banner footer),
++ description => "Which sidebars must be activated and processed.",
++ safe => 1,
++ rebuild => 1
++ },
+ }
+
+-sub sidebar_content ($) {
++sub sidebar_content ($$) {
+ my $page=shift;
++ my $sidebar=shift;
+
+- my $sidebar_page=bestlink($page, "sidebar") || return;
++ my $sidebar_page=bestlink($page, $sidebar) || return;
+ my $sidebar_file=$pagesources{$sidebar_page} || return;
+ my $sidebar_type=pagetype($sidebar_file);
+
+@@ -49,11 +57,17 @@
+
+ my $page=$params{page};
+ my $template=$params{template};
+-
+- if ($template->query(name => "sidebar")) {
+- my $content=sidebar_content($page);
+- if (defined $content && length $content) {
+- $template->param(sidebar => $content);
++
++ my @sidebars;
++ if (defined $config{active_sidebars} && length $config{active_sidebars}) { @sidebars = @{$config{active_sidebars}}; }
++ else { @sidebars = qw(sidebar); }
++
++ foreach my $sidebar (@sidebars) {
++ if ($template->query(name => $sidebar)) {
++ my $content=sidebar_content($page, $sidebar);
++ if (defined $content && length $content) {
++ $template->param($sidebar => $content);
++ }
+ }
+ }
+ }
+
[[!tag wishlist]]
--
cgit v1.2.3
From b849c63ce337f988fcbb08b39d197583e6fa6012 Mon Sep 17 00:00:00 2001
From: "http://dmarti.myopenid.com/"
Date: Thu, 4 Mar 2010 00:15:00 +0000
Subject:
---
doc/todo/salmon_protocol_for_comment_sharing.mdwn | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 doc/todo/salmon_protocol_for_comment_sharing.mdwn
(limited to 'doc/todo')
diff --git a/doc/todo/salmon_protocol_for_comment_sharing.mdwn b/doc/todo/salmon_protocol_for_comment_sharing.mdwn
new file mode 100644
index 000000000..f4fa0c535
--- /dev/null
+++ b/doc/todo/salmon_protocol_for_comment_sharing.mdwn
@@ -0,0 +1,3 @@
+The Salmon protocol provides for aggregating comments across sites. If a site that syndicates a feed receives a comment on an item in that feed, it can re-post the comment to the original source.
+
+[[!tag wishlist]]
--
cgit v1.2.3
From d72603534e677a4fbc0547ca3e5c9273d0d502ca Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Wed, 3 Mar 2010 19:48:23 -0500
Subject: comments
---
doc/todo/salmon_protocol_for_comment_sharing.mdwn | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/salmon_protocol_for_comment_sharing.mdwn b/doc/todo/salmon_protocol_for_comment_sharing.mdwn
index f4fa0c535..1e56b0a8b 100644
--- a/doc/todo/salmon_protocol_for_comment_sharing.mdwn
+++ b/doc/todo/salmon_protocol_for_comment_sharing.mdwn
@@ -1,3 +1,21 @@
-The Salmon protocol provides for aggregating comments across sites. If a site that syndicates a feed receives a comment on an item in that feed, it can re-post the comment to the original source.
+The Salmon protocol
+provides for aggregating comments across sites. If a site that syndicates
+a feed receives a comment on an item in that feed, it can re-post the
+comment to the original source.
+
+> Ikiwiki does not allow comments to be posted on items it aggregates.
+> So salmon protocol support would only need to handle the comment
+> receiving side of the protocol.
+>
+> The current draft protocol document confuses me when it starts talking
+> about using OAuth in the abuse prevention section, since their example
+> does not show use of OAuth, and it's not at all clear to me where the
+> OAuth relationship between aggregator and original source is supposed
+> to come from.
+>
+> Their security model, which goes on to include Webfinger,
+> thirdparty validation services, XRD, and Magic Signatures, looks sorta
+> like they kept throwing technology, at it, hoping something will stick. :-P
+> --[[Joey]]
[[!tag wishlist]]
--
cgit v1.2.3
From 58a6847cfb445dbb87716e4064f8151cc44a233a Mon Sep 17 00:00:00 2001
From: "http://oneingray.myopenid.com/"
Date: Fri, 12 Mar 2010 17:51:17 +0000
Subject: Note that, actually, SVG could be embedded into an Ikiwiki page,
albeit in a somewhat crude manner.
---
doc/todo/svg.mdwn | 8 ++++++++
1 file changed, 8 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/svg.mdwn b/doc/todo/svg.mdwn
index 89b183db6..2099751e3 100644
--- a/doc/todo/svg.mdwn
+++ b/doc/todo/svg.mdwn
@@ -57,3 +57,11 @@ in the trunk if other people think it's useful.
[htmlscrubber.pm]:http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blob;f=IkiWiki/Plugin/htmlscrubber.pm;h=3c0ddc8f25bd8cb863634a9d54b40e299e60f7df;hb=fe333c8e5b4a5f374a059596ee698dacd755182d
[diff]: http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blobdiff;f=IkiWiki/Plugin/htmlscrubber.pm;h=3c0ddc8f25bd8cb863634a9d54b40e299e60f7df;hp=3bdaccea119ec0e1b289a0da2f6d90e2219b8d66;hb=fe333c8e5b4a5f374a059596ee698dacd755182d;hpb=be0b4f603f918444b906e42825908ddac78b7073
+
+* * *
+
+Actually, there's a way to embed SVG into MarkDown sources using the [data: URI scheme][rfc2397], [like this](data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBzdGFuZGFsb25lPSJubyI/Pgo8c3ZnIHdpZHRoPSIxOTIiIGhlaWdodD0iMTkyIiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj4KIDwhLS0gQ3JlYXRlZCB3aXRoIFNWRy1lZGl0IC0gaHR0cDovL3N2Zy1lZGl0Lmdvb2dsZWNvZGUuY29tLyAtLT4KIDx0aXRsZT5IZWxsbywgd29ybGQhPC90aXRsZT4KIDxnPgogIDx0aXRsZT5MYXllciAxPC90aXRsZT4KICA8ZyB0cmFuc2Zvcm09InJvdGF0ZSgtNDUsIDk3LjY3MTksIDk3LjY2OCkiIGlkPSJzdmdfNyI+CiAgIDxyZWN0IHN0cm9rZS13aWR0aD0iNSIgc3Ryb2tlPSIjMDAwMDAwIiBmaWxsPSIjRkYwMDAwIiBpZD0ic3ZnXzUiIGhlaWdodD0iNTYuMDAwMDAzIiB3aWR0aD0iMTc1IiB5PSI2OS42Njc5NjkiIHg9IjEwLjE3MTg3NSIvPgogICA8dGV4dCB4bWw6c3BhY2U9InByZXNlcnZlIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LWZhbWlseT0ic2VyaWYiIGZvbnQtc2l6ZT0iMjQiIHN0cm9rZS13aWR0aD0iMCIgc3Ryb2tlPSIjMDAwMDAwIiBmaWxsPSIjZmZmZjAwIiBpZD0ic3ZnXzYiIHk9IjEwNS42NjgiIHg9Ijk5LjY3MTkiPkhlbGxvLCB3b3JsZCE8L3RleHQ+CiAgPC9nPgogPC9nPgo8L3N2Zz4=).
+Of course, this way to display an image one needs to click a link, but it may be considered a feature.
+— [[Ivan_Shmakov]], 2010-03-12Z.
+
+[rfc2397]: http://tools.ietf.org/html/rfc2397
--
cgit v1.2.3
From 844bb8134b5ff6e3d73dc3c8b91ed516fa618c41 Mon Sep 17 00:00:00 2001
From: "http://oneingray.myopenid.com/"
Date: Fri, 12 Mar 2010 18:33:10 +0000
Subject: Added an wishlist item.
---
...er_control_over___60__object___47____62__s.mdwn | 41 ++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 doc/todo/finer_control_over___60__object___47____62__s.mdwn
(limited to 'doc/todo')
diff --git a/doc/todo/finer_control_over___60__object___47____62__s.mdwn b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
new file mode 100644
index 000000000..714f5ae50
--- /dev/null
+++ b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
@@ -0,0 +1,41 @@
+IIUC, the current version of [HTML::Scrubber][] allows for the `object` tags to be either enabled or disabled entirely. However, while `object` can be used to add *code* (which is indeed a potential security hole) to a document, reading [Objects, Images, and Applets in HTML documents][objects-html] reveals that the “dangerous” are not all the `object`s, but rather those having the following attributes:
+
+ classid %URI; #IMPLIED -- identifies an implementation --
+ codebase %URI; #IMPLIED -- base URI for classid, data, archive--
+ codetype %ContentType; #IMPLIED -- content type for code --
+ archive CDATA #IMPLIED -- space-separated list of URIs --
+
+It seems that the following attributes are, OTOH, safe:
+
+ declare (declare) #IMPLIED -- declare but don't instantiate flag --
+ data %URI; #IMPLIED -- reference to object's data --
+ type %ContentType; #IMPLIED -- content type for data --
+ standby %Text; #IMPLIED -- message to show while loading --
+ height %Length; #IMPLIED -- override height --
+ width %Length; #IMPLIED -- override width --
+ usemap %URI; #IMPLIED -- use client-side image map --
+ name CDATA #IMPLIED -- submit as part of form --
+ tabindex NUMBER #IMPLIED -- position in tabbing order --
+
+Should the former attributes be *scrubbed* while the latter left intact, the use of the `object` tag would seemingly become safe.
+
+Note also that allowing `object` (either restricted in such a way or not) automatically solves the [[/todo/svg]] issue.
+
+For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by the `data` and `usemap` attributes) to, say, relative and `data:` (as per [RFC 2397][]) ones as well, though it requires some more consideration.
+
+— [[Ivan_Shmakov]], 2010-03-12Z.
+
+[[wishlist]]
+
+## See also
+
+* [Objects, Images, and Applets in HTML documents][objects-html]
+* [[plugins/htmlscrubber|/plugins/htmlscrubber]]
+* [[todo/svg|/todo/svg]]
+* [RFC 2397: The “data” URL scheme. L. Masinter. August 1998.][RFC 2397]
+* [Uniform Resource Identifier — the free encyclopedia][URI]
+
+[HTML::Scrubber]: http://search.cpan.org/~podmaster/HTML-Scrubber-0.08/Scrubber.pm
+[objects-html]: http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html
+[RFC 2397]: http://tools.ietf.org/html/rfc2397
+[URI]: http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
--
cgit v1.2.3
From 556181d417e3461de56c43445ec9b2b0aefc7141 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Fri, 12 Mar 2010 14:29:54 -0500
Subject: data:image/svg is a security hole as javascript can presumably be
inserted
---
doc/todo/svg.mdwn | 10 ++++++++++
1 file changed, 10 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/svg.mdwn b/doc/todo/svg.mdwn
index 2099751e3..274ebf3e3 100644
--- a/doc/todo/svg.mdwn
+++ b/doc/todo/svg.mdwn
@@ -58,6 +58,8 @@ in the trunk if other people think it's useful.
[htmlscrubber.pm]:http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blob;f=IkiWiki/Plugin/htmlscrubber.pm;h=3c0ddc8f25bd8cb863634a9d54b40e299e60f7df;hb=fe333c8e5b4a5f374a059596ee698dacd755182d
[diff]: http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blobdiff;f=IkiWiki/Plugin/htmlscrubber.pm;h=3c0ddc8f25bd8cb863634a9d54b40e299e60f7df;hp=3bdaccea119ec0e1b289a0da2f6d90e2219b8d66;hb=fe333c8e5b4a5f374a059596ee698dacd755182d;hpb=be0b4f603f918444b906e42825908ddac78b7073
+> Unfortuantly these links are broken. --[[Joey]]
+
* * *
Actually, there's a way to embed SVG into MarkDown sources using the [data: URI scheme][rfc2397], [like this](data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBzdGFuZGFsb25lPSJubyI/Pgo8c3ZnIHdpZHRoPSIxOTIiIGhlaWdodD0iMTkyIiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj4KIDwhLS0gQ3JlYXRlZCB3aXRoIFNWRy1lZGl0IC0gaHR0cDovL3N2Zy1lZGl0Lmdvb2dsZWNvZGUuY29tLyAtLT4KIDx0aXRsZT5IZWxsbywgd29ybGQhPC90aXRsZT4KIDxnPgogIDx0aXRsZT5MYXllciAxPC90aXRsZT4KICA8ZyB0cmFuc2Zvcm09InJvdGF0ZSgtNDUsIDk3LjY3MTksIDk3LjY2OCkiIGlkPSJzdmdfNyI+CiAgIDxyZWN0IHN0cm9rZS13aWR0aD0iNSIgc3Ryb2tlPSIjMDAwMDAwIiBmaWxsPSIjRkYwMDAwIiBpZD0ic3ZnXzUiIGhlaWdodD0iNTYuMDAwMDAzIiB3aWR0aD0iMTc1IiB5PSI2OS42Njc5NjkiIHg9IjEwLjE3MTg3NSIvPgogICA8dGV4dCB4bWw6c3BhY2U9InByZXNlcnZlIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LWZhbWlseT0ic2VyaWYiIGZvbnQtc2l6ZT0iMjQiIHN0cm9rZS13aWR0aD0iMCIgc3Ryb2tlPSIjMDAwMDAwIiBmaWxsPSIjZmZmZjAwIiBpZD0ic3ZnXzYiIHk9IjEwNS42NjgiIHg9Ijk5LjY3MTkiPkhlbGxvLCB3b3JsZCE8L3RleHQ+CiAgPC9nPgogPC9nPgo8L3N2Zz4=).
@@ -65,3 +67,11 @@ Of course, this way to display an image one needs to click a link, but it may be
— [[Ivan_Shmakov]], 2010-03-12Z.
[rfc2397]: http://tools.ietf.org/html/rfc2397
+
+> You can do the same with img src actually.
+>
+> If svg markup allows unsafe elements (ie, javascript),
+> which it appears to,
+> then this is a security hole, and the htmlscrubber
+> needs to lock it down more. Darn, now I have to spend my afternoon making
+> security releases! --[[Joey]]
--
cgit v1.2.3
From 4711076fad54ff8152f03a7e4bdd4b5c2df1916c Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Fri, 12 Mar 2010 15:00:39 -0500
Subject: clarify
---
doc/todo/mercurial.mdwn | 8 ++++++++
1 file changed, 8 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/mercurial.mdwn b/doc/todo/mercurial.mdwn
index e71c8106a..de1f148e5 100644
--- a/doc/todo/mercurial.mdwn
+++ b/doc/todo/mercurial.mdwn
@@ -119,3 +119,11 @@ I have a few notes on mercurial usage after trying it out for a while:
>> I think the ideal solution would be to build `$destdir/recentchanges/*` directly from the output of `hg log`. --[[buo]]
>>>> That would be 100 times as slow, so I chose not to do that. --[[Joey]]
+
+>>>> Since this is confusing people, allow me to clarify: Ikiwiki's
+>>>> recentchanges generation pulls log information directly out of the VCS as
+>>>> needed. It caches it in recentchanges/* in the `scrdir`. These cache
+>>>> files need not be preserved, should never be checked into VCS, and if
+>>>> you want to you can configure your VCSignore file to ignore them,
+>>>> just as you can configure it to ignore the `.ikiwiki` directory in the
+>>>> `scrdir`. --[[Joey]]
--
cgit v1.2.3
From 08485ec444cf81015e39c52e6ce8e7b933a036f6 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Fri, 12 Mar 2010 15:40:47 -0500
Subject: response
---
doc/todo/finer_control_over___60__object___47____62__s.mdwn | 7 +++++++
1 file changed, 7 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/finer_control_over___60__object___47____62__s.mdwn b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
index 714f5ae50..ac4b55568 100644
--- a/doc/todo/finer_control_over___60__object___47____62__s.mdwn
+++ b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
@@ -27,6 +27,13 @@ For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by
[[wishlist]]
+> SVG can contain embedded javascript. The spec that you link to contains
+> examples of objects that contain python scripts, Microsoft OLE
+> objects, and Java. And then there's flash. I don't think ikiwiki can
+> assume all the possibilities are handled securely, particularly WRT XSS
+> attacks.
+> --[[Joey]]
+
## See also
* [Objects, Images, and Applets in HTML documents][objects-html]
--
cgit v1.2.3
From b5e27e60ba38365f3e252df80c2a22503f00eb06 Mon Sep 17 00:00:00 2001
From: "http://oneingray.myopenid.com/"
Date: Fri, 12 Mar 2010 21:24:53 +0000
Subject: Note that still may be allowed, although in a form not
suitable for, say, SVG inclusion.
---
...er_control_over___60__object___47____62__s.mdwn | 34 +++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/finer_control_over___60__object___47____62__s.mdwn b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
index ac4b55568..c37d052db 100644
--- a/doc/todo/finer_control_over___60__object___47____62__s.mdwn
+++ b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
@@ -27,13 +27,43 @@ For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by
[[wishlist]]
-> SVG can contain embedded javascript. The spec that you link to contains
+> SVG can contain embedded javascript.
+
+>> Indeed.
+
+>> So, a more general tool (`XML::Scrubber`?) will be necessary to
+>> refine both [XHTML][] and SVG.
+
+>> … And to leave [MathML][] as is (?.)
+
+>> — [[Ivan_Shmakov]], 2010-03-12Z.
+
+> The spec that you link to contains
> examples of objects that contain python scripts, Microsoft OLE
> objects, and Java. And then there's flash. I don't think ikiwiki can
> assume all the possibilities are handled securely, particularly WRT XSS
> attacks.
> --[[Joey]]
+>> I've scanned over all the `object` examples in the specification and
+>> all of those that hold references to code (as opposed to data) have a
+>> distinguishing `classid` attribute.
+
+>> While I won't assert that it's impossible to reference code with
+>> `data` (and, thanks to `text/xhtml+xml` and `image/svg+xml`, it is
+>> *not* impossible), throwing away any of the “insecure”
+>> attributes listed above together with limiting the possible URI's
+>> (i. e., only *local* and certain `data:` ones for `data` and
+>> `usemap`) should make `object` almost as harmless as, say, `img`.
+
+>> (Though it certainly won't solve the [[SVG_problem|/todo/SVG]] being
+>> restricted in such a way.)
+
+>> Of the remaining issues I could only think of recursive
+>> `object` — the one that references its container document.
+
+>> — [[Ivan_Shmakov]], 2010-03-12Z.
+
## See also
* [Objects, Images, and Applets in HTML documents][objects-html]
@@ -43,6 +73,8 @@ For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by
* [Uniform Resource Identifier — the free encyclopedia][URI]
[HTML::Scrubber]: http://search.cpan.org/~podmaster/HTML-Scrubber-0.08/Scrubber.pm
+[MathML]: http://en.wikipedia.org/wiki/MathML
[objects-html]: http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html
[RFC 2397]: http://tools.ietf.org/html/rfc2397
[URI]: http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
+[XHTML]: http://en.wikipedia.org/wiki/XHTML
--
cgit v1.2.3
From 29ca20b87c565412fa603127425ccdaf4ca58b79 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Fri, 12 Mar 2010 16:50:04 -0500
Subject: response
---
doc/todo/finer_control_over___60__object___47____62__s.mdwn | 5 +++++
1 file changed, 5 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/finer_control_over___60__object___47____62__s.mdwn b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
index c37d052db..0ca949954 100644
--- a/doc/todo/finer_control_over___60__object___47____62__s.mdwn
+++ b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
@@ -56,6 +56,11 @@ For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by
>> (i. e., only *local* and certain `data:` ones for `data` and
>> `usemap`) should make `object` almost as harmless as, say, `img`.
+>>> But with local data, one could not embed youtube videos, which surely
+>>> is the most obvious use case? Note that youtube embedding uses an
+>>> object element with no classid. The swf file is provided via an
+>>> enclosed param element. --[[Joey]]
+
>> (Though it certainly won't solve the [[SVG_problem|/todo/SVG]] being
>> restricted in such a way.)
--
cgit v1.2.3
From c26b6c3be864aaf49fe0b0fc15c0af59323b7dde Mon Sep 17 00:00:00 2001
From: "http://oneingray.myopenid.com/"
Date: Fri, 12 Mar 2010 22:12:41 +0000
Subject: Note the use of on YouTube.
---
.../finer_control_over___60__object___47____62__s.mdwn | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/finer_control_over___60__object___47____62__s.mdwn b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
index 0ca949954..50c4d43bf 100644
--- a/doc/todo/finer_control_over___60__object___47____62__s.mdwn
+++ b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
@@ -57,10 +57,23 @@ For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by
>> `usemap`) should make `object` almost as harmless as, say, `img`.
>>> But with local data, one could not embed youtube videos, which surely
->>> is the most obvious use case? Note that youtube embedding uses an
+>>> is the most obvious use case?
+
+>>>> Allowing a “remote” object to render on one's page is a
+ security issue by itself.
+ Though, of course, having an explicit whitelist of URI's may make
+ this issue more tolerable.
+ — [[Ivan_Shmakov]], 2010-03-12Z.
+
+>>> Note that youtube embedding uses an
>>> object element with no classid. The swf file is provided via an
>>> enclosed param element. --[[Joey]]
+>>>> I've just checked a random video on YouTube and I see that the
+ `.swf` file is provided via an enclosed `embed` element. Whether
+ to allow those or not is a different issue.
+ — [[Ivan_Shmakov]], 2010-03-12Z.
+
>> (Though it certainly won't solve the [[SVG_problem|/todo/SVG]] being
>> restricted in such a way.)
--
cgit v1.2.3
From e8f6c06ca81e4ebd8d244e3863d21517d87b6620 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Sat, 13 Mar 2010 17:29:06 -0500
Subject: update; openid email addresses now available so this is unblocked
---
doc/todo/avatar.mdwn | 31 ++++++++++---------------------
1 file changed, 10 insertions(+), 21 deletions(-)
(limited to 'doc/todo')
diff --git a/doc/todo/avatar.mdwn b/doc/todo/avatar.mdwn
index b8aa2327f..4409e7b14 100644
--- a/doc/todo/avatar.mdwn
+++ b/doc/todo/avatar.mdwn
@@ -1,35 +1,24 @@
[[!tag wishlist]]
It would be nice if ikiwiki, particularly [[plugins/comments]]
-supported user avatar icons. I was considering adding a directive for this,
-as designed below.
+supported user avatar icons.
-However, there is no *good* service for mapping openids to avatars --
-openavatar has many issues, including not supporting delegated openids, and
-after trying it, I don't trust it to push users toward.
-Perhaps instead ikiwiki could get the email address from the openid
-provider, though I think the perl openid modules don't support the openid
-2.x feature that allows that.
-
-At the moment, working on this doesn't feel like a good use of my time.
---[[Joey]]
-
-Hmm.. unless is just always used a single provider (gravatar) and hashed
-the openid. Then wavatars could be used to get a unique avatar per openid
-at least. --[[Joey]]
-
-----
-
-The directive displays a small avatar image for a user. Pass it the
-email address, openid, or wiki username of the user.
+Idea is to add a directive that displays a small avatar image for a user.
+Pass it the email address, openid, or wiki username of the user.
\[[!avatar user@example.com]]
\[[!avatar http://joey.kitenet.net/]]
\[[!avatar user]]
+These directives can then be hand-inserted onto pages, or more likely,
+included in eg, a comment post via a template. Possibly included in a
+recentchanges page item via that template too?
+
The avatars are provided by various sites. For email addresses, it uses a
[gravatar](http://gravatar.com/). For openid,
-[openavatar](http://www.openvatar.com/) is used. For a wiki username, the
+[openavatar](http://www.openvatar.com/) could used, but I am not very happy
+with it; probably better to just get the email via SREG (as is done now for
+openid), and use that. For a wiki username, the
user's email address is looked up and the gravatar for that user is
displayed. (Of course, the user has to have filled in their email address
on their Preferences page for that to work.)
--
cgit v1.2.3
From e2c9b425415a00012b2c579c40c369da4ac7c98b Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Sat, 13 Mar 2010 17:46:28 -0500
Subject: thoughts
---
doc/todo/Separate_OpenIDs_and_usernames.mdwn | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
index 2cd52e8c4..ae427d540 100644
--- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn
+++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
@@ -6,6 +6,25 @@ I see this being implemented in one of two possible ways. The easiest seems like
A slightly more complex next step would be to request sreg from the provider and, if provided, automatically set the identity's username and email address from the provided persona. If username login to accounts with blank passwords is disabled, then you have the best of both worlds. Passwordless signin, human-friendly attribution, automatic setting of preferences.
+> Given that openids are a global user identifier, that can look as pretty
+> as the user cares to make it look via delegation, I am not a fan of
+> having a site-local identifier that layered on top of that. Perhaps
+> partly because every site that I have seen that does that has openid
+> implemented as a badly-done wart on the side of their regular login
+> system.
+>
+> Openid Simple Registration is now used to populate the userdb with the
+> email address for openid users.
+>
+> I am considering displaying the userid or fullname, if available,
+> instead of the munged openid url in recentchanges. It would be nice
+> for those nasty [[google_openids|forum/google_openid_broken?]]. But,
+> I first have to find a way to encode the name in the VCS commit log,
+> while still keeping the openid of the committer in there too.
+> Perhaps something like this (for git): --[[Joey]]
+>
+> Author: Joey Hess
+
Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat.
[[!tag wishlist]]
--
cgit v1.2.3
From 4f6c544fa8e7dd21450952f0a9fc3918ee600705 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Sat, 13 Mar 2010 19:12:52 -0500
Subject: munge to avoid markdown eating email addresses
---
doc/todo/git_attribution/discussion.mdwn | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
(limited to 'doc/todo')
diff --git a/doc/todo/git_attribution/discussion.mdwn b/doc/todo/git_attribution/discussion.mdwn
index dfb490bc2..6905d9b4b 100644
--- a/doc/todo/git_attribution/discussion.mdwn
+++ b/doc/todo/git_attribution/discussion.mdwn
@@ -72,7 +72,7 @@ no determination of uniqueness)
> GIT_AUTHOR_EMAIL can also be set.
>
> There is one thing yet to be solved, and that is how to tell the
-> difference between a web commit by 'Joey Hess ',
+> difference between a web commit by 'Joey Hess ',
> and a git commit by the same. I think we do want to differentiate these,
> and the best way to do it seems to be to add a line to the end of the
> commit message. Something like: "\n\nWeb-commit: true"
@@ -94,5 +94,5 @@ no determination of uniqueness)
> * github pushes to twitter ;-)
>
> So while I tried that way at first, I'm now leaning toward encoding the
-> username in the email address. Like "user ", or
-> "joey ".
+> username in the email address. Like "user ", or
+> "joey ".
--
cgit v1.2.3
From 8f4f81cdfdcb68be5efb385dc07e4a0a04352a9d Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Sat, 13 Mar 2010 19:24:51 -0500
Subject: wrinkles
---
doc/todo/Separate_OpenIDs_and_usernames.mdwn | 9 ++++++---
doc/todo/avatar.mdwn | 14 ++++++++++----
2 files changed, 16 insertions(+), 7 deletions(-)
(limited to 'doc/todo')
diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
index ae427d540..3fb952f96 100644
--- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn
+++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
@@ -13,8 +13,9 @@ A slightly more complex next step would be to request sreg from the provider and
> implemented as a badly-done wart on the side of their regular login
> system.
>
-> Openid Simple Registration is now used to populate the userdb with the
-> email address for openid users.
+> The openid plugin now attempts to get an email and a username, and stores
+> them in the session database for later use (ie, when the user edits a
+> page).
>
> I am considering displaying the userid or fullname, if available,
> instead of the munged openid url in recentchanges. It would be nice
@@ -23,7 +24,9 @@ A slightly more complex next step would be to request sreg from the provider and
> while still keeping the openid of the committer in there too.
> Perhaps something like this (for git): --[[Joey]]
>
-> Author: Joey Hess
+> Author: Joey Hess <http://joey.kitenet.net/@web>
+>
+>
Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat.
diff --git a/doc/todo/avatar.mdwn b/doc/todo/avatar.mdwn
index 4409e7b14..3a4e64b95 100644
--- a/doc/todo/avatar.mdwn
+++ b/doc/todo/avatar.mdwn
@@ -15,14 +15,20 @@ included in eg, a comment post via a template. Possibly included in a
recentchanges page item via that template too?
The avatars are provided by various sites. For email addresses, it uses a
-[gravatar](http://gravatar.com/). For openid,
-[openavatar](http://www.openvatar.com/) could used, but I am not very happy
-with it; probably better to just get the email via SREG (as is done now for
-openid), and use that. For a wiki username, the
+[gravatar](http://gravatar.com/). For a wiki username, the
user's email address is looked up and the gravatar for that user is
displayed. (Of course, the user has to have filled in their email address
on their Preferences page for that to work.)
+For openid, openavatar sucked and is now dead. So we need to use an email
+address instead, I guess. Problem is that the email address of a given
+openid is only known when that user is logged in and making a change.
+And we don't want to leak an openid user's email into a page either.
+Hmm. Suppose the gravatar hash could be calculated from the email address
+and embedded instead of the openid?
+
+Or, for openid, could use .
+
An optional second parameter can be included, containing additional
options to pass in the
[gravatar url](http://en.gravatar.com/site/implement/url).
--
cgit v1.2.3
From 702c097ac29f1b208158936a99317ebad3e4116f Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Sat, 13 Mar 2010 19:40:20 -0500
Subject: update
---
doc/todo/Separate_OpenIDs_and_usernames.mdwn | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
(limited to 'doc/todo')
diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
index 3fb952f96..7cfe49a5a 100644
--- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn
+++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
@@ -18,15 +18,25 @@ A slightly more complex next step would be to request sreg from the provider and
> page).
>
> I am considering displaying the userid or fullname, if available,
-> instead of the munged openid url in recentchanges. It would be nice
-> for those nasty [[google_openids|forum/google_openid_broken?]]. But,
-> I first have to find a way to encode the name in the VCS commit log,
+> instead of the munged openid url in recentchanges and comments.
+> It would be nice for those nasty [[google_openids|forum/google_openid_broken?]].
+> But, I first have to find a way to encode the name in the VCS commit log,
> while still keeping the openid of the committer in there too.
> Perhaps something like this (for git): --[[Joey]]
>
> Author: Joey Hess <http://joey.kitenet.net/@web>
>
+> So, what needs to be done:
>
+> * Change `rcs_commit` and `rcs_commit_staged` to take a session object,
+> instead of just a userid. (For back-compat, if the parameter is
+> not an object, it's a userid.) Bump ikiwiki plugin interface version.
+> * Modify all RCS plugins to include the session username somewhere
+> in the commit, and parse it back out in `rcs_recentchanges`.
+> * Modify recentchanges plugin to display the username instead of the
+> `openiduser`.
+> * Modify comment plugin to put the session username in the comment
+> template instead of the `openiduser`.
Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat.
--
cgit v1.2.3
From fd43e83fcf7bf24493ecfff54111c1c5f1cab573 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Sat, 13 Mar 2010 19:56:54 -0500
Subject: update
---
doc/forum/google_openid_broken__63__.mdwn | 13 +++++++++++++
doc/todo/Separate_OpenIDs_and_usernames.mdwn | 7 +++++++
2 files changed, 20 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/forum/google_openid_broken__63__.mdwn b/doc/forum/google_openid_broken__63__.mdwn
index 0e41d4ced..4ca5cac93 100644
--- a/doc/forum/google_openid_broken__63__.mdwn
+++ b/doc/forum/google_openid_broken__63__.mdwn
@@ -58,3 +58,16 @@ points to a fairly useless xml document, rather than a web page. --[[Joey]]
> I've added buttons that submit the two above URLs for logging in with a Google and Yahoo OpenID, respectively, to my locally changed OpenID login plugin.
> Using the Google profile page as the OpenID is really orthogonal to the above. --[[kaol]]
+
+>> Displaying email addresses is not really an option, because ikiwiki
+>> can't leak user email addresses like that. Displaying nicknames or
+>> usernames is, see [[todo/Separate_OpenIDs_and_usernames]].
+>>
+>> It would probably be good if the openid plugin could be configured with
+>> a list of generic openid urls, so it can add quick login buttons using
+>> those urls.
+>>
+>> The ugly google url will still be exposed here and there where
+>> a unique user id is needed. That can be avoided by not using the generic
+>> , but instead your own profile
+>> like . --[[Joey]]
diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
index 7cfe49a5a..fcdb49f6d 100644
--- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn
+++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
@@ -26,6 +26,13 @@ A slightly more complex next step would be to request sreg from the provider and
>
> Author: Joey Hess <http://joey.kitenet.net/@web>
>
+> Only problem with the above is that the openid will still be displayed
+> by CIA. Other option is this, which solves that, but at the expense of
+> having to munge the username to fit inside the email address,
+> and generally seems backwards: --[[Joey]]
+>
+> Author: http://joey.kitenet.net/ <Joey_Hess@web>
+>
> So, what needs to be done:
>
> * Change `rcs_commit` and `rcs_commit_staged` to take a session object,
--
cgit v1.2.3
From 725a1cf0e8d1fbdb7f449b632ee1fa3cb84835c7 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Sat, 13 Mar 2010 20:45:44 -0500
Subject: update; bleargh
---
doc/todo/avatar.mdwn | 50 ++++++++++++++++++++++++++++++++++----------------
1 file changed, 34 insertions(+), 16 deletions(-)
(limited to 'doc/todo')
diff --git a/doc/todo/avatar.mdwn b/doc/todo/avatar.mdwn
index 3a4e64b95..f0599e4ed 100644
--- a/doc/todo/avatar.mdwn
+++ b/doc/todo/avatar.mdwn
@@ -1,42 +1,60 @@
[[!tag wishlist]]
It would be nice if ikiwiki, particularly [[plugins/comments]]
-supported user avatar icons.
+(but also, ideally, recentchanges) supported user avatar icons.
Idea is to add a directive that displays a small avatar image for a user.
-Pass it the email address, openid, or wiki username of the user.
+Pass it a user's the email address, openid, username, or the md5 hash
+of their email address:
\[[!avatar user@example.com]]
\[[!avatar http://joey.kitenet.net/]]
\[[!avatar user]]
+ \[[!avatar hash]]
These directives can then be hand-inserted onto pages, or more likely,
-included in eg, a comment post via a template. Possibly included in a
-recentchanges page item via that template too?
+included in eg, a comment post via a template.
+
+An optional second parameter can be included, containing additional
+options to pass in the
+[gravatar url](http://en.gravatar.com/site/implement/url).
+For example, this asks for a smaller gravatar, and if a user does
+not have a gravatar, uses a cute auto-generated "wavatar" avatar.
+
+ \[[!gravatar user@example.com "size=40&default=wavatar"]]
+
+The `gravitar_options` setting in the setup file can be used to
+specify additional options to pass. So for example if you want
+to use wavatars everywhere, set it to "default=wavatar".
The avatars are provided by various sites. For email addresses, it uses a
[gravatar](http://gravatar.com/). For a wiki username, the
user's email address is looked up and the gravatar for that user is
displayed. (Of course, the user has to have filled in their email address
-on their Preferences page for that to work.)
+on their Preferences page for that to work. Also, when the user changes
+their email address in Preferences, the gravatar won't change until the
+wiki is rebuilt.)
For openid, openavatar sucked and is now dead. So we need to use an email
address instead, I guess. Problem is that the email address of a given
openid is only known when that user is logged in and making a change.
And we don't want to leak an openid user's email into a page either.
Hmm. Suppose the gravatar hash could be calculated from the email address
-and embedded instead of the openid?
+and embedded instead of the openid? That would work for comments,
+but not if the directive were used elsewhere.
-Or, for openid, could use .
+Or, for openid, could use . Which
+works fine, but users are not likely to figure out what they need to do to
+get an avatar associated with their openid.
-An optional second parameter can be included, containing additional
-options to pass in the
-[gravatar url](http://en.gravatar.com/site/implement/url).
-For example, this asks for a smaller gravatar, and if a user does
-not have a gravatar, uses a cute auto-generated "wavatar" avatar.
+---
- \[[!gravatar user@example.com "size=40&default=wavatar"]]
+Alternative, not overdesigned approach:
-The `gravitar_options` setting in the setup file can be used to
-specify additional options to pass. So for example if you want
-to use wavatars everywhere, set it to "default=wavatar".
+Modify comments plugin to have an option to display avatars.
+
+When posting a comment, fill in the avatarhash field in the template.
+The hash is calculated from the user's email address. If the user's email
+is not known, skip it.
+
+End. :P
--
cgit v1.2.3
From 823ec815d4fc9625d6fa3553ad03e9f2ff737659 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Sun, 14 Mar 2010 14:58:13 -0400
Subject: Add a include setting, which can be used to make ikiwiki process wiki
source files, such as .htaccess, that would normally be skipped for security
or other reasons. Closes: #447267 (Thanks to Aaron Wilson for the original
patch.)
---
IkiWiki.pm | 13 +++++++++++++
debian/changelog | 4 ++++
doc/tips/htaccess_file.mdwn | 30 ++++++++++++++++++++++++++++++
doc/todo/enable-htaccess-files.mdwn | 5 +++++
doc/usage.mdwn | 6 ++++++
ikiwiki.in | 3 +++
6 files changed, 61 insertions(+)
create mode 100644 doc/tips/htaccess_file.mdwn
(limited to 'doc/todo')
diff --git a/IkiWiki.pm b/IkiWiki.pm
index 251ed8cc8..ee94ce659 100644
--- a/IkiWiki.pm
+++ b/IkiWiki.pm
@@ -334,6 +334,15 @@ sub getsetup () {
safe => 0, # paranoia
rebuild => 0,
},
+ include => {
+ type => "string",
+ default => undef,
+ example => '^\.htaccess$',
+ description => "regexp of normally ignored source files to include",
+ advanced => 1,
+ safe => 0, # regexp
+ rebuild => 1,
+ },
exclude => {
type => "string",
default => undef,
@@ -1820,6 +1829,10 @@ sub file_pruned ($;$) {
$file =~ s#^\Q$base\E/+##;
}
+ if (defined $config{include} && length $config{include}) {
+ return 0 if $file =~ m/$config{include}/;
+ }
+
my $regexp='('.join('|', @{$config{wiki_file_prune_regexps}}).')';
return $file =~ m/$regexp/;
}
diff --git a/debian/changelog b/debian/changelog
index 92afe661f..e5347e2a1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -8,6 +8,10 @@ ikiwiki (3.20100313) UNRELEASED; urgency=low
as used by yahoo and google urls.
* Add complete German basewiki and directives translation done by
Sebastian Kuhnert.
+ * Add a include setting, which can be used to make ikiwiki process
+ wiki source files, such as .htaccess, that would normally be skipped
+ for security or other reasons. Closes: #447267
+ (Thanks to Aaron Wilson for the original patch.)
-- Joey Hess Sat, 13 Mar 2010 14:48:10 -0500
diff --git a/doc/tips/htaccess_file.mdwn b/doc/tips/htaccess_file.mdwn
new file mode 100644
index 000000000..5266eba41
--- /dev/null
+++ b/doc/tips/htaccess_file.mdwn
@@ -0,0 +1,30 @@
+If you try to include a `.htaccess` file in your wiki's source, in order to
+configure the web server, you'll find that ikiwiki excludes it from
+processing. In fact, ikiwiki excludes any file starting with a dot, as well
+as a lot of other files, for good security reasons.
+
+You can tell ikiwiki not to exclude the .htaccess file by adding this to
+your setup file:
+
+ include => '^\.htaccess$',
+
+Caution! Before you do that, please think for a minute about who can edit
+your wiki. Are attachment uploads enabled? Can users commit changes
+directly to the version control system? Do you trust everyone who can
+make a change to not do Bad Things with the htaccess file? Do you trust
+everyone who *might* be able to make a change in the future? Note that a
+determined attacker who can write to the htaccess file can probably get a
+shell on your web server.
+
+If any of these questions have given you pause, I suggest you find a
+different way to configure the web server. One way is to not put the
+`.htaccess` file under ikiwiki's control, and just manually install it
+in the destdir.
+
+[Apache's documentation](http://httpd.apache.org/docs/1.3/howto/htaccess.html)
+says
+> In general, you should never use .htaccess files unless you don't have
+> access to the main server configuration file.
+This is good advice -- if you can edit apache's main configuration files,
+then you should not use a htaccess file.
+--[[Joey]]
diff --git a/doc/todo/enable-htaccess-files.mdwn b/doc/todo/enable-htaccess-files.mdwn
index 412cb5eba..c895db75d 100644
--- a/doc/todo/enable-htaccess-files.mdwn
+++ b/doc/todo/enable-htaccess-files.mdwn
@@ -61,3 +61,8 @@ It should be off by default of course. --Max
+1 for various purposes (but sometimes the filename isn't `.htaccess`, so please make it configurable) --[[schmonz]]
> I've described a workaround for one use case at the [[plugins/rsync]] [[plugins/rsync/discussion]] page. --[[schmonz]]
+
+---
+
+[[done]], you can use the `include` setting to override the default
+excludes now. Please use extreme caution when doing so. --[[Joey]]
diff --git a/doc/usage.mdwn b/doc/usage.mdwn
index a105d7e59..f735170f0 100644
--- a/doc/usage.mdwn
+++ b/doc/usage.mdwn
@@ -234,6 +234,12 @@ also be configured using a setup file.
Specifies a rexexp of source files to exclude from processing.
May be specified multiple times to add to exclude list.
+* --include regexp
+
+ Specifies a rexexp of source files, that would normally be excluded,
+ but that you wish to include in processing.
+ May be specified multiple times to add to include list.
+
* --adminuser name
Specifies a username of a user (or, if openid is enabled, an openid)
diff --git a/ikiwiki.in b/ikiwiki.in
index ae1251ff6..da5555629 100755
--- a/ikiwiki.in
+++ b/ikiwiki.in
@@ -65,6 +65,9 @@ sub getconfig () {
"exclude=s@" => sub {
push @{$config{wiki_file_prune_regexps}}, $_[1];
},
+ "include=s@" => sub {
+ $config{include}=defined $config{include} && length $config{include} ? "$config{include}|$_[1]" : $_[1];
+ },
"adminuser=s@" => sub {
push @{$config{adminuser}}, $_[1]
},
--
cgit v1.2.3
From a5ee40104481ba06eaaf277ed2f6c363dd326608 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Sun, 14 Mar 2010 15:08:41 -0400
Subject: note that the patch on this page is complely broken, and allows any
file starting with a dot to be included
If you applied that patch to your site, you should remove it right away!
---
doc/todo/enable-htaccess-files.mdwn | 7 +++++++
1 file changed, 7 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/enable-htaccess-files.mdwn b/doc/todo/enable-htaccess-files.mdwn
index c895db75d..c08502bdd 100644
--- a/doc/todo/enable-htaccess-files.mdwn
+++ b/doc/todo/enable-htaccess-files.mdwn
@@ -12,6 +12,13 @@
qr/(^|\/).svn\//, qr/.arch-ids\//, qr/{arch}\//],
wiki_link_regexp => qr/\[\[(?:([^\]\|]+)\|)?([^\s\]#]+)(?:#([^\s\]]+))?\]\]/,
+> Note that the above patch is **completely broken**.
+> It removes the crucial excludes of all files starting with a dot.
+> The negative regexps for htaccess have no effect, so the whole
+> thing only "works" because it allows *any* file starting with a dot.
+> If you applied this patch to your ikiwiki, you opened a huge security
+> hole. --[[Joey]]
+
[[!tag patch patch/core]]
This lets the site administrator have a `.htaccess` file in their underlay
--
cgit v1.2.3
From 223b8efab0a55075bd53d03fe3cb2df07f13d9c1 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Sun, 14 Mar 2010 15:12:59 -0400
Subject: update
---
doc/todo/enable-htaccess-files.mdwn | 5 +++++
1 file changed, 5 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/enable-htaccess-files.mdwn b/doc/todo/enable-htaccess-files.mdwn
index c08502bdd..3b9721d50 100644
--- a/doc/todo/enable-htaccess-files.mdwn
+++ b/doc/todo/enable-htaccess-files.mdwn
@@ -64,6 +64,11 @@ It should be off by default of course. --Max
---
+1 I want `.htaccess` so I can rewrite some old Wordpress URLs to make feeds work again. --[[hendry]]
+> Unless you cannot modify apache's configuration, you do not need htaccess
+> to do that. Apache's documentation recommends against using htaccess
+> unless you're a user who cannot modify the main server configuration.
+> --[[Joey]]
+
---
+1 for various purposes (but sometimes the filename isn't `.htaccess`, so please make it configurable) --[[schmonz]]
--
cgit v1.2.3
From 4054f8d8ce0802b43e1c2c6f9cb71badbbcaf919 Mon Sep 17 00:00:00 2001
From: kierun
Date: Wed, 17 Mar 2010 09:14:46 +0000
Subject:
---
doc/todo/ACL.mdwn | 9 +++++++++
1 file changed, 9 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/ACL.mdwn b/doc/todo/ACL.mdwn
index d40701d60..57979385d 100644
--- a/doc/todo/ACL.mdwn
+++ b/doc/todo/ACL.mdwn
@@ -76,3 +76,12 @@ Any idea when this is going to be finished? If you want, I am happy to beta tes
> Example of use to only allow two users to edit the tipjar page:
> locked_pages => 'tipjar and !(user(joey) or user(bob))',
> --[[Joey]]
+
+> > Thank you for the hint but I am being still confused (read: dense)... What I am trying to do is this:
+
+> > * No anonymous access.
+> > * Logged in users can edit and create pages.
+> > * Users can set who can edit their pages.
+> > * Some pages are only viewable by admins.
+
+> > Is it possible? If so how?...
--
cgit v1.2.3
From ea07442e7ac6ef80cd98625b32f66bafc6af26b5 Mon Sep 17 00:00:00 2001
From: Jon Dowland
Date: Thu, 18 Mar 2010 15:21:38 +0000
Subject: comment
---
doc/todo/ACL.mdwn | 5 +++++
1 file changed, 5 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/ACL.mdwn b/doc/todo/ACL.mdwn
index 57979385d..c1f5d86f0 100644
--- a/doc/todo/ACL.mdwn
+++ b/doc/todo/ACL.mdwn
@@ -21,6 +21,11 @@ something, that I think is very valuable.
>>>> Which would rule out openid, or other fun forms of auth. And routing all access
>>>> through the CGI sort of defeats the purpose of ikiwiki. --[[Ethan]]
+>>>>> I think what Joey is suggesting is to use apache ACLs in conjunction
+>>>>> with basic HTTP auth to control read access, and ikiwiki can use the
+>>>>> information via the httpauth plugin for other ACLs (write, admin). But
+>>>>> yes, that would rule out non-httpauth mechanisms. -- [[Jon]]
+
Also see [[!debbug 443346]].
> Just a few quick thoughts about this:
--
cgit v1.2.3
From 760c315589dc0e3fa0ba5380113f4e86a989a7d9 Mon Sep 17 00:00:00 2001
From: Jon Dowland
Date: Thu, 18 Mar 2010 15:23:18 +0000
Subject: comment
---
doc/todo/ACL.mdwn | 3 +++
1 file changed, 3 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/ACL.mdwn b/doc/todo/ACL.mdwn
index c1f5d86f0..cac6c9f18 100644
--- a/doc/todo/ACL.mdwn
+++ b/doc/todo/ACL.mdwn
@@ -90,3 +90,6 @@ Any idea when this is going to be finished? If you want, I am happy to beta tes
> > * Some pages are only viewable by admins.
> > Is it possible? If so how?...
+
+>>> I don't believe this is currently possible. What is missing is the concept
+>>> of page 'ownership'. -- [[Jon]]
--
cgit v1.2.3
From 96a54b35fe2cdcdc1450b5d38c80e7b27b428c14 Mon Sep 17 00:00:00 2001
From: kierun
Date: Fri, 19 Mar 2010 15:45:26 +0000
Subject:
---
doc/todo/ACL.mdwn | 3 +++
1 file changed, 3 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/ACL.mdwn b/doc/todo/ACL.mdwn
index cac6c9f18..dd9793233 100644
--- a/doc/todo/ACL.mdwn
+++ b/doc/todo/ACL.mdwn
@@ -93,3 +93,6 @@ Any idea when this is going to be finished? If you want, I am happy to beta tes
>>> I don't believe this is currently possible. What is missing is the concept
>>> of page 'ownership'. -- [[Jon]]
+
+>>>> GAH! That is really a shame... Any chance of adding that? No, I do not really expect it to be added, after all my requirements are pushing the boundary of what a wikiwiki
+ should be. Nonetheless, thanks for your help!
--
cgit v1.2.3
From 1c7d5eabd7c9e94498af7f89a005311a850d742c Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/"
Date: Wed, 24 Mar 2010 03:24:15 +0000
Subject: propsed branch
---
doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 47 ++++++++++++++++++++++
1 file changed, 47 insertions(+)
create mode 100644 doc/todo/allow_plugins_to_add_sorting_methods.mdwn
(limited to 'doc/todo')
diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
new file mode 100644
index 000000000..3aa1d94a6
--- /dev/null
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -0,0 +1,47 @@
+[[!template id=gitbranch branch=smcv/sort-hooks author="[[Simon_McVittie|smcv]]"]]
+[[!tag patch]]
+
+The available [[ikiwiki/pagespec/sorting]] methods are currently hard-coded in
+IkiWiki.pm, making it difficult to add any extra sorting mechanisms. I've
+prepared a branch which adds 'sort' as a hook type and uses it to implement a
+new `meta_title` sort type.
+
+Someone could use this hook to make `\[[!inline sort=title]]` prefer the meta
+title over the page name, but for compatibility, I'm not going to (I do wonder
+whether it would be worth making sort=name an alias for the current sort=title,
+and changing the meaning of sort=title in 4.0, though).
+
+Gitweb:
+
+
+## Documentation extracted from the branch
+
+### sort hook (added to [[plugins/write]])
+
+ hook(type => "sort", id => "foo", call => \&sort_by_foo);
+
+This hook adds an additional [[ikiwiki/pagespec/sorting]] order or overrides
+an existing one. The callback is given two page names as arguments, and
+returns negative, zero or positive if the first page should come before,
+close to (i.e. undefined order), or after the second page.
+
+For instance, the built-in `title` sort order could be reimplemented as
+
+ sub sort_by_title {
+ pagetitle(basename($_[0])) cmp pagetitle(basename($_[1]));
+ }
+
+### meta_title sort order (conditionally added to [[ikiwiki/pagespec/sorting]])
+
+* `meta_title` - Order according to the `\[[!meta title="foo" sort="bar"]]`
+ or `\[[!meta title="foo"]]` [[ikiwiki/directive]], or the page name if no
+ full title was set.
+
+### meta title sort parameter (added to [[ikiwiki/directive/meta]])
+
+An optional `sort` parameter will be used preferentially when
+[[ikiwiki/pagespec/sorting]] by `meta_title`:
+
+ \[[!meta title="The Beatles" sort="Beatles, The"]]
+
+ \[[!meta title="David Bowie" sort="Bowie, David"]]
--
cgit v1.2.3
From 7fbddb032ee952c6d0b1ee290568ea4f42ef181f Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/"
Date: Wed, 24 Mar 2010 03:27:11 +0000
Subject: link to an alternative approach that I decided against
---
doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 6 ++++++
1 file changed, 6 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 3aa1d94a6..1533b6c44 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -14,6 +14,12 @@ and changing the meaning of sort=title in 4.0, though).
Gitweb:
+I briefly tried to turn *all* the current sort types into hook functions, and
+have some of them pre-registered, but decided that probably wasn't a good idea.
+That earlier version of the branch is also available for comparison:
+
+
+
## Documentation extracted from the branch
### sort hook (added to [[plugins/write]])
--
cgit v1.2.3
From 48c09d44637dd724d084b1d06e2277f11e80d489 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/"
Date: Wed, 24 Mar 2010 03:30:06 +0000
Subject: note: old version untested
---
doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 5 +++++
1 file changed, 5 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 1533b6c44..99f256fbe 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -20,6 +20,11 @@ That earlier version of the branch is also available for comparison:
+(The older version is untested, and probably doesn't really work as-is - I
+misunderstood the details of how the built-in function `sort` works when using
+`$a` and `$b`. The newer version has been tested, and has a regression test for
+its core functionality.)
+
## Documentation extracted from the branch
### sort hook (added to [[plugins/write]])
--
cgit v1.2.3
From 9d4bedf760fbbbdba28986c01c3e429f67386217 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/"
Date: Wed, 24 Mar 2010 17:11:17 +0000
Subject: relationship with [[plugins/contrib/report]]
---
doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 15 +++++++++++++++
1 file changed, 15 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 99f256fbe..21800f4de 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -25,6 +25,21 @@ misunderstood the details of how the built-in function `sort` works when using
`$a` and `$b`. The newer version has been tested, and has a regression test for
its core functionality.)
+This hook *isn't* (yet) sufficient to implement [[plugins/contrib/report]]'s
+NIH'd sorting mechanisms:
+
+* `report` can sort by any [[plugins/contrib/field]], whereas this one has a
+ finite number of hooks: if the `field` plugin's functionality is desirable,
+ perhaps parameterized sort mechanisms similar to pagespec match functions
+ would be useful? Then the `field` plugin could register
+ `hook(type => "sort", id => "field")` and you could have
+ `\[[!inline ... sort="field(Mood)"]]` or something?
+
+* `report` can sort by multiple criteria, with independent direction-changing:
+ if this is desirable, perhaps `pagespec_match_list` could be enhanced to
+ interpret `sort="x -y z(w)"` as sorting by (pseudocode)
+ `{ $cmp_x->($a, $b) || (-$cmp_y->($a, $b)) || $cmp_z->($a, $b, "w") }`?
+
## Documentation extracted from the branch
### sort hook (added to [[plugins/write]])
--
cgit v1.2.3
From 1a587504e949bf0584acdf7737597c8332467332 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
Date: Wed, 24 Mar 2010 22:48:47 +0000
Subject: what about a SortSpec rather than a sort-hook?
---
doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 2 ++
1 file changed, 2 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 21800f4de..5bfe102ac 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -40,6 +40,8 @@ NIH'd sorting mechanisms:
interpret `sort="x -y z(w)"` as sorting by (pseudocode)
`{ $cmp_x->($a, $b) || (-$cmp_y->($a, $b)) || $cmp_z->($a, $b, "w") }`?
+>> I wonder if IkiWiki would benefit from the concept of a "sortspec", like a [[ikiwiki/PageSpec]] but dedicated to sorting lists of pages rather than defining lists of pages? Rather than defining a sort-hook, define a SortSpec class, and enable people to add their own sort methods as functions defined inside that class, similarly to the way they can add their own pagespec definitions. --[[KathrynAndersen]]
+
## Documentation extracted from the branch
### sort hook (added to [[plugins/write]])
--
cgit v1.2.3
From 81cd30690024db1fc0b300e3a09504f1c613be21 Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Thu, 25 Mar 2010 00:05:58 +0000
Subject: an updated branch
---
doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 29 +++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 5bfe102ac..419a73419 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -40,8 +40,13 @@ NIH'd sorting mechanisms:
interpret `sort="x -y z(w)"` as sorting by (pseudocode)
`{ $cmp_x->($a, $b) || (-$cmp_y->($a, $b)) || $cmp_z->($a, $b, "w") }`?
+> I've now added both of these features to the sort-hooks branch. --[[smcv]]
+
>> I wonder if IkiWiki would benefit from the concept of a "sortspec", like a [[ikiwiki/PageSpec]] but dedicated to sorting lists of pages rather than defining lists of pages? Rather than defining a sort-hook, define a SortSpec class, and enable people to add their own sort methods as functions defined inside that class, similarly to the way they can add their own pagespec definitions. --[[KathrynAndersen]]
+>>> I'd be inclined to think that's overkill, but it probably wouldn't be
+>>> all that hard to implement... Joey? Any thoughts? --s
+
## Documentation extracted from the branch
### sort hook (added to [[plugins/write]])
@@ -49,7 +54,9 @@ NIH'd sorting mechanisms:
hook(type => "sort", id => "foo", call => \&sort_by_foo);
This hook adds an additional [[ikiwiki/pagespec/sorting]] order or overrides
-an existing one. The callback is given two page names as arguments, and
+an existing one.
+
+The callback is given two page names followed by the parameter as arguments, and
returns negative, zero or positive if the first page should come before,
close to (i.e. undefined order), or after the second page.
@@ -59,12 +66,32 @@ For instance, the built-in `title` sort order could be reimplemented as
pagetitle(basename($_[0])) cmp pagetitle(basename($_[1]));
}
+and to sort by an arbitrary `meta` value, you could use:
+
+ # usage: sort="meta(description)"
+ sub sort_by_meta {
+ my $param = $_[2];
+ error "sort=meta requires a parameter" unless defined $param;
+ my $left = $pagestate{$_[0]}{meta}{$param};
+ $left = "" unless defined $left;
+ my $right = $pagestate{$_[1]}{meta}{$param};
+ $right = "" unless defined $right;
+ return $left cmp $right;
+ }
+
+
### meta_title sort order (conditionally added to [[ikiwiki/pagespec/sorting]])
* `meta_title` - Order according to the `\[[!meta title="foo" sort="bar"]]`
or `\[[!meta title="foo"]]` [[ikiwiki/directive]], or the page name if no
full title was set.
+### Multiple sort orders (added to [[ikiwiki/pagespec/sorting]])
+
+In addition, you can combine several sort orders and/or reverse the order of
+sorting, with a string like `age -title` (which would sort by age, then by
+title in reverse order if two pages have the same age).
+
### meta title sort parameter (added to [[ikiwiki/directive/meta]])
An optional `sort` parameter will be used preferentially when
--
cgit v1.2.3
From 959d5b197d842e494076034f89d7bca84e531a45 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/"
Date: Thu, 25 Mar 2010 23:39:45 +0000
Subject: an alternative way to do plugins, as rubykat suggested
---
doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 37 ++++++++++++++++++++--
1 file changed, 34 insertions(+), 3 deletions(-)
(limited to 'doc/todo')
diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 419a73419..f37a0758e 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -44,10 +44,13 @@ NIH'd sorting mechanisms:
>> I wonder if IkiWiki would benefit from the concept of a "sortspec", like a [[ikiwiki/PageSpec]] but dedicated to sorting lists of pages rather than defining lists of pages? Rather than defining a sort-hook, define a SortSpec class, and enable people to add their own sort methods as functions defined inside that class, similarly to the way they can add their own pagespec definitions. --[[KathrynAndersen]]
->>> I'd be inclined to think that's overkill, but it probably wouldn't be
->>> all that hard to implement... Joey? Any thoughts? --s
+>>> [[!template id=gitbranch branch=smcv/sort-package author="[[Simon_McVittie|smcv]]"]]
+>>> I'd be inclined to think that's overkill, but it wasn't very hard to
+>>> implement, and in a way is more elegant. I set it up so sort mechanisms
+>>> share the `IkiWiki::PageSpec` package, but with a `cmp_` prefix. Gitweb:
+>>>
-## Documentation extracted from the branch
+## Documentation from sort-hooks branch
### sort hook (added to [[plugins/write]])
@@ -100,3 +103,31 @@ An optional `sort` parameter will be used preferentially when
\[[!meta title="The Beatles" sort="Beatles, The"]]
\[[!meta title="David Bowie" sort="Bowie, David"]]
+
+## Documentation from sort-hooks branch
+
+The changes to [[ikiwiki/pagespec/sorting]] are the same.
+The changes to [[plugins/write]] are replaced by:
+
+### Sorting plugins
+
+Similarly, it's possible to write plugins that add new functions as
+[[ikiwiki/pagespec/sorting]] methods. To achieve this, add a function to
+the IkiWiki::PageSpec package named `cmp_foo`, which will be used when sorting
+by `foo` or `foo(...)` is requested.
+
+The function will be passed three or more parameters. The first two are
+page names, and the third is `undef` if invoked as `foo`, or the parameter
+`"bar"` if invoked as `foo(bar)`. It may also be passed additional, named
+parameters.
+
+It should return the same thing as Perl's `cmp` and `<=>` operators: negative
+if the first argument is less than the second, positive if the first argument
+is greater, or zero if they are considered equal. It may also raise an
+error using `error`, for instance if it needs a parameter but one isn't
+provided.
+
+You can also define a function called `check_cmp_foo` in the same package.
+If you do, it will be called while preparing to sort by `foo` or `foo(bar)`,
+with argument `undef` or `"bar"` respectively; it may raise an error using
+`error`, if sorting like that isn't going to work.
--
cgit v1.2.3
From 263d9548969dcdf9a6add96f46fe03ba7701a1ca Mon Sep 17 00:00:00 2001
From: Jon Dowland
Date: Mon, 29 Mar 2010 14:58:21 +0100
Subject: ping joey: consider patch for next release?
---
doc/todo/allow_site-wide_meta_definitions.mdwn | 2 ++
1 file changed, 2 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn
index 99a9cf1e2..be66db99d 100644
--- a/doc/todo/allow_site-wide_meta_definitions.mdwn
+++ b/doc/todo/allow_site-wide_meta_definitions.mdwn
@@ -183,3 +183,5 @@ definitions essentially.
>>> ikiwiki for the break, and now I've returned to watching recentchanges.
>>> Hopefully I'll be back in the mix soon, too. In the meantime, Joey, have
>>> you had a chance to look at this yet? -- [[Jon]]
+>>>> Ping :) Hi. [[Joey]], would you consider this patch for the next
+>>>> ikiwiki release? -- [[Jon]]
--
cgit v1.2.3
From 97898ce585b36dbcb0a83356ef3e54c41d369437 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Mon, 29 Mar 2010 12:16:53 -0400
Subject: review, multiple concerns
---
doc/todo/allow_site-wide_meta_definitions.mdwn | 46 ++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn
index 99a9cf1e2..e4638f94b 100644
--- a/doc/todo/allow_site-wide_meta_definitions.mdwn
+++ b/doc/todo/allow_site-wide_meta_definitions.mdwn
@@ -36,6 +36,30 @@ definitions essentially.
>> I've made may not be acceptable, though -- I'd appreciate someone providing
>> some feedback on that hunk!
+>>> Well, re that hunk, taint checking is currently disabled, but
+>>> if the perl bug that disallows it is fixed and it is turned back on,
+>>> the hash values will remain tainted, which will probably lead to
+>>> problems.
+>>>
+>>> I'm also leery of using such a complex data structure in config.
+>>> The websetup plugin would be hard pressed to provide a UI for such a
+>>> data structure. (It lacks even UI for a single hash ref yet, let alone
+>>> a list.)
+>>>
+>>> Also, it seems sorta wrong to have two so very different syntaxes to
+>>> represent the same meta data. A user without a lot of experience will
+>>> be hard pressed to map from a directive to this in the setup file.
+>>>
+>>> All of which leads me to think the setup file could just contain
+>>> a text that could hold meta directives. Which generalizes really to
+>>> a text that contains any directives, and is, perhaps appended to the
+>>> top of every page. Which nearly generalizes to the sidebar plugin,
+>>> or perhaps something more general than that...
+>>>
+>>> However, excessive generalization is the root of all evil, so
+>>> I'm not necessarily saying that's a good idea. Indeed, my memory
+>>> concerns below invalidate this idea pretty well. --[[Joey]]
+
diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm
index 6fe9cda..2f8c098 100644
--- a/IkiWiki/Plugin/meta.pm
@@ -125,6 +149,10 @@ definitions essentially.
>> are only relevant to defined fields that you wouldn't want to specify a
>> global default for anyway.
>>
+>>> I generally agree with this. It is *possible* that meta would have a new
+>>> field added, that takes parameters and make sense to use globally.
+>>> --[[Joey]]
+>>
>> Due to this, and the added complexity of the second patch (having to adjust
>> `IkiWiki/Setup.pm`), I think the first patch makes more sense. I've thus
>> reverted to it here.
@@ -183,3 +211,21 @@ definitions essentially.
>>> ikiwiki for the break, and now I've returned to watching recentchanges.
>>> Hopefully I'll be back in the mix soon, too. In the meantime, Joey, have
>>> you had a chance to look at this yet? -- [[Jon]]
+
+>>> For this to work with websetup and --dumpsetup, it needs to define the
+>>> `meta_*` settings in the getsetup function.
+>>>
+>>> I also have some concerns about both these patches, since both throw
+>>> a lot of redundant data at meta, which then stores it in a very redundant
+>>> way. Specifically, meta populates a per-page `%metaheaders` hash
+>>> as well as storing per-page metadata in `%pagestate`. So, if you have
+>>> a wiki with a thousand pages, and you add a 1k site-wide license text,
+>>> that will bloat the memory usage of ikiwiki by in excess of 2
+>>> megabytes. It will also cause ikiwiki to write a similar amount more data
+>>> to its state file which has to be loaded back in each
+>>> run.
+>>>
+>>> Seems that this could be managed much more efficiently by having
+>>> meta special-case the site-wide settings, not store them in these
+>>> per-page data structures, and just make them be used if no per-page
+>>> metadata of the given type is present. --[[Joey]]
--
cgit v1.2.3
From 7a8bcf2a6745d570bf9055df7b0390f9a9ca8a0d Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Mon, 29 Mar 2010 12:19:22 -0400
Subject: fix bogus math
---
doc/todo/allow_site-wide_meta_definitions.mdwn | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn
index 704cb2c64..01cf12c1a 100644
--- a/doc/todo/allow_site-wide_meta_definitions.mdwn
+++ b/doc/todo/allow_site-wide_meta_definitions.mdwn
@@ -222,7 +222,7 @@ definitions essentially.
>>> a lot of redundant data at meta, which then stores it in a very redundant
>>> way. Specifically, meta populates a per-page `%metaheaders` hash
>>> as well as storing per-page metadata in `%pagestate`. So, if you have
->>> a wiki with a thousand pages, and you add a 1k site-wide license text,
+>>> a wiki with 10 thousand pages, and you add a 1k site-wide license text,
>>> that will bloat the memory usage of ikiwiki by in excess of 2
>>> megabytes. It will also cause ikiwiki to write a similar amount more data
>>> to its state file which has to be loaded back in each
--
cgit v1.2.3
From 675e34527f56021ce39e56e4288e8f0e32b36cfa Mon Sep 17 00:00:00 2001
From: Jon Dowland
Date: Mon, 29 Mar 2010 19:59:40 +0100
Subject: thanks for the review, patch to be revised
---
doc/todo/allow_site-wide_meta_definitions.mdwn | 3 +++
1 file changed, 3 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn
index 01cf12c1a..7129a44ac 100644
--- a/doc/todo/allow_site-wide_meta_definitions.mdwn
+++ b/doc/todo/allow_site-wide_meta_definitions.mdwn
@@ -232,3 +232,6 @@ definitions essentially.
>>> meta special-case the site-wide settings, not store them in these
>>> per-page data structures, and just make them be used if no per-page
>>> metadata of the given type is present. --[[Joey]]
+
+>>>> Thanks for the review - these are all valid points. I'll get working
+>>>> on a revised patch. -- [[Jon]]
--
cgit v1.2.3
From 0b63800df32fd6e5287a253ca01a099f79b77e6e Mon Sep 17 00:00:00 2001
From: Jon Dowland
Date: Mon, 29 Mar 2010 20:00:56 +0100
Subject: this sounds like the correct approach
---
doc/todo/more_flexible_inline_postform.mdwn | 5 +++++
1 file changed, 5 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/more_flexible_inline_postform.mdwn b/doc/todo/more_flexible_inline_postform.mdwn
index bc8bc0809..414476bd7 100644
--- a/doc/todo/more_flexible_inline_postform.mdwn
+++ b/doc/todo/more_flexible_inline_postform.mdwn
@@ -16,3 +16,8 @@ logical first step towards doing comment-like things with inlined pages).
> Perhaps what we need is a `postform` plugin/directive that inline depends
> on (automatically enables); its preprocess method could automatically be
> invoked from preprocess_inline when needed. --[[smcv]]
+
+>> I've been looking at this stuff again. I think you are right, this would
+>> be the right approach. The comments plugin could use it similarly, allowing
+>> sites which desire it to have an inline comment submission form on all
+>> pages with comments enabled. I'm going to take a look. -- [[Jon]]
--
cgit v1.2.3
From f673ce266c8dadb263c6850cc5f7d3e6e7a68e70 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/"
Date: Tue, 30 Mar 2010 12:01:35 +0000
Subject: feature request (part of ftemplate)
---
doc/todo/user-defined_templates_outside_the_wiki.mdwn | 8 ++++++++
1 file changed, 8 insertions(+)
create mode 100644 doc/todo/user-defined_templates_outside_the_wiki.mdwn
(limited to 'doc/todo')
diff --git a/doc/todo/user-defined_templates_outside_the_wiki.mdwn b/doc/todo/user-defined_templates_outside_the_wiki.mdwn
new file mode 100644
index 000000000..880ad6493
--- /dev/null
+++ b/doc/todo/user-defined_templates_outside_the_wiki.mdwn
@@ -0,0 +1,8 @@
+[[!tag wishlist]]
+
+The [[plugins/contrib/ftemplate]] plugin looks for templates inside the wiki
+source, but also looks in the system templates directory (the one with
+`page.tmpl`). This means the wiki admin can provide templates that can be
+invoked via `\[[!template]]`, but don't have to "work" as wiki pages in their
+own right. I think the normal [[plugins/template]] plugin could benefit from
+this functionality.
--
cgit v1.2.3
From a7ef2204dc36777f847e282f57299d93342a8ad6 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/"
Date: Thu, 1 Apr 2010 23:40:37 +0000
Subject: implemented!
---
doc/todo/matching_different_kinds_of_links.mdwn | 51 +++++++++++++++++++++++++
1 file changed, 51 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 26c5a072b..0049281fe 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -36,6 +36,11 @@ Besides pagespecs, the `rel=` attribute could be used for styles. --Ivan Z.
> normal links.) Might be better to go ahead and add the variable to
> core though. --[[Joey]]
+>> I've implemented this with the data structure you suggested, except that
+>> I called it `%typedlinks` instead of `%linktype` (it seemed to make more
+>> sense that way). I also ported `tag` to it, and added a `tagged_is_strict`
+>> config option. See below! --[[smcv]]
+
I saw somewhere else here some suggestions for the wiki-syntax for specifying the relation name of a link. One more suggestion---[the syntax used in Semantic MediaWiki](http://en.wikipedia.org/wiki/Semantic_MediaWiki#Basic_usage), like this:
@@ -45,3 +50,49 @@ I saw somewhere else here some suggestions for the wiki-syntax for specifying th
So a part of the effect of [[`\[[!taglink TAG\]\]`|plugins/tag]] could be represented as something like `\[[tag::TAG]]` or (more understandable relation name in what concerns the direction) `\[[tagged::TAG]]`.
I don't have any opinion on this syntax (whether it's good or not)...--Ivan Z.
+
+-------
+
+>> [[!template id=gitbranch author="[[Simon_McVittie|smcv]]" branch=smcv/link-types]]
+>> [[!tag patch]]
+
+## Documentation for smcv's branch
+
+### added to [[ikiwiki/pagespec]]
+
+* "`typedlink(type glob)`" - matches pages that link to a given page (or glob)
+ with a given link type. Plugins can create links with a specific type:
+ for instance, the tag plugin creates links of type `tag`.
+
+### added to [[plugins/tag]]
+
+If the `tagged_is_strict` config option is set, `tagged()` will only match
+tags explicitly set with [[ikiwiki/directive/tag]] or
+[[ikiwiki/directive/taglink]]; if not (the default), it will also match
+any other [[WikiLinks|ikiwiki/WikiLink]] to the tag page.
+
+### added to [[plugins/write]]
+
+#### `%typedlinks`
+
+The `%typedlinks` hash records links of specific types. Do not modify this
+hash directly; call `add_link()`. The keys are page names, and the values
+are hash references. In each page's hash reference, the keys are link types
+defined by plugins, and the values are hash references with link targets
+as keys, and 1 as a dummy value, something like this:
+
+ $typedlinks{"foo"} = {
+ tag => { short_word => 1, metasyntactic_variable => 1 },
+ next_page => { bar => 1 },
+ };
+
+Ordinary [[WikiLinks|ikiwiki/WikiLink]] appear in `%links`, but not in
+`%typedlinks`.
+
+#### `add_link($$;$)`
+
+ This adds a link to `%links`, ensuring that duplicate links are not
+ added. Pass it the page that contains the link, and the link text.
+
+An optional third parameter sets the link type (`undef` produces an ordinary
+[[ikiwiki/WikiLink]]).
--
cgit v1.2.3
From 1c8ac7d88c5a3d2c63892737e54be8a1b535936c Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Fri, 2 Apr 2010 16:41:04 -0400
Subject: review from the woods
---
doc/todo/matching_different_kinds_of_links.mdwn | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 0049281fe..20acdde49 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -96,3 +96,22 @@ Ordinary [[WikiLinks|ikiwiki/WikiLink]] appear in `%links`, but not in
An optional third parameter sets the link type (`undef` produces an ordinary
[[ikiwiki/WikiLink]]).
+
+> Some code refers to `oldtypedlinks`, and other to `oldlinktypes`.
+>
+> I'm curious what your reasoning was for adding a new variable
+> rather than using `pagestate`. Was it only because you needed
+> the `old` version to detect change, or was there other complexity?
+>
+> I have not convinced myself this is a real problem, but..
+> If a page has a typed link, there seems to be no way to tell
+> if it also has a separate, regular link. `add_link` will add
+> to `@links` when adding a typed, or untyped link. If only untyped
+> links were recorded there, one could tell the difference. But then
+> typed links would not show up at all in eg, a linkmap,
+> unless it was changed to check for typed links too.
+> (Or, regular links could be recorded in typedlinks too,
+> with a empty type. (Bloaty.))
+>
+> I suspect we could get away without having `tagged_is_strict`
+> without too much transitional trouble. --[[Joey]]
--
cgit v1.2.3
From 59ba938822ba0752e8d97e769c0d14f2eb0bbeb3 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Fri, 2 Apr 2010 16:54:06 -0400
Subject: template: Search for templates in the templatedir, if they are not
found as pages in the wiki.
---
IkiWiki/Plugin/template.pm | 10 ++++++++--
debian/changelog | 2 ++
doc/templates.mdwn | 6 ++++++
doc/todo/user-defined_templates_outside_the_wiki.mdwn | 2 ++
doc/wikitemplates.mdwn | 6 ++++--
5 files changed, 22 insertions(+), 4 deletions(-)
(limited to 'doc/todo')
diff --git a/IkiWiki/Plugin/template.pm b/IkiWiki/Plugin/template.pm
index 3e024c5f8..36282055a 100644
--- a/IkiWiki/Plugin/template.pm
+++ b/IkiWiki/Plugin/template.pm
@@ -37,7 +37,13 @@ sub preprocess (@) {
my $template_page="templates/$params{id}";
add_depends($params{page}, $template_page);
- my $template_file=$pagesources{$template_page};
+ my $template_file;
+ if (exists $pagesources{$template_page}) {
+ $template_file=srcfile($pagesources{$template_page});
+ }
+ else {
+ $template_file=template_file("$params{id}.tmpl")
+ }
return sprintf(gettext("template %s not found"),
htmllink($params{page}, $params{destpage}, "/".$template_page))
unless defined $template_file;
@@ -50,7 +56,7 @@ sub preprocess (@) {
$$text_ref=&Encode::decode_utf8($$text_ref);
chomp $$text_ref;
},
- filename => srcfile($template_file),
+ filename => $template_file,
die_on_bad_params => 0,
no_includes => 1,
blind_cache => 1,
diff --git a/debian/changelog b/debian/changelog
index adf0dfed6..362ba54ab 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -26,6 +26,8 @@ ikiwiki (3.20100324) UNRELEASED; urgency=low
* page.tmpl: Add Cache-Control must-revalidate to ensure that users
(especially of Firefox) see fresh page content.
* htmlscrubber: Allow colons in urls after '?'
+ * template: Search for templates in the templatedir, if they are not
+ found as pages in the wiki.
-- Joey Hess Sat, 13 Mar 2010 14:48:10 -0500
diff --git a/doc/templates.mdwn b/doc/templates.mdwn
index eff0e15e9..07531ae98 100644
--- a/doc/templates.mdwn
+++ b/doc/templates.mdwn
@@ -43,6 +43,12 @@ page will provide a link that can be used to create the template. The template
is a regular wiki page, located in the `templates/` subdirectory inside
the source directory of the wiki.
+(Alternatively, templates can be stored in a directory outside the wiki,
+as files with the extension ".tmpl".
+By default, these are searched for in `/usr/share/ikiwiki/templates`;
+the `templatedir` setting can be used to make another directory be searched
+first.)
+
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
documentation for the full syntax, but all you really need to know are a
diff --git a/doc/todo/user-defined_templates_outside_the_wiki.mdwn b/doc/todo/user-defined_templates_outside_the_wiki.mdwn
index 880ad6493..1d72aa6a7 100644
--- a/doc/todo/user-defined_templates_outside_the_wiki.mdwn
+++ b/doc/todo/user-defined_templates_outside_the_wiki.mdwn
@@ -6,3 +6,5 @@ source, but also looks in the system templates directory (the one with
invoked via `\[[!template]]`, but don't have to "work" as wiki pages in their
own right. I think the normal [[plugins/template]] plugin could benefit from
this functionality.
+
+[[done]] --[[Joey]]
diff --git a/doc/wikitemplates.mdwn b/doc/wikitemplates.mdwn
index 6c0480cea..6e5a7261d 100644
--- a/doc/wikitemplates.mdwn
+++ b/doc/wikitemplates.mdwn
@@ -5,7 +5,8 @@ to learn.
The aim is to keep almost all html out of ikiwiki and in the templates.
It ships with some basic templates which can be customised. These are
-located in /usr/share/ikiwiki/templates by default.
+located in `/usr/share/ikiwiki/templates` by default; the `templatedir`
+setting can be used to make another directory be searched first.
* `page.tmpl` - Used for displaying all regular wiki pages.
* `misc.tmpl` - Generic template used for any page that doesn't
@@ -43,7 +44,8 @@ The [[plugins/pagetemplate]] plugin can allow individual pages to use a
different template than `page.tmpl`.
The [[plugins/template]] plugin also uses templates, though those
-[[templates]] are stored in the wiki and inserted into pages.
+[[templates]] are typically stored as pages in the wiki, and are inserted
+into pages.
The [[plugins/edittemplate]] plugin is used to make new pages default to
containing text from a template, which can be filled as out the page is
--
cgit v1.2.3
From de62ea1cc8111dd96bc84b9c839be99c921168e3 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Fri, 2 Apr 2010 17:03:33 -0400
Subject: fix branch name
---
doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'doc/todo')
diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index f37a0758e..8edc95fb9 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -104,7 +104,7 @@ An optional `sort` parameter will be used preferentially when
\[[!meta title="David Bowie" sort="Bowie, David"]]
-## Documentation from sort-hooks branch
+## Documentation from sort-package branch
The changes to [[ikiwiki/pagespec/sorting]] are the same.
The changes to [[plugins/write]] are replaced by:
--
cgit v1.2.3
From 1b0d4e8d885ded59ca0ad1b4d1ca1315585cce06 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Fri, 2 Apr 2010 17:16:12 -0400
Subject: minor comment
---
doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 3 +++
1 file changed, 3 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 8edc95fb9..e4e1829dc 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -89,6 +89,9 @@ and to sort by an arbitrary `meta` value, you could use:
or `\[[!meta title="foo"]]` [[ikiwiki/directive]], or the page name if no
full title was set.
+ > I feel it sould be clearer to call that "sortas", since "sort=" is used
+ > to specify a sort method in other directives. --[[Joey]]
+
### Multiple sort orders (added to [[ikiwiki/pagespec/sorting]])
In addition, you can combine several sort orders and/or reverse the order of
--
cgit v1.2.3
From 9e7dcefd7ed9424de20706f63c7bab5182c5df78 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Fri, 2 Apr 2010 17:26:32 -0400
Subject: comments
---
doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 15 +++++++++++++++
1 file changed, 15 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index e4e1829dc..67d85f6f8 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -50,6 +50,21 @@ NIH'd sorting mechanisms:
>>> share the `IkiWiki::PageSpec` package, but with a `cmp_` prefix. Gitweb:
>>>
+>>>> I agree it seems more elegant, so I have focused on it.
+>>>>
+>>>> I don't know about reusing `IkiWiki::PageSpec` for this.
+>>>>
+>>>> I would be inclined to drop the `check_` stuff.
+>>>>
+>>>> Wouldn't it make sense to have `meta(title)` instead
+>>>> of `meta_title`?
+>>>>
+>>>> As I read the regexp in `cmpspec_translate`, the "command"
+>>>> is required to have params. They should be optional,
+>>>> to match the documentation and because most sort methods
+>>>> do not need parameters.
+>>>> --[[Joey]]
+
## Documentation from sort-hooks branch
### sort hook (added to [[plugins/write]])
--
cgit v1.2.3
From 1faf9b08e16bde9b4b0d72620fcef79c715e64de Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Fri, 2 Apr 2010 17:37:38 -0400
Subject: idea
---
doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 8 ++++++++
1 file changed, 8 insertions(+)
(limited to 'doc/todo')
diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 67d85f6f8..e1e05e81c 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -63,6 +63,14 @@ NIH'd sorting mechanisms:
>>>> is required to have params. They should be optional,
>>>> to match the documentation and because most sort methods
>>>> do not need parameters.
+>>>>
+>>>> I wonder if it would make sense to add some combining keywords, so
+>>>> a sortspec reads like `sort="age then ascending title"`
+>>>> In a way, this reduces the amount of syntax that needs to be learned.
+>>>> I like the "then" (and it could allow other operations than
+>>>> simple combination, if any others make sense). Not so sure about the
+>>>> "ascending", which could be "reverse" instead, but "descending age" and
+>>>> "ascending age" both seem useful to be able to explicitly specify.
>>>> --[[Joey]]
## Documentation from sort-hooks branch
--
cgit v1.2.3
From 2c7fe7ae2cf73141eba817d4275d9a6a897df8a8 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/"
Date: Fri, 2 Apr 2010 22:25:16 +0000
Subject: respond (also unindent Joey's review to avoid very deep indentation)
---
doc/todo/matching_different_kinds_of_links.mdwn | 61 +++++++++++++++++--------
1 file changed, 43 insertions(+), 18 deletions(-)
(limited to 'doc/todo')
diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 20acdde49..f8796652e 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -97,21 +97,46 @@ Ordinary [[WikiLinks|ikiwiki/WikiLink]] appear in `%links`, but not in
An optional third parameter sets the link type (`undef` produces an ordinary
[[ikiwiki/WikiLink]]).
-> Some code refers to `oldtypedlinks`, and other to `oldlinktypes`.
->
-> I'm curious what your reasoning was for adding a new variable
-> rather than using `pagestate`. Was it only because you needed
-> the `old` version to detect change, or was there other complexity?
->
-> I have not convinced myself this is a real problem, but..
-> If a page has a typed link, there seems to be no way to tell
-> if it also has a separate, regular link. `add_link` will add
-> to `@links` when adding a typed, or untyped link. If only untyped
-> links were recorded there, one could tell the difference. But then
-> typed links would not show up at all in eg, a linkmap,
-> unless it was changed to check for typed links too.
-> (Or, regular links could be recorded in typedlinks too,
-> with a empty type. (Bloaty.))
->
-> I suspect we could get away without having `tagged_is_strict`
-> without too much transitional trouble. --[[Joey]]
+## Review
+
+Some code refers to `oldtypedlinks`, and other to `oldlinktypes`. --[[Joey]]
+
+> Oops, I'll fix that. That must mean missing test coverage, too :-(
+> --s
+
+I'm curious what your reasoning was for adding a new variable
+rather than using `pagestate`. Was it only because you needed
+the `old` version to detect change, or was there other complexity?
+--J
+
+> You seemed to be more in favour of adding it to the core in
+> your proposal above, so I assumed that'd be more likely to be
+> accepted :-) I don't mind one way or the other - `%typedlinks`
+> costs one core variable, but saves one level of hash nesting. If
+> you're not sure either, then I think the decision should come down
+> to which one is easier to document clearly - I'm still unhappy with
+> my docs for `%typedlinks`, so I'll try to write docs for it as
+> `pagestate` and see if they work any better. --s
+
+I have not convinced myself this is a real problem, but..
+If a page has a typed link, there seems to be no way to tell
+if it also has a separate, regular link. `add_link` will add
+to `@links` when adding a typed, or untyped link. If only untyped
+links were recorded there, one could tell the difference. But then
+typed links would not show up at all in eg, a linkmap,
+unless it was changed to check for typed links too.
+(Or, regular links could be recorded in typedlinks too,
+with a empty type. (Bloaty.)) --J
+
+> I think I like the semantics as-is - I can't think of any
+> reason why you'd want to ask the question "does A link to B,
+> not counting tags and other typed links?". A typed link is
+> still a link, in my mind at least. --s
+
+I suspect we could get away without having `tagged_is_strict`
+without too much transitional trouble. --[[Joey]]
+
+> If you think so, I can delete about 5 LoC. I don't particularly
+> care either way; [[Jon]] expressed concern about people relying
+> on the current semantics, on one of the pages requesting this
+> change. --s
--
cgit v1.2.3
From 011fe920d162924876170d167be11dc64cf8be2f Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/"