Search options (Page 43 of 307)

Remove it in help.php as well?

Mmm, looks a bit messed up in IE and FF. In IE, the navlinks don't match up with the lines (personally, I don't like that layout in any case). Also, in both browsers, the last post column doesn't extend far enough to the right. The space between the blue headers (eg: for category names) and the actual content makes them seem like they're not actually meant to be together.

OK, I just wanted to make sure you weren't getting the wrong idea.
Personally, it doesn't matter to me: I'm aware of the implications of putting details there and changing it to a password field would change nothing for me. The question really is, as you said earlier, whether or not any gain in security we get offsets any loss of usability.

That's somewhat more difficult to do, since the buttons are generated after the rest of the page and we have to let extension authors create buttons as well, which could have different permissions levels. I think I'll let Rickard decide if we can/should move the button generation to just after we require header.php (not the actual output, just the generation).

It's not hashing, that would be impossible. It's changing the field from a plain text field to a password field, which would keep the password from being shown in the input field. It won't stop admins from viewing the source of the page and seeing the password. It won't stop people with access to the database from seeing the password. It will simply keep someone from looking over your shoulder at your screen (rather than at your keyboard) as you type it in. And the cost is that it's not as easy for you to tell whether or not you have entered your password correctly

Fixed

Fixed

And after some testing, I'm ready to declare it not a bug. I could only replicate it on PunDemo and only when I had Javascript enabled. Which makes me think the other views are very swift Googlebot spidering of content for Adsense.

Except when you go to send emails and it doesn't work

Doesn't work for me (using Windows XP)

That's double escaping, which is wrong (or single escaping if the person tried entering the entity instead of "s)

I have to relook at the permissions for those actions anyway: right now, they're limited to administrators although the buttons show up for mods and admins.

I have a feeling I know what this is due to, so I'll make a note to myself here and test it later:
redirect function, redirect time of 0