At the Forge

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.

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.

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.

Each XOOPS module packages together HTML, PHP and SQL into a defined list of directories that is consistent across modules. For example, you can always expect to find class definitions in the class directory, database definitions in the SQL directory, blocks in the blocks directory and images in the images directory. Configuration and version information is always in a xoops_version.php file in the module's root directory.

Installing a new module is as easy as downloading it and placing its top-level directory in the modules directory. So, if you download module foo from the Internet, and if your XOOPS directory is /usr/local/apache/html/xoops, you simply can move the foo directory to /usr/local/apache/html/xoops/modules. The next time you visit the Module Administration page, the module is there, ready for you to install and configure it.

One important issue the XOOPS developers have kept in mind is that of database upgrades. It is easy to imagine how the PHP and HTML portions of a XOOPS module would be upgraded. Upgrading a module that combines PHP with SQL is a tougher nut to crack, and it seems as though the XOOPS people have done an admirable job. The SQL directory in a XOOPS module may contain not only a mysql.sql file with MySQL definitions but also update files with ALTER TABLE commands that change the table definitions from one version to the next. Because each module's tables are insulated from the rest of the system, you should be able to upgrade XOOPS modules independently of one another and in nearly any order.

Now that we have gotten a taste of how to work with XOOPS modules, we are going to install the WeBLog module, written by Hiroyuki Sakai. This not only gives us a chance to download and install a third-party XOOPS module, but it also provides the functionality we originally were searching for, namely a Weblog system that is good for a community of users.

To install WeBLog, download the file from the main site (see Resources). As with most XOOPS modules, you should unpack it with tar zxf, and then copy or move the top-level weblog directory into your XOOPS modules directory. On my system, WeBLog was installed as /usr/local/apache/html/xoops/modules/weblog.

To install the module, simply go to the Module Administration page and click on install. You now can create and administer Weblogs of various sorts. The Module Administration page displays a new Weblog icon on the left side, allowing you to set permissions (which users are allowed to create and post to Weblogs), categories and even perform some basic database maintenance.

Now that you have made it possible to create a Weblog, return to your site's home page. You should see a WeBLog menu option on the left side of the screen with a collection of the most recent items from all of the Weblogs on the system. If this is your first time running the module, this page is mostly empty. You can create or modify your own Weblog by clicking on My WeBLog. Enter your posting in the appropriate parts of the HTML form, inserting at least 75 characters, unless you have changed this option in the Preferences Administration page. Once you have posted your new Weblog entry, you can view it by returning to the WeBLog menu item. That global viewing screen collects all of the individual Weblogs, but it also allows you to click on a user's name and view only his or her Weblog.

WeBLog provides a number of other useful features, ranging from RSS syndication to searchable and browseable archives, to the ability to comment on a posting. You also can ask to be notified when a new posting is added. Such notifications are placed in the XOOPS message system and are flagged on the main menu when you enter the site.

Figure 3. Success! With the site configured, watch the user blog entries and comments flow in.

If you want to create an on-line community of people with Weblogs, you could do much worse than XOOPS. It is supported by an active development community, and the WeBLog module appears to be stable and well maintained. Furthermore, the technology is simple and straightforward enough that those with Web/database experience should be able to modify and maintain the system on their own.

As I explored XOOPS, however, I could not help but compare it with OpenACS, another community-oriented Web system that has a Weblogs module. Is there any reason why someone would prefer to work with XOOPS rather than OpenACS, which arguably is technically superior?

As much as I love OpenACS, the answer is a firm yes. OpenACS is a great system when hard-core Web/database hackers are around, when you have root access to your own server and when you can turn the OpenACS toolkit into a workable customized solution for your needs. But many people and projects don't have the resources or the budget for such high-powered expertise; they are looking to accomplish things quickly and easily on a shared server that provides access to PHP and MySQL. For such people, XOOPS may be just the ticket. It lacks a number of features I would like to see, but it can be installed anywhere, maintained by the large community of PHP/MySQL programmers and administered by non-programmers with a minimum of training. It doesn't have many features I would expect in a more sophisticated system, such as Unicode support, multiple instances of a single package, content versioning and hierarchical groups. But it does do a good job for what it was intended to do, and the community of XOOPS users seems ready to help anyone who has issues and problems.

I find it hard to classify XOOPS as a content management system in the traditional sense, despite what the package maintainers claim. Yes, it allows you to post news articles and to have those approved by a site administrator before they go live. But I think XOOPS is better thought of as an easy-to-use community system that makes it simple to create Weblogs and other standardized content. For many people, that is more than enough, and the ease with which they can create relatively sophisticated sites outweighs the other considerations.

XOOPS is definitely not for everyone—the politics, the object-oriented code and the lack of certain features I consider vital make me think twice about recommending it. But I also have seen the time and effort it takes to get up to speed on such technologies as Zope and OpenACS, and the trade-off has not always been worthwhile. If you are an expert in PHP and MySQL, and you are looking to create a community site with good Weblog facilities, you might do well to consider XOOPS.

Resources for this article: /article/7500.