Sometimes we are asked to "Compare CMS and wiki", or asked for a "Blog and wiki comparison". Or, "Should we have a forum or blog?". Here is an appraisal of what each does, and how they work. You will be able to see from this which would be more appropriate for your own purposes.

• CMS = content management system - server-based software that holds and publishes all types of content, and often has multiple options as to how the website appears and functions.
  
• Wiki - a visitor-edited resource such as an encyclopaedia.
  
• Blog - a diary or news column type of page display, normally with a comments section for readers' opinion.
  
• Forum - a noticeboard program that allows people to start new topics or respond to existing ones.
  

All applications in these classes are dynamic server-side programs, with a very few exceptions. That means they are software that is installed remotely on a server and that interacts with a website visitor's browser. They present content from a database on the webserver to those who request pages or other information - other media can be served, like images, video, music and so on. A 'dynamic' site runs from a database, and page content can be changed; a 'static' site is of the older type, with normal web pages that cannot be changed once on the server.

Dynamic sites are substantially different from the older style of website that consisted of HTML pages existing on the server. These applications (or 'apps') have no existing pages, and serve content from a database, which is an information storage program that holds the text and publishing instructions. Some files exist in the usual directories (folders on the server), such as images - and the occasional static page such as an error page - but the majority of the content is supplied from a database. Pictures and other non-text media comes from the usual server folders, but all text and publishing / site management instructions come from the database - there are no pages on the server.

Database options

All of these apps therefore need a database. There are cut-down versions that do not need an SQL database, but instead use a flat-file database. This is not really a full DB, it is a text file of some sort. In fact a flat-file site can in theory hold 20,000 pages plus, but there are a lot of issues at this sort of size; a site of 5,000 pages using a flat-file DB is noticeably slow. A more practical limit would be a thousand pages; and in any case these applications do not normally have all the features of a normal database-run app. They are cut-down versions that can be used in otherwise impossible situations, such as where there is no access to a database, or to the server management functions that are needed to set up DB configuration. The flat file solution works on an IIS (Windows) server, which in some cases may have no PHP-SQL software on it, which is the database management software that 95% of blogs, wikis, forums and CMS use.

Databases hold information in an SQL format - ''structured query language'. This simply means an organised format as against random text. The most common DB is MySQL, an open-source (ie free) application. In essence the Internet runs on it, as it provides the backbone for countless services. The most popular proprietary equivalent is Microsoft SQL Server, which is the SQL DB used on Windows servers. There is a very much smaller user base here. Do not confuse this with MS Access, which is strictly for personal use on PCs, and was not designed to run on a server. Server technology has to be able to be hardened against attack, as it is constantly bombarded with threats of one kind or another; and Access cannot be hardened 100% as it was not designed for this scenario.

LAMP and Windows servers

A standard webserver is known as a LAMP server, standing for Linux - Apache - MySQL - PHP. There are other types such as Windows servers, also known as IIS servers. These have fewer options and often cost more to run a dynamic site on. They are used if you prefer the ASP codebase to the more usual PHP one.

Always use a Microsoft SQL Server database with a Windows web server, not an MS Access DB. You will usually find that hosting with the correct databases is not offered at the bargain end of the scale, for IIS. For example, on LAMP server hosting (the standard type), you can find a basic hosting deal with 5 databases for about £20 ($30) per year. On Windows hosting, an account with just one or two MS SQL Server DB's might well be £100 ($150) plus. Two DBs are needed for any commercial site.

How many databases are needed?

Only one DB might be sufficient for a basic website. However, a commercial site will need to run web analytics, and these need a separate DB. All webapps on a site could in theory run on the same DB (by using a table prefix), but this is very poor practice. It may be acceptable for 'secondary' applications to share a DB, but this should not be done with the main website application.

Therefore a CMS needs one DB, and web analytics plus a forum or wiki could possibly share another. So the minimum number of DBs a business site will need is two. This is not normally an issue on standard servers, since almost all hosting deals include at least two DBs. On a Windows server this might be an issue, though, as although one MS SQL Server DB is usually included, a second and third tend to incur additional cost.

Open source

OSS (open-source software) is very strong in this area. Commercial software only challenges in the CMS department, apart from one notable exception in the forum area. This means there are a multitude of free software options, and often only some of the more advanced plugins will cost; even then, they are likely to be inexpensive. This has probably been a major driving force in the expansion of the modern dynamic website field.

How forums, blogs, wikis and CMS are managed

Wiki applications are installed on a server and connect to a database on the server. They are an online editable resource. Typically, they are multiple-page documents that can be edited either by anyone, or by registered members of a group.

