Some time back I wrote the Forum Auth by Post Count MOD for phpBB2. I had to write it because so many people were using an “auto-group” MOD of some kind, and using it to grant permissions to view or post in specific forums. The general idea is good. In my opinion, the implementation is bad and can have a substantial negative impact on your board.
One of my clients was using an auto-group MOD to require posters to post in the “Introduction” forum on her board before they posted anywhere else. There were also certain semi-private forums that were not available (visible) until a member had reached a certain post level. Now in phpBB2 you manage permissions in two ways: by user (bad idea) or by group (much better). But there is no “event” system in phpBB2 that will automatically add (or remove) someone from a group. This is where the auto-group MODs generally come into play.
How They Work
Auto-group MODs generally operate by checking a set of rules (a query) against the user’s post count after each operation that can impact that value (the post count). If a user’s post count has increased above the set threshold they are added to the group(s) they now qualify for. If the user’s post count has decreased below a set threshold, then they are removed. Sounds simple, right? So what is the issue?
The issue is there are lots of things that can change a user’s post count. Let’s count them.
- A user enters a new post
- A user deletes their own post
- A moderator or admin deletes an individual post
- A moderator or admin deletes an entire topic
- The standard (automatic) pruning process removes a post
- A board admin deletes an entire forum
Is that enough? There might be more, but that list is certainly long enough to make my point for me. The good news is that most of the options above call the same code, so it’s not like there are lots of different places to add new code. That’s not the issue. The issue is what that code has to do. Every time the user’s post count changes, I have to:
- Get a list of groups with “auto-group” rules
- Get a list of groups that I am already in
- See if my new post count qualifies me for any new groups
- See if my new post count requires me to be dropped from any current groups
Once that determination has been made, I then have to execute queries to adjust my group membership(s). All of these add overhead to something (the posting process) that should be as smooth as possible. Posting is, afterall, what we want people to do on our boards, right?
And here’s the worst part. These queries will execute each and every time I enter a post! Suppose that I need to accrue 100 posts before I am granted membership to a private group. From post one through post ninety-nine I pay the penalty of checking for new group membership. On post 100 I finally get to join, yippee! But guess what… every post from 101 and on is still going to check my group membership!
In my opinion, this is a very inefficient process, and should never be run on a busy board.
The Forum Auth by Post Count MOD that I wrote does not require anything to be done during the posting or pruning process. If you look at the root issue (I want to grant access to a board only after a set post count is reached) the better solution is to add that information to the forum table. Afterall, in every case where you are requesting forum information (the forum name, for example) you can easily add new fields to the query. It is a simple matter to also request the “min_posts_to_view” field and compare it to my post count. How many extra queries does that take? Zero.
So in a nutshell that is the design behind the Forum Auth by Post Count (FAPC? Nah, don’t go there… ) modification that I wrote for phpBB2. Instead of overhead on every single post, I check one value that I have all the time ($userdata['user_posts']) against a value that I can easily retrieve every time I get the forum_id or forum_name from the phpbb_forums table and react accordingly. I want to talk more about the design of FAPC (see, it just doesn’t scan as an abbreviation) in my next post, because I think it uses a good approach. It isolates most of the code so phpBB2 upgrades are fairly easy, and it also makes it easy to reuse in a variety of places.
It’s not rocket science (but then again, only rocket science === rocket science) but it’s probably worth writing about. Stay tuned.
- Release Topic at phpBB.com