Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

The Requirements

Sign in to follow this  
Colin Jeanne


Merry Christmas everyone!

For this entry I'd like to describe the CMS I am planning on building. This will be the requirements that this project is designed to fulfil.

The Core CMS

My primary concern is that my system be flexible and scalable. I really have no idea what direction my site is going to take in the future so I would like to ensure that I can update this system quickly and easily. I believe it would be best if each application of the site (that is blogs, file databases, photo galleries, etc.) could be independent of the others and that the base CMS should not be dependent on any one application's existence.

In order to fulfil this requirement, the CMS should be able to accept and manage modules that describe an application. Each module should be a self contained set of code and auxiliary files that should have access to the shared resources of the CMS (such as the database). This will allow me to develop the site in parts: first the core CMS and then the individual modules.

Clean URLs
I want my URLs to be nice and clean, no ?module=blog&year=2004&month=12&day=25&item=TheRequirements junk at the end but rather blog/When/2004/12/25/TheRequirements, like at ongoing. That way I can change the underlying structure of my site as needed without breaking others' bookmarks. Further, this would make the URLs a bit easier to remember.

Since my site is important to me I'd like my CMS to be as secure from SQL injection and other hacks that could damage it or the users of the site.

Global Template
The CMS should support a global template for the site that would be placed in as few files as possible to allow for very quick visual modification of the site. The template will define the global navigation, header, footer, and layout. Each module will produce the content of this template.

I have yet to decide if a module should be allowed to override the template. I'm leaning towards, no.

A Central User Database
One of the shared resources my modules should have is a central user database. This would store various information about the users (email, password, hometown, interests, etc.) so that each could have a profile but would also maintain their level of access to the site. There should be a privilege flag for each user that determines the actions the user can perform, such as create resources on the site for modules that allow such things (a created resource could be a comment on the blog).

One problem I haven't worked out yet is how modules can maintain their own options for the users. For example, what it a forum module wanted a GD-like rating system, how would the module be able to store ratings? If I could find a way to work this out it might replace the flag the privilege flag mentioned before.

The Base Modules

These are the modules I currently have planned that should be enough to recreate my site as it is currently

The Blog
The blog should support the addition, deletion, and modification of enteries. I should be able to give an entry a specific post date (so that it can be something other than the current timestamp) and a last-modified date. Each entry should be able to be inserted into one or more categories where categories are easily created. The entries may then be searched by category or by post time (where post time is organized by original post date, not the last-modified date).

Comments should be supported and should also be able to be disabled for individual entries, categories, or globally. Anonymous comments will be supported although may be disabled. There should be a way to close entries to comments after a certain interval of time.

HTML should be disabled in the entries as well as the comments in order to ensure XHTML validity. Instead, some sort of BB code should be implemented that can be extended as needed.

Links Database
There should be a links database that stores links in one or more categories, have a title, and a short description. This module will support the searching and organization of these links.

I want this module because I find it difficult to manage my links now. I try to categorize them but some fit in multiple categories and others dont seem to fit well in any category I have created. I really dislike duplication of links on my static pages because it makes it difficult to remove all instances of it if I find that the site is no longer up or no longer what it used to be.

Downloads Database
Similar to the links database, this module will support the organization of downloads. Each download may be in one or more categories, has a title, description, and option of a screenshot.

Photo Gallery
Since I plan on having a lot more photos on my site I would like a module that is able to organize and present them as well in a similar manner as the downloads and links databases.
Sign in to follow this  


Recommended Comments

Guest Anonymous Poster


I'm severely lacking in actual experience coding, but couldn't you atomize the data for modules by assigning common UIDs and using SQL joins to gather common data? only problem is ensuring unique table names and possibly allowing modules to interact with each other...

Share this comment

Link to comment
Do you think giving each module a UID and providing a way to query all modules would be a good system? I was already planning a system where a module would be need to be registered with the CMS before it could start functioning; this process could assign a UID to the module as well as associating a name with the ID. Each module will be required to access the database through one database class so that no module need know the password of the database or any other information, in the operations to access module-specific tables this database class could prepend the UID to the name of the table to ensure that each table has a unique name. This would be done when creating a table

/*Creates a table logically named 'comments' for module 'blog'
The table would actually be named '1_comments' assuming the module's UID is 1*/
DB->create_table('blog', 'comments');

Another function could be created that allows a module to access the true table name. Perhaps like:

$table_name = DB->get_name('blog', 'comments');
/*$table_name now equals '1_comments'*/

A module would be required to use this table name in order to perform queries.

DB->query("SELECT * FROM $table_name WHERE user = $user_name");

A second module could then access the tables of 'blog' as long as it knew the names of 'blog's tables (before the UID was prepended). It could just use DB::get_name() to get the real names of the tables for one or more modules and use JOIN.

The second module could know the name of the blogging module through configuration by the administrator.

Share this comment

Link to comment
Guest Anonymous Poster


ER... I think I tried to say to much in one post there. What I meant was giving each user an ID (as the U in UID was meant to stand for... I suppose you thought either I didn't know that or was stretching it to mean the module as a user)

I can think of one problem off the top with just using an ID number for the modules, the base system would need to know what every module did, or at least have to associate a unique ID with a module after it gets registered, but what happens when you want to unregister a module? rename all the tables for modules that came after that? add error handling to whatever function scans for tables (if such a thing will be used, personally I think that after this method stays in use through several adds and removals of modules, the database would look "ugly".

What I meant by atomizing it is that each module gets their own table or tables, possibly prefixed with their own name or just make sure that their unique (preferrably something like the first one, since you're wanting expandability). After that you have several choices depending on what type of modules you have. Are they user selectable, or just admin selectable. If user selectable, you'll probably want a table that just specifies which UIDs are using which tables, or maybe you'll want to just tack that on to the end of a generic user_info table, whichever you think better suites your development/maintenance tastes. If it's just admin-selectable, you won't need that at all...

On a side note, you mention a central user database. This could actually be accomplished through using select joins on multiple tables to gather your info for presentation on a single page with one query (it will get to be a rather large query if you atomize too much... there is a balance to be had somewhere here as to how many tables are necessary for efficient storage AND retrieval of data...)

I'm not entirely certain, but I believe the clean URLs needs to be done with a combination of apache and modifying your code... in fact, here's what google turned up for me... http://www.evolt.org/article/Making_clean_URLs_with_Apache_and_PHP/18/22880/ be sure to check the comment section for further methods...

Share this comment

Link to comment
I interpreted the U to mean 'unique' ID for the modules, yes. Although the system does give each user a unique ID as well. For the module IDs, it might only be necessary to use the name of the module as the ID. The way I am planning on having the system work is to break the URL into the parameters for the module, one of these parameters is the name of the module to be used. For example, we'll say that I have a module whose ID is 'blog', I could access the module by the URL


The clean URL code splits the URL into an array of the 'directories' so that 'blog' is the first index, 'When' is the second, etc. The CMS will then find the code registered under the name 'blog' and then pass the array of these directories to that code. I have a test implementation of the clean URL system up here. Typing in something like http://www.invadersrealm.com/cjnet/A/Random/Directory/A_File will just print the URL after it has been split and after the name of the module has been extracted. The system also correctly opens the file http://www.invadersrealm.com/cjnet/test/variables.html

As for the central database, after further thought I decided to only include a user ID, an MD5 hash of their password, their name, and their join date since these seem like they would apply to any module that needs information about users.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!