Wedge

I've been thinking about this lately after cruising around sm.org, and the more I think about it, the more I don't want files being edited by plugins.

If a plugin requires a core edit, the user should have to do that themselves. We lose the ability to do quick patches SMF style, but I'm not convinced that's a bad thing either.

What finally made me change my mind? The number of reports of 'my site's been hacked'. Sure, on shared hosting you're definitely at more risk than you are on a VPS, but there is an inherent risk on a shared host that is made distinctly worse by having to change the file permissions, especially as people will often go away and change them to be writable generally when they don't need to, to avoid hassle in the future.

By limiting the scope of what is needed to be edited, the core files never need to be handled in that way.

The only argument that is on the other side of the fence is about people doing raw changes, but firstly if you are doing raw changes, that puts the onus on you to back up and so on. And it puts the onus on you to remember the changes you made.

Thing is, WP acts like this and it seems to be tolerated over there, but what happens is that the automated update actually can tell you what files are changing and you can then go away and figure out for yourself whether you should or should not deal with that.

I have no problem telling users that if they're going to modify the core software, they're responsible for the consequences, but I'm not going to babysit them for upgrading. There are good reasons why hacking the core shouldn't be done, and I'm finally convinced beyond doubt now that the benefits are easily outweighed by the problems attached.

Something that I need to write sometime: a plugin that queries the tables, lets users pick a table (or tables), and it should output the XML that the plugin-info.xml file uses.

Doesn't need to be pretty but it would be a useful plugin builder tool.

Leaving this here as a note for the future: if I or someone else makes a paid work and people ask about it for free, provide this link: http://shouldiworkforfree.com/

It seems to answer all the difficult questions.

Been thinking a lot about this over the last few days and discarded more UI designs than I can think of for it (eek), but I want to share how I envisage post moderation working from a configuration point of view, and on a related note, why it needs to be changed.

I'm not looking at the mechanics of how approval itself is managed, simply at how one configures what the rules for placing posts on moderation are.

So, what's wrong with SMF's post moderation configuration? Firstly, Core Features. Regular readers will know that I loathe and detest that page. It's nice enough but it's illogical for a regular user to deal with. The number of people who, in the last couple of years, have asked how to turn it on should be proof enough of that.

Then, assuming you turn it on, post moderation shares one dubious award with the calendar, in being the only areas of SMF whose access permissions are configured in three different interfaces (that all do the same job). Yes, that's right, there are three different ways you can set permissions for post moderation - the simple and the classic permissions interfaces, and its own custom page.[1]

And notwithstanding the fact that you have to actually then configure it. It would take a genius of Vizzini's stature[2] to configure post moderation right first time unless you know how it's implemented, since it's *really* not clear from the permissions page.

