Chapter 1. General principles

Table of Contents

1.1. The XOOPS core
1.2. Modules
1.3. Blocks
1.4. Users and groups
1.5. Content
1.6. Language files
1.7. Themes and templates

XOOPS is at once a software package, a network of Web sites and a very friendly and supportive community spread all over the world. The tie that binds together software, sites and community is the Web, the graphical face of the Internet.

To learn about the sites all you need to do is to point your browser to any of the XOOPS sites and there you’ll feel the warmth and strength of the community. To learn about the software, your best bet is to download the latest package and to begin playing with it. What? No documentation? Yes, we know (remember? We’ve also been there). XOOPS suffers from a lack of enough good documentation, and though this has been an effective incentive for many a webmaster, for many more it has been a turnoff.

That’s part of the reasons behind this manual. It’s part of a really much wider and deeper collective effort that goes under the moniker “XOOPS Documentation Project” and that is being tackled slowly but surely by a team of dedicated xoopsers (or xoopers, as some others call XOOPS fans: xoopies?).

So this manual will explain, with enough detail to also serve as a reference guide, the main workings of XOOPS, the software. Since there’s already another document called “XOOPS Installation Guide (XU-002)”, we’ll assume in this document that you’ve already installed your XOOPS package and have now a live XOOPS site. We’ll deal here with that oh-so-very-common-question that comes up once an again: what do I do after I install my XOOPS?

Ok. We’re ready to begin. If you’re set, let’s proceed at the beginning.

XOOPS is a tool to manage dynamic Web sites. This simple definition may serve you to have an initial grasp of the usefulness of this singular package. But it’s so general that it’s almost as saying nothing. Let’s try again. XOOPS is an open source set of scripts written in PHP that, when installed in an Internet host that has support for PHP, a web server such as Apache, and a MySQL database manager, allows the easy creation of dynamic, complex and content-rich Web sites, from personal weblogs all the way up to corporate portals.

XOOPS means eXtensible Object Oriented Portal System, and even though some call it ex-oh-oh-pi-es, the standard pronunciation of XOOPS is more like “zoops

Derived from other open source projects (XOOPS is a descendant of the venerable PHPNuke, through a branch called myPHPNuke. A good part of the package was completely rewritten, although there are inside the scripts pieces of old code that show their age when compared with the most recent parts.

As its ancestors, XOOPS is strongly oriented towards the construction of community sites. But it is flexible enough to serve as a single-webmaster site (a blog, for instance) and as an enterprise content-oriented portal.

In this introductory chapter, we’ll take a quick look at some of XOOPS main features. In later chapters we’ll see in detail how is it that XOOPS does its magic.

1.1. The XOOPS core

An easy way to think about XOOPS is to think of it as a commercial mall. In a mall, many different kinds of stores and businesses and services are lodged under the same roof, each with its own personality yet within the general frame of the mall’s design. To the outside world, the mall has huge windows that show some of the merchandise that can be found in the inside. To the individual store owners, the mall is like a turtle’s hull: it provides not only the physical space, but also a lot of basic services: electricity, water, air conditioning, some marketing, security, parking lot… the list goes on.

New let’s take a look at XOOPS under this metaphor. XOOPS is the mall; it’s the general hull that provides services to its tenants. Have you seen a mall with no stores? There’s no reason to go there at all; the same is true about XOOPS. If you see just the hull, there are not many reasons to visit the site.

Modules are this mall’s tenants. If XOOPS, the mall, is a bunch of scripts that provide the general framework of a dynamic Web site, then modules, the tenants, are smaller packages made up of scripts that provide a particular content offer to the site’s visitor. One module provides news; another, a picture gallery; another one, a discussion forum; yet one more, an area to download files. All these offer reasons for users to visit the site. And the general idea, as in a physical mall, is that the result is greater than the arithmetic sum of the parts.

In what other way are modules like the mall’s tenants? Well, to get installed in the site they must follow some rules. Some of them are coding rules: if a module doesn’t have a xoops_version.php file, XOOPS doesn’t even know it’s there. If the module doesn’t take advantage of the mall’s services, it would need a lot of code to accomplish common things. XOOPS, the mall, provides the modules things like user management, security, structure, functions and classes, and so on. There are also some presentation rules. Just as a mall’s store has to follow some of the building codes, a XOOPS module has to follow rules to create blocks and rules to present content using the Smarty template engine.

In the outer wall, a mall showcases the stores within. In its homepage, a XOOPS site showcases the modules within. The mall does it with shop windows; XOOPS does it with blocks. The mall administrator decides what merchandise to highlight in the shop windows. The equivalent, which is the XOOPS webmaster, decides what blocks to highlight in the home page.

Of course, a metaphor can only go so far before it gets s funny. Let’s not pursue this any more, or we’d need to explain that XOOPS the mall has some advantages over the real mall: it can switch between personalities to have a different look (using themes, called skins in other contexts); it can easily change the structure of the home page, the labels of the modules, etc. But the general idea is useful, as it separates clearly three basic components of the XOOPS system:

  • The core”, where the general functionalities of the site reside. The core also provides some extra features such as the notification options, that let users be informed about specific changes in a module’s content; the commenting system, that lets users leave on the site comments about specific content items; and the installation routine that makes sure a module complies with the elementary rules to be automatically incorporated to the site.

  • The modules”, which hold the actual content of the site, and which can be as simple as a block that displays a daily quote, or as complex as a full e-commerce package that allows the webmaster to make live commercial transactions on the Web.

  • The blocks”, which are “windows” to a module’s full content, though some blocks have an existence of their own.

The XOOPS core is actually a package of interrelated PHP files that in an appropriate setting provide the functions needed to operate the website. Many of these functions are completely hidden from the end user, and are only used by modules in order to work properly. Many more are visible to the user and to the webmaster through the System module, which gives the user some essential functions such as the login procedure, the main menu and the user menu, a hint of who’s online, access to the search function, and some theme-switching capability, to name a few. The core and the System module also give the webmaster the admin area, the place where most of the control over the site happens.

To sum up, then, the XOOPS core comprises a lot of power hidden under calls to classes or functions, provides the functional framework, the templating engine, the handling of languages and much more. It accomplishes part this through the System module, which is the only one installed in a default XOOPS package, as it’s through this module that the webmaster decides what other modules will be part of the live site.