At the Forge - XOOPS

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

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.

WeBLog

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.

Should You Use XOOPS?

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.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix