Wedge

So this has been bugging me, and given the intimation of just dropping everything we have and building something from scratch - which I'm not afraid of doing - so I spent time thinking about what we have, what we don't have, what everyone else is doing and why they are doing it.

This is a mighty post. For each section, there is the tl:dr; version for you. It's marked in bold.

---

First up, post count permissions... actually no, let's start with post counts as a whole.

SMF/Wedge is in the minority in actually assigning physical groups to post counts, and even more so in actually being able to hand out permissions for the same. In most of the forum systems, you can't even set permissions by post count directly, some not even indirectly. (Some of the forum systems allow for a promotion system, so that users get bumped into a new group when they go above a certain number of posts and permissions are granted on that new group, but it's not intrinsically a post count group if that makes sense)

In other words in most systems, post counts are pretty much a display matter rather than an organisational one. This certainly seems consistent with most forums I've seen, and it's even consistent with how most people use SMF; permissions for post counts are disabled by default, and most people only seem to need to turn it on to do things like moderation of the first few posts - of course, that's no longer an issue for us since moderation isn't a 'permission' any more.

tl:dr; do we actually *need* or *want* post count permissions? It seems like it has served to confuse people more than it has helped them.

---

Even if we do keep post count permissions, I'm also inclined to suggest a change to the way it is handled. Right now it is handled by virtue of a physical group attached to the user's account - primarily for being easy to get their post group's group data, but we don't need that so much any more.

In fact, the whole concept of primary group and secondary groups doesn't actually make any sense any more. Previously it used to be that the primary group was for showing a badge but since we ditched that concept some time ago to allow for any badges to be displayed, perhaps it's time to ditch the primary group/secondary groups concept and just have 'groups'. I'd probably even take the opportunity to move user->group association into its own table. This would solve some issues in terms of limitations (systems with crazy numbers of groups have had problems with exceeding the size of the varchar field), and for lookups from groups->users, it'd get faster, while performance of user->groups should be largely unaffected.

Post counts would receive a similar setup, though I'd drop the post count entirely from the user's account, and apply them at the point where the user's account/data is loaded. (I'd have a subcache of groups->posts, so I just have to use that). There would be a tiny performance hit on loading that information, but it would also save 1-2 queries for every post.[1]

Assuming we do keep post count permissions and so on, this has another interesting side twist. We can easily then do hierarchical groupings. Right now if you have the classical groups, they are 0, 50, 100, 250, 500. What that means is 0-49, 50-99, 100-249, 250-499. 500+. They're explicitly exclusive to each other.

What I'm getting at is that we'd be able to make it truly 0+, 50+, 100+, 250+, 500+ - so someone in that topmost group implicitly would be in all the lesser groups too. You could display all their badges if you wanted.

Depending on we do with permissions, this may or may not be an issue - one thing that always bugged me in SMF is that if you wanted to assign a permission by post count, you'd have to do it to each group over and above the one you wanted. But I'm thinking I wouldn't do it that way either. I'd actually just assign a post minimum/maximum count for each permission that was post count related and do it that way.

There is also a fringe benefit that if people somehow manage to remove the 0 post count group, it won't suddenly fuck everything up like it will in SMF every time.

tl:dr; The idea of primary/secondary groups is obsolete, I want to move them to a separate table, and I have funky ideas about changing post count groups including their permissions if we still want them.

Also tl:dr; I would explicitly add *everyone* to 'Regular Members' if they are logged in. This seems more logical to me that the current situation which is a by-product of the primary/secondary group antics.

---

Permissions themselves are complicated. It's also not like I can just repurpose SimpleDesk here either.

For those wondering what I did with SimpleDesk, I did several very strange things - in hindsight - that worked modestly well. Firstly, groups didn't have any permissions whatsoever. You created roles, e.g. a staff role or a user role, attached one or more groups to it, attached it to one or more departments.

I had sm.org in mind when I designed it. You have one group who is 'users' (Charter Members) and you declare all the permissions that users need to have, like posting tickets. You have multiple groups who are staff (the various team groups), and you declare - once - all the permissions that staff need to have like replying to tickets, seeing everyone's tickets, etc. and then attach it to all those multiple groups.

Conceptually for the main part of the permissions, that'd work quite well and as I posted originally about it in http://www.simpledesk.net/community/index.php?topic=709.0 it worked well for '1.1' when we didn't have this whole multi-department thing going on. But in 2.0 it actually didn't work all that well once I'd bastardised department (board) support into it... in essence, what ended up happening was not how I originally envisaged it but I forget why.

If you had multiple departments with common groups and rights and stuff it wasn't a problem. You define the user role, the staff role and just attach it to all departments. Worked quite well. But if you had two departments with no common groups, it sort of fell flat.

You'd have Dept A, with User Role A and Staff Role A, pulling from groups A1 and A2 with Dept B/Users B/Staff B/groups B1 & B2. It got ugly fast.

Fortunately, I don't think that's so much of a problem. There are three principle levels of management in a forum: administrator, global moderator (aka super moderator) and board moderator, as well as the regular members. These translate quite well to roles, actually.

The problem with the concept is not getting users to understand the group->role->permission setup. It is the interface for managing roles to boards/departments/whatever you call them and for the cases where you want things like moderators only in one board and whatnot and to give them powers for it.

The problem, ultimately, is that you get a difficulty curve that is exponential compared to complexity; simple setups are simple, complex setups get extremely complex to setup. This seems to me to be related to the way the different systems actually seem to intentionally try to simplify things - IPB et al don't have deny permissions. It's just not an option. Which makes me wonder whether it just requires more careful allow setup rather than using deny.

I'm resigned to the fact that any permission system is going to generate questions on how to configure it, but I think I can make something that will make sense to people, but still doing the setup of groups->roles.

tl:dr; I want to move away from this groups->permissions setup to groups->roles->permissions. Other forum systems use it and it works for them. I see no reason it shouldn't work for us and should be more sensible for most users.

---

Admin permissions have always been a problem. Too many admins give out full admin permissions then ask how to remove them afterwards. IPB in particular takes the opposite approach: the only permission granted by the admin group is to be able to go to the ACP homepage. But unless you have other permissions on top of that - which, I might add, are user specific (not even group specific) - you just get a 'no permission' page.

I wonder if we should approach things in much the same way for Wedge, that admins don't have power because they're in the admin group but because they have select powers over and above because of who they are. That would generally require more specific admin level permissions than we currently have, but that would make it easier to manage in the long run, I think. It would certainly limit the folks who add people to the admin group who suddenly worry about being removed again (because the notion of 'if you don't trust them, don't make them admins' is too exotic for these people)

Note that if we do this, admins don't magically get the same power they currently have, they would pretty much explicitly have to lose 'admins have every power'. Alternatively we approach it as a series of deny permissions so that the admin group does have full powers except for the powers you don't want them to have. Or even just give them all regular powers and then make adminly powers granted rather than explicit. It's complicated and I'm open to discussion on the idea.

tl:dr; We could reformulate admin powers to be less overarching and more granular. This has consequences for management too.



phew. Imma go play a game now and let this sink in with everyone and see what people think.

1.	Which has impacts especially for MyISAM tables.

Before I begin, I want to note something: I'm not just looking at IP.Board on its own. I hold a licence for the entire IP Suite, so I will look at each of those things.

Now, I've had my local installation kicking around pretty much since November without any changes, around the time 3.4.0 came out, so before I go any further, need to perform the upgrade. I wouldn't normally comment on this but damn it's slick. You just upload all the new files of everything, overwriting the old ones, then visiting example.com/admin/upgrade/ and the upgrader walks you through the steps. Picture attached. Everything thereafter is just it going through the motions and telling you what it's doing. I can't deny this is slick but to be fair, $125 for the basic system, it wants to be slick.[1]

IP.Board / IP.Core
This is smooth, I really mean smooth. They've put a lot of time and thought into this. Even from the sign in page being a popup on the current page (rather than anything else)

Presentation-wise, it's crisp and clean and just gets on with the job. Rounded corners are very minimal, the colour scheme professional and pretty neutral. You can see there's also a sort of mini portal in the core, too.

I will note that it isn't as lightweight as other systems in terms of performance; my localhost does occasionally take a couple of seconds to build a page but usually that's just the first time.

