Comments system

maniar · 2010-02-18 06:55:53

Spam is ofcourse and always an for commentators and not everyone likes the preview button. But I do think there should be a solid anti-spam solution.

I have mem_akismet installed but I haven’t had a chance of seeing it’s potential. Does it perform like Akismet ? Are you happy with it ?

There is another solution I really like from Drupal called Mollom I’ve used it myself on Drupal and Wordpress.
Only when it suspects a spam comment it goes into Captcha mode. The letters are also not too hard to read and there is even an option to listen to the audio captcha – which is actually audible.

Though there are limits to it. (There used to be a demo but I can’t find it !)

Perhaps a port to TXP … would … be … possible ?

SuMu · 2010-02-18 07:21:34

My own comments, I need no email notification of my own comments!

pauldice · 2010-02-18 07:31:51

maniar,

Thanks for your response. To answer your comments:

1. I realise there is a plugin for this. My point was that this is a feature that I would like to see in the core. I think it’s about the only commonly used feature (from the user perspective) that TXP commenting lacks.

2. The placeholder attribute allows you to specify the help text that appears in an input field before it has been populated by the user (e.g. ‘Search’ or ‘Your name here’). The autofocus attribute gives default focus to a particular input field. I realise that these effects can be achieved with javascript but I try to keep scriptiing to the bare minimum – especially when, as with rounded corners now, an easier and more elegant ~~CSS~~ solution exists.

3. I saw this option but I don’t think this allows you to actually do anything with the comment number, does it? Say I wanted to use the number for the comment permalink for example. How would I go about that?

4. Don’t mention it.

5. The point here is that there are other anti-spam measures one can at point-of-entry so it seems odd to be forced to use one of them, especially one that is relatively uncommon and has such an impact on user experience.

SuMu,

Obviously you wouldn’t be notified of your own comments. The feature is to let commenters know when other people contribute to the discussion.

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

wet · 2010-02-18 07:40:25

pauldice wrote:

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’.

NB: We would have to cater for different legislations (single vs. double opt-in requirements come to mind). A firm understanding of legislative requirements in some target demographics would have to be established before we could safely put such a feature in core.

Some tag consolidation would also be a good idea as there are so (too?) many of them.

The benefits of consolidation will have to be weighed against the ptoential loss of upgradeability. How do you determine the impacts of tag consolidation?

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

wet,

I think a single opt-in would suffice. Point taken about legislative requirements but I see the feature on so many comment forms that I can’t imagine there being any major obstacles. And it would be optional of course (meaning you would have a choice whether to include the option in your comment form).

Maintaining backward compatibility is definitely an argument against messing with the comment tags and I agree that after proper evaluation it just might not be worth doing. I just chucked it in there as Bloke mentioned it – I found the collection of comment tags a bit confusing on first glance.

maniar,

I forgot to mention in my last post that the advantages of using the email and url input types are largely semantic (apart for mobile devices which I understand do something clever with the virtual keyboard to help you enter that kind of data).

wet · 2010-02-18 08:07:45

pauldice wrote:

I think a single opt-in would suffice.

I beg to differ. For instance, single opt-in does not suffice in Germany or Austria. Austria’s legislation threatens disobedience of spam regulations with penalties of up to 35,000 EUR for severe cases. A few hundred EUR are a common starter.

pauldice · 2010-02-18 08:18:40

I’m surprised to hear that. I routinely use this feature and have never had to confirm. To be fair I probably don’t surf that many German or Austrian sites though.

jstubbs · 2010-04-25 15:46:46

Stef – re the comments forms – would you like me to post the contents of my suggested changes to the forms (comments_display, comments, comment_form) here or will you do that?

The changes I made do not address any changes to the commenting system, they simply improve the markup and layout if comments are allowed.

Bloke · 2010-04-25 15:50:40

jstubbs wrote:

would you like me to post the contents of my suggested changes to the forms

Yes please. Anything that makes the comment system less confusing / more useful out of the box gets my vote.

jstubbs · 2010-04-25 16:13:57

Okie-dokie, here you go:

comments_display form:

<txp:if_comments_allowed>
<div id="comments-post-form">

<txp:if_comments_preview>
<h3>This is a preview of your comment - press the submit button in order to post it.</h3>
<div id="cpreview">
<txp:comments_preview />
</div>
<txp:comments_form />

<txp:else />

<div id="comments-form">
<h3 id="<txp:text item="comment" />"><txp:comments_invite textonly="1" showalways="1" showcount="1" /></h3>
<txp:comments />
</div>
<txp:comments_form />
</txp:if_comments_preview>

</div>
</txp:if_comments_allowed>

comments form:

<txp:comment_anchor />
<div class="comment_post">
<div class="comment_meta">
<txp:comment_name /> <txp:comment_permlink>#</txp:comment_permlink>
</div>
<div class="comment_details">
<txp:comment_message />
</div>
</div>

comment_form:

<txp:if_comments_error>
<txp:comments_error break="li" wraptag="ul" />
</txp:if_comments_error>

