Comments system

Bloke · 2010-02-15 16:44:41

Taking input from various threads around the patch regarding comments, we seem to have a few opportunities:

Enable some of the comment tags as containers
Remove auto-append comments
Make comment_*_input / comment_remember / comment_preview / comment_submit tags into real tags and/or simplify the vast number of comment tags that are available
Reply to comments from the admin side (has been made as a plugin but could be implemented in the core if deemed necessary)
Some mechanism for automatically flagging (via an additional CSS class) the fact that the current comment is an author comment (based on e-mail address, I suppose?)
Indented (threaded/nested) comments (ok, that’s a plugin… is comment threading desirable in the core or should it remain plugin territory?)

And probably others.

I’ve just had a flick through publish/comment.php and can hardly make head nor tail of the logic. It’s just horrible, probably due to long-term feature creep and progressive enhancements that don’t gel with TXP as well as they could. Same goes for some of the comment prefs, which are often confusing.

One thing that has always bugged me is that the comment input tags aren’t customisable and you have to configure them all through the <txp:comments_form /> tag (isize, msgcols, msgrows, etc). So you can’t have an e-mail input field a different size to a name field, for example — might be useful in some languages.

Thing is, I’m not a huge user of comments so I don’t really know what’s important, what’s desirable and what makes sense for the core to do and where plugins should take over. This is where you all come in. I’d like to try and take stock of what’d actually be useful versus what’s just impractical or unimplementable, for whatever reason. e.g. I’m not qualified to figure whether completely removing the auto-append thing has an impact on usability or if simply turning it off by default is better.

Some thoughts off the top of my head, right or wrong:

Add one or more ‘true’ comment tags instead of the half-arsed versions we have now. This could be in the form of replacing the plethora of input tags with one ‘comment_input’ tag, e.g. <txp:comment_input type="name" />, <txp:comment_input type="email" />, <txp:comment_input type="preview" />, etc, and leaving the sizes of input widget as defined in the comments_form tag
Alternatively, keep the input tags as separate entities as they are now (though I’ve always thought it was confusing to have comments_preview and comment_preview being so closely named), make them real tags and offer some attributes to override the ‘default’ size values as specified via the <txp:comments_form /> attributes
Allow <txp:comments>, <txp:comments_form> and <txp:comments_preview> to become containers if you wish
Deprecate the textonly attribute and swap it for a more standardised link attribute in <txp:comments_invite />

Although I don’t want this to turn into “feature list by committee”, please argue any thoughts / ideas / improvements / patches related to TXP comments here, so I/we can figure out how to distil this down to a set of things that make sense to everyone and don’t cause too much upset. Thanks in advance.

<txp:comments_invite /> :-)

maniar · 2010-02-15 18:23:25

Expanding on the idea of author comments – I’d like that the author, when already logged into the back-end, need not re-enter his information when replying to comments on the front end.

Even when Wordpress introduced the reply-to-comments from the back end, I still used to reply from the regular comment form – because I prefer flat listed comments and I prefer replying to multiple commentators via only one comment.

benbruce · 2010-02-15 23:41:04

Bloke, I’ve always felt that the entire comment apparatus should be optional as a plugin. I don’t actually use them on my sites much so the whole thing is bloat for me. However, having a well-maintained comment plugin — possibly written by yours truly — that is as simple as plugging and playing and has all the features you mention, would be really great.

Especially if you are saying the code is weird and you’re going to essentially begin again, that’s my suggestion — make Comments a plugin, not a core feature.

Bloke · 2010-02-15 23:52:40

benbruce wrote:

I’ve always felt that the entire comment apparatus should be optional as a plugin.

I see where you’re coming from. I don’t use it much either so it’s bloat for me in 80% of sites. Perhaps an ‘official plugin’ (eeek, sounds like those ill-fated crockery elements) is an attractive proposition, though I’ve no idea how we’d manage upgrades :-\ Any thoughts?

Especially if you are saying the code is weird and you’re going to essentially begin again

Well it’s non-standard, yes, but I’d hoped to not have to start entirely from scratch! Was hoping to consolidate what was there and make it more consistent as well as adding a few features to make it more useful / less confusing for us all. But you got me thinkin’ on a tangent now…

maniar

when already logged into the back-end, need not re-enter his information when replying to comments on the front end

A noble suggestion, thanks. Will add it to the floaty pool of consideration. Anybody else who wants to chime in on the usefulness of this feature, as well as anything else mentioned so far, feel free.

