A website CMS or Content Management System is software that resides on a server and replaces web pages as a means of displaying a website. The pages do not exist and instead are created from a database on-the-fly, by the CMS software. The owner can edit content online without recourse to a webmaster. Additional website functions and features are added by means of plugins, so that custom development is not normally required. Page design is based on templates instead of the free-form method used in normal web pages, and this means that content is separated from design, so that each does not affect the other. This means the site owner can change the content without affecting the page layout, and that design issues are resolved more easily and quickly.
It is just as easy to create a 1,000-page website as a 10-page site, as the CMS creates the page framework and the content can be pasted in. A new page can be created and go live on the site in under two minutes if the standard page layout is chosen.
A website CMS is therefore the best way to run a large website, or indeed any site where regular edits or changes are made; and where additional functions will be needed at a later date. A large or complex site will be far quicker and cheaper to build with a CMS.
See also:
How To Use CMS - a guide to publishing content and other basic tasks
CMS terminology - the CMS dictionary - a guide to CMS definitions
CMS terminology - the CMS dictionary - a guide to CMS definitions
CMS advantages
- Pages are edited online via a normal browser.
- Edits go live immediately.
- The site owner can easily edit, add or delete pages.
- With minimal training, the site owner may be able to add new menu items and even sections to the site.
- Design and layout are controlled by templates - no custom design is necessary, though of course it can be utilised in order to extensively customise the page appearance.
- Additional functions are added via plugins - no custom work is needed.
- Plugins are (or should be) widely available.
- Content of many different types can be organised and presented in many different ways.
- Content is completely separated from presentation, meaning that the page content does not affect its layout.
- Rich media capability is usually better than for standard websites.
- Many people will have been down the same road you are on. This transfers directly to the CMS you will use, and even more to the plugins. This work has all been done many times before and you reap the rewards. Design issues, functionality issues, and how to do things better - all have been tuned already.
- 75% of web designers cannot even write valid HTML code (or can't be bothered to correct their first attempt). By using a modern, standards-compliant database-driven website application you avoid being dependent on the ability of your chosen contractor - a good thing, because 3 out of 4 are not competent.
CMS disadvantages
- A CMS must have a webmaster to oversee security and functionality issues. It is not like an HTML website that consists of static pages, that can be installed and then left. The webmaster needs to upgrade the CMS when security patches are released or when bugs are fixed. The website cannot be installed and then left.
- Freeform art-based websites are not ideally suited to a CMS.
- A specialist in the particular CM software used will be needed - an HTML website designer or a specialist in other apps will not get the best results.
CMS and WCMS
Some CMS software is designed for managing corporate content in-house and is not specifically for web publishing. Strictly speaking, if it is for web use it is termed WCMS (web CMS). However this tends to be used only among experts, and as far as we are concerned here, a CMS is for web publishing.
All CMS publish text and images as the primary, basic function. The other tasks they may accomplish determines what class they can be classified in.
All CMS use a database (DB) of some type, the most common being a variation on the SQL theme ('structured query language'). If no SQL database is available, then there is an alternative: a flat-file DB, which is essentially a text file. Naturally, these flat-file CMS applications are limited in terms of the maximum number of pages possible, but they can nevertheless be a better proposition than a standard HTML site for some purposes. If content is changed regularly, on a smaller site with no SQL on the server (or no access to the management apparatus), then a flat-file CMS could be the answer.
There are also a very small number of client-side CMS applications: these have the main application resident on the local PC instead of the server, and pages are generated locally then uploaded to the server. It is debatable whether this method of operation should be called a CMS or perhaps a website generator. It is used when there is no database on the server; when there is no access to the server management or even a control panel; or, finally, when the pagecode of the dynamic CMS is unacceptably script-heavy and a lightweight HTML alternative is needed.
So let's lay that out in short form:
1. On a normal website, the web pages exist on the server.
2. On a CMS site, there are no web pages on the server.
3. The CMS will normally use an SQL database of some kind to store the page text in.
4. The pages are built on demand and do not pre-exist.
5. When there is no SQL on the server, or no access to management functions, then a flat-file CMS can be used.
All CMS publish text and images as the primary, basic function. The other tasks they may accomplish determines what class they can be classified in.
Open-source or commercial CMS
There are a very wide range of content management systems available now - probably around 3,000 - so the choice is vast. They can be classified in many ways but the most obvious groupings are free software and commercial software.
At first glance it might look as if a free offering could not be of any value but in fact some of the best of all, until very large enterprise-scale requirements are reached, are free. This type is called 'open-source' software because the code is published. The advantage, and the reason it is often of high quality, is that it uses the modern distributed development system, whereby programmers join a project and contribute, and their contribution is rated by peer evaluation. This means that the best coders in the world contribute to these projects in their spare time.
It is important to realise that open-source software is not a cheap or second-class option - in some cases it is better than the commercial equivalent. This is not surprising when the real cost of development is calculated: one well-known open-source CMS would have cost over $5m to develop if the process had been commercial.
For this reason commercial software normally has to be quite expensive before it can compete in functionality and quality. All the modern advances in functionality, accessibility, standards compliance, SEO compliance, and web publishing innovation have been driven by open-source CMS. However the areas of documentation and support are not normally as well-organised as in the commercial field, and therefore enterprises may prefer to deal with a commercial single supplier.
CMS running costs
The most economical and easily-supported website content management systems accord with these basic principles:
For this reason commercial software normally has to be quite expensive before it can compete in functionality and quality. All the modern advances in functionality, accessibility, standards compliance, SEO compliance, and web publishing innovation have been driven by open-source CMS. However the areas of documentation and support are not normally as well-organised as in the commercial field, and therefore enterprises may prefer to deal with a commercial single supplier.
CMS running costs
The most economical and easily-supported website content management systems accord with these basic principles:
- The CMS is a recognised name and has a good reputation
- Plugins and templates are widely available from different sources
- The CMS runs on a normal webserver (a LAMP server)
There is nothing wrong with CMS that do not follow these principles, except they will be more expensive to build and implement, and much more expensive to operate, maintain and support.
There are a wide variety of offerings on the market, from the basic to the ultra-complex. Occasionally, websites are advertised as being a CMS only because they have an online editing capability; they do not comply with all of the other requirements for a CMS as stated above. Being able to edit a website online does not make it a CMS.
There are a wide variety of offerings on the market, from the basic to the ultra-complex. Occasionally, websites are advertised as being a CMS only because they have an online editing capability; they do not comply with all of the other requirements for a CMS as stated above. Being able to edit a website online does not make it a CMS.
CMS explanation
The term CMS means the singular or the plural, since it also stands for content management systems. These website applications work in a different way from normal sites, in that there are usually no pages at all on the webserver, apart from error pages and the like. Instead, there are configuration and application files (i.e. the 'works'), plus image and graphics directories, and a database. The pages are constructed on the fly, from text in the database, plus graphics or any other subsidiary files needed, and using publishing parameters (instructions) also from the database.All CMS use a database (DB) of some type, the most common being a variation on the SQL theme ('structured query language'). If no SQL database is available, then there is an alternative: a flat-file DB, which is essentially a text file. Naturally, these flat-file CMS applications are limited in terms of the maximum number of pages possible, but they can nevertheless be a better proposition than a standard HTML site for some purposes. If content is changed regularly, on a smaller site with no SQL on the server (or no access to the management apparatus), then a flat-file CMS could be the answer.
There are also a very small number of client-side CMS applications: these have the main application resident on the local PC instead of the server, and pages are generated locally then uploaded to the server. It is debatable whether this method of operation should be called a CMS or perhaps a website generator. It is used when there is no database on the server; when there is no access to the server management or even a control panel; or, finally, when the pagecode of the dynamic CMS is unacceptably script-heavy and a lightweight HTML alternative is needed.
So let's lay that out in short form:
1. On a normal website, the web pages exist on the server.
2. On a CMS site, there are no web pages on the server.
3. The CMS will normally use an SQL database of some kind to store the page text in.
4. The pages are built on demand and do not pre-exist.
5. When there is no SQL on the server, or no access to management functions, then a flat-file CMS can be used.
How a CMS page is created
A normal HTML website's operation is completely different from the way a CMS works. On a standard site, all the pages exist on the server. However, with a server-side web application such as a CMS, pages are built on the fly; they do not exist before a browser requests one. The sequence might go as follows:
1. The visitor's browser requests a page from the server.
2. The server (often Apache) looks in its cache to see if that page is in memory, having been previously served within a set time period. If yes, it supplies the page and its associated files.
3. If not, the server requests the page from the CMS.
4. The CMS looks in its own cache, if it has one, and if it locates the page pre-built, it then supplies it.
5. If not, it builds the page: it gets the publishing parameters and the text from the database, then graphics, images and other components from the relevant folders, builds the page, and passes it to the server app.
6. The server passes the page along to the browser. It also carries out a multitude of other tasks simultaneously: it queries the top-level htaccess file, queries the local htaccess file for all sorts of options and variables, serves the page's associated scripts such as CSS and JS scripts, executes any scripting, hands out one or more cookies, hands out the favicon, logs all the traffic involved with that page request, logs any errors; and all in 0.25 of a second - hopefully.
This sounds a bit involved but normally takes little time even for the longest process (provided that all parameters are optimal, which they hardly ever are). In reality there are some drawbacks.
This can be measured by benchmarking, which is built in to Apache server and therefore fairly easy to measure. As an example, while serving ordinary flat HTML pages, servers commonly benchmark at between 100 and 400 pages per second. The lower figure is a more realistic one, higher numbers only being possible when all parameters are absolutely optimal, which is unlikely in a production environment.
This means over a hundred visitors can be catered for per second on a standard webserver, all being well. This is a phenomenal number since if you calculate it as a visitor number per day, it comes out to over eight million. Even allowing for a factor-ten error, it is still far more than is ever likely to be encountered on most sites or even most multi-user servers. However, these are in effect theoretical figures because it is extremely unlikely a production server could supply pages this fast, multiple sites on the server will introduce all kinds of other problems, production servers have to execute other queries, a server cannot run at this load indefinitely, and neither can the network supply such a load to a single server. Even a factor-one hundred reduction in the page per second figure might not be sufficient for production.
However, when a CMS is used, pages served commonly drops to around four per second on the benchmark tests. Whoops! This is actually a much more realistic figure for a production server in any case; but because of the difference between a testing environment and a production server, as we saw above, the actual real-world figure is probably lower. Even four pages per second is a vast number that would not normally be required on a dedibox, though it might be needed on a busy multi-user server; but due to the difference between reality and benchmarking, the real figure in production is in any case probably even lower still.
These time lag and server load questions are partly resolved by caching - the 'memory pool' on both the CMS (usually) and the server which keep popular pages in memory, ready for instant serving. If nothing else this shows that a server needs plenty of RAM and fast disks. It also explains why server disks are more likely to fail than desktop PC disks.
1. The visitor's browser requests a page from the server.
2. The server (often Apache) looks in its cache to see if that page is in memory, having been previously served within a set time period. If yes, it supplies the page and its associated files.
3. If not, the server requests the page from the CMS.
4. The CMS looks in its own cache, if it has one, and if it locates the page pre-built, it then supplies it.
5. If not, it builds the page: it gets the publishing parameters and the text from the database, then graphics, images and other components from the relevant folders, builds the page, and passes it to the server app.
6. The server passes the page along to the browser. It also carries out a multitude of other tasks simultaneously: it queries the top-level htaccess file, queries the local htaccess file for all sorts of options and variables, serves the page's associated scripts such as CSS and JS scripts, executes any scripting, hands out one or more cookies, hands out the favicon, logs all the traffic involved with that page request, logs any errors; and all in 0.25 of a second - hopefully.
This sounds a bit involved but normally takes little time even for the longest process (provided that all parameters are optimal, which they hardly ever are). In reality there are some drawbacks.
CMS server overhead
This procedure requires some server overhead, building the CMS pages and carrying out the other tasks. It uses CPU time, memory, and all other resources on the server computer. This translates into two things: server load and extended page loading times.
This can be measured by benchmarking, which is built in to Apache server and therefore fairly easy to measure. As an example, while serving ordinary flat HTML pages, servers commonly benchmark at between 100 and 400 pages per second. The lower figure is a more realistic one, higher numbers only being possible when all parameters are absolutely optimal, which is unlikely in a production environment.
This means over a hundred visitors can be catered for per second on a standard webserver, all being well. This is a phenomenal number since if you calculate it as a visitor number per day, it comes out to over eight million. Even allowing for a factor-ten error, it is still far more than is ever likely to be encountered on most sites or even most multi-user servers. However, these are in effect theoretical figures because it is extremely unlikely a production server could supply pages this fast, multiple sites on the server will introduce all kinds of other problems, production servers have to execute other queries, a server cannot run at this load indefinitely, and neither can the network supply such a load to a single server. Even a factor-one hundred reduction in the page per second figure might not be sufficient for production.
However, when a CMS is used, pages served commonly drops to around four per second on the benchmark tests. Whoops! This is actually a much more realistic figure for a production server in any case; but because of the difference between a testing environment and a production server, as we saw above, the actual real-world figure is probably lower. Even four pages per second is a vast number that would not normally be required on a dedibox, though it might be needed on a busy multi-user server; but due to the difference between reality and benchmarking, the real figure in production is in any case probably even lower still.
These time lag and server load questions are partly resolved by caching - the 'memory pool' on both the CMS (usually) and the server which keep popular pages in memory, ready for instant serving. If nothing else this shows that a server needs plenty of RAM and fast disks. It also explains why server disks are more likely to fail than desktop PC disks.
Types of CMS
Content management systems can be divided into many different kinds, for several different purposes. Firstly, there are website CMS and non-website CMS. The former are designed to serve content on the Internet, the latter to contain and organise an enterprise's information in a private environment. Here, we are only concerned with website CMS, shortened sometimes to WCMS.
The next division is between the various classes of function, for example:
The vast majority of CMS are in the online brochure class, or at least operate in that class by default even if other roles are available. 'Brochure' class means that the website is an online equivalent of a printed brochure - its job is to present the business optimally, and display the products and services on offer. This is the definition of a normal website, since most sites are simply online brochures.
The most basic division is probably between the community / news model, and the provider-consumer model. These model types refer to whether a CMS is best suited to many people providing content, or one person or a small team doing so. The community model can be further subdivided into two sections: those suitable for one group or those suitable for multi-group use.
And so on, for other classes of CMS (see elsewhere on the site). In fact most CMS can perform several functions, although there is one feature that must be available in order for the CMS to work as a community type: frontend content editing and upload. Here, people can login via the frontend (as against the backend, which is the standard method and just for admins), and either input material or edit it online.
Often a CMS will function well in two or more classes, perhaps depending on what extensions (plugins) are available. It is possible to produce two or more versions from one basic CMS core, each being particularly suitable for one type of function.
A community / portal type CMS will function satisfactorily as a provider-consumer type with no modifications. The latter type is simpler because it requires fewer features, especially in the area of ACL. This refers to access control levels, or if you like, user rights - group or individual privileges such as editing, publishing and so on. This feature set is the most complex to provide, and to get right. An enterprise-level CMS must have a core feature set of elevated capability, including full ACL (group roles), versioning, workflows, and audit trails. There should be portal (intranet), VPN / WAN (extranet) and load-balancing capability. It is therefore the most complex.
Different types of DB affect how some CMS operate (SQL or flat-file), though this is transparent to end-users. A CMS normally functions as a managed content publisher, rather than a library of pages; and so it needs to be seen in a different light to flat HTML websites. It is best used as an interactive repository of information, whether that be at the first level, simply between owner and application; or at the second level, between visitors and the application.
The capability of individual CMS decides how many jobs they can do, how well, and in how many different ways. As new plugins are developed, new functions become available. From just being a convenient way of editing text, they now act in some cases as fully-interactive central community facilitators.
Open-source CMS costsWith 'free' applications (nothing is really free in the end) the costs vary with a DIY or commercial implementation. In DIY mode costs can obviously be minimised, though it is necessary to weigh up the implications of a go-it-alone approach. In 9 out of 10 cases the end result is not going to be as good, and of course the time input will be extensive.
Although in theory a DIY'ers time might not be costed in, since however it will be so extensive, and possibly three times as long as that of a pro who is doing the job every day, it needs to be itemised. As documentation, training and support will not be present, this should also be considered. Supporting a CMS might be the biggest time component of all, and the implications of this need considering - every CMS needs a webmaster, as they solve the problems. All complex websites have problems that need resolving.
Open-source CMS, DIY install and support costs:
Payment models
For both main choices, payment is usually in two parts - on install, and for support. For commercial implementation and support of an open-source CMS, a fee will be payable on install and then subsequently per year. These fees may be broken up into stage payments of one kind or another. For example there may be a deposit, then a balance payable on install. Then support costs may commence at three months in, and be paid quarterly or annually. A WCMS needs a webmaster and the client cannot do this - it is not a fit and forget solution like a fridge or TV. Upgrades, patches, and new feature requirements need to be factored in. Some running costs are involved, as might be expected for a commercial truck for example.
With commercial CMS the software license is also involved. This varies from a few dollars up to $100k or so for the big names like Broadvision. Many factors affect this cost, such as how many sites, intranet / extranet working, load balancing implications and so on. For single-site one-off installs, the license cost will be a fair proportion of the end cost, unless the software cost is very low. As the scale increases, the license fee becomes less of the end cost, as implementation costs will dwarf it (a Java CMS developer can cost £850 / $1,400 a day).
There is also another option, called Hosted CMS. This is where you simply pay a monthly or quarterly fee, with a minimal set-up cost. This is an attractive option for some buyers.
We should also mention the high start-up hosted type. This is essentially a standard commercial CMS install but you cannot choose the hosting, it is always on the developer's servers. This is probably a more common arrangement than might be thought. There are pros and cons to this, like all options - security is going to be good, but you may find there are severe limitations in other areas (with the type of web analytics you want to install, for example). This would be a deal-breaker for some.
The next division is between the various classes of function, for example:
- The micro CMS class
- The lightweight class
- The online brochure type
- The extended online brochure type, with rich media publishing
- The community / news model
- The provider-consumer model
- The enterprise class of CMS
- The ecommerce-enabled type
The vast majority of CMS are in the online brochure class, or at least operate in that class by default even if other roles are available. 'Brochure' class means that the website is an online equivalent of a printed brochure - its job is to present the business optimally, and display the products and services on offer. This is the definition of a normal website, since most sites are simply online brochures.
The most basic division is probably between the community / news model, and the provider-consumer model. These model types refer to whether a CMS is best suited to many people providing content, or one person or a small team doing so. The community model can be further subdivided into two sections: those suitable for one group or those suitable for multi-group use.
And so on, for other classes of CMS (see elsewhere on the site). In fact most CMS can perform several functions, although there is one feature that must be available in order for the CMS to work as a community type: frontend content editing and upload. Here, people can login via the frontend (as against the backend, which is the standard method and just for admins), and either input material or edit it online.
Often a CMS will function well in two or more classes, perhaps depending on what extensions (plugins) are available. It is possible to produce two or more versions from one basic CMS core, each being particularly suitable for one type of function.
A community / portal type CMS will function satisfactorily as a provider-consumer type with no modifications. The latter type is simpler because it requires fewer features, especially in the area of ACL. This refers to access control levels, or if you like, user rights - group or individual privileges such as editing, publishing and so on. This feature set is the most complex to provide, and to get right. An enterprise-level CMS must have a core feature set of elevated capability, including full ACL (group roles), versioning, workflows, and audit trails. There should be portal (intranet), VPN / WAN (extranet) and load-balancing capability. It is therefore the most complex.
Factors affecting how a CMS works
The vast majority of CMS work the same way, but there are a small number of factors affecting this. A few CMS can work additionally as a client-side application, and one or two only work this way. That means the application resides on the local machine (the PC) and the pages are generated there, then uploaded to the server. Thereafter, the CMS works in the same way as a normal flat HTML site - meaning that there is no scripted interaction between user and website.Different types of DB affect how some CMS operate (SQL or flat-file), though this is transparent to end-users. A CMS normally functions as a managed content publisher, rather than a library of pages; and so it needs to be seen in a different light to flat HTML websites. It is best used as an interactive repository of information, whether that be at the first level, simply between owner and application; or at the second level, between visitors and the application.
The capability of individual CMS decides how many jobs they can do, how well, and in how many different ways. As new plugins are developed, new functions become available. From just being a convenient way of editing text, they now act in some cases as fully-interactive central community facilitators.
CMS costs
All content management system ownership implies costs of some form, even for open-source solutions. Here is a brief explanation of payments and running costs.Open-source CMS costsWith 'free' applications (nothing is really free in the end) the costs vary with a DIY or commercial implementation. In DIY mode costs can obviously be minimised, though it is necessary to weigh up the implications of a go-it-alone approach. In 9 out of 10 cases the end result is not going to be as good, and of course the time input will be extensive.
Although in theory a DIY'ers time might not be costed in, since however it will be so extensive, and possibly three times as long as that of a pro who is doing the job every day, it needs to be itemised. As documentation, training and support will not be present, this should also be considered. Supporting a CMS might be the biggest time component of all, and the implications of this need considering - every CMS needs a webmaster, as they solve the problems. All complex websites have problems that need resolving.
Open-source CMS, DIY install and support costs:
- hosting
- templates
- plugins
- time - and a lot of it
- hosting
- implementation
- support, including webmastering, training and documentation
- software licence
- hosting
- implementation
- support, including webmastering, training and documentation
Payment models
For both main choices, payment is usually in two parts - on install, and for support. For commercial implementation and support of an open-source CMS, a fee will be payable on install and then subsequently per year. These fees may be broken up into stage payments of one kind or another. For example there may be a deposit, then a balance payable on install. Then support costs may commence at three months in, and be paid quarterly or annually. A WCMS needs a webmaster and the client cannot do this - it is not a fit and forget solution like a fridge or TV. Upgrades, patches, and new feature requirements need to be factored in. Some running costs are involved, as might be expected for a commercial truck for example.
With commercial CMS the software license is also involved. This varies from a few dollars up to $100k or so for the big names like Broadvision. Many factors affect this cost, such as how many sites, intranet / extranet working, load balancing implications and so on. For single-site one-off installs, the license cost will be a fair proportion of the end cost, unless the software cost is very low. As the scale increases, the license fee becomes less of the end cost, as implementation costs will dwarf it (a Java CMS developer can cost £850 / $1,400 a day).
There is also another option, called Hosted CMS. This is where you simply pay a monthly or quarterly fee, with a minimal set-up cost. This is an attractive option for some buyers.
We should also mention the high start-up hosted type. This is essentially a standard commercial CMS install but you cannot choose the hosting, it is always on the developer's servers. This is probably a more common arrangement than might be thought. There are pros and cons to this, like all options - security is going to be good, but you may find there are severe limitations in other areas (with the type of web analytics you want to install, for example). This would be a deal-breaker for some.
Servlets
Some CMS cannot run independently and need middleware: an additional application as a buffer between the CMS and the server app. Such an application is called a servlet, servlet container, or an application server, examples being Apache Tomcat and Zope.
CMS using these are much more restricted in the type of servers and hosts they can be used on, and in many cases require a dedicated server; support is also likely to be more restricted and expensive. For this reason they are best avoided unless your enterprise has specific needs that can only be addressed by using one of these applications. The use of servlets is extensive in the world of Java-based commercial CMS solutions.
Here is a list of application servers:
Apache Tomcat
JRun
WebSphere
Oracle BEA WebLogic
Sun-ONE
Zope (can run standalone or as middleware for another app)
CMS using these are much more restricted in the type of servers and hosts they can be used on, and in many cases require a dedicated server; support is also likely to be more restricted and expensive. For this reason they are best avoided unless your enterprise has specific needs that can only be addressed by using one of these applications. The use of servlets is extensive in the world of Java-based commercial CMS solutions.
Here is a list of application servers:
Apache Tomcat
JRun
WebSphere
Oracle BEA WebLogic
Sun-ONE
Zope (can run standalone or as middleware for another app)
Tidak ada komentar:
Posting Komentar