Chris Wiegman

Archive for August, 2008

I’ve been a fan of free and/or open-source software for some time, however I’ve just never been truly able to move to an all open-source platform. I’ve tried Ubuntu, OpenSuse, and various other Linux distributions as well as putting all free and/or Open-source software on a Windows system and every time I wind up with my tried and true Windows software. Although there are probably 100 or more little reasons for this, I can sum it up in 5 reasons.

1.) Many of my peripherals and other hardware just won’t work on the free operating systems. Whether it’s the audio or a scanner or something else the only way I can ever get everything to work at once is by applying some rather complex band-aids which, although they support the basic features of the hardware, never seem to support all the features I need.

2.) Too many updates! Some people complain about the frequency of Microsoft’s or Adobe’s updates, but they’ve got nothing on the daily downloads I need to keep my Linux OS and its software secure. On top of it, many times the updates modify the feature-set which can really add to the frustration level when the button you press doesn’t do what you expect it to.

3.) When I do find a software I like it often isn’t long until it gets cancelled. I can’t count the number of apps I’ve grown to rely on only to have them cancelled a few months later as the developer(s) just don’t have the time or money to support them anymore. Of course this happens in the commercial world too (just ask anybody who really liked Wordperfect) it is far more prevalent and can be far more annoying with OSS.

4.) While community forums can help with some support, they just can’t take the place of dedicated customer service people. I don’t use support services too often, but when I do I want to be certain that the person I’m talking to knows what they’re talking about.

5.) A lot of software packages just don’t play nice with each other. Firefox (as an example) is great, but it just doesn’t integrate as well as IE. This is true with office suites, IDEs and so many other applications. When your computer is composed of software from primarily one or two companies you know it will all get along far better than apps from all over the place. I’ve had more than one instance where the cool new app I found for one thing killed the functionality of something else. More often than not these problems often aren’t even evident for some time after you installed the new application which can make troubleshooting a lot more difficult.

In a nutshell, free/open-source software is good in doses, but to use it exclusively and disregard the commercial alternatives more often than not just isn’t worth the cost of both convenience and time.

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:

1. 

   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.

2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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!

Continued from Anatomy of a CMS – Part 1

When I left off last time I had a very rudimentary system in place which mostly involved editing a Microsoft Access database directly to update any data. Not only did the learning curve involved make collaboration a problem, but the system was also prone to other errors such as data corruption and more that are common when working directly with Access files and then copying them back and forth with an FTP client.

After about a year of this system I had learned enough and coded enough to put in place a better system. This system, known originally as Webedit, allowed a user to perform all the data manipulation from a web browser such as IE thereby eliminating having to access database files directly and also reducing the learning curve involved to add or update data. It did however pose a few new problems for me.

First, I had to choose a back-end database that would work with the ASP coding I was working in at the time (this was before the days of .NET). Microsoft Access was a solid choice, but it was also rather limiting and prone to frequent corruptions. On the other hand, it was easy to backup in that I had only to copy one file to whatever backup location I had decided on. In addition, it was also easier in that I didn’t have to add too much to the server in order to keep things running. At this point though the site was getting big enough that I had to move on to something cheap that would also be easy to maintain and would not be prone to the corruption issues. Really there were 2 choices at the time. Microsoft’s SQL server and MySQL. Now I can probably post full entries on the choice here alone, but to make it simple the price and features along with the community support lead me to the MySQL option.

Beyond the back-end I also had to decide how to manage data. How would I branch out to be able to manipulate such diverse data over the whole site with one system? Also, with so many areas to edit, how would I control who would edit what?

The answer to the first question has become the backbone of most of my CMS coding every since. I started by dividing each area into pages or modules that functioned as applications in themselves and could be added or removed at will. For instance, the code to update the job openings data was kept completely separate from the code to update the departmental directory. In addition, separate database tables allowed me to store this data in whatever format I needed and eliminated the need to redesign the site around the CMS and instead allowed for the development of a CMS based on a site.

As for the users, I had to develop a system in which users could log in and access only the data that pertained to them. In Webedit this was done through a simple login system in which I stored the user data in one table and used a separate table to map the user to the pages they had permission to. It worked pretty well. Users could now log in, work on select data, and update the site directly from their browser. Like all early systems however there was some limitations.

Early on logins and passwords were stored in plain-text format on the database allowing anyone access to data they shouldn’t have had. In addition, as it was my first time working with such code security against injection attacks or even someone coming along later and sitting down at the same computer was non-existent. Webedit was simply found in a directory off the main site and open to the world. Finally, although more data could be entered, a user still had to know html in order to enter images, links, or anything else into their data. Forms were pretty much a collection of input boxes and text areas which although they were effective for basic data entry, couldn’t really provide the character or detail needed for many types of data.

