Wedge

That's the thing: the admin panel is still very much in flux. There will be a LOT more in it than there is in SMF's, simply because we've added more to it than we have taken out.

Right now it is basically just SMF's admin panel with half a dozen things gone and plenty more added. So, thus, my question stands: you've said that you see a problem with the look and layout options. What problem do you see? How would you resolve it?

I have my own ideas, some of which are fairly controversial on the subject of pruning the admin panel, so let's start on a smaller area...

I'm not sure I know exactly what you mean about 'making things appear/disappear'. But I certainly won't disagree that the admin panel is a clusterfuck of stuff that doesn't really make sense. 1.1 was better, 2.0 took everything in 1.1 and added more "stuff" to it and it's confused a lot of people, particularly the way permissions were done.

That said, you can't, realistically, have configuration options for every little thing: the admin panel already exceeds 100 1st and 2nd level menu items (which means you're basically talking ~90 pages of stuff, all told - first level items just display the first of an item's second level items)

There is a certain degree of value in 'less is more', in fact. Or at least, the perception of less stuff even if there's actually more stuff available to you.

There's nothing that we expressly need 5.3 for in Wedge right now, but that's not to say we have to leave it that way. There's plenty of time to change yet :)

Low blow. Especially since you clearly don't know the whole story. The move back to closed source is simply so that SMF doesn't start ripping off our code after the way things went down. Once our code is sufficiently far away from SMF to be useful, I suspect we'll reopen it again later.

Oh, they've known for a while. It's not like it's a secret or anything.

I doubt it, don't really know. Though if it's a really well known university it could make a difference, e.g. Harvard or Yale comes to mind.

Oh? Well, I never went as far back as YaBB or YaBBSE, so I'm looking at it all from SMF 1.1 and later's perspective, and what I've seen said. My understanding was that SMF 1.0 did bbc parsing through regexp, on display, but that a vicious ReDoS could take it out because it wasn't protected against that, hence it was doing through string parsing and done on a regurgitation basis, and that security was one of the major factors.

But yes, your other comment about not changing it on upgrading is a good one. In our case, we explicitly allowed for that sort of thing because we were looking at fixing otherwise broken links when coming from non SMF sources.Funny you should mention that, that's exactly what the WYSIWYG editor tries to do, badly. So much so that it doesn't bother converting anything other than simpler HTML.No argument. Interesting comment there, there were plans to rewrite the bbc parser in C under the banner of smflib. (Not sure if that was after your time or not) but it never really went anywhere. It's still in SMF's SVN, untouched in pretty much forever.

I think whatever happens, we can't really afford to leave PHP, it's not like we can just conjure up a parser in C, and even if we could and did, I'd honestly not want the hassle of support for something like that.Correction: it needs *some* solution.

parse_bbc does caching, but only under certain circumstances: if a post takes over a certain length of time to parse, and the parse_tags parameter wasn't given. parse_tags is only applicable when you invoke the parser with a subset of tags to accept, e.g. for signatures that have a different set of rules to normal.

In real practice, only truly huge posts ever hit this limit anyway.This sounds like a good idea to me. I'm not sure offhand how we'd do it, but it seems more reasonable than just bulk throwing things at cache.I really need to get properly familiar with TOX-G's innards. Is there anything specific you're thinking about how it operates that you'd do differently?*nods* It does need to be done properly. I never seem to find the time to do this though :/So, then, if we were to htmlspecialchars it on output, presumably we wouldn't do it on saving the data in the first place? Or would we unsanitise it before resanitising it?

My one fear with doing that is that it opens a door I don't really want opened. SMF's ecosystem is populated with those who write SSI functions and jiggle around with the innards, and I'd really rather not give them any more ways to make it easier to make them insecure.Well, in 2.0, it's in the admin panel. Except it's broken.See, that's neat. And really, I'm not against the idea. I just wish they'd write rules and stick to them; it always used to be the case when I was on the Cust. team that bugfixes weren't allowed. Then they allow these bugfixes, and they even package up the bugfix for the IE 8 "jumping text bug" for 1.1.x as a mod rather than roll it into the update >_<Things like this I'm in one of two minds about - and it's been discussed here too. My take on it is straightforward enough: everything that's in the core of Wedge should be something that a "reasonable percentage of users" are going to use.

Right now the calendar is seemingly used by the relative minority. A small but vocal group use it for events, and a larger group turn it on because of birthdays.

So, my take on it, specifically, is that birthdays should be separated from the calendar, and then the calendar should either be moved out of the core, or made more useful, so as that more people would find it useful. For example, we've talked about accessing "Today's posts" from the calendar.

While I don't like to point at other systems and go "they do it" (it sort of goes against my "innovate, not imitate" philosophy), I look at WordPress and I see they have it. Different horses for different courses but they have a calendar in the core, enabled by default. Because it suits them to do so.

Given that we have blog support - because it's something we both want and I saw more and more requests for it at SMF (and the fact that if you have Wedge, you shouldn't really need to bridge to WP for a simplistic blog, have one system and be done with it), the calendar takes on a new light - and one that helps justify keeping it.