Wiki pages are edited using a plain code editor, but instead of using HTML they use wiki markup. This is for several reasons such as HTML being too complex or too risky to allow users access to, and it being easier to avoid the use of a plugin editor by using a plain code interface. This means that to edit a wiki, some wiki code has to be learnt. It's not vital, but a page written without it has no formatting and therefore looks like a Notepad page. Wiki markup is a similar concept to BBcode for forums, but uses different markup.

A wiki is an excellent tool for maintaining a manual; a software manual or help files; an encyclopaedia-type resource; or any other collaborative document that will grow and evolve over time. The most famous of all is Wikipedia, on online encyclopaedia of 5 million pages plus.

Since a wiki (or at least 'the' wiki, Wikipedia) can be edited by anyone, the information may be inaccurate or biased; but it is usually of excellent use for a topical overview. For any kind of authoritative data, the original sources must be researched. In some cases, pages are of high quality; in others, poor. In general, though, quality is much higher than might be expected.

A closed-group wiki is a fine solution for maintaining a specific document such as a manual. It is normally found now that community resources magnify the effect of any project by a considerable factor; and the use of a wiki is one way to harness this power.

For example, if a developer is working mostly alone on a free or inexpensive software application, it is unfair to expect them to provide extensive documentation - since this can easily take as much time, or even longer, than the main work on the application. In this case, the community can contribute by improving the documentation on a wiki, and this provides many benefits. It is probably fair to say that the end result may not be absolutely perfect, even in the case of very large communities - but that is not the point. Even commercial enterprises take this route as it has so many benefits.

Among the many wiki apps available are MediaWiki - the original, and probably the most complex and with the widest capability; Docuwiki, a similarly-capable app; and PMwiki, a flat-file wiki that does the job very well. Since a wiki is the simplest of the three application types we are looking at here, it follows that a flat-file solution is more likely to be successful. This turns out to be true in practice.

Normally, a wiki application is installed by FTP and browser command, using a database, usually the MySQL type. The usual codebase, again, is PHP.

CMS applications are installed on a server and connect to a database on the server. WCMS - website content management systems - are the modern way to run a large website; or one that has regular content changes; or one that needs extended functionality; or one that needs a multimedia capability; or, of course, a combination of these requirements. In fact, especially so in that case.

Like the other dynamic apps described, a CMS resides on a webserver and works with a database. Or, it usually does - but there are exceptions as with everything. Essentially, you may upload content of any type (text, images, graphics, video, music etc); edit pages quickly online; move your content around and display it as you see fit; and allow website visitors many privileges and interactive functions that were impossible on old flat-HTML websites.

A CMS is usually template-based, meaning that the design and layout is pre-set but can be altered; and that design and operation is separate from content. Whatever you do with the actual content (the text, articles, pictures etc) does not affect the page layout or site operation. This is in direct contrast to a flat site, where the content basically is the site.

The CMS route is the best way to manage large amounts of different content types that need regular or even occasional edits. These apps tend to be focused on one or two operational models: in other words, each works best for a particular purpose. These might include: as an online brochure or 'shopwindow'; as an ecommerce application with multiple content pages; as a community or news publishing app; as a multimedia publishing tool; as a team collaboration tool; as a multi-team tool; and so forth.

There are thought to be around 3,000 CMS applications available, both commercial and free. There are some very expensive commercial systems like Broadvision, which may cost hundreds of thousands of dollars to implement; or free ones that are both compact and simple to use - such as CMS-MadeSimple.

CMS quality
Commercial and open-source (free) CMS have no quality difference, and in practice it is easier to find high quality in open-source at present. A capable WCMS is about the most complex web software possible, and the large distributed teams (called projects) who produce the big open-source CMS are recognised as very successful in all areas except perhaps documentation.

To quickly publish pages with the minimum of hassle, the micro-cms WordPress takes some beating. For normal publishing tasks, through to complex news or multimedia publishing, you might choose Joomla, which is free, extremely flexible, capable, and well-supported. Drupal CMS is a quality application that has good ACL (which put very simply is the ability to limit users or editors to certain pages or sections). For medium-large business use, Drupal and eZpublish are popular. For an enterprise-class WCMS framework you could use eZpublish, Alfresco or Plone, though these require specialist hosting and support. These are all OSS, and there are commercial equivalents at every stage.