Message index is also quite interesting; you can selectively pull up a preview of a topic, but otherwise it just carries the same businesslike approach to the message index. Note the prominence of sorting options.

The topic view carries the same aesthetic approach. Interestingly, there is prominence given to the topic starter above the topic itself, I don't recall seeing that before, but works well. The usual realms of quoting and multiquoting are present, as well as likes. In fact probably the most notable thing here is the Blog This button, which essentially grabs the post and pushes it to the Blog area. I'll get to that in due course.

Editing is much as you'd expect, including inline editing, though the inline editor brings up the bbcode etc. which is powered by CKEditor. There's the 'reason for edit' and 'hide the edit-by line' stuff, but more importantly is the 'My Media' option in the editor.

Now, from my perspective, this is absolutely slick and demonstrates how it should be done, IMHO. Aeva went part of the way, allowing users to upload images directly from the editor, but this is even more spiffy. See attached. In essence, you can find anything you've previously submitted, that isn't itself a post and embed it into your post, be it an attachment you've previously posted - and it's tied to what plugins you have. As mentioned, I have the suite, so IP.Blog, IP.Calendar, IP.Download and IP.Gallery items are also available.[2]

I don't have any gallery items at just this moment, but you get the picture of how slick this beast really is.


So, let's take a look quickly at the other members of IP.Suite.

IP.Blog
Then we get to the members list - again, follows much the same vein as other areas aesthetically. Presents much as the board index but this time with boards as having individual authors, and blogs can also be 'external blogs' which amounts to redirections.

Adding a blog entry is much like adding a regular post, just with slightly different options. Both forum posts and blog posts offer titles and tags, plus content and attachments, plus polls. IPB also allows for automatically unlocking and relocking a topic at given times, for example if you want to post a new topic to announce a contest and only open it from midnight for 24 hours, for submissions.

Blog items can also have an image attached to them to represent them and have categories to sort them. It's all much as you'd expect (and given that it's a paid add-on, it's hardly surprising that it's covered) - and you can also elect to publish an item in the future too. Note that that isn't an option for regular posts, only blog posts.

There's also the option to create Group Blogs, which are not owned by a single user but owned by a collective, and then you can assign one or more membergroups to it to contribute. There is also a mini portal of sorts for showing in the sidebar (mini calendar, last entries, gallery albums from the blog's owner, last comments, showing the blog owner's avatar, random images from blog owner's albums, active users, tags, blog search and categories within the blog)

I can't really imagine what else would be needed; this all seems at least comparable (and often superior) to what WordPress offers as a blog solution.

IP.Calendar
Well, the calendar is not really very surprising. There are three views to the calendar, Month, Week and Day - something SMF never did (it only had month and week)... but as you dive in you realise it's far more intriguing.

Firstly, they have the notion of multiple calendars. There is the "Community Calendar", but also you can create individual calendars and assign permissions. Calendars can also be followed in terms of RSS feeds and 'following' which means you will get notifications and so on, plus the number of followers is also tracked.

Creating events is fairly straightforward - you add events to a given calendar, indicate that they are personal or public, or who they can be viewed by. Events can have end dates, they can repeat weekly/monthly/yearly and can have start/end times (including time offsets)

Note that calendar events are inherently separate from the forum and individually get contributed to in terms of comments.

This is also a perfect time to mention the search feature, incidentally. In the search area is a dropdown for what you want to search, be it the Forum, Members, Help Files, Blogs, Calendar, Pages (IP.Content), Downloads (IP.Download), or Gallery (IP.Gallery)... interestingly there is not a search-all option, even if you go to the full search page.

Configuration is fairly minimal, but you don't need vast numbers of options - and it does allow importing from iCalendar format too, which is interesting.

IP.Content
IP.Content is where you would add additional items for the site, and allows for things like an Articles system (which is not just for conventional articles but promoting regular posts to articles). It's nothing particularly special, has the usual gamut of article management type stuff; if you've seen any of the SMF portals, you have a fair idea of what to expect from that part.

Where it gets more complex is in the provision of blocks - again, a portal type construction, and lets you pull things like lists of articles, recent articles, recent comments, yada yada yada. Again nothing particularly original, but well put together.