Here's the problem: nowhere in the permissions does it ever tell you that if the user, for any reason, has 'post... without requiring approval', that overrides 'post... but hide until approved'. Unless you farted around, you'd never come to that conclusion on your own. It's almost broken enough that I'd call it a bug but it was as designed, seemingly. (It's designed by programmers, rather than *for* users.)

Let me explain the problem of doing this on a fresh SMF install, and you're welcome to join in at home. Today's challenge: configure it so that regular users don't have moderation but new users with up to and including 5 posts are moderated.

There are, in fact, two ways to do this, both of which are convoluted.

1. Turn on post moderation in Core Features.
2. Making sure that the 0-post count group is left alone, create a new post count group that requires 5 posts, so that once a user has successfully posted 5 posts (and until they're approved, it won't affect their post count), they can have different permissions attached.
3. Admin > Members > Permissions > Settings > Enable permissions for post count based groups (tick) > save

Here's where the paths diverge. Here's path A:
A4: On the same page as above (Admin > Members > Permissions > Settings) also enable Enable the option to deny permissions
A5: Go to Admin > Members > Permissions > Board Permissions and for each profile (that allows posting) set the permissions up as follows: Regular members should have "Post new topics, without requiring approval" and "Post replies to topics, without requiring approval" enabled, while the 0-post count group should have those permissions *denied* and "Post new topics, but hide until approved" and "Post replies to topics, but hide until approved" in their place. Once the user leaves the 0-post count group for the 5-post count group, the other permissions are no longer denied.[3]

Or, path B. It doesn't require deny permissions but it does things another way.
B4: Go to Admin > Members > Permissions > Board Permissions. For Regular Members, set all the posting permissions to disallow. Then in the 0-post count group, give them "Post new topics, but hide until approved" and "Post replies to topics, but hide until approved" and for every other post count group, give them "Post new topics, without requiring approval" and "Post replies to topics, without requiring approval".[4]

Either way, banal and frustrating (and in fact, you still have to do the same thing using the other interface but it's actually slightly *more* confusing, not less there).


So, here's what I think instead. I haven't quite found a UI I'm happy with which is why there haven't been any screenshots or commits on it yet.

Post moderation is one of those things that you're going to be setting rules for. Think about it; every time you actually want to set post moderation, it's going to be because you want it for specific situations. Some of those will be rather broad but specifically defined (all users with under 5 posts), some will be very specific (all new topics in a certain board)

Doing that last one in SMF is a brainfuck, in fact.[5] So instead, why not some kind of interface that lets you set those rules?

In fact, you can boil down almost every single kind of post moderation situation to rules. Some of them are simple rules, some of them are rules with conditions, and some are rules with exceptions, some with both conditions and exceptions.

But really, that's what's needed. Something to construct rules like:

* moderate all posts "where the user has less than 5 approved posts"
* moderate all new topics in "board x"

Then you can get more fancy:
* moderate all new topics in "board x" where "user has less than 100 posts"
* moderate all new topics in "boards x, y and z" where "user has been registered less than a week"

Or even:
* moderate all posts in "all boards" where "user has less than 10 posts" except "board x" (maybe it's a chit chat board where spamming is allowed, I dunno)

That's the core ruleset, creating rules about the user, but there's no reason why it couldn't be extended to other things like creating conditions or exceptions based on groups, or other user characteristics.

Then, just for fun, I want to introduce non-member-based rules. For example, I want to have it able to moderate posts that automatically contain certain words. I also want it able to moderate posts if they contain a certain number of links. (And have exclusions for all those things based on members etc. If a member has 200 posts, I don't think they should be limited from posting three or four links in a page for example)


I don't think any of this is over the top, I just think this is complicated to get right in a UI context and I'm more conscious of doing that than I ever used to be.

It's interesting to note that there are circumstances which could 'theoretically' be simpler to construct in SMF's environment but the reality is that they're pretty few and far between.


Thoughts?

Also as a footnote, let me add that I would be ditching the core features setup, and simply base it on whether there are any rules defined - no rules = post moderation is off.

1.	It actually gets its own page, template and images, while the calendar has to make do with using internal routines. But still, three places, and it's unique in how far the third page goes, elevating it in a class all of its own.
2.	Vizzini: Let me put it this way. Have you ever heard of Plato, Aristotle, Socrates? Morons. (If you don't recognise the line, do yourself a favour and look the film up. You won't regret it.)
3.	But now we have an extra membergroup that does absolutely nothing other than allow another group's permissions to expire.
4.	This means you still have the extra group, but at least the extra group is now doing something. This is also very fractionally faster, but harder to maintain as you have to set the new permission up on any new post count group you create.
5.	New board profile and everything. Notice I skipped over that small detail in the above, but it's true.

I'll just leave you with this article to ponder over: http://www.theregister.co.uk/2011/11/22/frank_fisher_creative_class/

I've flipped and flopped about a number of these things before, and it was a while ago that I figured I could include a bunch of the SEO tweaks into the core to shut people up about it, but I'm increasingly convinced that it would be better for me and for Wedge not to do that, but instead make a single multifunction plugin that 'did everything'.

It'll mean that instead of a bunch of little tweaks and a bunch of core things that I don't really want in the core, I can build a single plugin that does everything which will have a performance benefit as opposed to lots of little plugins.

I also think it demonstrates that, frankly, SEO is not a priority for Wedge (because it isn't) and is more reaffirming of my belief that SEO for forums is largely a waste of time than any pandering to those that refuse to listen to the evidence...

Been thinking about this today, and it's bugging me.

It occurred to me that there are a ton of tiny variation mods on sm.org for altering this stubby little block of posts, not to mention it being discouraged to even be used in the first place due to performance issues with it.

So it occurs to me, I could rip it out, turn it into a plugin and make it much more flexible than the core could be. It could show in the sidebar, or not, it could show with a variety of layouts etc, because that can all be handled more nicely through a plugin than it can in the core (since in the core we pretty much have to roll with one overall look, which is 'in the sidebar, not very flexibly')

Thoughts?

(And no, this isn't just because I'm trying to slowly divest the crap I never use into plugins or anything :whistle:)