[web] Help making good forum software
Author
I'm trying to create some forum software(in PHP with a mysql database) with unique requirements (At least as far as I can tell), and I'd rather create it myself than modify an existing package because I'm fairly certain that my requirements would take quite a bit of work to fit into any existing forum software.
Now, I could most definitely whip together something myself, but the problem is I have no design skills so the whole thing would be a hacked together mess with no chance of 'incremental improvements' really.
I'd greatly appreciate any pointers or resources that you think might help.
Lay it all down on paper first. Important things you will want to include:
I'll add more things if they ever come up.
- Where do the users login?
- What are the user priviliges; will you need Mods or will you moderate the entire forums yourself?
- How do you want new account setups to occur?
- How do you want the important post information displayed ?(believe me, this is an important one. Make sure that whatever design you come up with, each seperate post [user, join date, post, etc] are clearly divided up])
- What security precautions do you think are necessary?
- What happens when users forget passwords?
- Make all "functions" declared in a function.php of some kind. That way, adding little things here and there should make it easier for you
- MAKE SURE YOU COMMENT YOUR CODE
- For mysql, make sure you take the proper form entry precautions (stripping unwanted characters, etc).
- Since your using mysql, most definitely layout the database also. I cannont stress this enough. It will help you so much in the middle of development, especially if you have such a lookup table to see what values you need to grab in the code, and to make sure your database activity remains consistent.
I'll add more things if they ever come up.
Yeah, the database design is going to be critical if you want the software to be successful. There's a couple of things to consider to ensure you get the best database design possible.
Work out what sort of authentication system you want.
Come up with a list of features you'd like to support.
Decide how customisable you want the software to be (themes, board settings, etc.).
After creating the features list, come up with a rough table design.
Pick the table design apart, working out where redundant information could occur (like say if you delete a user, how are you going to handle any posts made by the user?).
Work out where data will be used in more than one place (most frequently occurs for IDs) and try to utilise link tables to ensure that your data fetching is fast, and is easy to query for.
The authentication design step, is a very important one and one that is often not given the attention that it deserves. Do you want administrators, moderators and other groups? Do you want administrators to be able to create their own groups with a defined list of permissions? What about moving users between groups? Think as far ahead as possible, as it's much harder to implement a permissions system, once a system is already in place.
Also, when concerning the database design phase, don't use your first table draft; it will have problems associated with it. The question I find most useful when designing tables, which I briefly touched on earlier, is asking yourself, "If this data can be deleted, if it gets deleted, how will I handle it and will there be any redundancies?". Keep asking that question at every stage of table design so that you can minimise any data bloating.
A side issue, but one I often see people ignoring, is speed. Very simple techniques can be applied in order to keep your data retrieval fast and efficient, which is essential for a forum being as it's data-heavy. Only select the fields you need. Never use select * from table, unless you know beforehand that you'll use every single field in that table.
As I said before, if your database design is good, you'll find that your whole application benefits from a speed increase.
The authentication design step, is a very important one and one that is often not given the attention that it deserves. Do you want administrators, moderators and other groups? Do you want administrators to be able to create their own groups with a defined list of permissions? What about moving users between groups? Think as far ahead as possible, as it's much harder to implement a permissions system, once a system is already in place.
Also, when concerning the database design phase, don't use your first table draft; it will have problems associated with it. The question I find most useful when designing tables, which I briefly touched on earlier, is asking yourself, "If this data can be deleted, if it gets deleted, how will I handle it and will there be any redundancies?". Keep asking that question at every stage of table design so that you can minimise any data bloating.
A side issue, but one I often see people ignoring, is speed. Very simple techniques can be applied in order to keep your data retrieval fast and efficient, which is essential for a forum being as it's data-heavy. Only select the fields you need. Never use select * from table, unless you know beforehand that you'll use every single field in that table.
As I said before, if your database design is good, you'll find that your whole application benefits from a speed increase.
Author
GRRR!!!!
Above all, my forum MUST NOT have the stupid logout but in this forum!!!
Thanks to the mods, I can repost it under my user name:
Ok, well I've worked out the database design somewhat already, and I'm posting a brief version at the bottom of the post so you can judge it and offer pointers if you would.
When you go to the forum, the index page should be a standard listing of the forums by category, with a menu up top with the option to log in, search, etc.
Before you can log in, you'll have to register, which will include entering a unique email (meaning nothing from hotmail, yahoo, gmail, or any other free service like that - yeah, I know that will make it lot less popular, but it is required) and probably the whole 'type in the text that appears in this image' thing as well. Then an email will be sent to you for activation, and you can log in after entering the activation code {or clicking the link}.
I'm thinking about making the forum 'ping' users every so often as well (maybe every 2-3 months) where it will send an email to the registered address and you have a week to enter the code in it or your account will be deactivated (meaning that when you log in, the only thing you can do is change the email address {at which point it will try again for activation} until you have reactivated). Maybe only a single ping would be good, to make sure the person didn't use a one-time-use email address.
The log in will const of entereing name/pw, and the script will check the database to see if that person is there and if so it will store their info on a server-side session and then take them back to the forum.
For permissions, I think the way I want to do it is to have a seperate permissions table that will store in each entry a group id and a forum id, and anybody in that group gets those permissions. Group #0 will be reserved and will represent the default permissions for users not in a group (or at least not in a group with special permissions for that forum). Also in each permission entry would be a boolean for 'allow' and 'deny', which would control how they stack together when a person is in multiple groups: The final permission will be min(deny entries, max(allow entries)), so that denying permissions has the final say, but without any 'deny' permissions, the highest allow entry is used.
The permissions should include:
Read Board [See Forum' Topic{Thread} List page]
Read Topics [See Posts in a Topic]
Start Topic
Reply To Topic
Edit Topic {None, Own, All On This Forum}
Edit Reply {None, Own, All On This Forum}
Delete Topic {None, Own, All On This Forum}
Delete Reply {None, Own, All On This Forum}
Move Topic From This Forum {None, Own, All On This Forum}
Move Topic To This Forum {None, Own, All On This Forum}
View User Info {None, Own, All With Posts On This Forum}
Attachments {0 to X bytes, File Types Allowed, Total Attachment Space Allowed on this forum, max attachments per topic, and other such details}
As far as features, I want:
full theme support - which means at the very least that themes need to be executable PHP script so that they can change practically everything about the look
a PM system - complicated by the details below
Per post ratings - should be easy, since users won't have individual ratings
I'd liked to support nested forums, to an arbitrary length, with the possibility of having a single forum appear in multiple places, or even including whole categories as if the forums in that category were also subforums of the forum you're looking at. I haven't worked the details out pat the nested forums.
As far as security, you can probably tell from my paranoia towards unique emails and the like that I want it to be quite difficult to be a 'registered anonymous' on the forums so to speak. The reason for this (which may seem contradictory) is that these forums I am making are all about anonymity. The biggest feature is that only moderators can see usernames, user ids, or anything like that. When you make a post, it will show nothing about the poster on the post. It will only show the date it was posted, the rating of the post, and when it was lasted edited (if it was). When sending a PM, you will send it to 'poster of post #postid' or somesuch, and essentially you'll start a private thread that shows at the top the post that the first PM was in reply to (with a link to the whole thread) and then the sequence of PMs in chonological order.
The reason I need to be strict about how people can join is that I want them to still be accountable for what they say, but only to the moderators. Amongst eachother, the forum's users should be able to say whatever they want and even do things like argue both sides of an issue simultaneously as two seperate people (since people can't see any identifying info, the only hint will be writing style), as long as they remain at least somewhat civil.
I have the tables planned out approximately as follows. Every table will have an ID field that acts as primary key, and names in angled brackets represent references to other tables
Categories: Name
Forums: Name, Description, <Category>
Users: Name, Password, Email, JoinTime
Topics: <Post>, <Forum>, Title
Posts: <Topic>, <User>, Time, Text
PM Thread: <PM>, Reply To <Post>, Title
PM: <PM Thread>, <User>, Time, Text
Users Waiting To Be Activated: <User>, Activation Code, Activation Deadline
Deleted Posts: <Topic>, <User>, Time, DeleteTime, Text
Groups: Title, Description
Group Membership: <Group>, <User>, Group Leader?
Permissions: <Group>, <Forum>, Read Board, ..., View User Info
[Edited by - Extrarius on September 21, 2004 7:04:07 PM]
Above all, my forum MUST NOT have the stupid logout but in this forum!!!
Thanks to the mods, I can repost it under my user name:
Ok, well I've worked out the database design somewhat already, and I'm posting a brief version at the bottom of the post so you can judge it and offer pointers if you would.
When you go to the forum, the index page should be a standard listing of the forums by category, with a menu up top with the option to log in, search, etc.
Before you can log in, you'll have to register, which will include entering a unique email (meaning nothing from hotmail, yahoo, gmail, or any other free service like that - yeah, I know that will make it lot less popular, but it is required) and probably the whole 'type in the text that appears in this image' thing as well. Then an email will be sent to you for activation, and you can log in after entering the activation code {or clicking the link}.
I'm thinking about making the forum 'ping' users every so often as well (maybe every 2-3 months) where it will send an email to the registered address and you have a week to enter the code in it or your account will be deactivated (meaning that when you log in, the only thing you can do is change the email address {at which point it will try again for activation} until you have reactivated). Maybe only a single ping would be good, to make sure the person didn't use a one-time-use email address.
The log in will const of entereing name/pw, and the script will check the database to see if that person is there and if so it will store their info on a server-side session and then take them back to the forum.
For permissions, I think the way I want to do it is to have a seperate permissions table that will store in each entry a group id and a forum id, and anybody in that group gets those permissions. Group #0 will be reserved and will represent the default permissions for users not in a group (or at least not in a group with special permissions for that forum). Also in each permission entry would be a boolean for 'allow' and 'deny', which would control how they stack together when a person is in multiple groups: The final permission will be min(deny entries, max(allow entries)), so that denying permissions has the final say, but without any 'deny' permissions, the highest allow entry is used.
The permissions should include:
Read Board [See Forum' Topic{Thread} List page]
Read Topics [See Posts in a Topic]
Start Topic
Reply To Topic
Edit Topic {None, Own, All On This Forum}
Edit Reply {None, Own, All On This Forum}
Delete Topic {None, Own, All On This Forum}
Delete Reply {None, Own, All On This Forum}
Move Topic From This Forum {None, Own, All On This Forum}
Move Topic To This Forum {None, Own, All On This Forum}
View User Info {None, Own, All With Posts On This Forum}
Attachments {0 to X bytes, File Types Allowed, Total Attachment Space Allowed on this forum, max attachments per topic, and other such details}
As far as features, I want:
full theme support - which means at the very least that themes need to be executable PHP script so that they can change practically everything about the look
a PM system - complicated by the details below
Per post ratings - should be easy, since users won't have individual ratings
I'd liked to support nested forums, to an arbitrary length, with the possibility of having a single forum appear in multiple places, or even including whole categories as if the forums in that category were also subforums of the forum you're looking at. I haven't worked the details out pat the nested forums.
As far as security, you can probably tell from my paranoia towards unique emails and the like that I want it to be quite difficult to be a 'registered anonymous' on the forums so to speak. The reason for this (which may seem contradictory) is that these forums I am making are all about anonymity. The biggest feature is that only moderators can see usernames, user ids, or anything like that. When you make a post, it will show nothing about the poster on the post. It will only show the date it was posted, the rating of the post, and when it was lasted edited (if it was). When sending a PM, you will send it to 'poster of post #postid' or somesuch, and essentially you'll start a private thread that shows at the top the post that the first PM was in reply to (with a link to the whole thread) and then the sequence of PMs in chonological order.
The reason I need to be strict about how people can join is that I want them to still be accountable for what they say, but only to the moderators. Amongst eachother, the forum's users should be able to say whatever they want and even do things like argue both sides of an issue simultaneously as two seperate people (since people can't see any identifying info, the only hint will be writing style), as long as they remain at least somewhat civil.
I have the tables planned out approximately as follows. Every table will have an ID field that acts as primary key, and names in angled brackets represent references to other tables
Categories: Name
Forums: Name, Description, <Category>
Users: Name, Password, Email, JoinTime
Topics: <Post>, <Forum>, Title
Posts: <Topic>, <User>, Time, Text
PM Thread: <PM>, Reply To <Post>, Title
PM: <PM Thread>, <User>, Time, Text
Users Waiting To Be Activated: <User>, Activation Code, Activation Deadline
Deleted Posts: <Topic>, <User>, Time, DeleteTime, Text
Groups: Title, Description
Group Membership: <Group>, <User>, Group Leader?
Permissions: <Group>, <Forum>, Read Board, ..., View User Info
[Edited by - Extrarius on September 21, 2004 7:04:07 PM]
Are you sure you can't just modify existing software? You know yourself that even after you've programmed in the majority of your features you're going to be left with months of bug fixing and security issues. Think how long these forums took to evolve and how much work you'll be reinventing. Your feature list actually looks like it would be more complex to implement than the current forums too. Do you really think it would better to write your own from scratch than spend time learning about a proven piece of software? Don't most forums have similar features to what you want? They might not be 100% identical to your requirements list, but you can either modify them or just live with it, knowing you've saved thousands of man hours.
Author
Quote:Original post by seanwThe big thing is the anonymity requirements, which would require reworking the entire forum system to hide the user's name and ID everywhere, which would take a lot of work. I'm fairly certain it would take longer to rewrite a foreign system that doesn't use my styles etc than to just create one that has everything I want.
[...]They might not be 100% identical to your requirements list, but you can either modify them or just live with it, knowing you've saved thousands of man hours.
The table design looks good, but it's hard to tell without seeing all of the fields in each table (I probably should have mentioned that you really need to go into that kind of detail before starting any coding).
So long as you're happy that you're providing all of the functionality you'd like, and that you're catering for all types of redundant data (deleted posts, deleted users, removed accounts after extended deactivation(?), deleted groups, deleted rights, etc.), then you'll be fine.
Oh and you should find it quite easy to place forums in multiple categories. You could write a utility function to cater for data being grouped in fields, such as:
Then you could check to see if a forum is in a specific category, with:
At least that way, you'd save yourself having to query multiple tables for a one-to-many relationship, when the data you'd retrieve is very small. Sometimes more efficient to do it that way.
If there's anything else you need, post back.
So long as you're happy that you're providing all of the functionality you'd like, and that you're catering for all types of redundant data (deleted posts, deleted users, removed accounts after extended deactivation(?), deleted groups, deleted rights, etc.), then you'll be fine.
Oh and you should find it quite easy to place forums in multiple categories. You could write a utility function to cater for data being grouped in fields, such as:
ForumID CategoryIDs1 2|4|6|92 1|4Then you could check to see if a forum is in a specific category, with:
// Obviously, using text instead of numbers for clarity.if ($forum->IsInCategory(4)) // Stuff.At least that way, you'd save yourself having to query multiple tables for a one-to-many relationship, when the data you'd retrieve is very small. Sometimes more efficient to do it that way.
If there's anything else you need, post back.
You should, IMHO
- Use CSS for presentation rather than the mess that most forums use, full of redundant HTML and legacy code bloat (font tags, anyone)
- Use a database access wrapper system which means you don't send raw queries most of the time - automatically escaping all strings etc to the database - effectively preventing SQL injection attacks
- Use a system for wrapping pieces of text you output - such as a templating system like Smarty - make sure that EVERY piece of text you output that could possibly have been entered or modified by a user is correctly escaped.
Mark
- Use CSS for presentation rather than the mess that most forums use, full of redundant HTML and legacy code bloat (font tags, anyone)
- Use a database access wrapper system which means you don't send raw queries most of the time - automatically escaping all strings etc to the database - effectively preventing SQL injection attacks
- Use a system for wrapping pieces of text you output - such as a templating system like Smarty - make sure that EVERY piece of text you output that could possibly have been entered or modified by a user is correctly escaped.
Mark
Author
Quote:Original post by hellzThose were the fields, essentially. I left out an id field in each table because every one would have an id, and the stuff in angled brackets is a foreign key(if not technically, then in practice thats the way the queries will be constructed) to the type of thing mentioned (aka <category> in the forum table is a foreign key to a category).
The table design looks good, but it's hard to tell without seeing all of the fields in each table (I probably should have mentioned that you really need to go into that kind of detail before starting any coding).[...]
Also, in reguard to the suggestion about the forum->category mapping: The problem isn't neccessarily that I want forums in multiple categories, but that I want them to have multiple 'parent forums' so they might appear in the main listing, under forum X, and under forum Y (for example). Of course, the same solution would work, but I think that having a one->many table is a more flexable solution and more what I'm after. I can't believe I forgot about that simple design 'trick' =-(
markr: I'm not sure how a database wrapper would work. Do you mean it should know about all the queries that will be needed and have functions like GetForumList() that returns the proper info for the forum index page (list of categories where each category is a list of forums or somethnig like that), or something else?
As for wrapping ouput, all user input will be plaintext so I can just use the PHP functions to convert HTML symbols to the proper ampersand codes and stuff like that.
And I hope to use CSS (in addition to PHP templates), but that will be one of the last things I do because it means I have to learn proper CSS. If you know of any good tutorials, I'd appreciate it (I already know about the w3c site, and it makes a good reference, but no such a good tutorial {unless there are tutorials that I missed}).
Yeah, I agree that the one-to-many table design would be best; it's just more flexible in gneral.
As for using CSS, perhaps consider meeting XHTML standards, too. The more standards you can meet, the more popular your forum software will be. As someone pointed out recently, IE's hold on the browser market, is significantly lower than it used to be, so meeting browsing standards is rapidly becoming much more important to reach a target audience.
Obviously using the w3schools site, as you've already mentioned:
XHTML Tutorial
CSS Tutorial
Other tutorials:
HTML Help's Guide to Cascading style Sheets - Always been a really useful site. Definitely worth checking out. Incidentally, there's a CSS validator linked from that page, too.
XHTML Tutorial - Covers pretty much everything you need to know to write XHTML. There's not that much to it really.
Validator:
Markup validator
Hopefully that'll be of use.
As for using CSS, perhaps consider meeting XHTML standards, too. The more standards you can meet, the more popular your forum software will be. As someone pointed out recently, IE's hold on the browser market, is significantly lower than it used to be, so meeting browsing standards is rapidly becoming much more important to reach a target audience.
Obviously using the w3schools site, as you've already mentioned:
XHTML Tutorial
CSS Tutorial
Other tutorials:
HTML Help's Guide to Cascading style Sheets - Always been a really useful site. Definitely worth checking out. Incidentally, there's a CSS validator linked from that page, too.
XHTML Tutorial - Covers pretty much everything you need to know to write XHTML. There's not that much to it really.
Validator:
Markup validator
Hopefully that'll be of use.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