IP.Content also provides the ability to create template blocks, which can be added to content areas as a way of managing how your content is displayed. If anything it's actually rather imposing on new users. To give you an idea, just check out http://www.invisionpower.com/support/guides/_/advanced-and-developers/ipcontent/

The other thing IP.Content gives you is the ability to manage straight up pages. You get to play with creating pages and folders for those pages, for example one of the demos is Site Root > media.html, which is a page showing the latest YT video, and a Recent Videos block underneath, which is just an example of them using their markup and templating system to show the linktree, some divs, followed by using their markup to pull in predefined blocks and a predefined database query/template combination (as defined in IP.Content)

It's very effective, but I can see how it could get overwhelming.

IP.Download
The Download item is fairly dry, actually, there's not really a lot to it but that's not an unfair assessment. There really is only so much you can do with it. Files have names, versions, tags, a change log box and description (of which only file name and description), plus the file itself, of course. You create one or more categories, putting files into categories... it's all fairly straightforward.

You can also add custom fields.

In the admin panel, though, it's a different story, all kinds of things can be done there - you can store files locally, store them remotely via FTP or even into the database directly if you so wish.

There's a variety of ranking options, plus things like file approvals, ability to turn the system 'online' or 'offline' (i.e. maintenance mode) as well as things like old versions of files, configuration of MIME types... it's surprisingly thorough behind the scenes even if it doesn't look it on the front end. There are also options for importing from a zip file or from a pre-existing directory.

IP.Gallery
IP.Gallery is much as you'd expect, you create categories and albums, though there are far fewer options than Aeva has :lol: - albums have names, descriptions without bbc, privacy (public vs private vs friends only, allowing comments, allowing ratings, watermarking) There is no option for nesting albums, interestingly.

The workflow is designed to be simpler, as you go to the front page, select your album (or use what the 'current album' is), hit upload and then it'll perform the upload - then, and only then, taking you to the edit-item page, where you give it a title, tags, description and copyright. Doesn't seem like there's a custom fields option.

The presentation of the gallery is much as elsewhere - you see an album and previews of all the items in it, and then to the item itself... it's essentially comparable to Aeva and Aeva is probably more thorough in terms of options - but I can't help but feel that IP.Gallery is more slick in presentation, though not by much.

IP.Chat
I can't comment on IP.Chat much, as I haven't used it...

Firstly, it requires your licence key from IPS to be put into your forum. This is, in itself, not a huge problem. However - and this is a big turn-off, IPS contacts your forum periodically to ensure the licence key is put in and valid etc. Now you get the licence key for test installs (same as regular licence key but with -TESTINSTALL on the end) which is bound to a given location (in my case, localhost/ipb/) and periodically I find that the licence key gets 'forgotten'.

Secondly, -TESTINSTALL installations automatically have IP.Chat disabled.

