I don't think the logic is broken... It just needs special treatment at the top level, just like you gave to AdminSearch. Although at this point I think it'd make more sense to do generic handling of all 'select'-type entries.
Why does it need special treatment? Doesn't it call a function and issue a normal template?
Also, I *think* there's supposed to be a confirmation request for deleting boards.... I only get one for deleting categories. Can you...confirm? Anyone?
Fairly sure there's supposed to be... there's a JS error in suggest.js (which is called for the board moderator selector) which causes the rest of the page JS to get upset, which prevents the confirm() being called.
Re: restore posts, I couldn't find the origin of the skeleton error. Argh. If you could look into it as well... I have no time to actually go and try to restore posts for now
I'll look into it right now I'm back on the PC.
Loosely related: when deleting a post, Wedge should update its 'children' posts to use the deleted post's parent ID. Should be easy enough, but we then have to update their own children, too... I'm not sure how to do this with minimal impact on the DB performance.
It's tricky - and that's before you get into the realms of split/merging. However, if you have any given tree of x->y->z, and it's y you're deleting, you only have to update all the cases for z where the parent is y. It's a single-direction graph, we're only recording the parent, not the children, nor the latter descendants, so if post y is deleted, UPDATE wedge_messages SET id_parent = x WHERE id_parent = y, and that'll match all the z cases because we're only recording the immediate parent...
And-- I guess 'parent' shouldn't be touched when removing through the recycle bin... Or maybe yes. What's certain is that it shouldn't be deleted when a post is 'unapproved'.
This is *really* where it gets fun. What might be better is if the actual hierarchy remains untouched in a physical sense but a simple "This post has been removed" placeholder is shown to the user. That would not only solve the whole issue of how to handle it (because you don't move it, you leave it totally in place) and prevent logical disjoint where the post is removed and the flow of conversation seems broken: it's still going to be broken if part of the conversation is missing, but at least you have context for it.