Wedge

OK, tl:dr version.

SMF's setup is royally broken, it's beyond a nightmare to configure and it's so unintuitive, even meriting the description 'nuclear clusterfuck' though not from me.

My suggestion is that instead of basing on permissions, to base it on rules instead. So that the admin can configure that posts will be moderated if:
* user has made less than x posts
* user is posting in x board(s)
* user has been registered less than a given period of time
* post will be moderated if it contains x words
* post will be moderated if it contains x links

Any or all of the above should be usable, and should be able to be configured with conditions or exceptions, e.g. post will be moderated if the user has < 10 posts OR contains a link, EXCEPT in board x. For example.

The idea is to provide some method for admins to set the rules they want to use and do so without faffing about with different post count groups or permissions or stuff.

(Also, you'll have to excuse me. Me and some people went to an all-you-can-eat Chinese restaurant, and not only did I eat a lot, I had some beer for the first time in a lot of months. I'm a bit squiffy right now.)

Sounds like perfect material for a plugin, and probably not a hard one to do either.

It was just a crazy idea, and I figured it might encourage a bit less going off-site.

For example, if we were to rename Class-Editor.php to Class-wedit, we wouldn't ever need to put a loadSource call in for it again. We could just refer to wedit, and if the class hasn't been already loaded, PHP can load it for us.

Stops you worrying so much about cross-dependencies by encouraging you to split things up and have them loaded on demand.

Mind you, I find it interesting that the general policy of Zend is to break things down to an atomic level; Zend stuff and stuff written to Zend standards generates a *lot* of small files. (xenForo has many 1-2KB source files for example)

Post and PM are similar, search is pretty unique, recent/unread/unreplies are all similar but they're not similar to search or posts/PMs, and I don't think they should be.

I'm not sure that putting in the user info would make a lot of positive difference in the search or any of the other areas (other than PM)

Even if people do make free software that's better than the paid competition, it's still not going to be acknowledged on the same level simply because it's not paid.*nods* You enjoy doing things for you, and like me the money is a side issue.If it's a top level layer in the sidebar (e.g. the info center as a whole) it can work just fine as a child of the default layer. The we:title is thematically consistent with we:cat, and it won't look particularly wrong.

But that's top level categories only and they might be expecting a ~220px wide column and do complicated things with floats and wrapping and so on that won't work on a bigger scale.

In that case, the compromise is to allow for both; if the developer knows in advance that it's going to work OK falling back to default, let them specify it, but if not, have the return value to accommodate it (which means they can dynamically do their own thing if they choose)Hmm. You know, we could solve some of this problem intelligently by setting up an autoloader function.

Depends what you're trying to do, really, I was more interested in allowing plugins to cleanly extend or alter the list of items, rather than customising it, but appropriate CSS would make a lot of difference.