Open-source vs commercial CMS
The field of web CMS is one where free software is supremely successful. Because of the complexity of these applications, the large open-source teams work well. Quality issues are well taken care of, with web standards compliance, legal compliance and accessibility issues normally well-covered. The same cannot always be said about commercial CMS apps although of course there are many examples of fine quality. In addition, open-source apps tend to have a much greater number of plugins available (5,000 for some examples), and since plugins contribute so much to how modern webapps work, this is extremely important. Without the plugins, custom work is needed - and that's not optimum use of CMS.

Because of the large numbers of CMS applications, there are many codebase and installation options. However, a popular choice is the standard PHP / MySQL base, since it is capable, robust and easily developed. Community-use CMS apps need to be able to be remotely installed via FTP and browser, though a CMS used by teams within an office can be local machine installable only. Commercial CMS applications come in many and varied codebases, server types and installation options.


Why use a content management system?
Probably 90% of enterprises will run their websites on a CMS eventually. It's the most efficient way to operate a commercial website, and does a large number of jobs very well. It has advantages in virtually every area over the old style of website based on pages. There are probably only two types of site better off run the old way - tiny, minimum-cost sites; and sites with highly complex and unique functionality, combined with a big budget to build and operate them.


SEO for CMS
There are many more complex issues when search optimising a CMS than with an HTML website. These essentially fall into the following areas:

• Since you cannot (normally) alter the framework page code, the core application developers need to have paid a lot more attention to accessibility and SEO than in a hard-coded site
  
• Even if the base application is good in this respect, poorly-coded templates and other plugins can easily destroy a good foundation
  
• A good CMS can be wrecked by unskilled implementers
• The tuning issues are often very different from HTML sites
  
• DB-driven web applications have many more security considerations than flat sites - and this affects all aspects of the operation
• Hosting issues are far more important with CMS - any host can handle an HTML site, but this is not the case for content management systems, where apart from anything else, the hosting needs to be of better quality than is occasionally evident
  

Forum software

Forum applications are installed on a server and connect to a database on the server. Forums are a core part of the social web, and also provide some of the best technical support options. Because of the vast numbers of people who use them, much useful information can be obtained; or you can just get into a discussion on what's the best rum if you like.

Forums have a built-in visual editor of simple form, and convert the user part of the code to BBcode not HTML. This is a similar thing to wiki markup although of a different type. It's used because HTML is too open to exploits to be allowed on a forum. The BBcode (bulletin board code) allows links and images to be inserted without risk.

A forum will normally comprise several separate Boards, which are the individual topic-centred discussion pages. You can read through others' posts (meaning the text they have placed on the page), and reply yourself; or you may start a new topic with a question or a statement. As with many areas there are conventions, etiquette, best practice and terminology to be learnt, but this need not handicap a newcomer. The forum can be both browsed and posted to via the ordinary web browser, and of course this is part of the power of these webapps - only a browser is needed to communicate fully in both directions with a forum, blog, wiki or CMS; so a lack of software or facilities cannot hamper anyone.

The best-known forum applications are SMF (open source) and vBulletin (commercial). There are many plugins for each, which all dynamic applications need or they cannot function fully in the modern Internet environment.

Forums are an online conversation tool where all can read others' opinions and post (upload) their own views. Each topic is completely separate from other topics, which means a forum is a better-organised affair than a blog. The difference between a blog conversation and a forum one is that a blog is a bi-directional affair, with the author / owner at the top; they control the direction of the conversation, since they own the site and posted the original article. A forum, in contrast, is a round table affair where individuals may start their own topic or reply on any one of dozens of other topics. A forum can be read, posted to and returned to at intervals; a blog post tends to be done and dusted after a few days or so. Forums have a searchable database of information, often of great value where experts on the subject post to the forum on a regular basis. The forum will email you when activity occurs on topics you are watching - and this facility is crucial since a busy lifestyle makes it impossible to cover all your web interests otherwise.

A forum is installed by FTP and browser command, using a database, normally of the MySQL type, with the usual PHP codebase. As with all these applications, there are alternative options using the ASP codebase for those sites using a Windows server.

Forums and security

Forums have more security implications than any other type of web application. These are so numerous, in so many areas, that a list and its accompanying discussion would take pages. Suffice it to say that untried and untested forums may work well and look good - but that is not the primary requirement. We think it is security and all the associated issues.

For this reason we cannot advise using any solution other than one with a long history and solid background. Some forums, though very popular, have proven easy to exploit, and as a result entire servers have been turned into malware farms. Mentioned above are the two options that we would recommend in open-source and commercial.

All-in-one Blog - Forum - Wiki

Is it possible to find an application that does all these jobs ?