benbruce · 2010-02-16 00:02:55

When I said “yours truly” I meant “you,” not “me,” by the way. :)

els · 2010-02-16 00:10:48

I agree with benbruce. I thought Txp is a CMS, not a blogging tool… ;)

BTW there is also a plugin for flagging author comments.

Bloke · 2010-02-16 00:29:35

Els wrote:

I agree with benbruce. I thought Txp is a CMS, not a blogging tool… ;)

Duly noted, thanks.

BTW there is also a plugin for flagging author comments.

Yes, net-carver’s excellent comment pack does it for one. There are probably others. I just can’t decide if that part of it is core-worthy or it should remain as a plugin solution (Ben’s idea of making the entire comment system a plugin notwithstanding).

Adding an author class is not that much extra code since we know the parent article, thus we know the author, so it’s one cacheable query away to look up the author’s e-mail/web address & name and compare it to the info against each comment. That does assume of course the supplied information is unique to a user which it may not be, but in all practical applications would be. The only time I can think of where it falls over would be if someone deliberately used the author’s e-mail address, web address and name to pose as the author. All that info is fairly easy to come by. Hmmm… plugins would fall foul of the same ploy, though. Can’t think of a way round it, unless the comments themselves were somehow “signed” by the author (perhaps by virtue of being logged in when commenting?)

Maybe we should scrap that idea…

uli · 2010-02-16 01:56:10

Els wrote:

I agree with benbruce. I thought Txp is a CMS, not a blogging tool… ;)

Hell, yeah!

jan · 2010-02-16 10:21:24

Maybe only flag as author comment when posted from the backend.
Of course chances are small that someone tries to identify themselves as the author but still it seems a bit unelegant to just check for the right email address. Besides, it saves you one instance where the user table gets queried.

Last edited by jan (2010-02-16 10:23:53)

pauldice · 2010-02-18 05:26:03

I’ve just started using TXP and was playing around with comments for the first time yesterday. There are a few things that I would like to see, some of which I think belong in the core and some that might be better as plugins. A basic implementation of comments is a good idea for a CMS (not having them at all might turn off potential users). More advanced features can be handled by plugins or third party solutions such as Disqus or IntenseDebate.

So here are the things I would love to see in the core (in order of importance). If there is already a way to achieve these without using plugins, please let me know.

1. The option to notify the commenter via e-mail of further posts. To my mind this is much more important than being able to ‘Remember Me’.

2. More control over the comment form fields. Not just sizes but it would be nice to use the ~~new CSS3~~ HTML5 input types (email, url) and attributes (placeholder, autofocus).

3. A tag to retrieve comment number (i.e. 1 for first comment, 2 for second comment etc).

4. Admin-side replies and flagging of author replies. Not huge things for me personally but I can see their use and they feel like core rather than plugin functionality. I think the flagging would have to require a login otherwise you leave yourself very open to pranksters.

Some tag consolidation would also be a good idea as there are so (too?) many of them. And comments_form feels like it should have its attributes moved elsewhere and be replaced with a simple output_form.

Last edited by pauldice (2010-02-19 04:04:52)

pauldice · 2010-02-18 06:07:59

Oops, forgot number 5 – an option to turn off comment previews. I’m all for less spam obviously but it seems harsh to enforce previews when there are alternatives such as captchas available.

maniar · 2010-02-18 06:43:56

@pauldice

A Plugin Exists
Can you please elaborate ? What specific cool and neat CSS3 trick would you like your fields to do ?
Comments are can be shown as an ordered list. Go to Admin > Advanced Prefs. The rest you can pretty up via CSS
(Thanks for chiming in)
(Thanks) but I am no fan of CAPTCHA especially if it is forced see my next comment.

Textpattern CMS

Textpattern CMS support forum

#1 2010-02-15 16:44:41

Comments system

#2 2010-02-15 18:23:25

Re: Comments system

#3 2010-02-15 23:41:04

Re: Comments system

#4 2010-02-15 23:52:40

Re: Comments system

#5 2010-02-16 00:02:55

Re: Comments system

#6 2010-02-16 00:10:48

Re: Comments system

#7 2010-02-16 00:29:35

Re: Comments system

#8 2010-02-16 01:56:10

Re: Comments system

#9 2010-02-16 10:21:24

Re: Comments system

#10 2010-02-18 05:26:03

Re: Comments system

#11 2010-02-18 06:07:59

Re: Comments system

#12 2010-02-18 06:43:56

Re: Comments system

Board footer