Wedge

All I'm doing here is altering its opacity, knowing full well that the relevant icon does have other layout stuff (notably enforcing padding) that it handles. But dropping opacity to nil and then adding a new element that can be altered, maybe I guess. Not something that interests me personally though.

I'm not sure how I feel about this one.

Here's the deal: when you present a username/password box, you're expecting a username and password. Either being absent is fair game to report to the user, and if the password is wrong, again, fair game to admit it.

But what should happen if the username is invalid?

SMF, and currently Wedge, report that the username does not exist. Note that this will be the same for email addresses, which means it's possible to brute force email addresses out of the system with work.[1]

If it isn't obvious what I'm getting at, let me explain. If you type in a username and password, but the username doesn't exist, it will tell you so, regardless of what the password is. If you type in a valid username (or email address), but a useless password, you get told the password is wrong. Given that information it is possible to use the login feature to validate email addresses against your forum's userbase to a degree.[2] All because you're telling them something about the data they have.

Here's the catch: it is better user experience to tell them what's wrong with their information, but by doing so you give away something in security that it might be better not to do.

So I'm on the fence about what I should do; the current approach is not wrong but neither is right. It's certainly a better experience than it blandly stating 'The username or password is wrong', but it is less secure. How important is this security, especially in light of privacy laws?

1.	Oh, and did I mention, this isn't recorded anywhere either?
2.	The session level brute force detector will still catch it, but it's not like that's too hard to sidestep.

Really simple idea, and I was bored. All it does is gently flash the PM envelope icon when there are unread messages.

Well, what I might do is implement caching and just not pull from cache for those users. The default case will save enough queries that way, I'd say.0.6% is the sort of figure I had envisaged would use this.

Eh, I've just realised that the caching code is even more complex than I thought when handling per-page caching because of the nature of moderated posts >_<

I think I'll leave that part for now and see how big a deal it really is in practice...

2: dns_get_record() [<a href='function.dns-get-record'>function.dns-get-record</a>]: res_nsend() failed
Subs.php
Line: 1744

This is related to my custom lookup code, but need to check why it might throw this.

Well, if I'm honest, I did plan to remove it anyway because it's an option that I really didn't think people knew about, let alone used, and I figured it would be better simply to have the admin-only setting which does have use, especially considering the ability to tweak performance with it.

I'm just trying to find ways to save on database queries is all, and this is certainly a big one: right now Likes will take at least one, often two, queries on thread view to make it work. The latter query is sometimes avoidable, sometimes not, but the first one is only avoidable if Likes is turned off. I was planning on caching by page (so caching likes for topic 1, page 1; topic 1, page 2 etc.) - but that's only viable if the caching can be cleared when a new like is added.

That's the thing: if I didn't do that, you could like a post, refresh it and you wouldn't see your own like for ~2 minutes because it would still be using the old cache.

How many of you realised you could configure the number of posts you see in a single page?

How many of you realised that you could set one thing as an admin and users can set their own separately? And that you can even turn off the user's ability to do so?

There's two reasons I'm asking this, firstly because I think it's a setting that can safely be ditched[1] and secondly, because I don't think I can make likes be cachable without this change.

(That's probably not a big deal for most of you, but it is for me, OK? :P Specifically, when you like something, you need to be able to expire that cache, and the only viable way to do that is based on the page you're on, e.g. topic 1, page 1, which only works if it's the same size for everyone, of course)

Thoughts?

1.

If anything, I'd suggest it *should* be ditched not only because of the user interface stuff but also the fact that you can performance tune it better doing it one-setting-fits-all and upping it from the default of 15 to more like 20-25 per page, it's more posts per page but fewer pages if that makes sense.

I believe Nao's already aware of this one, but when creating a board, its pretty URL isn't generated properly, causing all sorts of odd breakage when creating new boards.