The SavageReactor CMS

SR CMSThe SavageReactor CMS (hereafter referred to as the SR CMS) is written entirely in PHP and uses a MySQL database for storage of all site content, excluding images and downloads. It has been custom built by me, to meet my requirements, as such it isn't available for public consumption, at least not until I'm 100% sure that I haven't missed sanitising any user input. The following explains some of the key features of the CMS.

CMS Areas

The CMS is broken down into the following main areas:

Users, Groups and Policies

While designing the CMS, I wanted as much expandabliity and usablility as possible. It started occuring to me, that I may want friends to be able to add content to SR, but without the risk of them trashing the rest of the site. The solution to this was to implement users, groups and policies. These are a combination of Unix style user and group permissions, coupled with an Active Directory style policy system.

When any action is performed on the CMS, be it the front end, or administration panel, a user account is used, this could be your user account, or the standard "anonymous" account. First, the policies are checked to ensure you belong to a user or group who is granted access to the requested area.

For example, the CMS administration panel, may be setup to allow the 'cms_admins' and 'content_publishers' groups to login, another policy may specify that 'content_publishers' do not have permissions to upload images or delete pages etc.

Once the user passes the policy check, the object they are accessing is checked. An object could be a page for example. Every object has it's own user and group object, although this can be inherited from it's parent, in the case of a page, the parent would be the folder which contains it. Object permissions are stored in the same way as Unix permissions, using 0700 for user access only.

This way, specific users can only maintain specific pages, for example, if I wanted a user to maintain a section on cars, I would create a cars folder, and give them read-write permission to it, but no permission to anything above.

Add-On Modules & Runlevels

I don't have a huge amount of experience with other CMS's out there, but from what I have seen, installing add-on modules to the likes of phpBB, Invision PowerBoard and the like seems to be a huge chore that involves uploading files, setting up database tables and configuration options and sometimes modifying code.

In order to simplify this on the SR CMS several database tables are used to maintain and keep track of modules. To install a module, you simply extract and upload it, go into the administration panel's Module Manager where it will show as "awaiting installation". Click install, and the module is installed, database tables created and default configuration options added. You are then returned to the Module Manager to continue setting up the module.

Being a Linux user, I stole the idea of runlevels. Runlevels are applied to the front-end of the CMS. Every time a page is requested, the process of retrieving and building that page is split into levels. For example, the mod_redirect module, which allows redirecting installs itself into runlevel 0, which is executed as soon as the database is initialized. The module would then check the URL, and redirect if necessary, stopping execution at level 0. If a redirect isn't necessary, the front-end will advance to level 1.

More Info

If you're really that interested in the SR CMS, and would like more information, and if I'm feeling nice, the source code and installation instructions, please contact me.