Personally, I would check if the user was blocked before you check the specific post.

Yeah, I was just trying to make the logic as simple as possible to explain what I meant. If there are performance gains by doing it the other way, then it's just as easy to code.

If there are performance gains by doing it the other way, then it's just as easy to code.

Probably would be, but I'm just guessing, not knowing anything about how the rest of it is coded, or, again, what the assumptions are as far as how frequently it will be used.

Also, just a thought, but you could put in a "Block my post" option when posting - this would be better than whitefont for spoilers. Then, you would, obviously, have to check the post before the user.

you could put in a "Block my post" option when posting

Eek! Then we'd be blocking by post instead of by user, and that would interweave a whole different set of logic and database structure to track that.

My envisioned DB structure was simple:

user_id, blocked_poster

And for every post display loop, you check to see if the user's blocked, and then if this post has been requested explicitly.

I am thinking that the display of a post from a blocked user should look different from the display of a normal user. But I have no further ideas.

Then we'd be blocking by post instead of by user, and that would interweave a whole different set of logic and database structure to track that.

Structurally speaking, how is "unblocking by post" different from "blocking by post"?

From TT, I don't think the post stayed unblocked. It was just that the page reloaded with that post showing. Next time through, invisible again. So no need to record anything in the database.

That's how I was interpreting it here too.

It was just that the page reloaded with that post showing. Next time through, invisible again.

Aha! innerestin'....

Actually, I think I was thinking that each post would have a value for "View" (or block, depending on your viewpoint). However, as I think about it more, each USER will have a value of "Block" FOR EVERY OTHER USER, and, additionally, for each post. That's going to be big, but I can't see any way around it unless you don't allow them to unblock by post, which I think was what was being discussed up above.

It was just that the page reloaded with that post showing. Next time through, invisible again.

On edit, I found this. This would be easier, yes.

That's going to be big, but I can't see any way around it unless you don't allow them to unblock by post, which I think was what was being discussed up above.

The big? And the overhead? Not a fan. Is there objection to my interpretation?

Is there objection to my interpretation?

Nope. I like your idea. Much more elegant.

"Blinvisible" and "What does this do?" links could simply go to an entry in the FAQ rather than a new page.

That's swell.

with your extra interface scenario, we also need errorchecking on the "add user" side, which I was trying to avoid by only allowing you to delete a user from that page. Would that have a negative impact on the usefulness, if you had to see someone's post to block them?

That's fine. Then we can just have a list box with a delete button and the FAQ link.

Two clicks (Hide-Unhide) isn't too many for the occasional task of seeing a post from someone you've decided never to again. It's less than it takes to unsubscribe from the Angel thread before watch-and-post. If you have to do it so much it bothers you, you might be wanting to give that user a second chance.