Wedge

One of the more fun things about SMF, yes. I've wanted to do something with it for a while.Don't see why not. Essentially it's just about taking what's already there in the DB and displaying it in a new way, at least as far as I'm concerned.We haven't removed it, it's there just as it was in SMF ;) But that doesn't change how awkward it is.

Yeah, there are a number of things wrong with how SMF handles board moderators, not least the notion of confusing the hell out of people! I don't believe board moderators can access the moderation centre out of the box (but of course if you mess around with extra groups it will, of course)

That does get into the very thorny issue of access, but it also makes me wonder something else. There's no reason it explicitly has to be a 'board' with 'topics', yes it'd be nice if it did, but it would create a lot of problems in its own right. As an interim solution, the 'moderation' board could simply be a way of presenting what's in the existing report area based on what boards the current viewer is a moderator of.

What I'm proposing is essentially a real board with virtual topics. It wouldn't be searchable (at present, but it could be, is complicated!), but it could be placed within the ACP wherever the admin wanted. There would need to be additional logic to prevent multiple boards, and I know Nao won't like the idea of having a physical board that consumes space in the boards table.[1]

There's other stuff we could do instead, like having a virtual board shoved on the end of the board index unless another real board takes its place. It's all things that are doable, it's just minimising the damage otherwise.This is the real killer advantage of making it a physical board with virtual posts, we can get the list of posts on demand and enforce visibility properly.Yup. That's also all doable and I would imagine that you could go one further and integrate group requests into the same basic idea. It's what I'd do, put it that way ;)It's 3.36am. I do tired babble most of the time myself ;)

1.	It is one of the reasons why we both want rid of the recycle bin as a physical board.

OK, so I just tried the moderation centre. It is essentially just to create a board and divert the reports into it. I like the idea in as much as you can set where it lives and so on, plus lets you keep read hierarchy.

On the other hand it would also mean you could get into the situation where it's visible to people it should not be visible to. In neither situation are individual board moderators permitted to access it anyway from what I remember.

Having it as a board solves one problem: prominence. Having it also as a physical board solves other issues - it means people will see it (as good as what we have is, it's still not as prominent as a physical presence in unread or whatever), plus it makes it searchable out of the box, if that makes sense. Makes you wonder about other things, like membergroup requests, where they should end up.

As far as warnings go, I'm envisaging points based rather than percentages, I'm also envisaging it would have preset warnings with preset penalties that can be dished out. It's complicated.I have a story about that, but not for public consumption. I will send you a message, you'll understand where I'm coming from with it.

2. That's the problem with it. Most people don't even know the option exists and only discover it when they want to change something. Make it more clear, more people will use it.

4. We'll figure it out, heh. I don't really expect we'll change it, it was more a speculative thing than anything else.

5. I think it depends on the forum. The vBulletin forum I used to moderate, it was a big thing for each thread to have an icon, though there were about 40 icons to choose from and the filtering was more important there.

No... you misunderstand. I don't want to have to fart around enabling it. It would be 'on by default without any way to turn it off'. That's what I mean about the nonsense.Right now all the icons are gifs and there's no way to change that, it's forced in the code to be gifs.Right now it's stored as text. If you make it a number you get to save space and make it a little bit faster in some ways. But it does make some other things a bit more complicated.That seems easy enough to make as part of the interface overhaul (but effectively it's mostly already possible, just needs a nicer UI)As opposed to a more prominent dropdown that's already present showing the icon?

Especially when the CSS has all sorts of fun toys like harmonising some CSS3 automagically for you ;)

Some very interesting ideas there :)

OK, so I've spent a bit more time looking at vB 3.8.7, this time peeking into the DB and it's 158 tables. Yes REALLY. (Mind you, we have 90-odd tables at present, with a few possible casualties in future)

First up, I see a table storing the parsed copies of posts, subdivided by time and images. This is interesting because it means you'd parse_bbc once per post (unless you change settings, but that's its own interesting quirk, they have a maintenance thing for rebuilding it)

Second, the DB does indeed verify what I said before... in the attachment table I see a mediumblob column. It's certainly interesting, not innovative (I have thought of doing it for certain plugins)

