I recently rewrote my banner management system for one of my boards. The board is fairly active (in fact we’re averaging over 100,000 page views daily now) so with multiple page views per second taking place during the busiest times of the day it would make sense to be concerned about performance. And I was. But I also had to be concerned about auditing my banner and page statistics, and ensuring that if I said a banner was going to be displayed every 10 page views that it was. So the system had to be 100% efficient and just as accurate. That presented some challenges.

More…

In the first post about this MOD I introduced the basic concept of a daily digest and described how the scheduled process worked. The other half of the system is the user interface that allows the user to mark which forums they want to subscribe to. I will cover that (and a bit more about the database design) today.

More…

In the first post in this series on working with recursive data I talked about several different ways to store the information in a database. Some of them were promising, but they all had complications of some kind or another. I was using the phpBB Doctor Project Manager database design as an example, but there are quite a few different scenarios where recursive data will be found. Since SQL is not a recursive language, I am trying to find the best way to model the data so that I can access it with minimal fuss.

As an example, in my project management system I need to be able to quickly and easily identify the parent task, if the task has any sub-tasks (child records), and which tasks are at the same level (siblings). I would like to be able to traverse the tree in either direction (up to the parent or down to the child) without using recursion. In order to do that, I need a model that is different from anything presented in the prior post.

More…

I think I have frequently mentioned that my biggest board was at one time a mailing list. The mailing list had two modes: individual message or daily digest. Because of this, one of the first feature requests I got from my user community was a way to subscribe to a daily summary of activity from selected forums. The code to generate and deliver the digest was fairly easy. The user interface was a bit more challenging. Code is always easier if you don’t have to interact with users, because things are so much more predictable without them.

One of the main factors that I tried to keep in mind was performance. If 15,000 people subscribed to a nightly digest, I wanted the generation and delivery process to be as quick and painless as possible. So before I wrote any code I sat down with my thoughts and figured out a few shortcuts. More…

There are all sorts of scenarios that require recursive data. If you don’t know what “recursive” means, it’s a relationship from an entity back to the same entity. In English, it’s data that points back to itself. Some typical examples of recursive data are company org charts, inventory build instructions, or even forums for phpBB3. Yes, I’m talking about phpBB3, are you surprised? I hope not, because I’m going to reference phpBB3 only in passing. The article is actually more about storing recursive data in any form. It’s also how I store information in my phpBBDoctor Project Management system, among other things.

SQL is not a recursive language. When I write a query it’s all about relationships between rows, not about looping back through the same table. Oracle has a special construct used to traverse recursive data and it works very well, but it’s the only database that I am currently aware of to support this. Since most phpBB MOD authors will not be writing for Oracle, I will skip that concept for now.

As mentioned in the first paragraph I have recursive data in my project tracking system that I use here on the phpBB Doctor site. The design for this system is simple, but complex. The first table is the project table and it includes summary attributes for the project. These attributes include values such as when the project started, who is the project manager, a description of the project, and the status. The next table is the tasks table. A task is assigned to a project, but a task can be broken up into sub-tasks as well. There is no expected limit to the depth of the tasks. Here is a screen shot of my test project so you get an idea of what I’m talking about.

More…

One of the more popular MODs for phpBB2 (and now a standard feature for phpBB3) is subforums. The original forum structure for phpBB2 includes the following hierarchy:

Board -> Category -> Forum -> Topic -> Post

With the very popular Simple Subforums MOD (sometimes called SSF) you can get this:

Board -> Category -> Forum -> Sub-Forum -> Topic -> Post

For some people that one extra level is enough. You can enable posting at the parent forum or the child forum level if you want. Several years ago I wrote my own sub-forum MOD for use on my largest board. It works okay. Like the SSF MOD I only coded for one level. Unlike the SSF MOD mine is optimized from a query perspective, and doesn’t require the eXtreme Styles MOD. I think both of those are advantages to my code over SSF.

But what if there was something else… something in between a full-fledged sub-forum implementation and a basic configuration? I have written a new MOD to do just that, and am currently using it on my largest board.

More…

One of the features missing from phpBB2 is a Merge Topic option. Forum moderators can delete, lock, split, and move topics. A locked topic can be unlocked. A moved topic can be moved back to its original location. But there is no “undo” for deleting or splitting. If there was a way to undo a “split” it would most likely be called a “merge” which - if available - would also provide a way to merge two similar topics together to combine a discussion. In the next few posts I want to talk about how I designed and wrote a MOD to address the missing merge feature in phpBB2.
More…

Our Story So Far…

Not too long ago I published that post in which I described an “auto group” MOD. I went on to explain that I don’t really think they’re a good idea, and I posted a couple of reasons why. The main reason was that this type of MOD adds too much overhead since it spends a lot of time checking things but doing nothing. That’s why I wrote the Forum Auth by Post Count MOD. This post talks more about the design of that MOD, and why I think it’s more appropriate for a busy board… or even a not-so-busy board for that matter.

More…

I learned something today. A few days ago I posted about why I think that “auto group” MODs are bad for your board. Before I go any further, let me please make one thing perfectly clear: I am not saying that the coding is bad, in my opinion it’s just a bad idea to begin with. So neither post (the first one or this one) is intended to be a criticism of the coding techniques used by any MOD author who has written this type of MOD.

So what did I learn?

More…

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.

More…