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
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?
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.
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 ?
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 ?).
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.
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.
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 ...
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.