At the Forge - XOOPS

Create a community site with an article queue, comments, user blogs and more.

Over the last few months, we've been looking at content management
software (CMS) that makes it easy to create Weblogs, personal journals
that continue to grow in popularity and influence. There are no
hard-and-fast rules as to what constitutes a Weblog (or blog), but
most people probably would agree that the contents typically are short
articles, with the newest ones displayed first.

But there is a larger, slightly different, class of Weblogs out there
as well, which probably can be called Slashdot-style, for lack of a
better term. These Weblogs are edited by a small group of people but
have a large number of contributors. In many ways, these are closer
to on-line forums or bulletin boards than to Weblogs. However, such
software also provides Weblog capabilities for its individual members.
That is, a visitor to the site can read the main discussion,
create his or her own Weblog and read through other users'
Weblogs as well.

Although some packages—most notably Slash, which powers
Slashdot, use.perl.org and some other high-profile sites—were
designed around the idea of public and private Weblogs, other packages
have grown to incorporate this idea. One such package is XOOPS, which
supposedly stands for Extended Object Oriented Portal System. XOOPS is an
outgrowth of the PHPNuke and PostNuke family of portal servers.

This month, we look at XOOPS, paying particular attention at
WeBLog (pronounced Wee-Bee-Log), a module designed to facilitate the
creation and administration of public and private Weblogs. I
have reservations about XOOPS, but it can be an excellent tool for a
certain type of audience. In particular, the ease with which it
can be installed and administered, and with which each user can be
granted his or her own Weblog, is hard to beat.

History

XOOPS testifies to the power of the GNU General Public License, to the
Open Source community and to the fact that not all forks or
splits in an open-source project are bad. The XOOPS story begins
with PHPNuke, a suite of programs written in PHP and using MySQL for
its database back end. PHPNuke apparently
was built on top of ThatWare, a now-abandoned Slash clone written in
PHP.

What happened next is controversial, to say the least, and
demonstrates what can happen when an open-source project gets ugly: a
large number of PHPNuke contributors decided to fork the project and
named their version PostNuke.
Today, PHPNuke and PostNuke both exist, and little love is lost
between the user and development communities. From what I can tell,
and without examining the code in any depth, PHPNuke mainly
continues to be developed by Francisco Burzi, with the main criticisms having to
do with his management style, the hobbyist orientation of PHPNuke
modules and issues having to do with security. Although PostNuke is
quite popular and seems to have the edge on security,
administration, commercial-oriented modules and
database-independence, maintainers are accused of changing APIs too
frequently and of designing PostNuke to be too resource-intensive.
Meanwhile, some of the central PostNuke developers have left that
project, forking it into software that originally was known as
LostNuke and now goes by the name of Xaraya.

Finally, XOOPS seems (from what I can tell) to be an object-oriented
rewrite of PHPNuke. The XOOPS maintainers believe that by rewriting
the system to use objects, it is more secure and easier to
develop and maintain.

The good news is that all of these systems are available under the GNU
General Public License.
That said,
forks generally are seen as a last resort in the Open Source
community—and the fact that so many have happened on this software probably
testifies to the lack of strong management and leadership of these
projects. Reviewing the history of these projects renewed my
admiration for people like Linus Torvalds, Larry Wall and Guido von
Rossum, all of whom have managed to keep their communities together,
despite differences of opinion among the core developers.

XOOPS seems to have a smaller community than either PHPNuke or
PostNuke. However, the number of built-in and third-party modules is
quite large, and its object-oriented facilities mean it is fairly
easy to build your own module. Indeed, although the number of
modules has remained fairly modest, I was impressed by how easy it was
to install. Does this mean you should use XOOPS over another one
of the Nuke-alikes? That seems to depend as much on politics and your
planned use as on the technology itself, although the fact that XOOPS uses objects
does give it an edge, at least in theory, from my experience.

Downloading and Installing

Now that we have reviewed the historical evolution of XOOPS and
related pieces of software, let's set up our own XOOPS server. In
order to run XOOPS, you need a MySQL server—I am running the
admittedly old version of 3.23.58 on my workstation—and a copy of
Apache (version 1 or 2) with PHP installed.

Installing XOOPS is one of the most impressive and painless software
installs I have done in a long time. I downloaded the code from
the XOOPS Web site (see the on-line Resources section) and opened up the .tar.gz file in a temporary directory. I
then copied the entire HTML subdirectory into my Apache content
root, as /usr/local/apache/html/xoops. Once I had done that, I was
able to access the XOOPS installer at the URL /xoops on my system.

The installer is fully Web-based and walks you through the process
slowly but surely. The most confusing part probably was the page on
which you need to enter the user name and password of a MySQL user who
is authorized to create a new database and tables. The installer
also could be a bit more verbose in its error messages at this initial
phase, given that many people installing XOOPS are unlikely to be
experienced Web/database programmers.

That said, the installation was fairly simple and painless. I
returned to the /xoops URL on my system and was greeted with a simple
introductory screen that invited me to log in. I logged in as the
site administrator, and although the main screen was relatively
blank, I was able to move quickly to the Administration menu on the
left side of the screen (Figure 1).

Figure 1.
The XOOPS site administration page is where you select the modules
you want to appear on your site.

Administering XOOPS is fairly straightforward, once you understand
that everything in XOOPS is a module. The first order of business for
most XOOPS administrators then is to install additional modules.
Go to the Administration menu and choose Modules. The top of the
screen lists the modules already installed, and the
bottom of the screen lists those available but uninistalled.

To install an available module, click on the appropriate icon
next to the module's name. After you
confirm your choice, you should see an indication of which tables are
being created in the MySQL database, what access permissions have been
added to the system and whether the module was installed correctly.
Assuming that it was, you can return to the Module Administration
page, where you should see the newly installed module at the top of the
screen rather than at the bottom.

The default layout of a XOOPS site is rather empty. To include
additional items on the home page, you must go to the Blocks
administrative page, which lists the content features each module
includes. The News module includes three blocks—bigstory,
topics and top. The main Blocks Administration menu lets the
site manager indicate which blocks are visible. But the real power
happens in the Edit menu associated with each block, allowing you to
indicate where on the screen the block should appear—on the side, in
the center or somewhere else entirely.

Figure 2. Create a unique site layout by positioning
blocks from the Blocks Administration menu.