At the Forge - XOOPS
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.
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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development