]> sipb.mit.edu Git - ikiwiki.git/blob - doc/todo/comments.mdwn
todo/comments: Properly escape inline HTML
[ikiwiki.git] / doc / todo / comments.mdwn
1 # Known issues with the [[plugins/comments]] plugin
2
3 ## Unimplemented
4
5 * Previews always say "unknown IP address"
6
7 * Instead of just a link to add a comment, it could have a form to enter
8   the title, similar to the form for adding a new blog post.
9
10   > I'm not sure this is so useful? On Livejournal titles are allowed on
11   > comments, but very rarely used (and indeed usually not very useful);
12   > it's hard enough to get some people to title their blog posts :-)
13   > --[[smcv]]
14
15 * If a spammer posts a comment, it is either impossible or hard to clean
16   up via the web. Would be nice to have some kind of link on the comment
17   that allows trusted users to remove it (using the remove plugin of
18   course).
19
20   > Won't the remove plugin refuse to remove internal pages? This would be
21   > a good feature to have, though. --[[smcv]]
22
23 * Now that inline has some comments-specific functionality anyway, it would
24   be good to output `<link rel="comments">` in Atom and the equivalent in RSS.
25
26 ## Patches pending merge
27
28 * The default template should have a (?) icon next to unauthenticated users (with the IP address
29   as title) and an OpenID icon next to OpenIDs
30
31   > Done in my comments git branch, at least as a mockup (using the (?),
32   > {x} and {*} smileys for anonymous, OpenID and login respectively).
33   > --[[smcv]]
34
35   >> I've improved this to use independent icons from the wikiicons
36   >> directory (untested!) --[[smcv]]
37
38   >>> The new code produces links like /wikiisons/openid.png, which
39   >>> fail if ikiwiki is not at the root of the web server. --[[Joey]]
40
41   >>>> Sorry, I should have spotted that (the assumption failed on my demo
42   >>>> site, but the push to that site was when I was on the way out, so I
43   >>>> didn't have time to investigate). As a note for other ikiwiki hackers,
44   >>>> I should have used
45   >>>> `<img src="<TMPL_VAR NAME=BASEURL>wikiicons/openid.png" />`. --[[smcv]]
46
47   >>> I got to wondering if the icons are needed. On my comments branch
48   >>> (not master), I've dropped the icons and info can be seen by hovering
49   >>> over the author's name. Idea being that you probably don't care how
50   >>> they authenticated unless something is weird, and in that case you
51   >>> can hover to check. Does that make sense, should I merge it?
52   >>> --[[Joey]]
53
54   >>>> Yeah, go ahead. I preferred my layout with the author before the
55   >>>> comment - perhaps that's Livejournal's influence :-) - but I can always
56   >>>> edit the templates for my own site. As long as the default is something
57   >>>> reasonable and both layouts are possible, I don't really mind.
58   >>>> Minimizing the number of "resource" files in the basewiki also seems
59   >>>> a good goal. --[[smcv]]
60
61 ## Won't fix
62
63 * There is some common code cargo-culted from other plugins (notably inline and editpage) which
64   should probably be shared
65
66   > Actually, there's less of this now than there used to be - a lot of simple
67   > things that were shared have become unshareable as they became more
68   > complex. --[[smcv]]
69
70 * It would be useful to have a pagespec that always matches all comments on
71   pages matching a glob. Something like `comment(blog/*)`.
72   Perhaps postcomment could also be folded into this? Then the pagespec
73   would match both existing comments, as well as new comments that are
74   being posted.
75
76   > Please see [[plugins/comments/discussion]]. If I've convinced you that
77   > internal pages are the way forward, then sure, we can do that, because
78   > people who can comment still won't be able to edit others' comments
79   > (one of my goals is that commenters can't put words into each other's
80   > mouths :-) )
81   >
82   > On the other hand, if you still want me to switch this plugin to "real"
83   > pages, or if internal pages might become editable in future, then
84   > configuring lockedit/anonok so a user X can add comments to blog pages
85   > would also let X edit/delete comments on blog pages (including those
86   > written by others) in arbitrary ways, which doesn't seem good. --[[smcv]]
87
88   > I had a look at implementing comment() and fell afoul of
89   > some optimisations that assume only internal() will be used to match
90   > internal pages. So probably this isn't worth doing. --[[Joey]]
91
92 ## Done
93
94 * Add `COMMENTOPENID`: the authenticated/verified user name, if and only if it was an OpenID
95
96   > Done in my comments git branch --[[smcv]]
97
98   > Not seeing it there, which branch? --[[Joey]]
99
100   >> Bah, git push --all is not the default... 'comments' branch now (I've also rebased it).
101   >> Sorry, I'm on mobile Internet at the moment... --[[smcv]]
102
103   >>> merged by [[Joey]] in commit 0f03af38 --[[smcv]]
104
105 * Should the comments be visually set off more from the page above?
106   Rather than just a horizontal rule, I'm thinking put the comments
107   in a box like is used for inlined pages.
108
109   > I did put them in a box in the CSS... I agree the default template
110   > could do with visual improvement though. --[[smcv]]
111
112   >> I'll consider this solved by [[Joey]]'s changes. --[[smcv]]
113
114 * One can use inline to set up a feed of all comments posted to any page.
115   Using template=comment they are displayed right. Only problem
116   is there is no indication in that template of what page each comment in the
117   feed is a comment on. So, if a comment is inlined into a different page,
118   I think it should show a link back to the page commented on.
119   (BTW, the rss feed in this situation seems ok; there the link element
120   points back to the parent page.
121
122   > done --[[Joey]]
123
124 * One of Joey's commit messages says "Not ideal, it would be nicer to jump to
125   the actual comment posted, but no anchor is available". In fact there is
126   an anchor - the `\[[_comment]]` preprocessing wraps the comment in a `<div>`
127   with id="comment_123" or something. I'll fix this, unless Joey gets there
128   first. --[[smcv]]
129
130   > done --[[Joey]]