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.

Messages - Arantor
991
Features / Re: Miscellaneous/WIP screenshots
« on April 12th, 2013, 04:20 AM »
Hmm, yes, I see your point.

As for being plugin material, you're right. It should be. It doesn't fit in the core. It's not exactly a lot of code at this point (since it essentially just issues a very specific type of warning in the log)

* Arantor gets out the bone saw and starts cutting :niark:
992
Features / Re: Miscellaneous/WIP screenshots
« on April 12th, 2013, 03:51 AM »
Sort of but sort of not the same thing. Suspend account or deactivate account implies a longer term permanence, rather than a shorter-term time-out.

That's why 1) the default is 2 weeks and 2) it's not in the screenshot but there's no 'indefinitely' option to the timescale.

I should add, I'm not exactly that enthused by this (it just struck me that it would fit alongside what I was already doing), it would not really worry me to actually not implement this and make it a plugin later.
993
Features / Re: Miscellaneous/WIP screenshots
« on April 12th, 2013, 01:19 AM »
So, one of the things I needed to do was fix up the ban settings in the profile area. I never fixed it up with the replaced ban system. Long story.

Anyway, while I started work on it, it occurred to me that a ban-yourself option might be worth doing, if you want to take a timeout from somewhere and don't necessarily have the proper discipline to enforce it - like me at times :P

This is WIP. I'd be quite happy to modify wording if people have better suggestions.
994
Features / Re: Mail entities and stuff.
« on April 12th, 2013, 12:29 AM »
Just be *extremely* careful doing that. The rewriter is not a cheap process if you have to factor in things like looking up pretty URLs - and if you're doing the DB lookup every call, that's potentially DB queries every time you send an email. For some cases, that's not horrible - one off emails are fine. But newsletters... not so much.
Quote
I'm thinking that there isn't much of a reason NOT to send HTML emails by default...
There are some email services that treat such things as more likely to be spam.
995
Features / Re: CSS inheritance issue
« on April 12th, 2013, 12:18 AM »
Quote
This is for a core feature..? Like, in the Wedge SVN? I suppose not, otherwise you'd have added it directly to index.member.css..?
That's the point. I DID add it to index.member.css. But it doesn't work! It needs to use the first half of input.submit's definition (because it extends input.submit) but it needs to be declared before the end of input.submit's declaration (the bit I quoted) because the background declaration in input.warn overrides input.submit's declaration of background-position.
996
Features / Re: CSS inheritance issue
« on April 11th, 2013, 09:43 PM »
The context is straight forward - input.submit declares some stuff, for its main declaration, further down - but *after* all the main input.whatever classes. And then input.member.css is declared after that.

I don't see a mixes would solve this - it's simply that unless input.submit's declaration for background-position is somehow after the content of index.member.css being included, it can't be done.
997
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]
input.warn extends input.submit
background: url($images/warning_ban.gif) no-repeat
background-color: #fff0e3
:hover
background-color: #fff5e8

Except, and this is the troublesome part, this part is declared, effectively, before my input.warn class:
Code: [Select]
// Declare position only here, so that inherited classes can also set it.
input.submit
background-position: 5px center

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 :(
998
Features / Re: Things I'm currently working on... (And not making progress on.)
« on April 11th, 2013, 03:43 PM »
Quote
Yeah, vB3 is an example of what NOT to attempt...
Maybe tabs are too much, alright. But so are multiple profile pages..?
I dunno. Needs more thought.
Quote
Yes, I never even mentioned the lang attribute, only the hreflang one... What made you think I was talking about the html tag's..?
Because I was, in another thread, when I went looking?
Quote
The only reason I want hreflang to be as specific as possible, is for Google to be better at serving the proper content depending on the user's geographical position. (Well, if it works... Because I have yet to see a Google link with language=... in it. Probably requires moving the language part to a subdomain, or something... Which I'm not too fond of.)
That would be because Google won't ever have such URLs in it and with very good reason. First: duplicated content issues, second: canonical tag does not include language. And even if it did, the actual content of the page is not translated or anything, so even if you were viewing this site in French, all the content (just not navigation) is in English.

In fact the best thing to do would be to actually use the board flags stuff I did and use *that* to indicate the page's language. I'm not even sure the language flags should even be followed, really. (And I'm pretty sure other rules will cause most stuff to be set to noindex because of it!)
Quote
For the record -- every time I re-enabled debug info, it got disabled after a while. It happened twice to me already this week... But, it never happened to me on wedge.org -- only on my local install! Any clues..?
Well, debug info is stored in Settings.php which implies you're resetting it somehow.
Quote
Something wrong must have happened at some point. But since the other day, my plugins have yet to be disabled again, so I guess it's alright now. (I did a database dump to check on my variables, and they were all alright -- so it SHOULD not have disabled them in the first place...)
Unless you moved everything and then fixed all the paths and then (and only then) did a refresh would it have preserved things.
999
Features / Re: Moderation Centre overhaul
« on April 11th, 2013, 05:33 AM »
Quote
I like the idea of differentiating between open/close for reported threads and pending/closed for groups etc.
Switch of the language string, easy done ;)
Quote
this is probably the only feature I truly missed from my vB days along with the infraction system but I've been following your updates on that as well
I actually think the infraction system in the works is likely to be quite effective because of the way it handles punishments, it's much more gradual than other systems.
1000
Features / Re: Moderation Centre overhaul
« on April 11th, 2013, 05:09 AM »
Just for the sake of clarity, I've attached what I had in mind. It's not perfect but it should be very illustrative of what I'm talking about. Of course we'd fix the new indicators to actually be highlighted if there something new in there, and I think we'd probably find new icons anyway for that.

