So what is a CMS web site?

CMS or a 'Content Management System' quite literally allows you to control and manage the content within your web site - without technical training. Using this uncomplicated system you can very easily add, delete images and edit text in your web site on the fly. You can also have an unlimited number of pages and a full site-search engine. What's more... with E WebCraft - Web Design' you can have a highly professional CMS web site at a very reasonable price indeed!

We give you the tools to easily manage your online business! Total start design plan with Affordable CMS Web Design Package, is just right for those who want to start off right and add more elements as they grow.

A CMS or Content Management System help manage websites with ease and flexibility. Large websites and web portals use customized content management systems to manage large amounts of content and data through one user friendly admin module. Our expert web designers and developers have years of experience of developing custom managed websites, CMS design, CMS development and have been providing offshore CMS design and development services to clients based in Canada, USA, Europe and worldwide. We provide customization and integration of open source content management systems like PHP Driven CMS / Magento / Joomla and systems.

E webcraft CMS design and development services

Getting a new CMS designed and developed can be a costly procedure, and more so if you are using in-house resources. E webcraft CMS design and development services can save a lot of time, energy and cost for the development or integration of any content management system. E webcraft provides it’s own PHP driven content management system design services to clients and companies based in the USA and Canada.

We believe that websites are living entities that need to maintain their value and purpose for a company or organization's site visitors. We also believe that clients are best able to run and maintain their own websites, without needing to come to their web development firm time and again to update site content. That is why we have been building content management systems that allow clients to run their own websites, with administrative workflows that are tailored to the client's administrative needs.

Custom Content Management Systems

Our own Small and user friendly custom content management systems can also be used for medium and large websites, if the website requirements are clearly defined. We are also specialized in the design and development of custom content management systems which enable website owners to easily update their websites from a very user friendly admin panel.

How CMS works

What is the meaning of CMS is a frequent question, so here is a CMS definition:

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 by the software from a database. 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 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. In practical terms it means that design issues are resolved easier and quicker.

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.

How To Use CMS - a guide to publishing content and other basic tasks CMS terminology - the CMS dictionary - a guide to CMS definitions

Here are the main points of a CMS:

• 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 can 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 features 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 - ie what is on the page does not affect its layout.
• Rich media capability can be better than that for standard websites.

There are a very wide range of CMS available now - probably over 2,000 - so the choice is vast. The most economical and easily-supported website content management systems accord with these basic principles:

• The CMS has a name, and is recognised as a website solution.
• 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.

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, graphics or any other subsidiary files needed, and 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 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.

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.

The next division is between the various classes of function, for example:

• The micro CMS class
• The lightweight class
• The rich media type
• The online brochure type
• The community / news model
• The provider-consumer model
• The enterprise-level publishing class
• The ecommerce-enabled type

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 are provided. 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 lists, 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. 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.

Servlets

Some CMS cannot run independently and need 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. However, the use of servlets is extensive in the world of Java-based commercial CMS solutions.

There is a list of application servers:

• Apache Tomcat
• JRun
• WebSphere
• BEA WebLogic
• Sun-ONE
• Zope (can run standalone or as middleware for another app)