It took about 3 years to work out the kinks in Webedit, but by 2005 it was a rather solid system used by 1 or 2 of us to update a single website. In addition it grew to accept entries from the public via the main homepage and could even handle simple tasks such as email subscriptions to areas like jobs and similar functions. Not bad for a part-time coding project.

In 2004 I decided I wanted my own page in addition to the Aviation page. The catch is what would I use to update it? By this point there were a few CMS systems on the market, but I still didn’t like what they could do. Webedit was working well for my office, but how could I use it for a commercially hosted site with completely different architecture and less ability to secure items like the database and others? Also by this time my lack of security knowledge was starting to show. We were hacked a few times at work and some rather obscene spam was appearing in places it shouldn’t.

It was time for Webedit to receive a major overhaul. I needed not only more updated code, but as ASP was rather obsolete by this time I needed a new framework as well. Hence work began on a new CMS.

To be continued….

There are a lot of good content management system (CMS) packages available to developers today. Wordpress, Joomla, and Drupal have captured the vast majority of a market that is no longer interested in how pages are made, but instead has realized that content is where people need to spend their time. Even my little site here wouldn’t be possible without  the use of a CMS system to help me keep things straight.

Today getting started with a CMS is as easy as downloading an open-source package like Wordpress, Joomla, or Drupal. These prepackaged CMS packages offer not only a quick way to manage content on a site, but provide you with templates for the very site itself therefore removing the user from all tasks except writing the actual content. For home users, bloggers, and small businesses these can be a great way to get your ideas and products out to the web without the headaches involved in site development and design.

What happens when these prepackaged sites aren’t enough? What happens if you want to collect and process data that doesn’t fit into their standard code? In some cases there might be plug-ins or addons, but with these you often spend so more time trying to get them to work then you would by just making the html files yourself. This is my problem with many of the packaged solutions although when I started with CMS programming these open-source solutions just weren’t available.

What I needed was a solution that would allow for news posts similar to blog entries as well as other information such as storing employee data, job openings, and all the other data necessary to college students and faculty where I worked. By the beginning of 1999 I was spending more time coding html than I was on keeping the computers running which is what I was really hired to do, and heaven help me if I made a mistake and forgot part of a tag or something else. I lost many hours trying to track down errors in primitive web code. In short I needed a CMS that would take care of a lot of this formatting.

When I first started coding CMS systems the term wasn’t even part of the vocabulary. In the early days this was simply an experiment designed to serve 2 purposes. First, I wanted an easy way to convert text to formatted html using data-sets with multiple fields and reducing the errors created by hand-coding all of the data. Second, I wanted to give others the option to edit the data themselves therefore encouraging contributions from those who had access to data I did not.

The first system I designed began in 1999 using classic ASP and Microsoft Access as a database. The goal was to store job and scholarship information to make more options available to students and alumni of the university I work for. I found that with a little bit of code I could not only display the data, but I could also make a form to add data to the database, and then it was easy to go in to the database itself to perform the other necessary tasks such as editing and deleting entries.

To say this was a limited system would be an understatement. To be honest about the only help it provided in the beginning was in making sure that whatever I put into the database would appear uniformly on the department website. There was just too much of a learning curve to get others to contribute and with only 2 tables it definitely did not reduce the time I spent coding a lot of the other information on the site. It did serve us for about a year though during which time I was able to develop a much more usable system that was really the first incarnation of the CMS I use on nearly all my sites today.

Too be continued….

OK, so this is my 5th or 6th post and suddenly I’m commenting on the blogosphere as a whole. Where do I get off? HAHA, Well, to be honest I don’t consider myself an expert blogger at all. Instead I consider myself simply someone who wants to share his thoughts with other like-minded people. Isn’t that what blogging is all about anyway?

It has amazed me how many people I’ve talked to over the last few weeks consider themselves professional bloggers. Isn’t this what you would call a journalist? The idea of someone who does this as their main source of income so completely goes against the original concept of blogging that I wouldn’t call it blogging at all. It is low-budget journalism. On top of it, in order to keep a constant stream of ideas it seems that just about every other blog out there is trying to be the next consumer reports. How many people need to write about the pros and cons of the latest digital camera or TV or whatever? Where are some original thoughts on things that interest you? If you are interesting enough that people want to read about the thoughts in your head than that’s fine, but please don’t base your blog on canned content just to have something to write about.

Where will blogs go? Who knows. I’ve seen people leaning to life-streaming and other concepts in their effort to be original. Although I’m not sure this is really necessary I would personally like to see a return to people blogging about what they no best even if it means they might not have 20-30 posts every day. I also know that while my page here might not be the most attractive or contain the most content what it does have is and always will be original and won’t be posted in an effort to simply build page views. Hopefully a few people will find that alone interesting enough to check in once in a while.