Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Topics - Arantor
31
Off-topic / Shiny awesomeness
« on May 6th, 2013, 03:25 AM »
https://code.google.com/p/gource/
Basically, you take a repository of code with some history, like Wedge's - and throw it at Gource and it makes a fun animated history of it.
Only @Nao and a few other people will be able to plug it into Wedge's history but if you have some other version-controlled code, it's fun to watch.
I'll try and record the video of this at some point and share it on YouTube but I really need to find the time to do that, and I don't want to until at least after the warning system is done.
Basically, you take a repository of code with some history, like Wedge's - and throw it at Gource and it makes a fun animated history of it.
Only @Nao and a few other people will be able to plug it into Wedge's history but if you have some other version-controlled code, it's fun to watch.
I'll try and record the video of this at some point and share it on YouTube but I really need to find the time to do that, and I don't want to until at least after the warning system is done.
33
Test board / test
« on May 2nd, 2013, 01:59 PM »
test test test test test test test test test test
35
Features / Separating lock and unlock permissions
« on April 30th, 2013, 12:17 AM »
So I was going through my list[1] and I saw a mod that ensures only admins can unlock threads.
Now, I can't imagine this would be useful in every scenario but it seems to me that it'd be useful enough for some kinds of sites to have the lock/unlock separated into two own/any permissions rather than assuming if you can lock, you can unlock again.
Just a thought, just wondered what folks thought. It's not a killer feature, nor something I'm going to be that worried if I don't implement, but it seems like it could be a simple enough useful extension for a small enough cost.
(Don't forget SMF/Wedge do already understand the concept and difference between user lock and mod lock, i.e. where a user locks their own topic, they can unlock it again, but if a moderator locks it, the user won't be able to unlock it unless they're also a moderator)
Now, I can't imagine this would be useful in every scenario but it seems to me that it'd be useful enough for some kinds of sites to have the lock/unlock separated into two own/any permissions rather than assuming if you can lock, you can unlock again.
Just a thought, just wondered what folks thought. It's not a killer feature, nor something I'm going to be that worried if I don't implement, but it seems like it could be a simple enough useful extension for a small enough cost.
(Don't forget SMF/Wedge do already understand the concept and difference between user lock and mod lock, i.e. where a user locks their own topic, they can unlock it again, but if a moderator locks it, the user won't be able to unlock it unless they're also a moderator)
| 1. | Yes, it's fairly well known that I have a list of every SMF mod and with annotations as to what I want to see in Wedge. |
36
Features / return_raw buggy if enableCompressedOutput is on
« on April 29th, 2013, 12:07 AM »
I was surprised to find that every 90 odd seconds, I was seeing weird errors from the unread notifications lookup. Every time was the same, unexplained failure - no concrete reason, every request was simply left as 'pending'.
After some digging, I found there is one consistent reason for this: return_raw forces all the buffers to close. The problem is, doing that seems to cause it to screw up - in my case *every* request was failing because of this.
Bizarrely, if I don't close the output buffers, it works exactly as expected for me, behaves consistently regardless of setting. (All I did was comment out that line)
If the end-buffers line is left alone, it only works if enableCompressedOutput is disabled.
Curiouser and curiouser, I added the following debug code before the end-levels line:
Code: [Select]
With it enabled:Quote With it disabled:Quote
After some digging, I found there is one consistent reason for this: return_raw forces all the buffers to close. The problem is, doing that seems to cause it to screw up - in my case *every* request was failing because of this.
Bizarrely, if I don't close the output buffers, it works exactly as expected for me, behaves consistently regardless of setting. (All I did was comment out that line)
If the end-buffers line is left alone, it only works if enableCompressedOutput is disabled.
Curiouser and curiouser, I added the following debug code before the end-levels line:
global $settings;
trigger_error('Compressed output: ' . (!empty($settings['enableCompressedOutput']) ? 'ON' : 'OFF') . "\n" . print_r(ob_list_handlers(), true));With it enabled:
1024: Compressed output: ON
Array
([1] => ob_gzhandler
- => default output handler
)
1024: Compressed output: OFF
Array
([1] => default output handler
- => default output handler
)
38
The Pub / Warning Message
« on April 25th, 2013, 05:52 PM »
@Nao, would *really* appreciate your insight on these.
Moderated messages get a warning at the top saying something to the effect of 'Hey, this message is moderated!' and some months back I added in a facility to (temporarily) display the reason for moderation underneath it. I've since made that more permanent, but that's not really what I want to talk about. I'm just giving context: we have somewhere to store metadata about a message.
I've attached a picture to show what this looks like. I'd note that there are two visual issues I've noticed that (AFAIK) aren't the result of what I have locally - .postbg.approve isn't exactly much different to straight .postbg (or .postbg2 as per the immediately preceding message) and there's not a gap between messages like there should be. (NB We pretty much inherited this one from what I remember.)
Now, I want to add something else to the mix: notice for a member being warned for a given message. XenForo has this and I think it'd be a useful facility to add.
My concern is where to put it or what it should look like. I've attached an example from XenForo. I want to do something similar but I don't know where to put it in the template exactly. Or what it should look like.
Moderated messages get a warning at the top saying something to the effect of 'Hey, this message is moderated!' and some months back I added in a facility to (temporarily) display the reason for moderation underneath it. I've since made that more permanent, but that's not really what I want to talk about. I'm just giving context: we have somewhere to store metadata about a message.
I've attached a picture to show what this looks like. I'd note that there are two visual issues I've noticed that (AFAIK) aren't the result of what I have locally - .postbg.approve isn't exactly much different to straight .postbg (or .postbg2 as per the immediately preceding message) and there's not a gap between messages like there should be. (NB We pretty much inherited this one from what I remember.)
Now, I want to add something else to the mix: notice for a member being warned for a given message. XenForo has this and I think it'd be a useful facility to add.
My concern is where to put it or what it should look like. I've attached an example from XenForo. I want to do something similar but I don't know where to put it in the template exactly. Or what it should look like.
39
Bug reports / Pretty URLs still chronically broken
« on April 16th, 2013, 09:56 PM »
So I spent some time actually figuring out what the problem is, since as I've said it's *never* worked properly for me for a long time.
The rewrite filter for both boards and topics just injects the board prefix as in the DB, but while the default board seems to get the proper prefix (e.g. locally I get localhost/wedge prefixes), nothing else seems to, so everything ends up with a / prefix, e.g. /new-board-2 which obviously doesn't work properly.
Going into these boards' configuration after the event also doesn't work because the pretty URL is just listed as (localhost) / (empty box)
Storing all this directly in the DB also has other problems with respect to users who decide to move their site around, because they'll not only have URL issues to deal with for reindexing, they'll also have to cope with editing every board.
Seems to me that we might need to find some other method of dealing with this - because while it's fine on wedge.org, it's no good for most other sites.
The rewrite filter for both boards and topics just injects the board prefix as in the DB, but while the default board seems to get the proper prefix (e.g. locally I get localhost/wedge prefixes), nothing else seems to, so everything ends up with a / prefix, e.g. /new-board-2 which obviously doesn't work properly.
Going into these boards' configuration after the event also doesn't work because the pretty URL is just listed as (localhost) / (empty box)
Storing all this directly in the DB also has other problems with respect to users who decide to move their site around, because they'll not only have URL issues to deal with for reindexing, they'll also have to cope with editing every board.
Seems to me that we might need to find some other method of dealing with this - because while it's fine on wedge.org, it's no good for most other sites.
40
Archived fixes / Something is screwy with the main menu
« on April 15th, 2013, 04:50 PM »
I don't know why this is but it's seriously messed up right now.
I was clicking on the Home button repeatedly (here, just now) and some page loads it would show I had a PM outstanding, some it would show no PMs outstanding, some it would show a dropdown for the Home menu, some it wouldn't.
Oh. It just occurred to me. SMF bug strikes again.
Why are we caching the menu again? This is why it's messed up - caching at level 2 (which is what we're set to) stores the menu for the groups the user is in with the language. It's entirely possible that you have multiple members with the same groups with different information.
I don't really think we need to cache it...?
I was clicking on the Home button repeatedly (here, just now) and some page loads it would show I had a PM outstanding, some it would show no PMs outstanding, some it would show a dropdown for the Home menu, some it wouldn't.
Oh. It just occurred to me. SMF bug strikes again.
Why are we caching the menu again? This is why it's messed up - caching at level 2 (which is what we're set to) stores the menu for the groups the user is in with the language. It's entirely possible that you have multiple members with the same groups with different information.
I don't really think we need to cache it...?
41
Features / CSS inheritance issue
« on April 11th, 2013, 07:20 PM »
So, I want to add a new icon to the buttons, we have a tick and a cross and stuff like that, and I want to add a (!) button (i.e. using the warning icon)
Now, I don't want this in the main index.css file for obvious reasons so I thought, you know what, I'll put it in index.member.css, and extend input.submit that way.
So index.member.css has:
Code: [Select]
Except, and this is the troublesome part, this part is declared, effectively, before my input.warn class:
Code: [Select]
So background-position gets overridden by input.warn's own declaration.
I don't know how to deal with this in a good way since index.member.css stuff is loaded after index.css, but I don't really want to add this to index.css if I can help it. I think I'll just have to add background-position directly to input.warn :(
Now, I don't want this in the main index.css file for obvious reasons so I thought, you know what, I'll put it in index.member.css, and extend input.submit that way.
So index.member.css has:
input.warn extends input.submit
background: url($images/warning_ban.gif) no-repeat
background-color: #fff0e3
:hover
background-color: #fff5e8Except, and this is the troublesome part, this part is declared, effectively, before my input.warn class:
// Declare position only here, so that inherited classes can also set it.
input.submit
background-position: 5px centerSo background-position gets overridden by input.warn's own declaration.
I don't know how to deal with this in a good way since index.member.css stuff is loaded after index.css, but I don't really want to add this to index.css if I can help it. I think I'll just have to add background-position directly to input.warn :(
42
Features / Moderation Centre overhaul
« on April 10th, 2013, 01:49 PM »
So, I've been thinking about what to do with this. The moderation centre is one of those things that the other platforms have and yet I find all of them fairly depressing and uninteresting places. I'd like to say they were functional, but I'm not even sure that's entirely true. I certainly know of no-one who actually *likes* SMF's mod centre.
I have already made some changes, stripping out the way warning history was shown and removing the latest news block[1] but the more I look, the more I think a deeper change is actually required.
So, here's what I'm thinking. I expect to keep a mod centre, as such, but substantially transform how we interact with it. First up, not on the menu. I'm not convinced you need to access it that regularly. In fact, what I want to do is pull it onto the board index.
Have each major section (reported posts, membergroup requests, unapproved posts) as a virtual board. Not physical boards (too messy, causes unnecessary extra logic elsewhere in ensuring access is maintained etc.) but virtual ones, that don't consume ids, but appear on the board index. This would also mean having an idea of whether there are new things to read or not but this doesn't strike me as a significant deal.
More interestingly this would probably encourage people to actually get involved with things there because they'd know what was going on.
Then pull the logs (warning log, moderation log) as 'sub-boards'. Mechanically would be redirection boards without having to do an actual redirection. Not hard (SimpleDesk did it)
As for placement. I think I'd be inclined to keep it as a single category that the admin can move around. But if people *really* feel a burning need for it to be per-board placement that's something we can work on.
I'd also be inclined to pull this stuff into the unread posts area too if there are new items not yet read. I'd want to keep them separate from the rest of the unread items, so there's no need to splice the two together.
As far as anything else goes, for the most part it would function much as it does right now, though I'd probably clean up the look to be more like other areas.
One last idea, food for thought... do we want to get into the situation where a user who opened a report can be allowed to comment on it later?[2]
I have already made some changes, stripping out the way warning history was shown and removing the latest news block[1] but the more I look, the more I think a deeper change is actually required.
So, here's what I'm thinking. I expect to keep a mod centre, as such, but substantially transform how we interact with it. First up, not on the menu. I'm not convinced you need to access it that regularly. In fact, what I want to do is pull it onto the board index.
Have each major section (reported posts, membergroup requests, unapproved posts) as a virtual board. Not physical boards (too messy, causes unnecessary extra logic elsewhere in ensuring access is maintained etc.) but virtual ones, that don't consume ids, but appear on the board index. This would also mean having an idea of whether there are new things to read or not but this doesn't strike me as a significant deal.
More interestingly this would probably encourage people to actually get involved with things there because they'd know what was going on.
Then pull the logs (warning log, moderation log) as 'sub-boards'. Mechanically would be redirection boards without having to do an actual redirection. Not hard (SimpleDesk did it)
As for placement. I think I'd be inclined to keep it as a single category that the admin can move around. But if people *really* feel a burning need for it to be per-board placement that's something we can work on.
I'd also be inclined to pull this stuff into the unread posts area too if there are new items not yet read. I'd want to keep them separate from the rest of the unread items, so there's no need to splice the two together.
As far as anything else goes, for the most part it would function much as it does right now, though I'd probably clean up the look to be more like other areas.
One last idea, food for thought... do we want to get into the situation where a user who opened a report can be allowed to comment on it later?[2]
| 1. | Seriously, what was up with that? I don't know any moderator that would be able to use that information, since only the admin could do anything with it. Was the hope that admins would magically be able to see it and do something with it? |
| 2. | I know at least one person asked me for a facility in SimpleDesk where reported posts would be diverted to the helpdesk for that very reason. |
43
Features / Sources/notifiers
« on April 9th, 2013, 05:33 AM »
I'd kind of like to see Sources get a new folder to put new (core) notifiers in. Right now there's only the Likes notifier in core but I'm expecting things like personal messages and replies and stuff get (core) notifiers and I think having that in its own folder would be nice and tidy.
Only really affects me, Nao, Dragooon and anyone else who uses/makes core notifiers.
Only really affects me, Nao, Dragooon and anyone else who uses/makes core notifiers.
44
Archived fixes / Event delayer gets upset if there's a " in it
« on April 7th, 2013, 04:55 PM »
I don't know if this should even be fixed, but I do want to make record of it.
I have a select, it has a simple onchange, which is to alter the disabled property of another input. Specifically,Code: [Select]
The nested quote mark causes issues, but as I said, I'm not sure this necessarily needs a fix - doing something like this is not what you would necessarily call common.
I have a select, it has a simple onchange, which is to alter the disabled property of another input. Specifically,
onchange="$(\'input[name=\"infraction_duration_number\"]\').dostuff();"The nested quote mark causes issues, but as I said, I'm not sure this necessarily needs a fix - doing something like this is not what you would necessarily call common.
45
Archived fixes / Flexbox bug
« on April 5th, 2013, 05:10 PM »
From a PM. I have clearly hidden who sent it and the content because none of that is relevant. The first code snippet has issues with the horizontal scrollbar, the second forces the entire post to have a scrollbar.
Also note the poster width is different too. Chrome 26, btw.
Also note the poster width is different too. Chrome 26, btw.
* Arantor thinks flexbox is buggy :(