This article is also available as a TechRepublic download.
I wrote about how to install and setup one of the most powerful open source Web
tools, XOOPS. Of course the basic installation and setup will be of little good
to those wanting to run powerful content management systems for a company. With
that in mind it only makes sense to show how to take XOOPS and turn it into
that powerful CMS. And that is exactly what we are going to do.
So from installing necessary modules, to configuring those
modules, to using those modules, after this article, XOOPS will be purring
along nicely as your new content management system.
Modules, modules everywhere
What we want to do is pick and choose the modules that will
create a very versatile CMS. So we won’t assume any particular usage for the
CMS. What we will want to have are:
management tools (such as CVS)
My first thought was that I was going to have to collect
together an entire group of modules to piece together everything necessary to
mold XOOPS into a well-rounded CMS. But the more I research the more I realize
that modularizing a CMS could easily lead to a disconnected process. That of
course may install a bit of a hurdle in creating a CMS with our tool. But it’s
not impossible. Knowing this I will start from the bottom up and highlight the
module/(s) that will serve as the foundation for the CMS.
The one module I have found most useful for creating a CMS
is the AMS (Article Management System) module.
At first it seems this module might be everything needed to create a
solid CMS. But there are a few necessary tools missing. More on that later. The
over-riding issue with this module is, even though it serves as an outstanding
core for the CMS, it’s far from intuitive. Because of this, a good portion of
this article will be dedicated to the explanation of this module.
The first thing to do is to download the module. You can get
the module from the XOOPS
module repository. Once you have the module downloaded, move it to the
XOOPS module directory (on my installation it is /var/www/html/xoops/modules)
and unpack the file. Once the file is unpacked, log onto your XOOPS site as
administrator and go to the Administration menu, click on the System Admin
button, click on the Modules link, and then click on the Install icon for the
installed click on the System Admin button and then click on the AMS button to
launch the module.
first thing to take care of (as always) are the Preferences. Above the various
tabs at the top of the module is a link for the Preferences. Click on that. On
the preferences pages there are a number of items to configure. Many of these
will depend upon the needs your company places on its CMS. Once you have your
preferences configured, it’s time to move on to the real work.
The first tab you want to visit is the Topics Manager tab.
The topic manager in AMS is where everything begins. Before any document can be
managed at least one topic must be created. This topic serves as a sort of
trail-head for all articles.
Near the top of the Topics Management section you are given
a list of existing topics. Each topic includes its topic ID, name, parent topic
(if any), and the edit or delete option. Below this is in the “Add a topic”
area is where you add new topics.
Each new topic requires the following entries:
- Topic Name: Topic name is simply
the descriptive name for your topic. This name must be forty characters or
- Parent Topic: If you have existing
topics already created, and you wish to create a new topic as a child,
then select the topic you want you new topic to be listed under here.
- Topic Image: Here you can select
an image to accompany your topic. You can either select from the existing
images, or upload your own. Should you chose to upload your own you must
make sure the server has write permissions to the /modules/AMS/images/topics
directory in XOOPS root directory.
- Linked Forum: If you are using
NewBB 2 modules then you are able to use specify which NewBB 2 forum that
will link to your topic. With this configured, all articles published
under this topic will then have a discuss button displayed at the bottom
which will link to the specified forum. NOTE: This feature ONLY works with
- Banner: If you are using a banner
ad manager, place your banner code here to have it displayed at the top
screen when viewing that topic. This is not required.
- Inherit from parent: This option
ONLY applies to sub topics. If you have set a topic to use a certain
banner, and you wish all sub topics to display the same banner, then you
will need to make sure this check box is ticked in ALL sub topics. This
check box also works as an override. So even if you have configured your
sub topic to display a specific banner, it will not be displayed if this
check box is checked.
For our example we will create a Linux: CMS topic. We’ll title
it as such in the Topic Name text area. The Topic Image is not necessarily
critical but can, for obvious reasons, make life much easier for those working
within the system. I’m going to assume the NewBB 2 module is not installed so
the Linked From option will not be used. There will be no banner code nor
Inherit From Parent configurations.
Click Modify to save the new topic.
Before anyone moves on to submitting/managing articles you
want to first work within the Submit/Approve Permissions tab. Click on that tab
and notice the topic you just created. What you want to do is give various
users permission to work within these topics. Without giving those users
permissions, no one will be able to do any work. So now you have to decide who
actually gets to submit, approve, and view topics.
Because this is a CMS, you do not want to give anonymous
users permissions to do anything within the system. By allowing anonymous users
to make changes to articles, it will be impossible to track any of these
changes. Anonymous users could be allowed to view, but it makes no sense to
allow them to edit or approve.
Once you have made a change to each section, click submit.
You will have to go through this for each permission section. You can’t make
all changes and click the final submit button. This will not work.
Now that you’ve added a new topic and made the necessary
permission changes, it’s time to move on to submitting articles. Oddly enough
the submission of articles is not started within the module. To do this go to
the home page of your XOOPS site where you’ll notice an entry for Articles in the left side
navigation. Once you click on that entry two sub-menus will appear: Archive and
Submit Article. Click on the Submit Article menu and you’ll find the main work
area for articles.
This work space looks very much like a standard Web form. It’s
quite self explanatory. Here you can title, format, select an audience, write,
attach files, and select options. One thing to note is that when first creating
an article you will want to uncheck the Publish option. If you do not uncheck
the publish option the article will publish as soon as you click Post. There is
a caveat to this. If, during the Permissions configuration, you only give
Webmasters approval permissions, the registered users will not have this
option. It would be smart to take advantage of this so that only a select group
can finalize an article for publication.
What would a CMS be without the ability to manage articles?
Nothing much. From the Managing Articles tab you can add, edit, and delete
articles. But remember, this is a CMS, so just because you are adding an
article doesn’t mean the article in question is published. The very nature of a
CMS is such that various people can work on an article before the article is
published (or the software is released, etc). So right now we are working at
the article creation phase of the process.
Another very powerful tool within the Manage Articles tab is
the search feature. From my experience, a company’s article archive (including
the pre-publish stage) can get rather large. So the ability to filter a search
is invaluable for a proper CMS. From here articles can be filtered by Title,
Topic, Author, and Status and can be filtered in ascending or descending order
or by story ID, title, published, hits, or rating.
The rest of the features of this module are all bells and
whistles (albeit very nice bells and whistles.) Getting to know these features
will simply finish off the job selling you on AMS as a CMS foundation. But,
there are other topics to touch on before we wrap this CMS up.
Of the media companies I have worked for, the ones that
produced in-house dictionaries for editorial staff to refer to always seem to
be the ones that function far more seamlessly. Fortunately there is just the
module for XOOPS to cover this need.
module allows registered users to add, search, print, email, and comment on
definitions. The installation of this
module is done exactly as the AMS module. To configure the module, once
installed, go to the Administration menu and then select the Dictionary button
from the left navigation. From here you can either add a definition or
configure the module.
Obviously you will want to configure the module before
adding definitions. The two most critical configurations will be to disable
anonymous submission of entries and the Comment Rules. The comment rules applies
to comments that can be attached to definitions. Unless there is a need for
users to comment on definitions, I would disable this feature. One other
configuration will define if clicked definitions will appear in a the current
window (either browser or tab) or in a pop-up window. Since many users
configure their browsers to not allow pop-up windows it is probably smart to
have the clicked definitions open in the current window.
The next step with this module is populating it with
entries. Once the entries are available they can be found from the left
navigation under the Dictionary entry.
Although this module was not designed for the specific task
of CMS, it can be creatively used as such. I have found this module to be a
handy way of helping staff keep track of “tickets”, the “tickets”
importance, responsible users for the “ticket”, and the status of
each “ticket”. Of course by “ticket” I would be referring
to a specific article (or code fragment for example) within the CMS tracking.
Get this module
from the XOOPS module repository and install it in the same manner the previous
modules were installed. This module is quite a piece of work and would be
fairly straight forward as used in the way it was intended. But as for using
this in a CMS environment it could use a bit of “howto”.
As with all XOOPS modules, it is configured from the
Administration menu from the left navigation. From there click on the xHelp
button (again on the left side) and select Preferences. Most of the preferences
are self explanatory. There are a couple to pay attention to. The first is
Ticket Overdue Time. This is a handy feature that allows you to configure how
long staff has to deal with a ticket before it is late. This configuration is
done in hours.
The other configuration to look into is department
visibility to staff members. This configuration sets if various staff are
limited to who they can submit to. If you check Yes on this configuration,
staff members will be limited to submitting tickets only to departments where
the XOOPS group they belong to is selected.
In the xHelp module you have to set up departments. For my
CMS I created the following departments: editorial, graphics, and developers.
Once departments are created, staff are then added to the department (all of
this done as the administrator through the xHelp module). So user puddinhead
is a member of the editorial department and user stephali is
a member of the graphics department.
If the visibility option is checked, when puddinhead
submits a ticket only members of the editorial department would be able
to see that ticket. And when stephali submits a ticket only members of
the graphics department would see that ticket. If the visibility option
is not checked both puddinhead and stephali could see each others
the xHelp module, users log tickets. For use in a CMS environment the logging
of tickets would occur when either an article is needed for development or created.
Let’s create a ticket for an article on XOOPS that is needed. The user – we’ll
say it’s an administrator – logs in and goes to the xHelp module. From within
the module click Log Ticket and fill out the necessary information. At this
point files could be added. The ticket would be assigned to editorial, given
the necessary priority, and then logged.
the ticket is logged anyone in the editorial group would be able to view the
ticket. They would also be notified via email to identify the needed job.
tickets are created, a number of actions can be taken on a ticket, from the
Summary link at the top of the xHelp module.
The actions available will depend upon the user-level. Say a member of
editorial logs on, checks out the various tickets, and sees an article they are
perfectly suited to cover. That member of the editorial staff would click the
check box next to the article and then, from the drop-down list near the
bottom, select respond, and click Go.
a response is logged that response will be visible within the tickets summary.
tip that will help out quite a bit is if you enable a staff of users that have
all roles assigned to them in the Manage Staff tab. By doing this you ensure
that not just one person (administrator) will be able to handle the task of
assigning users to tickets and so on.
xHelp module is very powerful and could easily take up an entire article all on
its own. Suffice it to say that it’s only limited to your creativity as to how
you employ this flexible module in your CMS.
CMS is a huge undertaking. I’ve seen many companies spend thousands upon
thousands of dollars and man-hours working with what ultimately fails them. Don’t
let this happen to you. Instead bring into your company a versatile system that
is modular, stable, and free (as in beer of course). XOOPS is the perfect tool
for you to develop a CMS that will suit your needs.