Third, we have the choice of postbits, either the two column layout we use - which vB 3.8 claims is *legacy* or there's the full-width poster info with all the other stuff above the post. It's fugly to my eye but I can see the appeal for some. I kind of hope we can pull this off with the template skeleton, or at least either a plugin or a theme can do it, to prove it can be done.

Fourthly, adding views to the view count is not live. It is actually pushed into a separate log and updated hourly, presumably to prevent full table locking on the topics table.

Lastly and most interestingly, threaded conversation. Yes, that feature is in 3.8.7 (but was removed in later versions, not that I'm sure exactly when it was)

So here we have an actual working implementation, let's explore the consequences of it. Firstly, storage of the tree - it is how has been provided for Wedge, i.e. each message tracking its immediate parent.

This is what brings me to the fundamental issue I keep harping on about, retrieving the tree. I'm actually amazed this isn't a serious performance killer looking at it. It's nasty. I can't share it for obvious reasons but it looks like SMF 1 code in some respects - queries with double quoted strings, with variables injected into the query from outside. Including just randomly shoving crap into the SELECT (fields), JOINS and WHERE criteria of the query. It doesn't validate it or anything, it just hands it off to a hook (which is a bare box in admin panel with an eval() around it) and expects the hook to populate global variables. The query takes the form of SELECT post.*, user.* and some other stuff... that would be like us saying SELECT wedge_messages.*, wedge_members.* with some clauses to join them. This is also a query joining... at least 3 tables right there in the query. OUCH.

But it validates something interesting... that fetching the entire tree is not implicitly horrendous. But it does leave a very sour taste in the UI mouth.

vB 3 presents a three-pronged approach to threading. Firstly, we have threaded mode. A largeish subset of the tree is displayed at once, offhand I'm not sure what the rules are but it is a decent subset of the tree around where you are in it. I'd need more time to build a huge tree to assess what its rules really are, but it seems sane. Only one actual message is visible at once and replying to it is of course implicit. Multiquote is fairly important if you want to cross threads of course, but when you press the quote button, whatever you're replying to is the target for the hierarchy.

Then we have hybrid. This is a little curious - again, we get the tree shown to us. But this time when we view an item, we view its children in an otherwise flat style. It's not entire depth, it looks like it descends 5 levels to fetch replies and I don't know how it handles pagination but it folds all those up into chronological order and displays them otherwise flat. It's rather interesting to watch - but the real fun is replying. By default you have to actually select a post to reply to - even before *quick reply* becomes an option (as of course, full reply is no big deal, it just gears up to reply to that one message). The other choice, admin only, is to allow users not to have to do that, which means that by definition any reply is to the end of the thread (so it just replies to the last chain of whatever)

Lastly we have linear. Linear is effectively the same as hybrid - without showing the tree, so it just fetches a subslice of the thread's posts in order. But the real fun part is that by default it still holds the nesting data, so that you still have to pick something to reply to, even if you're not actually using threading because the hierarchy must still be maintained. Here of course every thread would just appear to be one long chain from the top because although we have the capacity to store the parent, we don't have the UI to support that properly, especially with quite reply.

This is the second problem with nested posts, of course (the first being performance).

There is an inherent third problem that comes up, which Kindred mentions every time it's brought out on sm.org, and he's right to a point - it encourages back and forth between individuals rather than addressing the group - but it would likely be useful for some of the discussions that fragment here, actually.

Threaded replies is something we have talked about, something we have indicated that we would be interested in but the nesting aspect always worried me. But if vBulletin does it, it really can't be as bad as I'd feared (or been able to benchmark on my own stuff). What I'm going to do is sleep on it, after all it is bed time, and see how I feel about it all in the morning.

Incidentally, it has provoked a feeling in me. One of the other SMF forks has pursued (and admirably so) a major feature that really appeals to them, though it's something I never wanted to touch beyond a plugin, mostly for support issue reasons... but the fact they're pursuing 'big features' encourages me to want to run wild and pursue big things too.

Also, don't make me look too hard at vB 3's code, is uggggggggleeeeeeeeeee.