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
2296
Plugins / Re: Maximum Images Per Post
« on December 5th, 2012, 04:22 AM »
Just a random thought, instead of doing a preg_replace first, couldn't you just:
Code: [Select]
(Yes, I looked at your max images plugin as the base for Word Count Limits. Made me realise how messed up the API is.)
return substr_count(strtolower($body), '[img');(Yes, I looked at your max images plugin as the base for Word Count Limits. Made me realise how messed up the API is.)
2297
Plugins / Word Count Limits
« on December 5th, 2012, 04:02 AM »
OK, so I ported my old Word Count Limits plugin to Wedge[1], and I did some overhauling in the process.
The idea of the plugin is to limit posts that are either too short or too long, and do something about it. In this case, it hooks into the moderation filters stuff, so you can make moderation systems as flexible as you like.
Want to enforce a minimum of 5 words on every post? Easy.
Want to enforce a minimum of 100 words on every new topic (not just replies), but only in a certain board? Almost as easy. (Moderation Filters > New Rule > Prevent the post when... a new topic is started... where board is <given board> and the number of words in the post is less than 100 words)
Yup, moderation filters is damn awesome, even if I do say so myself haha. Screenshot of this feature is attached.
Also, I made it so it could be both words and individual characters (where a complex accented letter or other multi-byte character is counted as 1) could be handled, through the same facility.
There is one caveat: right now moderation filters has one major flaw, in that the 'prevent the post being made' message is not very helpful - it just says 'The post contained content that is not permitted on this forum'. I know about that, I just don't know yet how best to fix it - I've been wrestling with it since I added mod filters months and months ago. The problem is that the combination of rules that could be causing a post to be denied is extremely complicated and potentially multiple rules could all cause the same result.
Imagine a rule that says the post will be prevented if the word 'fuzzlewuck' is in the post, but only if it's in the posted in certain boards, and they have less than 100 posts. How best to convey that to the user? (But the moderation filters can trivially enough create that set of rules.)
Anyway. I digress. Have at it. (It's in the plugin area for beta testers)
Also, the API for extending moderation filters needs cleaning up. I know live627 kind of hinted at that, but damn it is ugly. When I figure out the above problem, I'll clean up the API while I'm at it, it'll probably need it.
The idea of the plugin is to limit posts that are either too short or too long, and do something about it. In this case, it hooks into the moderation filters stuff, so you can make moderation systems as flexible as you like.
Want to enforce a minimum of 5 words on every post? Easy.
Want to enforce a minimum of 100 words on every new topic (not just replies), but only in a certain board? Almost as easy. (Moderation Filters > New Rule > Prevent the post when... a new topic is started... where board is <given board> and the number of words in the post is less than 100 words)
Yup, moderation filters is damn awesome, even if I do say so myself haha. Screenshot of this feature is attached.
Also, I made it so it could be both words and individual characters (where a complex accented letter or other multi-byte character is counted as 1) could be handled, through the same facility.
There is one caveat: right now moderation filters has one major flaw, in that the 'prevent the post being made' message is not very helpful - it just says 'The post contained content that is not permitted on this forum'. I know about that, I just don't know yet how best to fix it - I've been wrestling with it since I added mod filters months and months ago. The problem is that the combination of rules that could be causing a post to be denied is extremely complicated and potentially multiple rules could all cause the same result.
Imagine a rule that says the post will be prevented if the word 'fuzzlewuck' is in the post, but only if it's in the posted in certain boards, and they have less than 100 posts. How best to convey that to the user? (But the moderation filters can trivially enough create that set of rules.)
Anyway. I digress. Have at it. (It's in the plugin area for beta testers)
Posted: December 5th, 2012, 03:58 AM
Also, the API for extending moderation filters needs cleaning up. I know live627 kind of hinted at that, but damn it is ugly. When I figure out the above problem, I'll clean up the API while I'm at it, it'll probably need it.
| 1. | http://custom.simplemachines.org/mods/index.php?mod=2117 if you're wondering. Though this is better, even if the underlying detection for word count is much the same. |
2298
Features / Re: Plugin revs
« on December 5th, 2012, 03:50 AM »
(4 files, 1 folder, 11KB)
Revision: 61
Author: arantor
Date: 05 December 2012 02:49:24
Message:
+ [Word Count Limits] Initial checkin.
----
Added : /word_limits
Added : /word_limits/WordLimits.english.php
Added : /word_limits/WordLimits.php
Added : /word_limits/WordLimits.template.php
Added : /word_limits/plugin-info.xml
Revision: 61
Author: arantor
Date: 05 December 2012 02:49:24
Message:
+ [Word Count Limits] Initial checkin.
----
Added : /word_limits
Added : /word_limits/WordLimits.english.php
Added : /word_limits/WordLimits.php
Added : /word_limits/WordLimits.template.php
Added : /word_limits/plugin-info.xml
2299
The Pub / Re: Documentary Videos
« on December 5th, 2012, 03:21 AM »
What got me started on this - aside from remembering that XenForo had done it because it's a good idea - is the complexity of the moderation filters setup. It's a very, very powerful facility, and it needs some explanation that a manual probably doesn't cover very well.
2300
Plugins / Re: Calendar
« on December 5th, 2012, 03:20 AM »
And therein lies the problem. I actually had a sort of related discussion earlier on today that touches on this.
Nao and I have an awkward position: we're just not able to throw any old code together and push it out. Even if we were cowboys without scruples, we certainly shouldn't be doing that. Being the project developers is a responsibility - buying into our platform[1] means we have certain responsibilities as part of that.
One of those responsibilities, as far as I'm concerned, is making sure users have their data to themselves. If they want to integrate it with third parties for whom privacy is a buzzword to toss around, that's their problem, not mine. But that's not really the issue that irks me so much.
What gets me is when people are quite prepared to suggest that I toss aside something I've spent a lot of time and energy on, so they get their shiny thing quicker (because if I'm not working on something, presumably I can drain my spare time off into fixing some of the other stuff). They forget that what gets done around here is solely down to Nao and I having the time and energy to do it, and every time I hear 'you shouldn't bother with that, you should just use <x>', I can't help but see hypocrisy in it. And that annoys me immensely.
Take this very example. There are reasons why I could dispense with the calendar. Some people don't want it, and that's cool. But to suggest I should stop working on it (when I was quite enthusiastic about it!) just because there are 'more important' things to work on is a great fallacy and one only enjoyed by the ignorance of what's involved.
See, Wedge isn't just a forum software. It's a platform at the heart of a (currently very small) ecosystem. The core doesn't need a calendar, as evidenced here. But the ecosystem does, and I can't rely on third parties to develop it (either as a self contained feature or integrated into Google Tentacleplex), so I have to do it - and I think a lot of people actually forget things like that. But I can't forget it. I don't have that luxury, I wish I did, because it would make my life a lot less stressful.
Let me add a little something to the party. I have a spreadsheet listing SMF mods. I'm not ashamed to admit this, but it lists every mod on the mod site as far as I was able to compile it, and by the name of each mod, I have a listing for 'yes', 'no', 'maybe', 'should be core' and 'is already core'. There are about 1600 items on this list, of which there are nearly 300 to-do items on there, almost 600 no's, and about 500 maybes, the rest being made up by as-core or already core, or in 11 cases so far, ones where plugins exist to replace that functionality.
That is, ultimately, how I see the ecosystem. There's so much left to do. And I would really appreciate people not telling me that I shouldn't bother and just hand it off to a third party who cannot be trusted to do anything.
Nao and I have an awkward position: we're just not able to throw any old code together and push it out. Even if we were cowboys without scruples, we certainly shouldn't be doing that. Being the project developers is a responsibility - buying into our platform[1] means we have certain responsibilities as part of that.
One of those responsibilities, as far as I'm concerned, is making sure users have their data to themselves. If they want to integrate it with third parties for whom privacy is a buzzword to toss around, that's their problem, not mine. But that's not really the issue that irks me so much.
What gets me is when people are quite prepared to suggest that I toss aside something I've spent a lot of time and energy on, so they get their shiny thing quicker (because if I'm not working on something, presumably I can drain my spare time off into fixing some of the other stuff). They forget that what gets done around here is solely down to Nao and I having the time and energy to do it, and every time I hear 'you shouldn't bother with that, you should just use <x>', I can't help but see hypocrisy in it. And that annoys me immensely.
Take this very example. There are reasons why I could dispense with the calendar. Some people don't want it, and that's cool. But to suggest I should stop working on it (when I was quite enthusiastic about it!) just because there are 'more important' things to work on is a great fallacy and one only enjoyed by the ignorance of what's involved.
See, Wedge isn't just a forum software. It's a platform at the heart of a (currently very small) ecosystem. The core doesn't need a calendar, as evidenced here. But the ecosystem does, and I can't rely on third parties to develop it (either as a self contained feature or integrated into Google Tentacleplex), so I have to do it - and I think a lot of people actually forget things like that. But I can't forget it. I don't have that luxury, I wish I did, because it would make my life a lot less stressful.
Let me add a little something to the party. I have a spreadsheet listing SMF mods. I'm not ashamed to admit this, but it lists every mod on the mod site as far as I was able to compile it, and by the name of each mod, I have a listing for 'yes', 'no', 'maybe', 'should be core' and 'is already core'. There are about 1600 items on this list, of which there are nearly 300 to-do items on there, almost 600 no's, and about 500 maybes, the rest being made up by as-core or already core, or in 11 cases so far, ones where plugins exist to replace that functionality.
That is, ultimately, how I see the ecosystem. There's so much left to do. And I would really appreciate people not telling me that I shouldn't bother and just hand it off to a third party who cannot be trusted to do anything.
| 1. | Remember, it's not all about money, not all investment is financial. |
2301
The Pub / Documentary Videos
« on December 5th, 2012, 03:08 AM »
I've been thinking about doing some videos about Wedge's features - not unlike the 'Have You Seen' board in XenForo's main community forum.
Partly it lets me showcase some of the things we do have, and partly it lets me explain things in a way that I just can't with a conventional forum post.
Thoughts? I don't want to automatically jump at GoogleTube because I think they're just as bad as anything else going on in the Google Tentacly Monster. But I'm not sure any of the others are any better.[1]
Partly it lets me showcase some of the things we do have, and partly it lets me explain things in a way that I just can't with a conventional forum post.
Thoughts? I don't want to automatically jump at GoogleTube because I think they're just as bad as anything else going on in the Google Tentacly Monster. But I'm not sure any of the others are any better.[1]
| 1. | GooTube gives effectively free bandwidth, with ads. Vimeo... Vimeo actually sucks. Plus would be ideal but for videos that 'promote', that would be the much more expensive Pro account. Mind you, that didn't seem to stop XenForo... guess it depends on the difference between promotion and discussion. |
2302
Plugins / Re: Calendar
« on December 5th, 2012, 02:24 AM »
I have to be honest, that's encouragement I do need right now.
It just seems like every time I suggest something of late, I'm presented with the feeling that it's a stupid idea and that I should just use someone else's work instead (never mind whether it's suitable or not, just that I shouldn't bother with my own ideas and just work on reusing everyone else's)
It just seems like every time I suggest something of late, I'm presented with the feeling that it's a stupid idea and that I should just use someone else's work instead (never mind whether it's suitable or not, just that I shouldn't bother with my own ideas and just work on reusing everyone else's)
2303
Off-topic / Re: Play the Alpha version of a RTS space game
« on December 4th, 2012, 04:42 PM »
No, you didn't get banned elsewhere because you didn't get to defend your posts, but because you've joined a forum to post about your game where it is basically inappropriate.
What made you post here? We're not a game forum, by any means, so from our standpoint you've done nothing different to any other spammer, joined up solely to broadcast a link that is nothing to do with the site you're on. Small wonder you've been banned elsewhere.
What made you post here? We're not a game forum, by any means, so from our standpoint you've done nothing different to any other spammer, joined up solely to broadcast a link that is nothing to do with the site you're on. Small wonder you've been banned elsewhere.
2304
Off-topic / Re: Play the Alpha version of a RTS space game
« on December 4th, 2012, 02:58 AM »
On the other hand, if we're popular enough to be considered a human spam target that's a good thing :D
2305
Off-topic / Re: Play the Alpha version of a RTS space game
« on December 4th, 2012, 01:36 AM »
I mean, don't get me wrong, I think it is neat, I just think this is a human spammer until I see some evidence to the contrary. (It doesn't feel like a pump and dump email scam.)
2306
Off-topic / Re: Play the Alpha version of a RTS space game
« on December 4th, 2012, 12:06 AM »
And you joined just to spam?
2307
Archived fixes / Re: Add plugin doesn't work
« on December 3rd, 2012, 09:06 PM »
Yes, of course it does.
But for attachments and AeMe uploads, at least there is a layer of insulation. It's not executing that code directly, or at least it shouldn't be. (And there are .htaccess rules to prevent files being requested directly and to prevent PHP execution)
It's one of the long-standing issues in PHP and web server design. In the truly separated spaces, single site on a VPS for example, this wouldn't be a risk because you wouldn't have other users to contend with (only flaws in your running applications stack, but that's a given) - we're dealing with the state of play on a shared server, where by definition there are tons of other users on a server, all of whom have the ability to access those files by definition - they have to be writable by a user who isn't the file owner.
The difference, ultimately, is that attachments are other uploads are a calculated and considered acceptable risk. They shouldn't be called directly, nor executed, so the risk that they get malware or similar is actually small - there's not a significant payoff in compromising those files.
But if you can compromise live PHP on a site, it's going to try to compromise anything else on the server - there's a payoff in doing it.
But for attachments and AeMe uploads, at least there is a layer of insulation. It's not executing that code directly, or at least it shouldn't be. (And there are .htaccess rules to prevent files being requested directly and to prevent PHP execution)
It's one of the long-standing issues in PHP and web server design. In the truly separated spaces, single site on a VPS for example, this wouldn't be a risk because you wouldn't have other users to contend with (only flaws in your running applications stack, but that's a given) - we're dealing with the state of play on a shared server, where by definition there are tons of other users on a server, all of whom have the ability to access those files by definition - they have to be writable by a user who isn't the file owner.
The difference, ultimately, is that attachments are other uploads are a calculated and considered acceptable risk. They shouldn't be called directly, nor executed, so the risk that they get malware or similar is actually small - there's not a significant payoff in compromising those files.
But if you can compromise live PHP on a site, it's going to try to compromise anything else on the server - there's a payoff in doing it.
2308
Archived fixes / Re: Add plugin doesn't work
« on December 3rd, 2012, 08:07 PM »
Oh, I got a solution. I found a zip extraction library, but that it needs some clean up. Like using a proper __construct method, stripping dozens and dozens and dozens of lines of stupid and useless comments (like // ------ Return, just before a return statement) and general cleanliness stuff.
That and the fact that I've already stripped 55KB off the original 199KB by cleaning the code up.
OK, here's the underlying logic.
* The core Wedge files and folders should never be writable by the webserver under normal circumstances. The single greatest reason for things being hacked is files being writable when they shouldn't be, on a shared server. Thus, the files not being owned or typically writable prevents that from being the case.
* We don't have a temp folder anywhere in the Wedge installation for this reason, and I'm loathe to make one for the above - doubly so when it's directly accessible via user-side HTTP. Given how much hassle SMF has with its temp folder being added/removed, I want to avoid it entirely.
* This means any temp file is going to be in the system temp folder - where the upload is going to go anyway. But the system temp folder is writable by any user. As a result, anything that goes through there is potentially open to contamination. Once stuff is extracted, it's pushed via S/FTP to the plugins folder where it is essentially live. As such it absolutely has to be as safe as it can be - and everything I can do to prevent contamination on the shared server, the better.
* The other problem with system temp folders is that you can't guarantee the lifetime of any file. Limiting it to just the uploaded zip file is one step to protecting that.
I don't think I'm being particularly paranoid, or suffering from NIH[1], but this is the weakest part of the system and short of just dropping it and forcing everyone to upload manually (which as I stated does also prevent things like updates being handled well), it's a no-go.
Note that even without the zip component, I'd still need to do a lot of the same for things like handling smileys, the same deal with uploading via S/FTP is going to be the case.
That and the fact that I've already stripped 55KB off the original 199KB by cleaning the code up.
OK, here's the underlying logic.
* The core Wedge files and folders should never be writable by the webserver under normal circumstances. The single greatest reason for things being hacked is files being writable when they shouldn't be, on a shared server. Thus, the files not being owned or typically writable prevents that from being the case.
* We don't have a temp folder anywhere in the Wedge installation for this reason, and I'm loathe to make one for the above - doubly so when it's directly accessible via user-side HTTP. Given how much hassle SMF has with its temp folder being added/removed, I want to avoid it entirely.
* This means any temp file is going to be in the system temp folder - where the upload is going to go anyway. But the system temp folder is writable by any user. As a result, anything that goes through there is potentially open to contamination. Once stuff is extracted, it's pushed via S/FTP to the plugins folder where it is essentially live. As such it absolutely has to be as safe as it can be - and everything I can do to prevent contamination on the shared server, the better.
* The other problem with system temp folders is that you can't guarantee the lifetime of any file. Limiting it to just the uploaded zip file is one step to protecting that.
I don't think I'm being particularly paranoid, or suffering from NIH[1], but this is the weakest part of the system and short of just dropping it and forcing everyone to upload manually (which as I stated does also prevent things like updates being handled well), it's a no-go.
Note that even without the zip component, I'd still need to do a lot of the same for things like handling smileys, the same deal with uploading via S/FTP is going to be the case.
| 1. | Not Invented Here syndrome |
2309
Archived fixes / Re: Add plugin doesn't work
« on December 3rd, 2012, 01:18 PM »
Not browsing how I want it, no.
2310
Archived fixes / Re: Add plugin doesn't work
« on December 3rd, 2012, 03:39 AM »
Given how many people seem to have trouble with even the most basic of tasks, I've been wondering the same thing, but on the other hand, if the framework is there for such things, it's also going to be possible to do things like plugin updates.
Cutting this out cuts out a *lot* of other stuff too.
Cutting this out cuts out a *lot* of other stuff too.