Using A Content Management System For Your Web Site
What is a Content Management System?
A Content Management System (also known simply as a "CMS") is a package of php
scripts which are designed to work together to allow you to maintain a
community-based web site. With this system, you can have people log in and
submit content (great for programmers or community projects), organize your web
site easily into sections, add or remove areas when you want, add content
without creating a new page (it does this automatically), and display the
content on a news board-type system or even as regular web pages. With special
add-in scripts (sometimes called Add-Ins, Plug-Ins, or
Modules ), you can extend the function of the site. Some of these include
quizzes, polls, donation and even shopping cart systems. CMS sites are used for
news boards, online stores, blogs, open source programming projects, and special
communities.
Is a CMS right for your site?
Going from a plain static HTML-based web site to a dynamic
CMS-based site takes some consideration. If you are a total beginner to the
internet, web sites and maybe the computer in general, then a CMS is not
for you. You'll need to start with a
normal web page design and learn from
there. However, if you are good at HTML, PHP and Perl, and are familiar with
MySQL (three things you must know to get started with CMS sites), and
have a site or an idea for a site that will either allow people to register and
contribute and/or interact with your content or you have a good many pages and
topics to cover (or both), then a CMS will make your site far easier to
maintain. CMS sites are also good for those who want to expand and maybe add
areas to the site, or may decide to change or delete other areas. Instead of
going through all your code to remove menu items, going to your FTP server and
deleting pages and directories, you can log in as an administrator to your CMS
site and easily do this through your web browser. Some CMS systems even let you
delete multiple areas or pages all at once. You can make changes just as easily.
What You'll Need
To use a CMS-based system, you'll need to
request a CGI account to run the scripts in the
package. In addition, most CMS-based systems also require that
you obtain a MySQL Database. Note that you'll
need to start your CGI account first and have it active before you can
request your MySQL Database.
In addition, you also may want to have your own Apache (Linux) or IIS
(Windows) server and MySQL server along with phpMyAdmin installed to work on the
files and design before you upload things to your CGI server. See
Designing The Site Before Publishing below for reasons why this can be
beneficial.
Planning Your Site
Before you even get started, you'll want to plan out your site so that you can
best choose a CMS for your site, and know ahead of time what you'll want to put
in it. Even if you're converting an existing HTML web site to a CMS system,
you'll still may want to plan for more areas, or possibly more interaction with
your visitors. If you are designing a new site, you might find our
web site tutorials
helpful, including
Web Site Creation and Design.
In a text editor, create a notes.txt file. In this file you'll want to have the
following for each area (Sometimes called Sections) and also list any
sub-areas (sometimes called Categories) under these areas, and the same
information for those. The reason you'll want this in a text file is because
it'll make it easier to just cut and paste these into the CMS category or area
description fields.
Description of the content (this also may be used for Search Engine
Optimization).
What Category or Section the page is linked to.
If it's a Category, what Section it's linked to (or list it under a section
title), and menu item name (if any) which will appear under the section.
If it's a Section, what menu item it's linked to.
If intending to have registered users, determine which areas they have access
to and which areas they can add content to.
Any external RSS feeds you intend to add to your site.
List and descriptions of Categories for your News Section
Where your advertising will be placed (i.e.. banner ads, side banners, text
ads, etc.)
Any special features you plan to have, such as polls, rating system, User
profiles, downloads (please see Registered Users and File Uploads and
Handling Media and Archive Files before deciding on non-web related
content), shopping carts or catalogs, etc. Make a page for each one of these
sections, and list categories for each if needed.
Keywords for each page. Some CMS systems allow you to add these to each page
for Search Engine Optimization. Keywords should be a short list separated by
commas, and words which are relevant to the content on that particular page.
Choosing The Right CMS
After you have your web site planned out, you can now go ahead and look for a
CMS which will closely fit your needs. We have a few
CMS Tutorials
that can help you determine which one to use, and step-by-step instructions on
how to install it.
If you are putting together just a news type system with maybe a few registered
users, or a knowledge base or story database, sometimes a Blog system may
suffice. These also have become powerful enough to act as Content Management
Systems. We have a few
Blog Tutorials
where you can learn more about the different ones available and how to install
them.
Finally, keep in mind your skill level. Some CMS packages may be harder to learn
how to use than others, and some may require you to know HTML, PHP, Perl and
MySQL in order to edit the files to suit your site's design needs. Others
include an easy web-based interface that do most of the work for you.
If you are not willing or able to create your own template or site look, you may
want to use pre-made templates. This is another consideration you can make
before actually downloading and installing a CMS. Take a look at a few
templates available for the CMS you're considering and decide if any of them
would suit your needs. This may help you decide what CMS to use.
Designing The Template
You can also design your own template. One easy way is to take one of the
default templates that come with the CMS package, copy the directory to a new
one (so you preserve the original template) and work on the copy. Edit the
different images to suit your needs using an image editing program such as
Gimp,
Paint Shop Pro,
PhotoShop, or
Ulead PhotoImpact.
In these programs, you can change the colors or images in the template.
Always keep the image sizes the same as the original, however, so that
everything still fits in place.
Once you have the images done, work on the CSS Stylesheet files (usually these
files have the extension of .css) and change the colors to match the new colors
of your images.
Lastly, you may want to edit some of the .php files in the template to display
things the way you'd like.
Even if you're designing a template of your own from scratch, looking at the
pre-existing template files in the CMS system will help you learn how one is put
together. Different CMS systems use different template and/or style formats, so
they are not usually interchangeable.
Another thing to keep in mind when designing your template is to not use
Shockwave and/or Flash animation anywhere in your templates. You are not
allowed to put these and other types of media files on the CGI server. See
Handling Media and Archive Files for more information and some ideas on
how you can get around this, if you still need to.
Designing And Testing
You may want to design and test your site on your web server on your own
computer and not our servers before you upload and publish the site. Our servers
distribute bandwidth between all domains so
that no one domain will take away too much bandwidth from the others. As a
result, too many repeated hits to your site (which can especially occur when you
are reloading the pages too frequently to check the progress of your changes to
your site) can slow your site down to nearly unusable. This normally will not be
an issue after the site is online and live, and under normal use. But in
development, the frequent refreshing to check the effect of changes to your site
can be far more numerous. By using a separate server on your local machine, you
can reload as often as you like (depending on server settings) and not worry
about this.
If you still want to do it on online or don't know how to set up the needed
servers, just be sure to plan your site carefully and not reload or recheck your
pages too frequently. Sometimes just going from one administration page to
another during setup of your CMS can slow your Active Web Hosting server down a
bit. Resolve to to the development in small chunks, taking a break for about 30
minutes before working on the next section of your site.
Whether you are on our servers or your own, you'll need to be mindful of file
and directory permissions. As you work with your site and notice something won't
write or open, write down the directory and/or file(s) that were affected, so
that when you upload them to your CGI server online, you can set those same
permissions there as you did on your own server.
One common permission that is not often set at default is the write
permission. This is done for security reasons. You should only allow write
permissions to those files and directories that need it set in order for the CMS
to function. How you do this depends on the server you are using. In Apache, it
can be as simple as setting the CHMOD to 777 or 666 depending on whether you
also need the file executable (directories that need to be written to would need
to be set to 777 since the executable bit needs to be set in all so that
the directory can be entered/accessed). Perl scripts (.cgi and .pl) need to also
have the executable bit set. PHP scripts don't need an executable bit to be set,
normally. However some may need this. See the installation instructions for your
CMS to be sure. Also be sure you place the directory in your Apache Server's CGI
directory.
If you are using IIS on Windows, you'll need to go through a different method to
set write permissions. Here are steps you can use for setting up your test
directory:
First put the test directory into your IIS server root directory so it can find
it. This is where you'll be editing the files too.
In your Internet Information Services utility program (this manages the IIS
server and comes with Windows XP Pro), expand the following in order: Internet
Information Services, [Your machine name], Web Sites, Default Web Site.
Right click on Default Web Site and select Properties.
In the Server Extensions tab, click on the Don't Inherit Security
Settings box and then the box next to Manage permissions manually.
Click OK to exit this dialog.
Now right click on the test site's directory or file you need write permissions
for. Select All Tasks and then click on Permissions Wizard. Follow
the screens, selecting Inherit all security settings (even though we
checked not to before). Then you'll see the next screen will show that your
files should be executable, readable, and writable. Click on Replace all
directory and file permissions (recommended) and finish the wizard.
Right click on the same directory or file, and this time choose
Properties.
Under Local Path in the Directory tab, you can further set up the
permissions, such as Executable Permissions if you don't want the file
executable (leave at Scripts Only) if it's a directory.
In the Documents tab, be sure that Enable Default Document is
checked.
In the Directory Security tab, click Edit. You may want
Integrated Windows Authentication and Allow IIS to control
password as well as Anonymous Access checked if you are on your
own private server behind a firewall and know that your site can not be
accessed via the internet. However, if you have it set up so that others can
access your site via internet, you'll want to set this page up differently, so
that you can provide a password to access each page, etc. Please refer to the
IIS instructions for more information on how to set up a secure directory on a
public server. Though it's recommended you test your scripts on a private server
that is not accessible to others on the internet.
After you have set this up, click on the Default Web Site entry and then
the black Stop (square) button and next the black Start (arrow pointing right)
button in the top tool bar. This stops and restarts the server, allowing the new
changes to take effect.
Finally, since most CMS packages need MySQL to work (again, check the CMS
instructions), you'll want to set up a database in your MySQL server. To make
the transfer from your server to your Active Web Hosting database smooth, you
may want to make a database called, for example, yourdomaincom, meaning
your actual domain name without the dot. Set up a new user for that database and
give it the same username and password you use for your Active Web Hosting
database. Do this only if you're using a private server that is not
accessible to the internet. If you are on a server that is accessible to the
public, you'll want to ensure that this is secure, and may want to use a
different database, username and password. Just keep in mind you'll need to
change these maybe even in the database itself when you convert the files to
your Active Web Hosting database.
Now just point your browser to the URL of your CMS (for example, maybe
http://localhost/mambo/installation/index.php or whatever your CMS's
installation path is on your server). Now you can design your site in real
time and refresh the browser pages to see your changes in effect as often as
you like without any potential server slowdown.
Registered Users and File Uploads
During the design and setup phase of your site, you'll need to consider the
permissions your visitors will have. For example, think about what areas you
don't want the general public to see. You can set up so that a visitor has to
register with a username, password and email address in order to see those areas
of the site.
Probably the most commonly used feature of most CMS based sites is the ability
to allow visitors to interact and even add content to your web site. You
need to be careful of a few point here though. First, never allow
unregistered visitors to contribute content to your site. You are held
responsible for all content that is on your entire domain, whether or not
you put it there yourself. If someone uploaded illegal content, you could
be liable for it and may even have your domain temporarily taken offline until
you remove the offending content. This is why CMS systems let you have
registered users for your site. At least then you can approve the content
before it is made available to the public (i.e.. published) and
that you know who had submitted the content.
Even if the user is registered, there are still some restrictions you have to
consider due to the way Active Web Hosting's CGI servers work. For example,
there are certain
file types allowed on the CGI server, and
other files that are not allowed. Please see
Handling Media and Archive Files below for more information.
In addition, your visitors are
not allowed to upload files to your CGI server.
Basically all your registered users may do is submit only text-based content and
links to other content. However, if planned carefully, you can provide
reasonable work-arounds.
Handling Media and Archive Files
If you need to provide media other than text-based or non-media image files
(i.e.. files that do not have the .gif, .jpg, .bmp or .png file extension), or
you need your visitors to provide content other than plain text-based content
(i.e.. media or even image files) you can still do this safely if you consider
the following tips:
Set your CMS so that all submissions your visitors add to your site are
approved by an administrator (this would be you, the owner of the site) before
being seen by the public.
Let your visitors know on a Submit Content page that all items are to be
approved before going public, and that they are to provide links to
images, media, archive and any other files. This means they must host them on
another server of their own choice. If you decide you would like to publish the
article, you can always download the extra links to your computer and upload
them and link to them on your own server. Keep in mind that media files have to
be placed on your web server and not your CGI server where your
CMS is placed. This is because only text and non-media files are allowed on the
CGI server. However, to help keep your site from slowing down due to large files
being displayed or downloaded too often, you may wish to just keep the links to
the off-site content in the article and publish it as-is. Either way, at least
you will need to review the article and edit it appropriately if necessary
before publishing visitor's submitted content.
Transferring Your CMS To Your Active Web Hosting CGI Server
Once you have your site all designed, tested and ready to go, you'll need to
change a couple files and back up your database. First, find any configuration
files that may need to be changes. Typically, you'll need to change all
instances of http://localhost... etc. to your http://cgi.yourdomain.com/...
(where yourdomain.com is your actual domain name). If you used a
different database, username and password, you'll need to edit those too. Always
first copy the old configuration files and save the old copies just in case.
Next, using phpMyAdmin,
back up your entire MySQL database tables that
are used for your CMS. This is why it's a good idea to just use a separate
database for the CMS in the first place. Then you just back up the whole
database. If you used a different database name, username, and password that you
use for your normal web site, you'll have to edit the .sql file to change
instances of those, if some CMS systems store this information in the database
too. However, most usually just get the information from an external
configuration .php file and not place it in the database.
Now upload all your CMS files and folders to your CGI server exactly as they are
on your hard drive. Be sure to go and change file and directory permissions on
our CGI server to what you had them set to when testing on your own server.
Next, log into phpMyAdmin
with your database username and password,
and import your database .sql file you
saved from your own personal database on your computer. This will import all
your settings.
Testing Your Site
Now point your browser to your CMS directory online and check it out. From there
you can try and fix any other bugs and inconsistencies or correct any errors by
testing all features and pages, registering as a test user (you can delete this
user by logging in as administrator later) and testing tings as a normal user.
If you run into problems, you'll need to consult the CMS, and MySQL
documentation and the script files that come with your CMS. It is beyond the
scope of this tutorial to mention or provide answers for errors that may crop up
as some may be complicated. As mentioned at the start of this tutorial, it is
best you have some prior experience and knowledge using CGI, MySQL, PHP, etc. so
you can fix the problems yourself. Also, there are many online forums which you
can ask questions of other users and get help with just about any problem you
may have.
One useful technique is to use a search engine such as
Google or
Yahoo! and put in quotation marks in the search
box the exact error message (or at least the first few words) to see if there's
more information on this on the internet somewhere. Chances are, others may have
come across the same problem and have even found a work-around or solution. Also
check the web site you downloaded the CMS from to see if they also have some
sort of support forum that you can ask questions in. Generally, it's best to
avoid emailing the author(s) of the CMS unless you are reporting a genuine,
repeatable bug in the program.
Going Live With Your New Site
Now that you have your site online and working properly, it's time to go live.
You can make the site available to your visitors depending on two criteria:
Connecting Your Domain To Your CMS
You can have your domain point to your CMS if you uploaded all your files and
directories to your root directory on your CGI server and not in a sub
directory. This means that the index.php file for your CMS would reside
naturally in the root directory of your CGI server. You can then
request that your domain point to your CGI server.
This way, when visitors type in http://yourdomain.com/ or
http://www.yourdomain.com/ in their web browser, they will be taken directly to
your CMS site.
Redirecting Visitors Immediately To Your CMS
Alternatively, you can redirect visitors to your CMS
from your web server using Meta Refresh Tags. This means that
when they go to your domain name, they load first an index.html file on your
web server that contains the meta refresh tag, and that will then
automatically take them to your CMS site on your CGI server and load that page.
This is a two-step process and some search engines won't follow this page.
However, search engines can still spider your CMS site content and so it will
still show up in search engines. Except the URL will then read something like
http://cgi.yourdomain.com/ instead of http://www.yourdomain.com/
or http://yourdomain.com/ due to the fact the search engines will be
using the URL that the CMS site is actually on. The way to avoid this to request
that your domain point to your CGI server as stated above.
However, if you are going to be displaying or providing for download
media content such as executable programs or binary files, movies or media such
as AVI, WMV, MOV, Shockwave, Flash, etc. or Audio files such as MP3, WAV, OGG,
etc., you can not set your domain to your CMS site because you'll still
need to host the content not allowed on the CGI server on your web server and
use your domain name to link to it in your CMS site documents. This is why the
Redirection method may be needed instead. As mentioned, your site will still
show up on search engines and visitors bookmarking the CGI address should do no
harm, as it will then just bypass your web server's index.html page and go
directly to the CMS site itself. Having cgi. in your URL shouldn't hurt your
search engine ranking opportunities too much.
In Summary
While setting up your site or transferring your existing site to a CMS site can
take a lot of work, the benefits are well worth it. Your visitors will now be
able to see much more content than you could maintain on a basic HTML site, and
even interact, participate and provide content for your site. In addition, the
process of maintaining your site's growing content will be far easier because
the CMS will take care of registrations, and creating new pages for you without
you having to hand-code every page and upload them separately. In addition, you
password-protect content much more easily than you could with a plain HTML site.
You can also easily provide more interactive features for your visitors. If
you're planning to have (or already have) a site that seems to grow at a faster
rate than you can code and upload pages, then a CMS is the perfect solution. You
can also add more areas, interests, or remove areas that are not of much
interest or use any longer. Content Management Systems are becoming quite
popular on the web for the very reason they provide quality interaction for
visitors and easy maintenance for webmasters.
|