<fieldset>
<legend>Comment form</legend>
<ol>
<li><label for="name"><txp:text item="Name" /></label><br /><txp:comment_name_input /></li>
<li><label for="email"><txp:text item="Email - required but not displayed" /></label><br /><txp:comment_email_input /></li>
<li><label for="web"><txp:text item="Website" /></label><br /><txp:comment_web_input /></li>
<li><label for="message"><txp:text item="Your comments" /></label><br /><txp:comment_message_input /></li>
<li><txp:comment_remember /></li>
<li>Style your comments with <txp:comments_help />.</li>
<li><txp:comment_preview /> <txp:comment_submit /></li>
</ol>
</fieldset>

Quick run through:

Comments_display form is wrapped with an if_comments conditional to avoid displaying anything unless it is specifically chosen
Comments_display form shows only the just-posted comment when submitting a new comment, which avoids confusion if the newly posted comment comes after a lot of comments
Comments form is cleaned up with more styling hooks
comment_form – no more tables! This alone has confused many users because the default stylesheet has no rules for tables (as I recall)
comment_form shows any errors directly above the comments form
comment_form uses fieldset and an ordered list which is helpful for non high-tec users

Am using these three forms on all new templates for consistency of markup and CSS.

Siguo · 2010-04-26 00:51:49

The first problem with comment system is its anti-spam solutions, with present anti-spam solution, we have to PREVIEW before post, that’s really a little awful, and made the comment system code very heavy and difficult.

So I think we have to find a BETTER anti-spam solution before we make a BETTER comment system.

And I really found one, like this: http://docs.jquery.com/Tutorials:Safer_Contact_Forms_Without_CAPTCHAs

I think this method is very Light, Smart and Cool.

Last edited by Siguo (2010-04-26 00:52:28)

Bloke · 2010-04-26 08:44:13

Siguo wrote:

we have to PREVIEW before post, that’s really a little awful

Not to me. I happen to like it. Why is it so bad to look over what you’re intending to post before submitting it? Doesn’t that give you the opportunity to correct it and make fewer typos / errors / markup gaffs, which would otherwise require a further post to rectify?

The TXP engine makes it very clear that you need to preview first — and designers can (and do) make it even clearer with some neat CSS to really make the preview stand out. I’d argue that people who hit a button labelled Preview and then close their browser tab without reading the screen don’t care enough about their message contents to make sure it appeared on the site!

So I think we have to find a BETTER anti-spam solution…

I’ve used things along those lines before for contact forms — which takes a more logical and heuristic view of bots vs humans than the awful knee-jerk captcha things.

But the jQuery solution is really limited to contact forms. It’s not really applicable (at least in that format) for TXP’s comment system, and here’s why:

when the page loads it makes a note of the timestamp. The timeout for a contact form can be short — it’s traditionally the only thing on the page (zem_contact_reborn does this). The timeout for an article has to take into account the article length, the number of comments and how quick your visitor can read (they may be using a screen reader too). If the visitor reads all 300 comments and then decides to add their views, the assumption is they’re non-human, which is actually the reverse of reality. A bot will likely fill the form in quicker than a person so the logic should be reversed too. Although that might impact people who can speed-read, or prevent commenting on articles that are very short / have no other comments yet
it requires a salt. The only place a salt can be placed is in server-side code. If we ship TXP with a hard-coded salt, everybody will know what it is so it’s a pointless security measure. If we allow people to change it in prefs, the $prefs array is made available to the page and is therefore visible by anyone who can construct var_dump($prefs) (or even var_dump($GLOBALS)) in an article/form or other script. If it’s an attribute in one of the comment tags, it’d have to be mandatory, which implies a backwards-compatibility and ease-of-deployment issue (yeah yeah, the comment system itself could be argued to be an ease-of-deployment nightmare already ;-)

For those reasons I don’t think it’s workable in its current guise. Perhaps it can be modified to fit, but there have been attempts in the past to offer non-preview comment solutions (I think there’s a plugin actually) and TXP’s preview system always seems to prevail.

I know it may seem I’m constantly railing against you (I’m not, honest!) but I just can’t see how this can be applied to comments. If I’ve missed something obvious, please try and get it through my thick head :-)

Last edited by Bloke (2010-04-26 08:47:32)

Textpattern CMS

Textpattern CMS support forum

#13 2010-02-18 06:55:53

Re: Comments system

#14 2010-02-18 07:21:34

Re: Comments system

#15 2010-02-18 07:31:51

Re: Comments system

#16 2010-02-18 07:40:25

Re: Comments system

#17 2010-02-18 07:59:39

Re: Comments system

#18 2010-02-18 08:07:45

Re: Comments system

#19 2010-02-18 08:18:40

Re: Comments system

#20 2010-04-25 15:46:46

Re: Comments system

#21 2010-04-25 15:50:40

Re: Comments system

#22 2010-04-25 16:13:57

Re: Comments system

#23 2010-04-26 00:51:49

Re: Comments system

#24 2010-04-26 08:44:13

Re: Comments system

Board footer