Anatomy of a CMS – Part 3
This is article is the conclusion of the Anatomy of a CMS series.
In 2005 the latest evolution of my CMS system was released. Although the new system was based on many of the concepts I had used in the Webedit system it contained a completely new code-base written in PHP instead of ASP which I had used for the previous versions. In addition, although I kept MySQL as the database engine, I completely redesigned the database itself making the coding of the site easier and the application itself far more efficient. This new framework along with MySQL allowed Bridge to run not only on IIS, but also on the more popular Apache for even more compatibility.
As for features, but the time I released Bridge there were a number of items I knew I would need to incorporate:
-
A screenshot of the Bridge main menu
I would need to continue managing users allowing for overall system security as well as providing users to only the data they needed. To accomplish this I borrowed from the Webedit by using a permissions table to associate users with the data modules they would need access to. To beef up security I made more use of cookies and began to use sessions to track a users inactivity. I could now log out a user after a specified period of inactivity preventing someone from doing any damage if the user walked away from their computer for a while. Now a user must log out or end their session or they will have to provide their user-name password the next time they log in. It is also smart enough to allow for auto-login into the system should the browser be closed and the user return before the activity timer stops.
- For system level security I’ve put bridge on a separate domain from the website it supports and have made use of IP filters to prevent access to certain sites. This has greatly improved security as a whole.
- As injection attacks have become more common I wrote a cleanit method to remove all unnecessary code from entries. This method is applied to all form submissions throughout the site.
- While I still make use of email subscriptions on some content, I’ve been able to boost that security a little as well. Now only an email address has to be entered to subscribe or unsubscribe. An email is then sent to the user with a link to confirm the selected action. If the address is already in the system it will be deleted, and if it is not it will be added to the subscription database.
- As RSS has become more common I have included it within the system. Selected content can be published automatically to an RSS feed. Feeds are updated whenever a record is added or modified within it’s own module as well as when a user logs in to the Bridge system. Although cron would have been another option, I elected not to use it to keep the code a little more portable.
- For SEO I realised it was a bad idea to use a lot of get data in a URL. I wanted SEO friendly URLs, but was limited again by portability. Although mod-rewrite would work fine in Apache, it just isn’t available in IIS without some expensive 3rd party applications. Instead I created a method of generating actual files for each entry. They are added and deleted as a module is updated and are checked for accuracy upon login. Although this admittedly would not be the best situation for a site with a lot of entries, with the few hundred I have in my sites it has so far worked flawlessly. In addition, the page itself can still be changed easily as the created file merely contains the primary key of the required data and an include file for the template I want to display.
- I needed to make things easier for users. This I did with the inclusion of three things. First, I added tutorials which can be linked to from the main menu. Second, I rewrote the main menu to represent the modules with pictures and not just text. A user can use a link below the picture to display extra information describing the module. Finally, I’ve rewritten the left menu to divide categories into sections and allowing users to turn off menu items that don’t edit website data directly. This keeps the menu from getting to long is some of the bigger sites.
- With the use of components such as FCKeditor I realized that now it wasn’t just advantageous for us to update dynamic content on the site, but also to update various static content such as the menus and various other data found throughout the site.
- Finally for some sites it was becoming necessary to incorporate features to publish data that won’t even be for the homepage. Instead I needed to use data such as an employee directory for other functions such as text messaging, and printing phone lists in printer friendly formats such as PDF.
Some of the standard files in a module.
After looking at all the requirements I had for Bridge I realized that I would not only have to keep with the modular format of Webedit but would in fact have to expand it to incorporate the ever-growing feature set. Now adding modules was easy, however making them all come together wasn’t. What I did was rewrite each module and each database table using as many “standards” as possible. For example the file to process as new record was the same for each module and only the necessary code changed. This approach lead to 4 standard database fields, and roughly 20 files that with minimum modification could be adapted for nearly any data type. To the right in a view of one of those modules with some of the standard files. In this case the files are for an employee directory, however I could change them to enter static content for a page on ice cream with about 5 minutes of work.
It is by using these standard files separately for each module and by being able to incorporate custom files within the modules when necessary that I was able to make the system all work together and allow the user to be able to edit any data without having to learn any new functions or features.
To tie everything together I use a common template as well as a few key files. First is the the login script. Not only does this do the normal security functions necessary to log in a user, but it also performs various other functions such as updating RSS and other files, and presenting data to the user in a manner that makes the most sense for that user. For instance, a user with access to only one module may not want to see a menu at all. They just want to edit their data. On another front a user may be entering data with their own content information for all sorts of entries. The login script sets the cookies and sessions that allows the modules to find and process these options accordingly.
Together the login script along with the individual module files allow for over 50 functions in some installations and can be easily modified and installed on a new system in less time than it often takes to set up a site with Joomla or another CMS therefore not only allowing a user to display his or her data in the way they want, but allowing them to do so quickly without spending hours editing configuration files.
As of this post, Bridge is actively powering about a dozen websites with modules for nearly 100 different tasks. Although a demonstration page is not yet available, I have bought a URL and look to launch a fully-functional demonstration by the end of the year. As with all coding projects, the more it grows the more I can find and add new features making this a perpetual work-in-progress that will continue to evolve along with the technology that powers the web itself. If you are a coder yourself and would like to help please let me know. I can often use all the help I can get!
Comments are closed.