+ Home
+ News
Ideas Whiteboard
The following list are the ideas thought of that the 1.0 release of phpMyForum should contain or at least be capable of working towards. Comments or suggestions to feedback@phpmyforum.org thanks.
Did I mention that Dido is damn fine music to write to? :o
- Easy to install
- Presentation system based on templates
- Should this be as php files that are include()d that contain php variables such as $name, $date, $message_body, that are replaced during normal parsing? This could be quick, but it may be restrictive.
- May be better to use a file that contains various keywords held in braces, such as {name} that are replaced inside a php variable. May be slower than the first idea.
- Template files should be found with their language and country part of their path / filename. This permits the site owner to translate the presentation layer and aloso customise it per country. We may also like to permit file patterns to match templates to let the designer pick a set of templates according to current website "theme" chosen.
- I'm thinking along the lines of an include($pathtotemplates."/$lang/country/theme/message-full.tpl"); for path format.
- Should be have a single php file that must be included at all times which itself provides an API to other "private"objects and methods?
- Objects:
- Message: contains the message itself, a link to the poster, and a link to the forum in which it was posted
- Forum: contains meta info about the forum together with links to the messages within it
- Need to think about common modes of display:
- List of forums in a heirarchy
- Be able to display current forum in 'breadcrumb' mode (parent - parent - parent - us)
- In parent - parent - parent us -> [ list of children ] mode
- Part of a drop-down menu (html select)
- List of messages in a hierarchy
- List of messages in the current forum sorted by date (ascending and descending), threaded (depth limit?) or flat-mode. How many per page?
- What information can we usefully present with a message list? Subject, date, posted by, and how many replies it's had? What if they were displayed in search result forum, would they need the forum name too?
- The message itself, a template with many bits of information available to be displayed:
- Poster
- Date posted
- Where it was posted (which forum)
- Subject
- Body
- Any more?
- List of forums in a heirarchy
Database Schema
Here are the current thoughts on what's needed for database storage of forum data.
Stuff we need to store:
- Forums...
- Must have a unique identifier (an int)
- -May- have a link to a parent identifier (a way of getting a parent/child/sibling relationship), zero for a root node. This may in fact be a reference to an object elsewhere on the website, such as a news or article item.
- Should have a short name quickly identifying it (e.g. "Support", "<product-name>")
- -May- have a longer descripton permitting site administrators and/or visitors to understand the forum's purpose, what's on/off topic, who's in charge, do's and don'ts when posting, etc.
- Must have a 'date created' date/time stamp
- Messages....
- Must have a unique identifier (an int)
- Must have a link to a parent identifier (a way of getting the parent/child/sibling relationship), zero for a root node
- Must have a way of identifying the poster (we must support a user ID number or username, NULL for anonymous posting)
- Must have a way of vetting the post, so a single integer value would be useful here, such as zero for not checked, more than one for one or more levels of checking for content suitability (this can be used to moderate a forum)
- Subject/Title of the message
- Body of the message
- Date posted
- Date last updated
- Native support for pre and post processing. For example, a column indicating whether the visitor has chosen to format the message in html, or whether s/he wants the forum to do this (e.g. do we nl2br() it or not). This could be supported both as a built-in function for common desirable features, and an extra table column containing a set of comma separated numbers indicating particular pre and post processing user-defined functions should be applied to the message. This may require further clarification!
- File attachments?
And so for the database tables themselves...
Table: forums
| Column Name | Type | Properties | Column Description |
|---|---|---|---|
| id | Integer or String | Unique | Identifies the forum from the others, or references an object elsewhere on the website |
| parent | Integer | None | Zero says it doesn't have a parent, otherwise it's the id of it's parent forum |
| name | Short text | None | Short name identifying the forum in text |
| description | Long text | None | Describes the forum, do's and don'ts, etc. |
| created | Date/time stamp | time() created | Tells us when the forum was created |
Table: posts
| Column Name | Type | Properties | Column Description |
|---|---|---|---|
| id | Integer | Unique | Identifies the post from the others |
| parent | Integer | None | Zero says it doesn't have a parent, otherwise it's the id of it's parent post |
| poster | Integer or short text | None | Identifies the poster |
| moderation | Integer | Range 0-9 | Indicates whether the message has been through a particular moderation or vetting procedure. Number indicates what, if any, level of process it has been through |
| subject | Short text | None | A short subject that quickly indicats the content that the message contains |
| message | Long text | None | The full body of the message, which may include anything ASCII or Unicode (I presume we can do this). Not binary data. May contain HTML if desired |
| posted | Date/Time stamp | now() when created | Tells us when the message was posted |
| updated | Date/Time stamp | now() when modified | when modified? well when is this? define later |
| preproc | Medium text | None | Comma (,) separated list of functions that should be run over the message (what parts?) before it is committed to the database. No arguments can be given to the functions thus they must be kept within the appropriate objects and access private data structures |
| postproc | Medium text | None | Comma (,) separated list of functions that should be run over the message (what parts?) before it is given up for display in a template. No arguments can be given to the functions thus they must be kept within the appropriate objects and access private data structures |
Configuration
Some thought needs to go to a configuration system. Storing our settings could be done in two basic ways: file on disk (xml, custom syntax, or a php file), or a database table. It is probably preferable to store details in a database, although we would still require a configuration file to load such things as database source name (DSN) and any additional information such as a prefix string to phpmyforum's table names.