If comments are disabled after some have already been posted, the option to post comments remains.

[Hickeroar]

A "debate" on one post on my site got a litte more out of hand than I wanted to deal with, so I unchecked the "allow comments" box in the manage section of that post and saved it.

However, on the post, comments could still be posted while both logged in and not logged in. I would have thought a move like this would have "disabled" any more comments from being posted, but the comment box didn't go away.

When I went back into the post manager, the "allow comments" box was still unchecked, so it HAD saved that setting.

I might add, that if this is "fixed" it would be wise to keep displaying previously posted comments or at least give the option.

[nmoog]

I can not replicate this with 1.6... was it fixed?

[markjaquith]

This is a template issue. No problems with built-in templates.

[Nazgul]

markjaquith, a small off-topic question.

Yesterday foolswisdom asked me to close these kind of tickets as wontfix or worksforme as you can't specify when or where they were fixed. (It could in theory be possible that the built-in themes used to be affected by this)

Is there an official guideline for how to handle these tickets?

[markjaquith]

Nazgul,

I messed up. Should be "invalid," as it isn't a problem with WordPress, but with his template.

This is my guideline, although I'm happy to receive correction:

Fixed -- When I know that it was a bug, and know that a fix was committed at some point. If I can find the fix, I'll point to it.

Worksforme -- When I can't recreate the problem. Could be PEBKAC, or could be that a fix was already implemented and the user is just using an older version

Invalid -- Not a bug, or not a bug that WordPress can fix

Wontfix -- May be a bug, but not one that we're going to fix at this time

Duplicate -- When another ticket exists. If the issue has already been fixed in another ticket, I still use duplicate.

I may not have stuck to those guidlines as well as I should have, but that's how I see them working.

[foolswisdom]

Mark,

Seems like a sound approach.

The key for me is *know* that a fix was committed, which hopefully we get pretty good at being during the current release cycle.

If I do NOT know the revision that fixes it, I like WORKSFORME because it challenges the reporter to test it again, does not lead others to come looking for info about how it was fixed, and a minor benefit is not inflating the fix count in a particular release.