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
1651
Features / Re: Editing PMs
« on February 9th, 2013, 06:25 AM »
Yeah, there's no way to know that. Even if SMF sent read-receipts (which it doesn't), it doesn't have any way to track them and not all clients even send receipts anyway.
1652
Features: Posts & Topics / Re: Moderation Filters
« on February 9th, 2013, 06:25 AM »
MOAR FEETCHURES! :D
1653
Features / Re: AJAX Likes
« on February 9th, 2013, 06:24 AM »
The backend already supports it, I just need to write the client JS for it. It's been how many months already?
1654
Features / Re: Editing PMs
« on February 9th, 2013, 06:21 AM »
PMs being read is implicitly tracked even in SMF. The problem is, we introduced 'mark PMs unread' :D
1655
Features: Posts & Topics / Moderation Filters
« on February 8th, 2013, 11:25 PM »
Feature: Moderation Filters
Developer: Arantor
Target: Moderators
Status: 98% (there's things I could do with it that aren't currently done, but things most people probably won't even notice)
Comment:
This one needs a bit of explaining. I never liked the way SMF handled post moderation. I remember the first time I did it, and it bugged the hell out of me. So I came up with this.
Essentially, the idea is to run a series of rules when a post is made, and potentially take action based on the post, its contents and/or its author.
Rules are constructed in the forum of:
* Moderate the post... when any new post is made... if the following conditions are met.
or
* Prevent the post being made... when a new topic is started... if the following conditions are met.
There are also other options available, too.
In essence, this gives you very fine control over moderation without having to manually involve moderators. Don't like certain words being used (e.g. profanity)? Easy, just create rules to prevent the post even being made if it contains a word you don't like.
You can also mix and match criteria, for example you can block posts being made, in a certain board, if they contain certain words and it isn't a moderator making the post. The functionality is there to enable you to tailor the automatic moderation for your community, and the system is extensible, too.
Out of the box, you can prevent a post, moderate a post, or even pin/lock a post[1], limited to just new topics, or for any post. And out of the box you have the choice of a lot of variables: what board the post is in, the post count of the user, the warning level, content of the subject, content of the body, which group the user may/may not be in, or how many links are in the post.
Already, too, there are additional plugins for this, which add facilities like how many smileys are used, how many images are used, the number of words in a post and more, so there really are a lot of options for flexibility.
Developer: Arantor
Target: Moderators
Status: 98% (there's things I could do with it that aren't currently done, but things most people probably won't even notice)
Comment:
This one needs a bit of explaining. I never liked the way SMF handled post moderation. I remember the first time I did it, and it bugged the hell out of me. So I came up with this.
Essentially, the idea is to run a series of rules when a post is made, and potentially take action based on the post, its contents and/or its author.
Rules are constructed in the forum of:
* Moderate the post... when any new post is made... if the following conditions are met.
or
* Prevent the post being made... when a new topic is started... if the following conditions are met.
There are also other options available, too.
In essence, this gives you very fine control over moderation without having to manually involve moderators. Don't like certain words being used (e.g. profanity)? Easy, just create rules to prevent the post even being made if it contains a word you don't like.
You can also mix and match criteria, for example you can block posts being made, in a certain board, if they contain certain words and it isn't a moderator making the post. The functionality is there to enable you to tailor the automatic moderation for your community, and the system is extensible, too.
Out of the box, you can prevent a post, moderate a post, or even pin/lock a post[1], limited to just new topics, or for any post. And out of the box you have the choice of a lot of variables: what board the post is in, the post count of the user, the warning level, content of the subject, content of the body, which group the user may/may not be in, or how many links are in the post.
Already, too, there are additional plugins for this, which add facilities like how many smileys are used, how many images are used, the number of words in a post and more, so there really are a lot of options for flexibility.
| 1. | For example, a rule where the post is made by a moderator, and begins with /lock to lock a topic quickly. |
1656
Features: Security / Re: Bad Behavior
« on February 8th, 2013, 11:08 PM »
I think what will be far simpler is to just go through and review the features added/removed by comparison to SMF at the end, heh.
I will add the mod filters item to the Features board, meant to do it already.
I will add the mod filters item to the Features board, meant to do it already.
1657
Features / Re: Mini-skeletons
« on February 8th, 2013, 11:07 PM »Added support for <move> on any skeleton, but also for <rename> and <remove>... Dunno what else I should support...
Also, I decided to have these commands in skeleton.xml instead of skin.xml, but I'm not sure what's best.
Wedge loads all skeleton.xml files (parents and children), from root to deepest level, and concatenates them. It doesn't care about 'replace' type items, mostly out of laziness. skin.xml is loaded but also deleted everytime it finds a new child skin.xml... I don't really know which is the best 'behavior'... Perhaps I should even drop support for replace-type skins... But I'm not confident that Weaving is simple enough to accomodate for everything. Meh...
Oh, you mean that... No, I just meant showing a list of links to the posts, each pointing to them 'in context'.Quote from Arantor on February 8th, 2013, 09:38 PM The concept of displaying an individual post on its own is nothing new - vB did it (I assume it still does but the train wreck since vB 4, I have no idea what it does and does not do any more)
I never saw it as limited... But then again, you're the specialist.. :^^;:Quote No. Bans are for getting rid of people. Warnings are for less serious matters, behavioural correction. The current warning system is a bit limited.
I've long since wanted to break the warnings down into smaller units, and throw in extra ones - like removing avatars, signatures for people who can't be trusted, or the infamous Disemvoweler. (The grunt of that is already implemented, it just needs the rest of stuff implemented for it)
That, combined with predefined warnings that come with predefined behaviours (or at least, allow the admin to set these things up), e.g. see a user with an inappropriate avatar, send them a preset warning that automatically removes their avatar for a day. Just for example.
These are things the current warning system can't do.
Or maybe have two types of child skeletons, like in permissions... a copy type, and an extend type. copy = independant, extend = uses the same stuff as its parent(s).Quote Well, such behaviour is fine if it is documented, especially if there is a given actual use in the core.
I can already feel the headache coming up... Ahh... Ahhh... Yes it's here.
I won't insist, all right... :^^;:Quote Today has been... interesting.
Mine has only been interesting by the fact that Milady is travelling with a friend and thus I had all the time I needed to take matters in hand and finish the mini-skeleton system... Which would have probably stalled otherwise... :whistle:
1658
Features / Re: Mini-skeletons
« on February 8th, 2013, 09:38 PM »Could even just show the links to individual posts, without bothering to show the posts... Hmm?Quote from Arantor on February 8th, 2013, 07:13 PM Tempting, very tempting.
Warning? Like, soft banning..?Quote I'm still wrangling with design work for the new warning system right now.
Yeah, but it's not so great when it comes to consistency.Quote Sounds great to me.
I think I should just do <skeleton id="pm" extends="msg" /> and be done with it..?!
Then have skeleton commands like <move> elsewhere. I don't know. But this is also the kind of situation where I wonder, "should a move to the parent skeleton affect the child skeleton as well...?", and then BAAAAAH.
Err... Okay?Quote Not even close. The f-bomb has been dropped many more times today. Lots of stupidity out here in real life.
1659
Off-topic / Re: And people wonder why I think Facebook Connect is a bad thing
« on February 8th, 2013, 09:06 PM »
YT does actually have a static image preview IIRC.
1660
Off-topic / Re: And people wonder why I think Facebook Connect is a bad thing
« on February 8th, 2013, 08:27 PM »
Any kind of embedding of any content you don't have *total control* over is fundamentally dangerous. Even down to attachments, potentially, if you think about it.
It's all about what is acceptable risk.
Content inside an iframe theoretically should not normally be able to break out of the iframe. At least that's how it's supposed to be implemented. From a practicality and usability perspective, it's better than using Flash to embed video.
Privacy is a much thornier issue, and it's why crap like the half-assed cookie law came into play.[1]
The only way to get around that, then, is to simply not embed anything. That's cool, it's an option. Site owners have the choice.
They do also have the choice to use/not use FB Connect. MY choice is to not put them in the core. I have no problems defending this logic: aside from the practicalities attached to maintaining APIs as a core feature, I am wary of encouraging admins to defer control of authentication to a third party.
The fact that FB connect usually doesn't generate good forum participation is a small matter.
It's all about what is acceptable risk.
Content inside an iframe theoretically should not normally be able to break out of the iframe. At least that's how it's supposed to be implemented. From a practicality and usability perspective, it's better than using Flash to embed video.
Privacy is a much thornier issue, and it's why crap like the half-assed cookie law came into play.[1]
The only way to get around that, then, is to simply not embed anything. That's cool, it's an option. Site owners have the choice.
They do also have the choice to use/not use FB Connect. MY choice is to not put them in the core. I have no problems defending this logic: aside from the practicalities attached to maintaining APIs as a core feature, I am wary of encouraging admins to defer control of authentication to a third party.
The fact that FB connect usually doesn't generate good forum participation is a small matter.
| 1. | The intent of the law is sound. The implementation is not. |
1661
Features / Reply to New Topic
« on February 8th, 2013, 07:22 PM »
I came across Discourse recently; it's a forum built on Ruby on Rails, and I described it as the bastard lovechild of Vanilla and Google Wave. This is not a good thing.
But it does have some interesting ideas, most interestingly for me, it has 'Reply to New Topic'.
The idea is that you can hit the reply button, leaving a reference back to the original topic (e.g. as a quote or link) but essentially convert what would otherwise be an off-topic tangent into a new topic.
It's one method of keeping things on topic in what is essentially a flat topic model like we have.
Thoughts?
But it does have some interesting ideas, most interestingly for me, it has 'Reply to New Topic'.
The idea is that you can hit the reply button, leaving a reference back to the original topic (e.g. as a quote or link) but essentially convert what would otherwise be an off-topic tangent into a new topic.
It's one method of keeping things on topic in what is essentially a flat topic model like we have.
Thoughts?
1662
Features / Editing PMs
« on February 8th, 2013, 07:16 PM »
So, this came up in recent conversation: the ability to edit PMs.
You can edit posts, should you be able to edit PMs that you yourself have sent?
Putting aside the small issue relating to email notifications, is this something that you would ever find useful? Concerns?
I can see the use of editing a PM for 10 minutes or so before actually sending in case you want to make last minute typo fixes or whatever.
Thoughts?
You can edit posts, should you be able to edit PMs that you yourself have sent?
Putting aside the small issue relating to email notifications, is this something that you would ever find useful? Concerns?
I can see the use of editing a PM for 10 minutes or so before actually sending in case you want to make last minute typo fixes or whatever.
Thoughts?
1663
Features / Re: Mini-skeletons
« on February 8th, 2013, 07:13 PM »All right Sherlock :P
I guess it just didn't jump to me that it was that regular.
Heck I didn't realize I myself posted a few messages at ALL hours of the day! But apparently, except for 3 posts, 4am is the hour where I'm sure to be asleep!
(Feature suggestion™: make these links clickable to actually see the posts I made at 4am... Wondering if they're intelligible at all :lol:)
Don't worry, as soon as I implemented it, I renamed it to an internal array... It made way more sense as it was a per-skeleton thing anyway.
Oh, can you believe that for the first time in my nearly 38 years of existence, I actually built an OBJECT from the ground up, that is not a SINGLETON, and that is actually more USEFUL than any equivalent procedural/functional code, and easier to read?
I'm astonished. I've always been anti-objects, but weSkeleton at least proved that large, complex code can benefit from being objectified... Well, not the case for Wess though, but I did my best too ;)
We'll just need to split the existing skeleton into more functions, to make it possible to do these.Quote That makes sense to me :)
I really did a basic one, as you'll see. <msg_author> is just a single block of code, I just didn't feel like splitting it into as many functions as needed. Feel free to do it by yourself, otherwise I'll just do it later on.
You mean "new weSkeleton('msg')"? Have a look at the source, that's what I did eventually ;)Quote
Originally I used 'msg' as a prefix, but I figured it was best used as a proper ID, for rendering quirks, i.e. main skeleton vs mini-skeletons. There were at least two places that needed to test against the main skeleton.
My code uses the <skeleton id>, so it wouldn't be able to see the context unless we use a modified skeleton with a different ID.Quote Let the source indicate it is a reply through whatever means it has to but then the template can display it, whether it wants to use an icon or anything else.
Hmm, maybe we could do something like... (prototype ahead!)
<copy-skeleton from="msg" to="pm">
<rename from="msg_author" to="pm_author">
</copy-skeleton>
Or something like that... Thus, no need to copy the actual skeleton, meaning that inherited skins can simply modify the parent skeleton and the rest will follow.
Most used word of the day. :angel:Quote Makes sense.
1664
Features / Re: Mini-skeletons
« on February 8th, 2013, 05:47 PM »I don't really remember you doing that other than for the last few weeks, except occasionally...
Started reading... Will have to forward to Milady, maybe it'll help her understand why I'm always systematically pulling a Cinderella... :P
Well, this came up when I wrote the mini-skeleton for Msg, really.
For instance, in the template, you get <footer> tags around the footer area if $context['ignoring'] is set. Instead of adding two tests in _before and _after, I figured I could simply disable these functions earlier in the code flow. Then it struck me that I couldn't disable _before and _after function calls, only the entirety of the block (_before, _after and the actual block itself), and adding a setting to disable only the _before and _after would make it look fucked up.
But just after that, I had to create a $context['show_action_bar'] variable to determine whether the action bar should be shown... And it's tested in all three places: before, during and after. In that particular case, having a temp disable could help me disabling the action bar very quickly.
I agree, though, that there's nothing that couldn't be addressed by what I'm doing right now -- $context variable tests in the individual functions.
But it's also an easy addition, I think... (?)
Just set $context['temp_disables'] or something (do you have a better name to suggest...?), and in the render_recursive function, if isset($context['temp_disables'][$id]) then return directly, do not pass Go. Then at the end of the render process, just unset the context var.
Here's a suggestion... Why don't you post a poll or at least create a new topic to discuss this? I'm sure it's a feature that many people would want -- and also, possibly, would dislike. I personally would rather have it.Quote There's absolutely no way to edit a PM once it is sent. I have never once questioned this logic, perhaps I should.
Heck, we could even have a feature to delay sending of PM notifications by a minute or so, just like Gmail does to give you time to cancel a sent message ("You're fired!" -- Oops, wrong To: field... Where's that Cancel button?!)
If it detects you're editing the message when it's supposed to send it, it can delay it by an additional minute, etc...
Okay, it's probably a BIT much for not much in return...! But sometimes, it could be helpful. I think.
Which is why it may be a 'bit much'.Quote
Alright, we could also simply disable the Quick Edit button in the msg skeleton... :lol:
Plus, I've resumed work on it... Did a few (lot of?) changes in the code path followed to create the main skeleton. For instance, wetem::hide() is called automatically by Wedge if the main skeleton can't be found -- which is either intentional (Ajax data), or accidental (not uploading skeleton.xml to the skins folder). At the very least, you'll be getting the default layer, instead of the "corrupted skin" fatal error. One could argue that the corrupted error is better for debugging, but I'm just not sure about it. For instance, if someone reloads your page WHILE you're upload a new copy of skeleton.xml, they might end up with that error, instead of at the very least getting the content they wanted.Quote This seems to make sense but I think it's the sort of thing that will only truly make sense when it is done and can be poked and prodded.
Anyway, all of this can be reverted later...
I've also gotten rid of the prefix.
Will commit my WIP soon. At least, it's working... ;)
Whadayamean..?Quote This affects both types of message, incidentally. I'd put it as part of however the subject is set up.
(I've implemented 'temp disables' and renamed it to just... 'skip', which makes more sense. The function is accompanied with a description that explains it's just for the next pass.)
| 2. | If it's a skeleton, part of it is a bone. |
1665
Off-topic / Re: And people wonder why I think Facebook Connect is a bad thing
« on February 8th, 2013, 05:14 PM »
They are, but they're perceived to be a transient thing.
Also, the option you're thinking of is actually commented out in the code and the default is 3 years not 1 ;)
Also, the option you're thinking of is actually commented out in the code and the default is 3 years not 1 ;)