Forum .LRN Q&A: Re: How to run multiple parallel .LRN instances

Collapse
Posted by Joel Aufrecht on
Install.xml is using during site installation to determine which packages to install initially.  It's not touched after that.  If you want several different "sites" that share a common user database, use subsites.  Create a new subsite for each different department, and use the features of acs-templating (modifying the default templates in each subsite directory) to give them unique appearances.  If you want to run two different, isolated instances on the same computer, you need a separate OpenACS instance (ie, directory tree, config.tcl, database) for each.  You can then give each one a unique IP, or have them share an IP and use different ports, and direct incoming traffic with any of several different virtual hosting schemes.
Collapse
Posted by Raad Al-Rawi on
Joel

You're absolutely right for a plain OpenACS solution, but I don't believe you can use subsites with .LRN to achieve this.

I think the only way is to run multiple instances of .LRN (according to how many different designs you want to support) or to hack the system and pull in different master templates/css files/whatever.

<Raad>

Collapse
Posted by Raad Al-Rawi on
Nima - you are right in stating the problems that exist should subsites work, however, I don't think they can in any event.

Janine - I missed the obvious! Different instances would present the same communities with different presentation, so that would not be much use unless you started a very messy filtering process - I don't think I'll go there!!
You mention themes, but I guess you mean designs as opposed to the actual .LRN themes, as they only go a little way to providing a custom look.

If people are interested in our solution, I'll gladly provide details. It's not ideal for 2 reasons:

- It involves a change to template_tag in the templating handler, which seems fairly core stuff
- The templating cache has to be refreshed constantly because I could not find another way around a problem where the master template would be cached from page to page, even if it had changed. Obviously this change is detremental to performance, although I'm not certain to what degree.

The second issue is probably resolvable if someone with more experience looked at what was going on - in the end I got it to work and we are living with the performance hit.
The first issue is only significant if this was a feature people wanted in core .LRN, so I guess it would be down to whether this was put forward as a TIP.

<Raad>