I see no reason why the list of threads couldn't contain the board name as well. I didn't in the mock-up but I see no reason to limit it that way. I think I would probably have put that in actually, since the UI will be new. (Think message index but with a twist, rather than what we have now)

Actually if I'm honest it was vB that encouraged me down this path.
Quote
I'd argue it should be changed, as I did the edit it's not new to me :niark:
I think we can take a look at it ^_^ I will note that this commit is very quickly escalating in size so it won't be fixed by me any time soon.
1001
Features / Re: Moderation Centre overhaul
« on April 11th, 2013, 04:51 AM »
Quote
I took that to mean have all the moderation boards in a category by themselves or having the option of some facility to have each board display teir ow reported posts.
That wasn't what I meant. I should really make a mockup of what I'm thinking, might be easier to explain. I figured that you'd have a 'board' for reported posts, a 'board' for reported PMs, a 'board' for group requests, that kind of thing. You might want to put them in different places for some unknown reason, don't know why you would but you could.

That's what I was thinking but in hindsight a single category with that stuff in it would be enough.
Quote
This is kind of where my crazy brain was going... while viewing a particular board the number of open reported post would be indicated maybe in the sidebar or something like the attached.
That's where it starts getting messy. The total number of open mod reports is currently known (calculated and stored). It's not subdivided by board, and while we probably could make it do so, it's likely to get ugly quickly if we do.
Quote
Hmmmm bug maybe... editing my last post caused it to be marked as new for me.
That's actually something SMF has done in the past. We're not entirely sure whether we want to preserve that behaviour or not.
1002
Features / Re: Moderation Centre overhaul
« on April 11th, 2013, 04:07 AM »
Quote
Instead of unread, how about resolved/unresolved. As a moderator I'd rather go for the reports that havent been dealt with yet opposed to being presented with all unread reports.
Resolved/unresolved is an interesting concept but doesn't quite work properly for my money. I would rather envisage it as a variant of topics - open ones are open, closed ones are effective locked, and you only really need to track unread status for the open ones. But I can see the argument of not worrying about read/unread.

That said, the layout is totally malleable, because I'm not worried about keeping original code or anything, I'm quite happy to burn any of the original code and replace it with my own if that works. Most of the functionality isn't entirely bad, it's mostly poor UI from my perspective.
Quote
My desire would be more towards per board but of course in many if not most cases a category should suffice: so I'm willing to sacrifice my desires for the greater good if there are issues such as performance or difficulties in doing it per board. Again I'd throw this at the mercy of beong optional.
Performance and complexity is pretty much the same either way. I would argue that a category would be simpler to manage.

The main reason for pushing for boards/category rather than pushing for the current menu arrangement is quite simple - increased prominence. The menu, as prominent as it might seem, doesn't give prominence for details like the number of open items (now, we have the menu item highlighter, like PMs)
1003
Features / Re: Moderation Centre overhaul
« on April 10th, 2013, 11:36 PM »
Quote
I'm for the suggestions in their entirety. been gunning fr something of the sort for quite some time.
I had a lot of our conversations of the past in mind when writing this up. ;)
Quote
As for the original reporter being able to comment later, I'd say this would have to be optional.
I think it would be optional, but it's one of those things you can't really write in later, it either needs to be done up front or not at all.
Quote
however stubborn me would just rather the thing gets reported and the moderators deal with it according to site policy and be done with it.
I would note that of course, there could be PM conversations that would serve much the same purpose. But that raises almost as many issues if you're not careful.
1004
Features / Re: Moderation Centre overhaul
« on April 10th, 2013, 10:56 PM »
Quote
is it possible to have a post reported appear like the new member awaiting approval?
It already is. It already is even in SMF! It even shows up in the menu (that bit's not in SMF)
Quote
but for me there should only be alerts or notification and action to be taken and that action logged, what would be nice is to have it so that if a member is reported that you could click that persons name an it would take you to  where you can deal with that individual like ban, or warn, approve or what ever.
Much more than that is actually needed in a meaningful fashion for most sites, unfortunately.
Quote
And do away with the menu yes item, yes.
The moderate menu item has been gone for literally years - it's been under the admin menu for almost as long as I can remember - but I'm thinking about doing away with that too.
1005
Features / Re: Mail entities and stuff.
« on April 10th, 2013, 10:54 PM »
Quote
Don't get what you mean here...?
We don't have any controls over what's in a post, save for ensuring that quotes are saved as entities (which we do, for both kinds of quote) And we don't entitify everything as it currently stands. Since emails go out with post contents with no apparent problems (though we should retest this with accented UTF-8 characters to be absolutely sure), I don't see why there is a problem with the in-between bits doing exactly the same thing.