Thirdly, IP.Chat seems to be set up to be primarily hosted on IPS servers rather than your own (since if it were self hosted I don't see why it would need the key)

I have tried it, and honestly it's nothing that incredible; it is conventional AJAX polled chat, though it does of course tie into your actual accounts - and it doesn't have the requirement attached of adding load to your server because it's not hosted on your server. This may or may not be an acceptable trade off for you.

IP.Nexus
I haven't tried this. Unlike the rest of the IP Suite, IP.Nexus is shipped encrypted - you either need ionCube Loader or Zend Guard Loader to make it work. Interestingly there are three separate downloads of IP.Nexus because you have the ionCube version, the ZGL for PHP 5.2 and the ZGL for PHP 5.3+ versions.

Their argument is that it increases security, but I'm not convinced it really does. But that's another matter. IP.Nexus is a combined billing system and helpdesk - and it's what's used on IPS' own site for handling billing and sales of IPB itself. It is competent but nothing truly outstanding.


Quick Roundup
This has been a long enough post - so I'm going to leave it there for the client side and write up the admin panel in the next post. The one thing I would say about all this, though, and it's perfectly true: IPB has long been considered the most professional of the forum world - but it's nothing special. It does what it does very well, it's solid and capable but otherwise unremarkable.

I would note that I'm not entirely convinced about their security record, by the way. My licence was purchased on 5th November, which was IPB 3.3.4, and since then there have been two 'critical' patches plus we're now up to 3.4.5 (3.3.4 -> 3.4.0 -> .1 ----> 3.4.5), plus various patches for each of the modules. Now, some of those are bugfix patches, sure, but even so that does raise questions for those of us used to something like SMF's timeline (4 patches since June 2011)

1.	The reason it operates the way it does is because a lot of stuff, templates and language strings and stuff, is all in the database so it all needs to be synced.
2.	And they install as cleanly as the upgrader, you just dump the files and tell it to find them, but since it's all built by IPB, it's hardly surprising.

I don't know where exactly, but it is.

Just for shits'n'giggles I thought I'd install Wedge on 000webhost, to see if the 'white screen of lying-about-memory' came up. So I'm installing SVN, updated with latest changes plus a few in my local repo but that are absolutely unrelated[1] and I get all kinds of excitement when wading through the install process.

These will produce a couple of thousand errors per regeneration of the CSS.

8: Undefined index: selector
Apply Filter: Only show the errors from this file
File: /home/a2849756/public_html/forum/Sources/Class-CSS.php
Lines 883, 929, 954, 970, 985, 1107, 1239

8: Undefined offset: 3
Apply Filter: Only show the errors from this file
File: /home/a2849756/public_html/forum/Sources/Class-CSS.php
Line: 1325

8: Undefined offset: 4
Apply Filter: Only show the errors from this file
File: /home/a2849756/public_html/forum/Sources/Class-CSS.php
Line: 1326

2: implode() [<a href='function.implode'>function.implode</a>]: Invalid arguments passed
Apply Filter: Only show the errors from this file
File: /home/a2849756/public_html/forum/Sources/Subs-Cache.php
Line: 686


I dunno what's wrong with it since it works fine locally with the same files.

1.	Moving a call hook in index.php, a tweak to number_context in Subs.php and a slight change to the installer to test for SimpleXML.

Carrying on from my tour around vB 3.8.7, I took a look last night at MyBB. I thought for about half a second about learning just enough to go troll MyBB but that seems a bit much :niark:

OK, so I hear a lot of MyBB fanboys squealing about how much better MyBB is than SMF, and not once have I ever heard why it is so, so I thought I'd try and figure it out for myself.

First reaction
I'm looking at the default theme and my very first reaction is "This reminds me of vB 3.8.x". It's not an exact knock-off but somehow it reminds me more of vBulletin than anything else does; phpBB and SMF have very much their own identities, even back in SMF 1.1.x days.

The second thing is how cluttered it all seems - as per first screenshot. MyBB claims to support a threaded view but I'm not sure it works properly or if it does, it isn't working properly for me, as I can't consistently get something to be a nested child. Strike one for MyBB.

And HOLY FUCK IN THE NAME OF ALL THAT IS HOLY... I know a lot of people dislike the whole 'return to the board' thing but then we have the interstitial screen, the infamous 'Thank you for posting, you will now be returned to...' with an option to dive out to the board. Eeeeew. Fortunately, it is disableable in the admin panel, but still...

OK, one thing I did see that impressed me, AJAXive quick reply. But that's not that much right now. Other than that it's not really much different; though the layout of information above the post itself makes it clumsy IMO, if you have an inch+ header on top of every post to put the user information in.


Admin panel
OK, so let's take a look through the admin panel.

The front page is not really surprising - admin notes, some interesting mini-stats (MyBB/PHP/SQL versions, number of threads/posts/users, subdivided by totals, new and awaiting approval)

Oh, that's weird... there are two different themes in the admin panel. Classic and Sharepoint, I'm using Sharepoint because it looks slightly nicer to me.

Then I see something learned from vB: a page whose sole purpose is to link you to page after page of settings. They're very long pages, too... see attached. I'm all for comprehensive options - and the options seem pretty comprehensive without going overboard, but the layout needs some serious work IMHO. There's only 25 options on this page, but you can see how long that page is. And there are 21 pages of just settings, if that makes sense.

Most of it is pretty straightforward stuff until I see this particular option in the Server and Optimization page:Say whaaaaaaaat? And no, there's nice help popup or anything to explain it... And there's a typo elsewhere on that page >_<

And WTF... I've seen this elsewhere but it truly makes no sense to me: Add New Setting. You can actually add new items to the admin panel directly, but unless you're actually doing something with it, it seems a bit redundant and if you are doing something, you might as well make a plugin out of it.

That leads me to something else that *really* grates on me: display ordering. Various controls give you the option to set their order (like custom fields being ordered, settings/setting groups)... and you set this by putting in numbers. Want a new custom field to be the second one down? Put in a display of 2 then order the rest to move them down too... because that's a nice user experience.

Other stuff seems fairly straightforward, though I slightly baulk at the 'MyCode' new bbc options. You create it with straight up regex, their example:
Regular Expression

Replacement

A history lesson: SMF used to do their bbcode with this back in 1.0. One of the main reasons 1.1 dropped the old ubbc function and replaced it with the scary beast that is parse_bbc is because of ReDoS vulnerabilities. If you have regular expressions, it's possible to craft a post that can mess with them to cause the PCRE library to poop itself and create incredibly slow-parsing situations which can DOS the server (hence ReDoS - regex denial of service)


All in all, it doesn't strike me as being anything that exciting and certainly not being deserving of the fanboyism... hell, even the Apple vs Android fanboys have valid arguments in their favour but this doesn't seem like it.

In fact the only thing I can see that has any advantage so far is the plugin system but when I looked at the plugin architecture... whooo... my exact comment last night was that it blows monkey chunks compared to Wedge, it looks like the plugin's actual file must be loaded at startup to initialise it (as opposed to us which doesn't explicitly have to load anything, just validate its existence)

