Re: Problems with comments.py

On Wed, 8 Jun 2005, Nathaniel Gray wrote:
> 
> 1. There doesn't seem to be any consistent philosophy about what errors 
> should be reported to the user and what should go to logs.  If a comment 
> couldn't be saved because the comments file couldn't be opened, there's 
> no message to the user, just a log message, despite the fact that the 
> user's comment will be lost.  OTOH, when I submit a comment and e-mail 
> isn't set up correctly I see this message:
>
>    Error sending mail: SMTP instance has no attribute 'sock'Comment
>    submitted. Thanks!
>
> Some random user commenting on my blog shouldn't be told about problems with 
> my e-mail configuration.
>
> Basically, if a comment is rejected or fails to be saved, the user should be 
> told so.  If it's due to an internal error, the user should be told so, but 
> not get detailed info -- maybe a numerical or symbolic code to indicate which 
> line the error came from.

Yeah, I agree, it sucks.


> 2.  The new way of having story.html displayed for comments makes it 
> impossible to put status/error messages at the top of the page where 
> they're easiest to see.  So the user has to scroll down beyond the story 
> to even know that there was a problem with a comment.  It was also 
> annoying that this behavior changed without notice between 1.0 and 
> 1.2.1.

The old way would stomp on the existing story template which caused other 
problems.

You could put in an anchor that will scroll the page down to where the 
comment error is immediately upon posting.  I would suggest using that.

In terms of notice, I'm pretty sure there's notice in several places. 
This was a known not-backwards-compatible behavior change of the comments 
plugin and I thought I had made sure that there was ample notice.  Having 
said that, I don't see anything anywhere.  I think I totally dropped the 
ball.  I thought I had a README just like I did with the PyBlosxom core 
packages.


> 3.  It's hard to style status/error messages.  If a message is output, 
> $comment_message should expand to a <div 
> style="commenterrormsg">...</div> block.  If no message is output it 
> should expand to an empty string.  That makes it easy to incorporate the 
> error message output in your flavour files without having them take up 
> space, and it makes them easier to style as well.
>
> 4.  Actually, the whole "status message" approach to error handling is 
> bogus. It's annoying to have to try to weave error handling into flavour 
> files that are also supposed to handle non-error cases.  It would make 
> more sense to have a comment-error.html file where you can handle errors 
> properly.
>
> 5.  If a comment is entered without an e-mail address then crashes happen. 
> Even worse, they corrupted my comments database.  The plugin needs to 
> transform and validate its input *before* attempting to write it to the 
> database.  Code like:
> 
>    cfile.write(makeXMLField('title',comment))
>    cfile.write(makeXMLField('author',comment))
>    cfile.write(makeXMLField('link',comment))
> 
> is dangerous because if the second makeXMLField call fails then the file has 
> been partially written!  All transformations should be done before the file 
> is written to.  Incidentally, the fix for this crash is simple.  In the 
> cb_prepare function you need to add these lines after the "if 
> form.has_key('email')" statement:
> 
>        else:
>            cdict['email'] = ''

The email part was my fault and it's fixed in the new version of comments 
that hasn't been released yet because I haven't had time to finish up the 
other things I wanted to do.


> 6.  I've added a "magic word" feature to comments.py that requires the 
> user to type some magic word to validate that they're not a spammer. 
> It's really simple, not dynamic, not industrial-strength, but if 
> everybody out there chose a different word and a different way of 
> *asking for* the word it would make comment spamming much harder.  Is 
> this something you'd be interested in integrating?

I've been doing a lot of work on the PyBlosxom manual to covers issues. 
I tossed in a chapter on comments last week or so which talks about 
dealing with comment spam (though much of the material is missing):

    http://pyblosxom.sourceforge.net/1.2/manual/c848.html

The comments plugin uses a comment rejection callback to allow you to have 
other plugins deal with the business logic for how you want to reduce 
spam.

On the PyBlosxom site, we use the nospam plugin (check the mailing lists 
and registry for details) to reduce comment spam.  On my site, I reject 
all comments that have words like "casino" and "blackjack" in them using 
my wbgcomment_blacklist plugin and then all other comments go into draft 
status to be manually approved.

So, we're not interested in adding that to the comments plugin directly, 
but you could write a comment-rejection plugin based on what you're 
talking about and the nospam plugin does something similar to what you're 
talking about.


> Ok, I guess that's it for now.  I'm sorry if I came off as sounding 
> negative. I actually like pb a lot and I'm grateful for the time you 
> guys spend on it. If you agree with the things I've said above but don't 
> have the time to fix them then I can put together patches.

I'm ok with negativity--these issues you're bringing up are definitely 
issues.

If you could work up a patch for issues 1 and 5, that would help a 
lot.

I think we're definitely interested in thoughts on how to restructure the 
system to better handle error messages from plugins.

As you state, there are two flavors of error messages: ones that need to 
go back to the user and ones that should only be seen by the blog owner. 
The latter should go to the log files, but our logging is still in 
somewhat of a shambles.  Steven committed some logging fixes to the DEVEL 
branch, but I haven't brought them over into the 1.2 branch because I'm 
just doing bug fixes right now and don't have time to do anything else. 
Those are conversations for the pyblosxom-devel mailing list.


Inconveniently, I've got HUGE life changes in the next two weeks and then 
I'm on vacation until July.  I'll try to slam-dunk some of the things I'm 
sitting on over the next few days so I'm not leaving anyone high and dry.

/will


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20