Wedge

No... I'm not vastly interested in developing or supporting MU myself, hence the 'evil glare' comment. But by adapting the design somewhat from SMF's database structure, MU becomes far less of the evil nightmare it is to implement in SMF.

The reason it's such a butt-ache is that the members table contains partial avatar information (the rest is in the attachments table, which you can't really share), and membergroup associations (inlined into the row, so all your multi-forums need to share membergroups by design).

SMF and Wedge do it for almost everything that moves into the database, except in a few specific places where the ability to use raw HTML is desirable and only the admin can set that up (board descriptions, censored words - which is why in 2.0 RC4 it became admin only as opposed to being moderate_forum before that).

That is to say, usernames, topic subjects and the like are htmlspecialchars'd with ENT_QUOTES if I remember right, while messages are htmlspecialchars'd, and pushed through preparsecode which fixes up certain bbcode requirements (neuters nobbc contents, enforces the html bbcode is only accessible by admin, attempts to fix/validate certain types of bbcode interaction, e.g. table->tr->td).

I wonder if preparsecode's changing everything into br tags is a holdover from YaBB where everything was in flat files. (I don't know how it was stored, but it seems feasible to me)That's one of the things we can do something about. We've expressly set ourselves on the path of having an importer rather than just 'upgrading' the existing tables - aside from the fact it lets people run them both side by side to experiment, it also means we can do manipulations along the way like fix any of these things we decide to resolve.Depends what you mean by sanitise. htmlspecialchars both ends strikes me as a bad idea, for example.Well, the methodology I was referring to was that all mods using the database should use $smcFunc's functions, and should be using the proper parameterisation, or the proper insert method made available that deals with escaping etc for you.

And yes, if it's broken, it should be fixed. That's one of the things that rattled me so much about 2.0 final: an astounding number of bugs were just deferred. While I as much as anyone accept that software is released with bugs, there's a difference between releasing with known bugs and releasing with unknown bugs, as well as releasing with architectural bugs that will need a complete rewrite of components to fix, and it irked me immensely that so many known bugs that weren't major but weren't that hard to fix (in more than one case a fix was provided and shown to work), and were still deferred through some "well, it might cause regressions" mantra.We use jQuery in Wedge. Not just because it means we get to minimise the code to be sent to users (since the admin can pick a CDN copy of jQuery), but the time we spent writing JS is shorter, and I suspect less time is also spent in debugging. Plus a lot of users do add stuff that makes use of jQuery, so having it in the core means plugins won't try each adding it and falling over each other.

htmlspecialchars is a tool. It protects against one angle of attack. There are others.

Let's be honest for a moment: the entire nature of cookies is a workaround for the fact that you want to represent some semblance of state over a protocol designed to be stateless.The password has been hashed with the passwordSalt (password_salt) value, which is known only in the database, and it *must* be SHA1 hashed with that salt on receipt, it won't ever be accepted by the cookie authentication code if not, and that salt is never shared.

They have access to the 'softer' stuff. They won't be able to go into the admin panel (assuming admin security has not been disabled), or change account options for other users (also uses admin security check), or change account details for the user they're masquerading as (since it requires their current password to do so)

That's something that bothers me about WP: some people that know what they're doing use PDO etc, others use WP's own functions, and somewhere in the middle, shit happens.

At least with SMF, mods are vetted and generally have had oddities weeded out - so SMF, and Wedge, sort out magic quote once and for all, right up front, and mods are then allowed to use that content - plus they're all supposed to use the proper methodology for inserting data into the DB and querying it using the abstracted methods.

Unless your name is <censored> and you can 'legitimately ignore the rules' because you're one of the people who enforces them, and it worked 'OK' for the more wild and untamed SMF 1.1 so just re-wrapping it in the 2.0 style call is acceptable >:(

There is a second reason why you might/would htmlspecialchars content on output: simply that you may not always be able to guarantee the sanity of runtime variables etc. in the current context.

The thing you might need to watch out for is double-calling, no need to call htmlspecialchars on outputs where it has already been run before...

As for me, I've been working on the new package manager and one component I want to introduce but haven't been able to decide exactly how I want it to work.

Also, it's starting to be noticed: http://www.simplemachines.org/community/index.php?topic=438826.0

Yes, all software invariably ships with bugs, but it still feels like a PR move to me rather than one done for the right reasons.