What I will say is that it does have a bunch of things in the core, like thread prefixes (where you pick a prefix out of a set list), as well as stuff like announcements (setting predefined messages in a board above all the topics like super-pinned topics)[1]

Permissions are weird though, see attached. You set the default permissions per group elsewhere (where it's a simple tickbox, yes/no) and set per board overrides here. There doesn't seem to be deny permissions so it is simply allow/disallow as we know them and you drag the permissions between the two or you can press the 'Set Custom Permissions'. It does seem very clunky compared to SMF's let alone what I've talked about for Wedge.

So yeah, pretty much as expected, MyBB stacks up reasonably well to SMF in terms of features but the admin navigation is ugleeeeee... and yet it's much like how XenForo does it and that's considered good... I dunno what goes through these peoples' minds sometimes.

1.	Which I might add to Wedge, though before I saw it in MyBB

Just a slightly crazy thought. The file cache serializes content and unserializes it later on.

I wonder if it is safe and better performing to json_encode it instead. Only if native json_encode is available, of course. I did a test a while ago and for the data set I had (large arrays, of arrays of numbers), unserialize was significantly slower than json_decode for my data.

We don't serialize resources or object instances in the base software (there is no reason for us to do so), so from my perspective I see no real reason why we can't do that. If native functions are not available, then we use serialize as normal.

Thoughts?

You guys all know vBulletin 5 is a train wreck, right?

If you didn't, here's the proof: http://www.vbulletin.com/faq/

For those who aren't interested in clicking on links etc, I'll share the truly WTF ones. I swear I'm not making any of this up, and you can look at the FAQ yourself.And this is a supported product, or something.

This comes up fairly often, so I have a proposal about this that would effectively solve all the issues around it (at least IMHO)

Have a flag attached to each PM to indicate 'saved' status. If a PM is 'saved', it cannot be deleted by the user unless they unsave it (feel free to change the word). This would allow users to delete in bulk without having to worry about accidentally deleting messages.

Then, the admin has the power to set a time on deleting messages that are not marked saved/locked/preserved/whatever you want to call it. The admin gets a control on cleaning up the database while users get the power to protect things they want saved that are important.

The lock feature would always be available to users regardless of anything else, while the deletion aspect would only occur if the admin turned it on and set a number of days - and that part would be off by default.

How does that sound to everyone?

http://xkcd.com/1208/

For some reason this makes me think of Wedge.[1]

1.	I can't imagine why.[1]  1.  No, really, I can't imagine why.