Forum OpenACS Q&A: Subsites with separate domain names - issues

Request notifications

(All comments below are in regards to 5.0.0.) I have a couple subsites sharing an OpenACS instance that are actually unrelated. The tree looks something like: +- (subsite)
(root)    |   -forums
          |   -blog
          |   -etp 
          |- (subsite)
          |   -forums, blog, etc
          |- (subsite)
              -blog, photoalbum, etc
Sites aren't accessed by the root domain name, although technically the user could get to the content by hittind, the expectation is that they're using the domain name.

Ok, so far so good. I can mount subsites, set up the host-node map, and get some packages working. However, I'm seeing some issues that make OpenACS less subsite-friendly than I'd like. (Some of this is also documented in bug #1447.) Here's a list. If there's an obvious great solution to some of these, I'd love to hear it :)

  • Notifications - notifications cannot be mounted in more than one place - doing so causes forums/ to error out (due to multiple nodes being returned). However, each subsite needs to have notifications mounted, to allow and visitors to use notifications. (See also bug #1453, where lars-blogger mounts notifications and causes forums to break on server reboot.) Additionally, it would be nice if notifications used the subsite domain instead of the main site domain when sending emails.
  • Context bar - The context bar by default goes back up the main site, although the content isn't even accessible to a user visiting through So my context bar looks like "Zebra" (with a link to slash) | Apple (which is actually /apple, but that resolves to, so it's ok) | Forums, for example. Preferred behavior would be to not show parts of the site map that are closer to the trunk than the point that points to. I need to try the suggestion in this thread, where Malte asks about something similar - Tom's suggestion may be just what I need.
  • General Comments - several packages need general comments. Fortunately, one can mount general comments in multiple places without (at least so far) any problem. However, GC is not subsite aware, and shows every comment on every subsite. As I am aiming for the illusion of 3 separate instances, this is undesirable.
  • Each subsite creates its own "Subsite Parties" group. (And Subsite Members, Subsite Administrators.) From admin/permissions, there's no indication which of the three "Subsite Parties" corresponds to the subsite that contains the package I'm actually modifying. Suggestion: Change generic names to include the subsite name. (This can be done after the fact with the groups UI, but it might be preferable to do it automatically - *if* the subsite name is known when the groups are set up.)
  • Admin links and documentation - an /acs-admin link is offered to a main site admin visiting a subsite, although doesn't work. (Subsite admins seem to be offered only an /admin link, which works fine.) Should things like /acs-admin, /api-doc, and /doc work from within any subsite/domain by default?

Posted by Don Baccus on
These are all great comments/bug reports.

In order ...

1. You need to customize the context bar yourself and I think this makes sense.  Because as a default I think treating an OpenACS site-with-subsites as something of an integrated whole  is correct.  We might want to parameterize the toolkit so you can install it in a "each subsite is its own world" mode.

2. Making general comments subsite aware should be easy, and it is possible Daveb has done so in his improved version which is in contrib.  This will eventually replace the existing general comments package but he needs to fix the gawdawful attachments package rewrite first.

3. Notifications is probably fairly easy to fix.

4. Yes, it would be good to customize subsite group names automatically.

5. Links to global admin doc and similar directories should probably be generated with a fully rooted URL rather than short-handed the way they are.

I don't have time to work on any of these issues myself at the moment, but am available to answer questions by e-mail...

Posted by Don Baccus on
Why not do these as separate OpenACS instances, though, if you really want to treat them as being separate?  The subsite mechanism wasn't really designed to support the "each subsite is a separate world" paradigm.

Are you just concerned about being able to efficiently share machine resources and want to run within a single AOLserver instance?  If so AOLserver's virtual server facility would do what you want, allowing you to define resource pools for virtual servers that can be shared or separate etc.

Posted by Cathy Sarisky on
Why not do these as separate OpenACS instances, though, if you really want to treat them as being separate? The subsite mechanism wasn't really designed to support the "each subsite is a separate world" paradigm.

True, but it isn't all that far off from being able to do it, either! :)

I haven't played with AOLserver 4 yet - if this turns out to be too much headache, I could certainly go that route. It seems like that would still be higher resource usage, no? Wouldn't each instance have its own loaded procs? (Caveat: I know nothing about AOLserver 4.)

I got the context bar working this afternoon. Tom's suggestion in the thread linked above was spot on.

Posted by Malte Sussdorff on
Before a lot of people go after this, what are the key benefits of having different sites as subsites of your site that you can not achieve with seperate OpenACS checkouts from your own CVS.

Things I can see:

- User has the same password across all sites and does not have to register more than once.
- You can aggregate statistics across all sites.
- You use one tablespace.

Things I can see that are not in favour:

- If a subsite becomes to large it is not easily possible to transfer it to it's own server.
- Not sure about the seperate access statistics and how they would work.
- Customizing the functionality on one subsite is not possible (easily)

Posted by Hérick Moniz on
For me the greater advantage of a subsite steading alone is being able to maintain a single source of code for many customers. This is particularly important when you do modifications to OpenACS that are not taken back into the main OpenACS repository.  That way if a customer points you to a bug, every customer get the benefice.

This will occur because it is not possible to have a tool kit that fills all the needs, and because it not easy to know how to modify a module so we could still sync it with the CVS tree.

The templateing system is a good way to allow modification of a module look but what if we like to modify a module behavior ?

For example, in my case I like to create a mechanism to control which user maybe register to a group. My first thinking will be to modify /acs-subsite/register but in doing so I will not be able to sync it with the main CVS tree...


Posted by Lars Pind on
Yes, the use case here is running an ASP service, where you really don't want to go through the trouble of maintaining and upgrading multiple code bases and DB's, if you can avoid it.

Here are some notes from a brainstorm I had with Branimir recently:

It's something worth thinking more about, and then once we do it, we do it right.


Posted by Cathy Sarisky on
One more addition.  Users accessing '' cannot edit their information.  The edit button doesn't put them into edit mode.  Forcing edit_p=1 causes ad_form to display the data for editing, but submitting the data bounces the user back to the edit page, without saving any data.  Blech.
Posted by Barry Books on
I wrote a bug about the edit_p problem. I think there is a redirect in the process that loses the form variable because the form is submitted with a POST and the redirect is a GET. The big question is what to do about it. The redirect could pick up the form variables and export them on the URL or the form could be changed to a get. There is also a function that builds the URL in the first place. It could be changed to return the correct URL in the first place.