Forum OpenACS Q&A: Re: Don't understand "big picture" of what to do

Posted by Richard Hamilton on

Yes, that is correct.

An example of when OpenACS's subsite functionality can be useful would be as follows:

You are an international hotel chain with a corporate main website and a dedicated website for every hotel you own. Some of these use different languages, some use different character sets and all have their own sets of registered customers.

Any customer can potentially be a guest at any hotel, and whilst some employees may only need access rights within their own hotel website, many of the country and worldwide managers need to be able to access the website of several hotels or even all of them. The MD of the whole organisation needs access to everything.

In this situation, there are a number of ways that openacs can facilitate. Here is one:

You set up a domain name for your hotels group (let's say ''), and you set that up to resolve to your OpenACS 'Main' subsite. This becomes your central corporate website with shareholder info etc.

Because your hotels have fully delegated marketing, you now set up an individual subsite for each hotel, and delegate the admin rights to the individual employee at each hotel who is responsible for it.

The hotels can now operated independently, and you have centralised overall control (technical updates, new capabilities, admin, security, data, intellectual property, central marketing and access/control of customer database and lists).

Each of the subsites can be run as independently or non-independently as you wish. They can each have their own domain names, or operate as a url within the
domain. Alternatively you could set them up to be resolved as,

OpenACS is about flexibility and integration.

I hope this simplified example will help.

Have a look at the worldwide Greepeace website for an example.


Posted by sal berg on
Thanks, all of these answers definitely help.

I think the main problem is that the documentation doesn't really give the "big picture" (or at least I can't find it) because it's sort of "assumed knowledge" by the people who already use the system - it's already intuitive to them. But to an outsider first coming in, it's hard to get a grasp on what he is looking at.

For instance when I opened the product for the first time, I didn't know if this was a demo website I was supposed to modify for myself, an administration tool to administer developers who would be working on the system, or some other thing. It in fact looks like all of these things. I guess you would tell me that it in fact IS all of these things?

1. So... assuming I just want to build a single website for a single entity, not the complicated hotel example you gave, the recommended approach is to take the ACME "main site" and customize it and change it around to make it my own?

2. For my own website I will need to extend the "Users" database table I found to also include other information such as address, phone number, etc. Is the recommended approach to add another table with that information, and use a foreign key from the Users table? Easy enough, but in adding and removing users, I need some way to extend those already-existing functions. I believe I read that there were callbacks and such that could be used for this?

I really appreciate the help here. This community seems very friendly. This product is certainly powerful - probably the most advanced I've seen for this sort of thing. It's just a little rough around the edges as far as the documentation and what not. If I get to be good enough using this thing, I'll chip in with whatever help I can.

Posted by Torben Brosten on
An installation is capable of any purpose, demo, admin or developer tool etc.

The application code is in /packages

For upgrading purposes, it's best to think ahead. Put static files in /www/resources or somewhere in the /www file hierarchy and put new procedures etc in their own files. This way, when updating, you are not overwriting your customizations (as much).

A general rule for extending tables is to create your own tables and use a common reference from the existing one, such as object_id to join them via queries. This way, any modifications you make are unlikely to be affected by changes to the core system. There are advanced CMS db features available via the object database such as revisioning etc, but those features are not fault tolerant if used in a nonstandard way. It's best to have a test system running to implement changes you aren't sure about their impacts to the system. It's good experience to build the test site from a backup of the live site to verify your backup procedures work. Always make a backup before changes so you can revert if need be.


Posted by Brian Fenton on
Hi Sal

welcome to the community! Feel free to update the wiki with any info you think would be useful to other users.

Just re the extending of the users table, I believe (not 100% sure) there is a "Contacts" package that will do exactly what you need. See here

best wishes

Posted by sal berg on
Thanks Brian, I will check out the contacts package.

Still having a few problems understanding this. For instance, in trying to implement the functionality that I hope the contacts package will do for me, I created a subsite, which I then wanted to customize. My thinking was that sub-directories would be placed somewhere, and files copied there, which I could then modify in order to customize the subsite. Of course, this didn't happen (no sub-directory anywhere) so I was largely at a loss as to how to customize. I guess there is something fundamental I am failing to grasp.

Thanks again!

Posted by Torben Brosten on
Hi Sal,

For a basic site, the acs-subsite package is already mounted, so there's no need to create another. To add directories, use your favorite *nix mkdir command in openacs-4/www/. or install/mount the file-storage package to have files dynamically manage via web.