Comments system

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)

Siguo · 2010-04-26 09:16:36

1. 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?
—————————————————-

that’s not always right.

the first question we must answer is: if txp is fit only experienced and serious users, like a technical site, personal blog, newspaper site, or it can fit any level users, like a bulletin board, sns, ecommerce shop.

At my situation: I’m planning build interactive site use txp, like bulletin board, multiuser blog, sns, even ecommerce shop, just use txp. my site users will vary from any levels, with a big number, maybe 100000+.

when we MUST consider this situation, the PREVIEW step becomes a very serious thing, and include the textile….

2. I know it may seem I’m constantly railing against you (I’m not, honest!)
——————————————————-
haha, I like people to rail against me, that make me think deep. :)

Last edited by Siguo (2010-04-26 09:40:50)

Bloke · 2010-04-26 09:40:40

Siguo wrote:

my site users will vary from any levels

Fair enough, in that case you’ll want a plugin. nhn_livecommentpreview was quite neat (if you can find a copy) because it previewed as you typed and therefore skipped the PREVIEW step. There was also low_discuss that removed the preview. Both those are orphaned and I think 404 :-( But if you ask around, someone else is bound to have a copy. There are probably others — perhaps newer ones that are currently maintained.

There’s also rah_comment_spam which gives you some nice controls over additional anti-spam measures that would mean you could remove the preview step and still be fairly sure that spam would be kept low.

Siguo · 2010-04-26 09:53:09

Fair enough, in that case you’ll want a plugin.
——————————-

thanks, Bloke, I’ve written one plugin myself to skip the preview step, and it works well.
I will focus on roles and permission this week, and I will share my thougts here, it’s my pleasure to get your advice and guide。

thebombsite · 2010-04-26 11:13:17

Just a quick comment on Jonathan’s forms.

For the comments_display form I would add <txp:if_comments_disallowed></txp:if_comments_disallowed> tags at the bottom to display a text message.

For the comment_form form I would not use an ordered list as it isn’t a list and would probably entail extra CSS to negate any previous “ordered list” styling. My own preference is to use “p” tags.

jstubbs · 2010-04-26 11:48:33

Hi Stuart, thanks for the feedback. There is always room for improvement, and I am pretty sure we all agree that the current comments markup is ready to be withdrawn.

I am not sure about the first point, this will result in a text message being displayed if comments are disallowed which may be a little surprising to most users, especially if the auto-append comments is set to “yes”. In my view its better to add that message only if one wants it to be there.

The second point – think I used an ordered list for screen readers. This is an ongoing debate and this article sums up the concept quite well. I also use p tags, divs or just plain labels and fields.

Last edited by jstubbs (2010-04-26 11:49:12)

johnstephens · 2010-04-26 13:02:51

I also like the forced preview feature for the majority of sites. It’s proven to be an excellent method to prevent spam without moderation or hiding the comment form behind a login.

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

I appreciate the CMS focus of Textpattern, but I think there’s room for some form of this feature in the CMS core. Instead of looking at a comments system as a vestige of blogging, I see at least one major aspect of commenting that could be valuable to a wider variety of sites: Handling user-submitted content.

The only problem with comments in this regard is that they are tied to a specific data model. If users could configure custom fields for comments as easily as for articles— even using a plugin like glz_custom_fields, and if comments could be *appended to other content-types*— including other comments —I think using TXP to build interactive sites would become exponentially easier.

Textpattern CMS

Textpattern CMS support forum

#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

#25 2010-04-26 09:16:36

Re: Comments system

#26 2010-04-26 09:40:40

Re: Comments system

#27 2010-04-26 09:53:09

Re: Comments system

#28 2010-04-26 11:13:17

Re: Comments system

#29 2010-04-26 11:48:33

Re: Comments system

#30 2010-04-26 13:02:51

Re: Comments system

Board footer