Sure - install a CMS. Most content management systems can have these other functions plugged in as required. The least expensive option we know that performs really well in all these areas is Joomla CMS. If you expand it to include all these options it won't be simple for a beginner to set up or to run, though, but that is only to be expected. There are plenty of places to get help but the best solution is probably to find a mentor who will help you - unless you can take the commercial route.

There are advantages and disadvantages to the various ways of running all these applications on one website. The three ways to do this are:

• All installed separately
• All running as CMS plugins
• The other applications are bridged to the CMS
  

If they are all separate, ie co-installed on the same website but as different and discrete applications, performance is best under heavy load and problems are reduced. But this has the big disadvantage of separate logins for all the sections of the site, which can be inconvenient.

If you can find a CMS that does exactly the jobs you need, plus it has the required plugins for the application types under discussion, you would probably find that this is the best solution of all. However, the content management systems that do this well may not be of the class you need. In any case a blog is not normally connected to a CMS - there are plugins for this, of course, but a separate install seems optimal as there are few reasons, apart from styling, to use a plugin.

If a forum and wiki are bridged to the CMS, then at least there is a single sign-on. But bridged applications often have problems with login issues, and seamless operation is something of a pipedream.

There is a full discussion of the options in this area on the Compare Forums page, as it is especially important for that use.

A fully-extended CMS with other main website applications running as plugins has several advantages and disadvantages:

• It is far easier to manage than a bunch of separate apps
  
• It has a single sign-on
  
• It has co-branding (theming) across the site by default
• Templating is therefore far simpler
  
• It may be easier to do upgrades and security patches
• SEO may be of much higher quality than for any of the individual apps

But:

• The plugins can never approach the functionality of specialist apps (unless they are basically a repackaged/plugin version of a main website app
• Such a CMS is not for beginners, the webmastering may be complex
  
• The CMS will be heavily loaded
• There may be scalability issues
  

It is necessary at the outset to choose between a commercial, semi-commercial or open-source application. In the CMS field, there are plenty of all types. There are fewer commercial versions in the blog, wiki or forum areas.

Open-source is free software with published code - though there are a lot of variations on this theme - and essentially means that costs are minimal for the software, though some plugins may need to be purchased. Even commercial plugins are often inexpensive, in this area.

The first thing to recognise here is that the quality of the applications is often superb, and equal in every way to commercial ones. Of course, offerings vary between the limited, through the competent, to the outstanding. The Internet mostly runs on open-source (more servers run on it, using Linux and Apache, than on any other solution), so there is no question of this being a second-class option. However, support services vary from non-existent to extensive, depending on the software. Community support is very important in this area. There are always costs associated with managing a complex online presence, and even if the original software was free, this does not apply to any other aspect.

Semi-commercial normally refers to an open-source core application with mostly commercial plugins. These CMS apps are typically mature and stable tools with extensive plugin availability and support options. The costs are normally slightly less than a full-commercial set-up will approach; with the bonus that there are going to be more options in most departments than with a commercial product, and most likely a lot more plugins.

The average commercial CMS software one-off license costs from £2,500 upward - though there are some at a fraction of this. Often, a license at £2.5k and up (or $5k in USD) will include initial implementation. A license at for example £500 cannot include this, so the initial cost will probably be the same once implementation is taken into account. These costs are for 'value' options at the lower end of the scale. Commonly, a full commercial set-up will run from £10 to £20k-plus ($20 - $40k) for a smaller mid-range implementation.

There are advantages to trialling an OSS CMS first, whatever the intended eventual route; and many enterprises stay with an OSS solution even though they could afford a mid-range commercial solution. As costs escalate, with multi-site considerations and extended functionality, it is normally found that the initial software license is not the largest percentage of the final costs, even with a more expensive commercial CMS license.

LAMP servers

Ninety per cent or more of these modern dynamic web applications are designed to run on a normal server, ie a standard Linux / Apache server, which is the most common and universal type, and often called a LAMP server. There are alternatives of course, such as Sun, Lighttpd, and Windows. Some of these are effectively the same as a LAMP server, as the operating system or server application variant behaves precisely the same as its LAMP equivalent. Unix works about the same as Linux; Lighttpd works about the same as Apache - at least, for all practical purposes.

However, there is one type that stands alone: the Microsoft Windows IIS server. These are used when the main website application is ASP and/or .NET based. You should always specify Linux / Apache hosting unless you have a specific and potent reason to do otherwise, since there are vastly more options in all areas when using LAMP; and your costs will inevitably be higher on a Windows server.