Forum OpenACS Development: site template returns to default when creating new communities

I have realised the following: if you change the site template of your dotlrn installation (I followed the instructions given in this post), the main site template returns to default value when a new community is created.
I think the problem appears because of the following code:

parameter::set_from_package_key -package_key "acs-subsite" \
  	            -parameter "DefaultMaster" \
  	            -value "/packages/dotlrn/www/dotlrn-master-custom"

This code is in /openacs-4/packages/dotlrn/tcl/apm-callback-procs.tcl
Hi Luis,

I've tried to reproduce that behavior with no success. Which version of dotlrn are you using? and also, with which theme does it occur?

Hi Emmanuelle,

The code that is supposed to be wrong is in CVS since 3 months ago, so it's possible that you don't have latest version on your server. I've just installed all from CVS, using branch 5.2

I want to have Kelp theme. I can configure it with no problems, but when a new community is created, Sloan theme comes back. As said previously, I guess I know the exact code that produces the problem, but I do not want to change it due to I'm not sure about the purpose of this code.


I do have the last code from oacs-5-2 (we are working on releasing .LRN 2.2.1 alpha). Kelp theme is not supported for .LRN 2.2 but anyway I will have a look.

It does not matter. You should absolutely not rewrite the parameter for the site wide master just because a new community has been created. People have reasons to use a different site wide master.

This happend to one of our clients as well, we are just about to delete the code from the callback procs. This code has already been taken out for th 2.1 release when restarting the server was resetting the site-wide master template to the .LRN default template. Why got something like this back in ?

Dear Luis, I commented the code out and new communities could be created like a charm. As the code is in package_instantiate it will reset the parameter each time a new community is created. It would make more sense to have it in the package_install callback, but that's for the .LRN crowd to decide. For the time being, I made sure to comment this out 😊.

Alternatively you could always say that people using .LRN have to change the dotlrn-master-custom template, but why offer the DefaultMaster template then (can we hide a parameter if another package is installed ?).

I'm just starting to look at this ...

The first error is that the default master for .LRN should be set in the install.xml file, not the install callback. This provides an obvious place for people to change it with their own custom master.

Well the basic error is clear: this parameter should not be set every time a new dotLRN instance is instantiated.

I may be accidently responsible for that, I accepted code for site-templates into 2.2.0 without studying it closely. After I took a close look (and thanks for the excellent comments, guys) it was immediately obvious that his is very, very wrong.

It would be fine to set this parameter in an "after_install", since dotlrn is installed by default by the install.xml file and therefore the param is set before the user has the chance to set their custom template.

But ... install.xml is setting the default template for "/" to dotlrn-master, only to have the after_instantiate callback overwrite it.

Wrong, and silly, even if moved to an after_install callback.

The proper thing to do is ot edit the install.xml file.

In this way, a new install gets set to the correct default, communities do not overwrite the site master template, and if the user wants to change the configuration they change it in install.xml, where the configuration info for which packages to install etc is also kept.

One-stop configuration, in other words.

I am testing and committing this change this evening, and it will be in 2.2.1 alpha.

Of course if you do have a custom master template, and want to support switching master templates on a community or user bases, you probably want to be sure that your custom master template contains the functionality of dotlrn-master-custom.

If you don't care about that functionality I think (but do not know for certain) that your existing custom master templates for .LRN sites should work ...

Here is how I tested my change:

1. Installed
2. Verified that the acs-subsite master was dotlrn-master-custom
3. Changed it to dotlrn-master (which works fine for the default Sloan theme)
4. Created a community
5. Verified that the acs-subsite master was still dotlrn-master

So that should do it, right?

I want to release 2.2.1 alpha on Friday so speak up now if I have not fully understood the problem.