Wedge
Public area => The Pub => Topic started by: Arantor on February 12th, 2012, 01:41 AM
-
Thinking about making some changes to this from the user perspective, would like to know what you think about it at present.
I have actually already said what I plan to do but would like some general feedback on it first.
-
I think that the icons are clumsy. Checkboxes make more sense to me.
-
Well, I'm trying to find out how many people use them (and so far the poll is trending towards what I long suspected)
To be honest, I'm looking at doing what I already suggested (and I think Nao agreed with), which is to simply pull quick moderation as being an option, and make it hardwired in for those who can see it, so it's always visible.
-
I use checkboxes all the time. They're great for cleaning up spam, making multiple topics sticky/unsticky in a short time etc. I've used icons for a few days and I found them horrible looking. But I guess that's just because of the icons
-
+1!
-
Definitely +1 :eheh:
-
I'm thinking the option was added by request from a vocal minority of people at a time when the SMF guys wanted to please everyone. Just like Dragooon and I added plenty of options to Aeva and SMG that really shouldn't have been offered. I'll try to clean these up, too. Simplicity trumps extensivity. Most of the time.
-
+100 :D
-
+1 :)
-
OK, the poll is definitely confirming my suspicions: that not only should quick moderation be just turned on and set to checkboxes, but that the very fact it wasn't turned on by default did confuse some people.
So yeah, time to get busy on the phasing out of stuff :D
-
As an aside, I found that the search handler does some queries based on this, as to whether the user has permission to do different things in each board.
Then I discovered, for each thing it's testing for, there's a query being made. There's 3 queries being run per search without quickmod, and 11 queries being run - per search - with quickmod enabled.
Needless to say, I'm changing how boardsAllowedTo works when confronted with an array, so that it can be made faster than one query per permission.
-
OK, the poll is definitely confirming my suspicions: that not only should quick moderation be just turned on and set to checkboxes, but that the very fact it wasn't turned on by default did confuse some people.
So yeah, time to get busy on the phasing out of stuff :D
Then I discovered, for each thing it's testing for, there's a query being made. There's 3 queries being run per search without quickmod, and 11 queries being run - per search - with quickmod enabled.
Needless to say, I'm changing how boardsAllowedTo works when confronted with an array, so that it can be made faster than one query per permission.
-
Quick mod is just a single checkbox, so it doesn't take space and even if I never really use it, it's still okay to have the checkbox in there...
Yeah, that sounds quite odd to me.. Then again, if it's just for people with moderation powers, it's bearable...
The only saving grace is that, by default, the quick moderation is off, so only 3 queries get issued by default, not 11. But I've rewritten boardsAllowedTo by now so that if it receives a single string, it returns a simple array of boards, but if it gets an array, it returns an array (key = permission, value = array of boards where that permission is granted), and it looks like on searching the source that this won't be a problem to do it differently.
-
Anyway, for those who haven't seen the changelog, I've done it, and it all seems to work as expected :)
-
Did it also run the extra queries even if the only option available in QMod is mark as read? That would be quite harsh since that could be all members, not just moderators.
-
Yes, it did run those extra queries, even if the action is markread, because even as one of the comments notes:
// !!! Maybe just do this on the actions people want to use?
I haven't gotten into rewriting quick moderation yet, since it clearly needs a rewrite (given that it sets up for people doing multiple actions at once but there is no interface I can see for doing this)
-
Ah yes. I started a rewrite using classes but you said it wasn't the right approach IIRC.... after I get back I can upload it in the private area for you to look at if you'd like.
-
Well, I'm not sure what the right approach is, I just think that using classes isn't quite the way to go for that particular operation. (Given how little of Wedge uses classes elsewhere, that is.)
But certainly it needs some kind of kick up the backside.
-
Re: latest revs -- haven't checked thoroughly, but are you sure $context['open_mod_reports'] is always available, Pete...? It's going to be accessed even when not logged in, etc, as far as I'm aware...? And it seems to be set only in ModerationCenter.php and Security.php...?
Other than that -- great to see you tackled this, thank you :)
-
Yes it is. banPermissions() in Security.php currently sets it up regardless of the user.
But yeah, it was something that I figured might as well be done :)
-
Perfect then, thank you :)
-
Bump for this... As said before(http://wedge.org/pub/feats/7211/brave-new-world/msg275123/#msg275123), $context['open_mod_reports'] isn't always set. I'm going to commit some of my changes, and this includes a test for emptiness for this, but please fix it another way if you can ;) (and if you can make it faster, obviously... Not that an empty() test is anywhere slow.)
-
I did notice that but I have no idea why that should be. banPermissions() deals with that.
*penny drops*
Googlebot you say? That makes sense. is_not_banned() won't be called when BB is tripped, because it's just dealt with before even getting that far. empty() is sadly the best way here because for BB trips, there's no point in setting stuff like the mod cache up.
-
Holy cow. I think your Member Options rewrite is buggy.
I just realized that the bug I was complaining about in Quick Reply was probably triggered by the fact that I'd just changed the default value for newest PMs... It seems that it reset *all* of the items to "No"!
As for Googlebot, then the problem would be fixed, right? I'll try to disable the thing.
However, we still need to get rid of the no_board errors. There are still tons of them. Just got 4 pages worth of pages from a bad bot called ZoomInfo (nextgensearchbot or something). In just a few minutes... And I think it'll plague the error log for a while.
-
I just realized that the bug I was complaining about in Quick Reply was probably triggered by the fact that I'd just changed the default value for newest PMs... It seems that it reset *all* of the items to "No"!
As for Googlebot, then the problem would be fixed, right? I'll try to disable the thing.
Just got 4 pages worth of pages from a bad bot called ZoomInfo (nextgensearchbot or something)
So, to recap, open_mod_reports will require an empty() check on it before use because the way BB is set up, that won't be set up. Or, in the BB execution path in Security.php, set it to 0 there. (Come to think of it, $board and $board_info should be minimally initialised in that same branch, which should prevent the no_board issue, though they'll still trip BB's rules anyway. All that needs to be done is setting up $board and $board_info like they are in Load.php's loadBoard(), as if $_GET['board'], $_GET['topic'] and $_GET['action'] are all empty.)
-
I just realized that the bug I was complaining about in Quick Reply was probably triggered by the fact that I'd just changed the default value for newest PMs... It seems that it reset *all* of the items to "No"!
I did some tests, and here's what I found: the only way to ensure a value isn't overwritten, is to simply click 'Change' next to it. Then it will show the select boxes... Which I don't touch, of course. This seems to be enough to guarantee that the value won't be reset by changing another option.That doesn't surprise me. I cleared out several pages last night of intrusion reports from them, and have reported the fact that their crawler is buggy to them.
So, to recap, open_mod_reports will require an empty() check on it before use because the way BB is set up, that won't be set up. Or, in the BB execution path in Security.php, set it to 0 there.
(Come to think of it, $board and $board_info should be minimally initialised in that same branch, which should prevent the no_board issue, though they'll still trip BB's rules anyway. All that needs to be done is setting up $board and $board_info like they are in Load.php's loadBoard(), as if $_GET['board'], $_GET['topic'] and $_GET['action'] are all empty.)
-
I did some tests, and here's what I found: the only way to ensure a value isn't overwritten, is to simply click 'Change' next to it. Then it will show the select boxes... Which I don't touch, of course. This seems to be enough to guarantee that the value won't be reset by changing another option.
From what I could see online, they're not spammers but more likely they're in it for money and don't give a shit what their crawler does. So, basically -- everyone's screwed...
'kay, I'll look into that... (Well, technically it'd be best if you did it. I'm going to commit before that anyway.)
What I will say is that fixing BB's codepath should be the better solution for the open-mod-reports case and it will be necessary to fix that path for the no_board stuff anyway.
-
Shit, that means the code's broken, it's not supposed to change anything unless it's reset in $_POST.
I'm considering taking the old list from the old Wedge.org and simply copying the data again.Well, if they don't fix it, it's going to be kicked back by BB. If we don't like what it does, we can block it entirely if we so choose ;)
I'd tend to ban these IPs before it even reaches index.php :PUp to you. I'm busy with yet more packing. Every time I think I'm packed, I find more stuff to go through. >_>
What I will say is that fixing BB's codepath should be the better solution for the open-mod-reports case and it will be necessary to fix that path for the no_board stuff anyway.
-
I'm considering taking the old list from the old Wedge.org and simply copying the data again.
// In the themes table, id_member = -1 is guest/new user option, 0 = theme option, any other = user id it applies to
There are times it wouldn't necessarily be like that, especially if there were other themes involved. But it's always those values and always theme id 1 now. (0 is for the cases where it is a theme option as indicated by Current Theme)I'd tend to ban these IPs before it even reaches index.php
When are you planning to leave?