Forum .LRN Q&A: How to run multiple parallel .LRN instances
has someone experience with running multiple instances of .LRN on a single machine but with the same user base. As far as I can see the different schools at our university prefer to have their own designs thus a single installation won't work.
Do I have to copy an install.xml file in the root directory of openacs with multiple application elements:
<application name="school1" pretty-name="School 1" home="http://openacs.org/projects/dotlrn">
<mount package="dotlrn" mount-point="school1" instance-name="school1"/>
<set-parameter url="/school1" name="DefaultMaster" value="/packages/dotlrn/www/school1-master"/>
<set-parameter package="acs-kernel" name="IndexRedirectUrl" value="/school1/index"/>
<set-parameter package="acs-kernel" name="CommunityMemberURL" value="/school1/community-member"/>
<set-parameter package="acs-kernel" name="CommunityMemberAdminURL" value="/school1/admin/user"/>
<set-parameter package="new-portal" name="default_theme_name" value="#new-portal.sloan_theme_name#"/>
<application name="school2" pretty-name="School 2" home="http://openacs.org/projects/dotlrn">
I appreaciate any help,
I could be wrong, but I don't think this will work.
My experience has been to set up different AOL server instances running on different ports, and point each instance to the same database (in the <instance>.tcl file).
If the only reason to have multiple instances is to have different designs, there is a way of doing this, but it is a bit of a hack and will affect performance because it involves effectively turning off the template caching.
It does work, though, and you can apply a different master templates to each community/subgroup and the way I implemented it, you can choose whether child subgroups inherit their parent's template or not.
If you want more details, let me know - although I hope I am wrong and there is another way :)
where do I create new subsites? The Site-Map does not allow me to make several copies of the default dotLRN instance on the same level so that I could have something like this:
But I guess you mean something else. I don't want two independent instances just multiple for each school with different templates.
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.
1. How to achieve different designs for different institutions that have the same user base.
2. How to organize the communities and courses separately depending on the school.
3. How to merge that information back for a student who is a subscriber within multiple institutions. I don't think that is possible.
Although it would be possible (as far as I know) to run multiple sites that use the same data, it still wouldn't really do what you want, because all of a student's courses would be visible in each one (meaning that in each site, most of the courses would look "wrong"). And the more they looked like different sites, the more you would have users who were surprised that a customization they made on one site showed up on the others.
What is really needed is the ability to set theme by class/community, but that feature doesn't currently exist.
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.
Would it be possible with your implementation to install multiple dotLRN instances with different look but same user base? If yes. I really would like to learn how you did that. But as I said (and I think Janine meant the same) it makes only sense if courses/communities are presented seperately on different instances while the user still has an aggregated view on all his/her subscriptions under My Space.
That mean each community or subgroup can have it's own look that extends beyond the community portal and into the package pages (e.g. forums). The user portal would still use the master-template specified by the ACS main site.
So the question that arises is this:
If a user is a member of 2 communities, each with a different master-template, does it matter that when they go to Community A, the forums-portlet and forums pages look different to those in Community B?
The answer depends on several factors: how different are the designs? Are people expecting a different look? Would it surprise them that the fishing club's pages look different to the chess club's pages?
One thing to consider is the use of closed communities and limited users.
If you wanted to host seperate communities/groups with a discreet set of users, you could set them up as limited users (can't see other communities, no personal portal if member of one community only).
The other thing to consider is design. You could make the design for one community very, very different to that for another; but in practise you will be constrained by the structure of the .LRN portals, portlets and pages in general. So although the package pages could look very different, I don't think they would be so different as to make it confusing for users to understand.
Just a few thoughts :)
you are right. Regardless of the performance issue of your solution the result you achieved is what I am looking for. The problem is that while all schools want to share a similar site structure they want to distinguish themselves with different look (different header logo, slightly different color sheme and portlet design). While pages look similar in their structure that user knows that he changed from business school content to computer science to law school...which I think is even a helpful orientation as long as the site structure and the overall design is not to different.