Building a Forum - Part 1
When I took over managing 4W Forums, I needed some forum software. I had a slow server at the time, so something lightweight compared to some of the well-known forums out there. I settled on Luna as it looked great, was lightweight and had an active developer. That is until 2020, when development just stopped. It didn't just stop; the site wasn't renewed either. Luna as a forum is dead unless someone forks it into something else.
This leads me to the major downfall of using a lesser-known, lightweight forum. There's so much to love about it, but when it comes to moving everything over to a new forum, there are no options to easily convert everything into a new forum database.
So, I decided to work on building my own. This comes with some advantages, like using the existing database and modifying it to suit what I want. I can keep all the data, user accounts and levels but make it my own. Naturally, I created a backup copy to work from. The downside is that it's a lot of work. There's so much development to do into something like this. So I'm going to chronicle my journey to creating my own forum from almost scratch since I'm at least keeping a large part of the base database.
Along with a complete design, I'll also be working on some other features. A long requested one is the option to like a comment. It's not a high-priority one so will be one of the last parts added. But it's in the plan, so I'm building it with this feature in mind. I'm also allowing the tagging of users to posts. This I've already started work on and comes with some functionality choices.
My first thought about tagging users was about spamming. I don't want people spamming up the notification system and going completely ham with tagging users. So I thought up a limit. You will only be able to tag up to five users per comment. That not only helps with spamming the feature but also with regard to the database.
The function works by looking at text within a new [tag]@username[/tag] BBCode option that I added. Every user has an @username which is built from their username. Spaces replaced by an underscore, special characters removed, etc. I currently have it set so that it cannot be changed. A user can change their username, but their @username will remain constant. When submitting a comment, I look for instances of [tag]@ with a closing [/tag]. The query cycles through the comment up to five times, depending on how many are found.
Instances of the tag are saved to notifications which will inform and link users to a comment they are tagged in.
Hopefully, limiting how many can be used will not only save spamming but also be nicer on the system. I might have a much better web hosting package than I did with the old hosting company when I picked up 4W Forums, but I will want to be mindful of making it run as smoothly as possible.
This will be one of the last things I add to the forum, but I'll be putting the building blocks in place for it as I go. The count will be included in the database twice for ease of use. Similar to how the comment count of a topic or the thread count for a forum is done. A number in the relevant database and the list of rows for the actual items. My thinking on this is all about forum speed. I don't know what the thinking was behind the comment/thread count initially, but I'd assume it's so that the SQL query doesn't involve counting rows for every row via a join. It's just one table, and it pulls in the number stored in the relevant row.
So, that's what I'm going to do with likes. Each comment row will have a like number associated with it. When a user clicks on the like button, that number increases. At the same time, it will also update a likes table where it will add the comment id and the user id. I need to work out logistics on how that'll work in practice, though, because I don't want people being able to like the same comment numerous times, but I also don't want to run a database query on every comment as that would be a lot of queries in an active thread.
I have some thinking to do on that. One thing I do know for sure, though, is that I'll use an AJAX callback to update the like function. Saves the whole page from reloading unnecessarily.
Additionally, the whole forum is getting a redesign. Given the amount of code I have to write, it just made sense to redesign things too. Things might change from this as I progress, but I'm happy with it for now.
The current forum allows for accent colours along with picking a light or dark theme. I'm keeping accent colours around - the default being blue, whereas I've selected a nice yellow for when I log in. Background-wise, there will no longer be the choice between dark or light. This is purely down to font colours on posts. There needs to be some consistency, and I've noticed before that some users have made some text a fairly light colour. It looks nice on a dark background, but the text is barely legible for those users using a light theme. Likewise, the other way around, where if someone used a dark font other than the default, it becomes hard to read. Therefore, a consistent background colour solves that problem as much as it can be solved. I'll never be able to stop people from selecting a colour that has atrocious contrast, but alleviating that with having just a single background colour should help.
Problems to consider
The first problem to consider is page speed. I want to keep things as lightweight as possible for ease of use and site speed. I want things to load as quick as possible. There's a lot of background processing, but it does what it needs to. As I add more features, I'm going to have to keep this in mind.
A big one that will require a bit of thinking, though, is unread posts. I need to work out the best way to handle this so that users can see what posts are new since their last visit. But it's not just their last visit I need to think about. If someone opens the forum and comments on a post, and someone else comments on another thread, I need that to show as a new post to them. I've looked at a few options but have yet to settle on what would be a good option. Some require a lot of database work - saving user ids and post ids into a table for unread posts and updating whenever a user reads a thread. If the forum grows, that table could grow an insane amount. This is the biggest problem I need to consider as I move forward with the rest.